Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CB32 is broken #5775

Closed
DorpsGek opened this issue Oct 3, 2013 · 6 comments
Closed

CB32 is broken #5775

DorpsGek opened this issue Oct 3, 2013 · 6 comments
Labels
component: NewGRF This issue is related to NewGRFs flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

DorpsGek commented Oct 3, 2013

mb opened the ticket and wrote:

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
.tt-forums.net/viewtopic.php?f=68&t=68737&sid=2b951b4c8cb163b4645cebf94511904b).

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

Test newGRF and savegame attached.

Attachments

Reported version: trunk
Operating system: All


This issue was imported from FlySpray: https://bugs.openttd.org/task/5775
@DorpsGek
Copy link
Member Author

DorpsGek commented Nov 3, 2013

Alberth wrote:

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.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/5775#comment12715

@DorpsGek
Copy link
Member Author

DorpsGek commented Nov 3, 2013

Snail_ wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5775#comment12716

@DorpsGek
Copy link
Member Author

frosch wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5775#comment12755

@DorpsGek
Copy link
Member Author

frosch closed the ticket.

Reason for closing: Bug in NewGRF


This comment was imported from FlySpray: https://bugs.openttd.org/task/5775

@DorpsGek
Copy link
Member Author

Snail_ wrote:

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)?


This comment was imported from FlySpray: https://bugs.openttd.org/task/5775#comment12756

@DorpsGek
Copy link
Member Author

frosch wrote:

Updating the recolouring on reversal should be restored in r26026.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5775#comment12792

@DorpsGek DorpsGek added flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) component: NewGRF This issue is related to NewGRFs bug labels Apr 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: NewGRF This issue is related to NewGRFs flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Development

No branches or pull requests

1 participant