luaduck wrote:

I've also gzipped all of the command dumps here: http://ttd.duck.me.uk/files/dumps.tar.gz (warning 320mb file) - there's a few at the beginning of the archive that were before that savegame was taken, but I've included them because lazy.

This comment was imported from FlySpray: https://bugs.openttd.org/task/6130#comment13551

planetmaker wrote:

1338.sav seems to be the correct savegame. It's loaded in line 1050 of the commands-out.log and a desync found (much) later in the commands-out.log in line 20224.

This comment was imported from FlySpray: https://bugs.openttd.org/task/6130#comment13552

Marctraider wrote:

Any news on this?

This comment was imported from FlySpray: https://bugs.openttd.org/task/6130#comment13601

frosch wrote:

The log files gave no hint on what could have happened. The desync was not reproducible from the logs.

Also one of the desyncing clients joined just at about the server start, so it is very unlikely that it is caused by incorrect savegame or cache handling.

Only options left are:
* The client machine is legitimately broken, as it corrupt memory. But if multiple clients desynced, this is unlikely.
* The desync is caused by different CPU or OS architectures. E.g. 32bit client vs. 64bit server. Windows client vs. Linux server. Big endian client vs. little endian server.

Possibly the replay could be replayed on a 32bit machine. But it would help if someone would identify some pattern in the desyncing: I.e. are always the same people desyncing. What is different about their machines?

This comment was imported from FlySpray: https://bugs.openttd.org/task/6130#comment13602

frosch closed the ticket.

Reason for closing: Unreproducible

possibly #6329

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