Changing graphics over time [OpenTTD vs. TTDPatch]

[Uwe]

Hi,

I just stumbled across the following problem: For an articulated tram, I want to provide two different sets of sprites to reflect the modernization that the model has been going through. To simulate that, I want to switch from the "old" sprites to the "new" ones at a certain time. Since this should only happen at a depot (no tram has ever been magically reconstructed in the middle of town), I cannot use the current date as a decision criterion. Instead, I opted for the date of last service (var 92 according to the vehicle structure). This works fine in TTDPatch, the vehicle enters a depot for service and the sprites are switched correctly. However, in OpenTTD only the very first vehicle of the consist is updated. It seems the value of var 92 is only correct for that first vehicle. Is this intended or is this a bug that should be fixed?

Regards,
Uwe

[Eddi]

sounds like a bug to me.

and as i said previously, bugs go to bugs.openttd.org

[andythenorth]

I just stumbled across the following problem: For an articulated tram, I want to provide two different sets of sprites to reflect the modernization that the model has been going through.

Have a look at my attached code for HEQS, specifically the bulldozers. They don't do *exactly* what you specify, but similar: the lead vehicle has different graphics depending on year built (or replaced), and uses different trailers according to the same date criteria.

Specifically look around sprites 1315 and 1320. Code is documented, but any queries, I'll see if I can help.

cheers,

Andy

[Uwe]

Well, with some further tests I can now state that up to TTDPatch r2068 it works the way I want it to, that is, the graphics are updated for the whole consist. r2069 and newer show the same behaviour as OpenTTD. Which leads me to the question whether or not the behaviour in the older Patch versions was actually correct...

[frosch]

IMO it is correct, that only the first vehicle is serviced, and not articulated parts.

However, using varaction2 type 0x86 should solve your problem, doesn't it?

Btw. I guess 80+x variables not explicitly mentioned in the specs will always have some implementation-specific touch, which also might change over time.

[Uwe]

@frosch: You're right, using varaction 02 type 86 solves my problem just fine. So it was an error in the old version of the Patch that started the confusion all along. Sorry for that.