The problem: I always get desync immediately the first time I try to join the server. This means I need to transfer and load the game twice to get properly connected to the server.
I setup a server on localhost and test this issue. The game's behaviour is different from connecting to bridgewater-brunnel server. When connecting to the localhost server for the first time, the game is paused and frozen (occasionally the game will recover from this state and keep on running, but in most cases it just seems to be stuck). I load a save at this time and connect to the local server again, and then everything seems to be fine.
Detail Later...
The test environment setup:
The testing platform is Gentoo Linux, but I guess it could apply to other linux distros as well.
Obtain two copies of simutrans-extended source code at simutrans-extended and simutrans-extended_server respectively.
The client is built by cmake and installed to location. Suppose the starting working directory is <prefix>:
cd simutrans-extended
mkdir build
cmake .. -DCMAKE_BUILE_TYPE=Release -DCMAKE_INSTALL_PREFIX=<prefix>/simutrans-extended-install
make -j8
make install
Then change to the client install to get the pak:
cd <prefix>/simutrans-extended-install
./get_pak.sh # then select pak128-britain-ex and install
The client is launched with the following command:
./simutrans-extended -use_workdir -singleuser
The server is built by makefile.
cd simutrans-extended_server
cp config.template config.default
# edit config.default, with backend posix, color depth 0 and linux os
# also turn on optimize
make -j8
The server is run within the source code
cd simutrans
ln -s <prefix>/simutrans-extended-install/simutrans/pak128.britain-ex-nightly
../build/default/simutrans-extended -use_workdir -singleuser -objects ./pak128.britain-ex-nightly -log 1 -debug 2 -load server-test -server 20001 -server_name DesyncTestServerPleaseIgnore
I test with this 2 save games on my local machine. The first one is generated and the second one is saved from the b-b server on 2023-01-11 (In game date: 1791 Feb). But I have trouble including these files in forum post...
Also this is not a issue out recently, it has been here for a while. At least when I host my own simutrans-extended server I have similar immediate-desync issues. Back then it is not too annoying as I transfering that game twice is not too much burden for me. But it is quite frustrating for the b-b server considering its map size...
Thank you for the report. I have also noticed this, albeit my experience of it is that it is inconsistent in whether or not it occurs on the Bridgewater-Brunel server. Unfortunately, debugging loss of synchronisation errors is extremely difficult and can sometimes take hundreds of hours of intensive work to track down a fault. It is unlikely that I will have time to do this for an extremely long time unless the issue is narrowed down significantly.
If anyone could assist in narrowing down this issue, that would very much be appreciated. On the face of it, it appears as though the issue may be related to what data are transmitted in the saved game as distinct from what data are retained locally, although this is uncertain.
Thanks for the reply.
I might not understand what this sentence means (I am not good at English):
QuoteI have also noticed this, albeit my experience of it is that it is inconsistent in whether or not it occurs on the Bridgewater-Brunel server.
It will be nice if further information on the
inconsistency could be explained.
For me this always happens when connect to the server when I have a different map loaded locally (usually demo.sve)
That means if I launch simutrans and it opens demo sve, then I will desync immediately after connecting to BB from there.
If the bb savegame is loaded locally, then I won't desync immediately.
I assume this might be related to simuconf initialisation, where are few settings depend on other settings.
It might be that dependent variables are initialised after their first use to initialise another variable.
But this is purely an idea where I'd start searching. It might be an entirely different issue.
Quote from: TransshipmentEnvoy on January 13, 2023, 09:57:51 AMThanks for the reply.
I might not understand what this sentence means (I am not good at English):
It will be nice if further information on the inconsistency could be explained.
All that I am able to recall at present is that it occurs sometimes and not others. However, Sirius's observation in the following post is interesting. I will take particular note of what saved game is running when I join the server to see whether this makes a difference, and I should urge others to do so, too, and post the results here. If we can narrow this down significantly, it may be possible to fix this without massive amounts of work.
https://forum.simutrans.com/index.php/topic,21444.msg199254.html#msg199254
I wonder if this issue is of the same kind.
At least in my environment this has not been resolved. But dysync does not occur. It just keeps time suspended.
Quote from: [C] Ranran on January 13, 2023, 11:07:46 PMhttps://forum.simutrans.com/index.php/topic,21444.msg199254.html#msg199254
I wonder if this issue is of the same kind.
At least in my environment this has not been resolved. But dysync does not occur. It just keeps time suspended.
Thank you for linking this related issue!
Actually I think it is rather unclear what is the exact relation between the time suspension and the desyncs. However I still think they should be related because they both happen when trying to join servers.
Quote from: jamespetts on January 13, 2023, 03:44:40 PMAll that I am able to recall at present is that it occurs sometimes and not others.
Hope this bug is not related to concurrency and threads...
Actually, today I make 10 attempts in my localhost server. Out of 10 I have one time that the time do not suspend and the game goes on normally.
That reminds me of something:
- Start the client. The little default map is loaded.
- Accidentally join the Stevenson-something server b/c it's late and you click the wrong line
- Desynch immediately
- Join the BB server
- Voilà. No desynch. Works pretty reliably for me.
Quote from: zook2 on January 14, 2023, 12:56:44 PMThat reminds me of something:
- Start the client. The little default map is loaded.
- Accidentally join the Stevenson-something server b/c it's late and you click the wrong line
- Desynch immediately
- Join the BB server
- Voilà. No desynch. Works pretty reliably for me.
Actually you don't need to join another server. Just load some local save (do not include the demo.sve from the pakset) and then join the B-B server, and things seem to be working fine.
Quote from: Sirius on January 13, 2023, 12:40:36 PMFor me this always happens when connect to the server when I have a different map loaded locally (usually demo.sve)
That means if I launch simutrans and it opens demo sve, then I will desync immediately after connecting to BB from there.
If the bb savegame is loaded locally, then I won't desync immediately.
This exactly reproduces my experience on TSE's server. I always loaded an old TSE save locally before joining to avoid this problem.
I did some testing, and I, too, desync immediately if I try to join B-B from a save other than itself or the 8x8 world save I usually load the game with.
Interesting. I wonder whether simply updating demo.sve would fix this?
It might, but it doesn't fix the incomplete or wrong initialization issue.
Quote from: Sirius on January 21, 2023, 07:43:20 PMIt might, but it doesn't fix the incomplete or wrong initialization issue.
Indeed - it might be a quick fix that would save a lot of time and trouble until the real problem, which is likely to be fantastically difficult to isolate, can be found and remedied.
In that case I'd rather expect once the problem is hidden, the real problem will never be fixed ;)
But sure, it's an easy quick fix of the symptom.
Quote from: [C] Ranran on January 13, 2023, 11:07:46 PMhttps://forum.simutrans.com/index.php/topic,21444.msg199254.html#msg199254
I wonder if this issue is of the same kind.
At least in my environment this has not been resolved. But dysync does not occur. It just keeps time suspended.
I accidentally discover that if the game pauses and time suspends, first click the "Change Options" icon (Q) and then click the "New Map" button, and then the game starts to run normally.
As discussed here (https://forum.simutrans.com/index.php?msg=203364), this problem appears to be broader in scope than first identified. There have been some occasions on which it has not been possible to connect to the server at all, even when loading from an existing saved game. It is still not entirely clear that these are the same problem, however.
For reference, my results so far are as follows: connecting directly from the command line works without error (or at least did to-day, initially, at least). Connecting in-game causes loss of synchronisation on the first attempt but not the second, as before. This was unchanged whether the connexion attempt was made by the in-game network browser or by typing "net:bridgewater-brunel.me.uk" on the command line.
Thus, the behaviour to-day seems to be consistent with the earlier behaviour reported in this thread, and inconsistent with the behaviour yesterday. There is as yet no clue as to what could possibly have caused this inconsistency. However, connecting on the command line (that is, adding the command line switch "-load net:bridgewater-brunel.me.uk") appears as though it might possibly be a workaround to this problem when it is more severe.
I should also note that the server just lost sync with all clients (a total of 6, 3 instances that I had connected for testing and 3 other players. The reason for this remains obscure.
Note: a possible but difficult to fix cause of this issue has been identified - see here (https://forum.simutrans.com/index.php/topic,22405.0.html).