Trying to open schedule of reversing train causes desyncs

[ACarlotti]

Basically as it says in the description - as far as I can tell it seems that attempting to open the schedule on the client just produces a dialog saying that you can't interrupt the reversing operation (or something to that effect), while the server ends up thinking the schedule dialog is open. As a result, the train then departs as planned on the client, but does not depart on the server.

I haven't tried reproducing this yet, but if my diagnosis is correct then reproducing it should be fairly easy. When I triggered the desync the reversing train was one that I had sent to the depot - I wanted to delay it because I accidentally ordered it to the depot just ahead of a scheduled departure. (The depot could be relevant, but I wouldn't expect so.)

[Phystam]

In my server game, the "earlier depart by 5 minutes" phenomenon was also seen. Is it related with desyncs?

[ACarlotti]

In my server game, the "earlier depart by 5 minutes" phenomenon was also seen.

I don't know what you mean here.

I believe I have found the specific bug that I was encountering - I've pushed a fix to my Github for it. The issue is that when opening the schedule was forbidden, it was only being blocked if the schedule belonged to the current active player. So if the server and client had different active players, then the convoy could enter the EDIT_SCHEDULE state on exactly one of the client/server.

This bug is also present in Standard - that section of code is identical in both.

I think there may be further desync-causing bugs involving some combination of editing schedules or sending convoys to depots while they are reversing; however, I haven't been able to work out what else might be going wrong yet.

I believe these desyncs are unrelated to the one relating to St. Mary Beddington on the Bridgewater-Brunel server.

EDIT:
Diagnostics on the remaining desync.
I opened the schedule on the client (while the server was set to a different active player). Both the client and the server changed the convoys state to EDIT_SCHEDULE. The weight reported in the client reduced by two passengers (in the same period between the ends of two consecutive sync steps). The weight on the server did not change.
Hypothesis: The weight_summary is only updated when it is needed, which can include usage in gui components. So it is probably not suitable for using in a checksum. Oops.

[jamespetts]

Thank you for your work on this. I have a query about this fix:

Code Select Expand


-       if(  (is_locked()  ||  line_update_pending.is_bound())  &&  get_owner()==welt->get_active_player()  ) {
+ if (is_locked()  ||  line_update_pending.is_bound()) {
if (show) {
create_win( new news_img("Not allowed!\nThe convoi's schedule can\nnot be changed currently.\nTry again later!"), w_time_delete, magic_none );
}
return;
}


The new code would, it seems, open an error dialogue box on a remote client or on the server, no matter who the active player is, whenever a player attempts to change a schedule when this cannot be done.

The thing that needs to be the same on client and server is the "return" line; can we not move the get_active_player() check to run after the if(show) check to prevent this, or did you alter the code in this way for a reason?



Incidentally, the issue relating to weight summaries is interesting. If the weight is updated in response to GUI elements, this is in principle capable of causing loss of synchronisation between server and client  if the weight summary is updated on the client but not on the server and the physics for vehicle movement is based, as it is, on those weight summaries.

I do wonder whether a similar issue might be behind the loss of synchronisation issue on the Bridgewater-Brunel server at present, although quite how to test for this is currently unclear.



Phystam - I am not aware of a known bug that can be described as "earlier depart by 5 minutes". Can you elaborate and, if necessary, post a full bug report in a separate thread with a reproduction case?

[ACarlotti]

The new code would, it seems, open an error dialogue box on a remote client or on the server, no matter who the active player is

The parameter show is true only on the client that called the tool, and the test was specifically introduced to ensure that the window was only shown on the client that called that triggered it, even if other clients had the same active player.

I think there may be further desync-causing bugs involving some combination of editing schedules or sending convoys to depots while they are reversing;

I've done enough testing now that I believe that all the desyncs I was seeing have now been fixed.

[jamespetts]

Splendid, thank you for confirming that: that is most helpful.