Strange behaviour possibly causing desync

[Matthew]

Steps to reproduce

1. Start Simutrans-Extended #210bfad (current nightly) with debug 2 turned on (and log if not using a terminal) and connect to Bridgewater-Brunel online.
2. Jump to (805,1509). Open the info window for the elevated canal and observe that the canal max speed is 9 km/h.

3. Now open the info window for the elevated canal at (805,1510) and observe that the canal max speed is 1 km/h, because "The speed is limited on account of being in a built-up area".

4. Opening further info windows shows that the max speed remains 1 km/h on the stretch of the canal up to (805,1516) inclusive and then returns to 9 km/h.
5. Open the minimap, turn on "City limits", and observe that the canal is not within a built-up area. (The roads to the north, south, east and west of these tiles are not within city limits either, so I don't think it's one of those very narrow cities we sometimes see). And also, it's a canal.
6. Wait until you desync (this might take hours so see step 9).
7. Without unpausing, return to the terminal or open the log and examine the checklists. Compare the checklists as described here, except that you should not perform them on the first two debug sums, but on the second and third debug sums. See the example here:

8. The result of the debug sum calculation is expected to match the ID of a convoy that is 2 tiles from the portion the canal with the unusual speed limit and moving towards it. (Maybe this is a sheer coincidence, but I've observed it twice now with different convoys).
9. The canal is used by BR Southern Region's "Resgere - Glmnydd Fuel Oil" line, which is owned by SuperTimo. If you have his co-operation or can override his password, then you might be able to get a desync more quickly by sending those convoys along the canal. But I haven't asked him to try that, because I don't want to risk desyncing other players or the server getting stuck.

Notes

I discovered this by accident when trying to testing spme modifications to the client UI to make reporting such desyncs more user-friendly. It's possible that the desync was caused by my changes, but I was able to reproduce it exactly with the official client downloaded from B-B.

I have some further ideas about possible causes and context but I know that is not always helpful, so please let me know if you would like me to say more.

[Matthew]

As this is still causing desyncs like clockwork, I have put a copy of a save game containing the bugged canal here. It seems reasonable to encourage the player to replace the canal on B-B.

[jamespetts]

I have been doing some extensive testing on this this evening. I have narrowed down the problem to code that I did not write and do not know well enough to fix within a reasonable time for the present. The problem appears to be that, in some cases, when loading a game, ways on piers falsely record having a gradient. 

Certain ways, in this pakset, always canals, which have a different speed limit depend on the gradient (to simulate locks) will thus load incorrectly in these cases with the gradient restricted speed limit rather than the correct speed limit.

This appears to happen in particular after initially loading demo.sve, so it is very likely that this problem is one and the same as the problem in which loading demo.sve before loading an online game will cause a loss of synchronisation after loading the online game.

Unfortunately, because I do not know the code for the piers, it would probably take me many consecutive days of intensive work to be able to learn that code and fix this problem, so this is not something that I can do at present.

If anyone else would like to look into this, however, that would be much appreciated.

[neroden]

Hmmmm.  I want to take a good look at all the speed limit code and clean it all up.  A problem for another year (SIGH)

FWIW, the pier code is pretty elegant compared to most of the code in simutrans (kudos to PJ Mack)