Ok, so I've found another bug (or, at least, an undesirable patch behavior). Let me precise I'm still using version 0.8 .
Background: my set uses the "property" callback (CB36) a lot, as well as the "recoloring" callback, in order to change properties (capacity, length, weight etc), recoloring scheme, and graphics of the wagons, according to the engine they're attached to.
It looks like this structure is not very well compatible with this otherwise wonderful patch.
My actions to reproduce this bug, and its effects, are the following:
I create a consist pulled by a specific steamer, with three different types of wagons (a mail van, a mixed mail/passenger coach, and a passenger coach).
When pulled by this steamer, the first vehicle I mentioned will have its length shrunk from 4/8 to 3/8; the second vehicle, which is actually articulated and made of 3 parts, will be stretched from 4/8 to 6/8 length. All the vehicles will see their properties slightly change, in terms of capacity for example, as well as their graphics and recoloring (they will be recolored in brown, while a default wagon is recolored in green).
This is the initial stage, before reversing:
File comment: Normal train running forward
bug 20180718 0.png [ 17.64 KiB | Viewed 901 times ]
When this consist reaches the end of line, the patch reverses it. However, perhaps due to the changes in length occurred through CB36, I'm getting this error message (I actually get it twice, most likely because there are two vehicles -the mail van and the mixed coach- whose lengths changed):
File comment: Error messages...
bug 20180718 1.png [ 20.08 KiB | Viewed 901 times ]
Once the consist runs in reverse, all the changes to the coaches I made through CB36 are lost! Each coach reverts back to its default state. Even when the train reaches the depot, the in-depot view remains wrong.
File comment: Consist after reversing...
bug 20180718 2.png [ 12.18 KiB | Viewed 901 times ]
It looks like that, when reversing a train, this patch flips all vehicles, so that the original engine is not the first vehicle in the consist anymore; therefore, CB36 and the other callbacks will lose their hook (I technically use the "engine()" syntax in m4nfo to link to the engine).
This is the same problem I saw when decoupling. Perhaps we should find a way for each vehicle to keep its characteristics as of when it left the depot, even after reversing or decoupling. I know that probably, if I avoided using CB36 like this, the issues would go away, but that's not really realistic (I couldn't achieve half of what I want without it).
Karn, please feel free to ask me any further questions if you need extra info. I could even send you the GRF I used for this.