Topic: Network games do not reload when other players join

[Matthew]

Steps to reproduce

1. Update the Windows client to a build since the Great Merge of 2020-12-12.
(I was using MSYS2 build #5b76bff of this branch, but I have noticed all the symptoms over the last couple of days when using official executables. I just did not see the pattern until now. I will try to reproduce with an official build soon. EDIT: Confirmed with official client and server on #c4cd41f)
2. Open the Windows client (EDIT: Due to this bug, you probably need to use simutrans-extended.exe, even in 64-bit)
3. Connect to an online game. (The server will transfer a save file, which we will call Save A)
4. Build a recognizable item (e.g. a couple of tiles of track on barren ground).
5. Wait for someone else to connect. The game will save its current state. (The client will make a save, which we will call Save B).
6. The client will reload the game. You will see the new connection welcome message, though you will not jump to the spawn point.
7. Go to the place where you built the recognizable item. It will not be there, because the client has reloaded Save A. (The recognizable item will still be present on the server though).

Expected outcome: The client loads Save B so that you can continue playing where you left off.

Probable cause: Save B is being saved with a .sv_ extension which is not subsequently renamed to a .sve extension. For example:



This is a reoccurrence of a bug from Standard which was discussed on the forum earlier this year, though I haven't found the thread yet EDIT: discussed but not really solved here. The use of a .sv_ extension is intentional and was introduced in this issue.

EDIT: The Standard thread suggests the bug was perhaps unintentionally 'fixed' between r9176 and r9274. I scanned through the commits between those points, focusing on those that appeared relevant (ignoring e.g. GUI & Squirrel commits), but I could not see anything relevant (though I'm a novice and may well have missed stuff). I now notice that Antarctic said in that Standard thread that the problem stopped when he switched to Steam, so it might be related to some difference between the official build and the Steam build instead.

Possible relevant entry on the second line of simu.log:

Code: [Select]

ERROR: loadsave_t(): failed reading with error 1This error is recorded in all my logfiles since 2020-12-13, but not before.

That error message appears to be generated using codes from this enumeration in loadsave.h:

Code: [Select]

enum file_error_t {
FILE_ERROR_OK=0,
FILE_ERROR_NOT_EXISTING,
FILE_ERROR_BZ_CORRUPT,
FILE_ERROR_GZ_CORRUPT,
FILE_ERROR_NO_VERSION,
FILE_ERROR_FUTURE_VERSION,
FILE_ERROR_UNSUPPORTED_COMPRESSION
};If that is correct, then the code means the game was searching for a file that does not exist.

[jamespetts]

Thank you for the report. I have only been able to reproduce this in a very specific case, viz. when two different clients on the same computer try to join the server at the same time. In that case, the client2-network.sv_ files will clash with each other and produce an "invalid data" error (code 13). I cannot practically test this in other conditions at present.

I am not familiar with the code in this area, and thus it is difficult for me to test this properly or understand what is happening when a failure occurs, although I have improved the debugging code so that whenever this occurs it gives an error to the log/command line with the error code of whatever caused the failure to rename.

Any assistance would be appreciated.

[jamespetts]

I have not been able to solve the ultimate cause of this issue, so I have made a change which I believe has the effect of disabling the use of a temporary filename when Simutrans-Extended is operating as a network client, as any corruption in this network save file is not a problem in any event as this is always intended to be transient, the proper saved game being stored on the server.

I should be grateful if people could re-test with to-morrow's nightly build whether this assists matters.

[Matthew]

I have not been able to solve the ultimate cause of this issue, so I have made a change which I believe has the effect of disabling the use of a temporary filename when Simutrans-Extended is operating as a network client, as any corruption in this network save file is not a problem in any event as this is always intended to be transient, the proper saved game being stored on the server.

I should be grateful if people could re-test with to-morrow's nightly build whether this assists matters.

James, thank you for looking for a quick fix to this bug. I look forward to testing it with the new nightly build.

While studying this bug, I discovered that the patch to Standard that probably introduced this bug was intended to resolve problems caused by a lack of memory on the Bridgewater-Brunel server. "Plus ça change, plus c'est la même chose!"

[jamespetts]

James, thank you for looking for a quick fix to this bug. I look forward to testing it with the new nightly build.

While studying this bug, I discovered that the patch to Standard that probably introduced this bug was intended to resolve problems caused by a lack of memory on the Bridgewater-Brunel server. "Plus ça change, plus c'est la même chose!"

Indeed - this is a reason that we will want to revert my temporary fix once the real cause of the problem has been found and fixed.

[jamespetts]

I was hoping that Ceeac's helpful porting of the stream system to Extended would have solved the underlying problem but it appears not: the client2-network.sv_ file is still not renamed to client2-network.sve after saving has been completed.