FS#5775 - CB32 is broken

Attached to Project: OpenTTD
Opened by Michael Blunck (mb) - Thursday, 03 October 2013, 13:59 GMT
Last edited by frosch (frosch) - Wednesday, 13 November 2013, 14:46 GMT
Type Bug
Category NewGRF
Status Closed
Assigned To No-one
Operating System All
Severity High
Priority Normal
Reported Version trunk
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
  • Michael Blunck (mb) (2013-10-13)
  • Jacopo (Snail_) (2013-10-05)
Private No


In r25806 (and reportedly already in r25755), CB32 is broken.

It did work according to the specs still in 1.3.2 (stable), but in the latest series of nightlies bit1 is triggered for all the vehicles on the very same day (see http://www

Since 1.3.2 (r25632) there were two suspicious commits dealing with CB32, namely r25744 and r25695.

Test newGRF and savegame attached.
This task depends upon

Closed by  frosch (frosch)
Wednesday, 13 November 2013, 14:46 GMT
Reason for closing:  Bug in NewGRF
Comment by Alberth (Alberth) - Sunday, 03 November 2013, 19:45 GMT
Tested with r25937, starting from your recolour3.sav
I bought the 2nd train a few days later, and they nicely change colour after each other, see the attached image.
Also added my save for reference.

Since the global day counter is used as base modulo 32, if you buy vehicles at a multiple of 32 days apart, the moment of change will be the same.
In particular, vehicles bought will have the same day counter. (EDIT: "vehicles bought at the same day" is what I wanted to write there)

In normal play, users will buy vehicles at an evenly distributed modulo count, which is what the comment in the newgrf spec is about.
Comment by Jacopo (Snail_) - Sunday, 03 November 2013, 20:10 GMT
To Michael's point, all the wagons in a consist will change color according to when CB32 is triggered for *the engine*. Instead, every single wagon in the consist should change its color independently, based only on its own date of built (not the date of built of the engine).

In the stable version (1.3.2), each wagon used to change color independently, as I described: instead, Alberth's example, when all wagons in the same consist change their color simultaneously, is a clear explanation of why CB32 is broken. Could you please fix it so that each wagon changes color independently?

- EDIT - To test this, please form a consist in which the engine and the wagons are built in different days. In the stable version, each wagon will change its color according to its own date of built, so their colors will vary in the same consist: in the nightly, all the wagons will simultaneously change color, whenever the engine's CB32 is triggered.
Comment by frosch (frosch) - Wednesday, 13 November 2013, 14:46 GMT
I took a look at the test NewGRF above:
The recolour callback returns a recolouring depending on the duration since the last service (current-date minus last-service-date).

I believe you are misinterpreting the meaning of callback 32. It says, that returning 2 will update the recolouring.
The reverse of that statement is not true: The recolouring is not only updated when CB 32 returns 2.

In fact the recolouring is updated due to numerous other triggers (rearraging the consist, changing railtype, recently also when loading etc). In fact OTTD is free to update the recolouring whenever it likes, as long as it also does it when callback 32 triggers. If the colouring of vehicle shall not change, then the result of CB 2D must not change. CB 32 does not matter at all, it is only one trigger of many.
Comment by Jacopo (Snail_) - Wednesday, 13 November 2013, 15:14 GMT
Ok. Then how can you explain the different behavior between OTTD 1.3.2 (wagons changing independently) and the nightly (wagons all changing at once)?
Comment by frosch (frosch) - Sunday, 17 November 2013, 16:03 GMT
Updating the recolouring on reversal should be restored in r26026.