SmatZ wrote:

Solutions I could come with:

Situation in TTDPatch (r1962): it seems to ignore different vehicle length after reversing.
This is not a solution for OTTD, because it could be a reason for desyncs (vehicle length affects speed in curves, and player who joined later would have different cached value stored).

A bit hacky solution would be to always clear VRF_TOGGLE_REVERSE before updating cached vehicle length.

Trying to solve this by making train longer would be problematic. There can be 100 wagons of length 5 in one direction and 8 in another... and it could happen that the track is too short for that long train. So a test run would be needed before the actual reversing if there is enough space... probably by calling TrainController() for to-be-first vehicle (with possible problems like Random() calls in pathfinder, VehicleEnterTile(), signal state changes, ...) or by having another function to do the job. Code complexity would grow for little effect (is it realistic to have train twice as long after reversing anyway?) and possible further bugs could be introduced.

It is possible to simply check if length of any wagon didn't change after reversing and if it does, crash the game (probably with usererror() to give an explanation). However, it could be misused in network games with canset.

Do the check before reversing by setting VRF_TOGGLE_REVERSE and update caches (by TrainConsisChanged(), or simply the vehicle length callback if available). I am in favour of this solution.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2150#comment4487

SmatZ wrote:

What the specs say:

http://wiki.ttdpatch.net/tiki-index.php?page=Callbacks# Wagon_length_callback_11_

"This callback is used instead of property 21 whenever the train leaves a depot or is displayed inside a depot. If the callback fails, the value of property 21 is used instead."

So there should be no point in changing vehicle length if not inside a depot (or is leaving a depot).

This comment was imported from FlySpray: https://bugs.openttd.org/task/2150#comment4488

matthijs wrote:

16:30:09 < blathijs> I would be in favour of option # 1
16:30:35 < blathijs> Just give a message that a GRF is faulty (can we point out which GRF?) and that desyncs might occur
16:30:51 < blathijs> and ignore desync reports from people running Canset until it is fixed
16:42:22 < SmatZ> people may be annyoned by those messages
16:45:18 < blathijs> Yup, which is a good thing IMHO
16:45:37 < blathijs> That will stop people from playing with broken GRFs
16:46:26 < blathijs> but, to be a bit more reasonable, you might want to keep a "broken" bit for every GRF, and only warn once

This comment was imported from FlySpray: https://bugs.openttd.org/task/2150#comment4489

SmatZ wrote:

This GRF crashes TTDP r1962, too. But only when the Train details window is open.

Attachments

• SCR2.png (52.89 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2150#comment4494

SmatZ closed the ticket.

Reason for closing: Fixed

In r13816. OTTD will now give a warning about such behaviour.

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