The game time does not progress after connecting to the network and does not ref

[Ranran(retired)]

I have previously reported this bug in somewhere. Prissi said it was difficult to track down.
I thought this might be an environmental issue, but recently I've seen this bug report from time to time in Japan. Therefore, I think there is a bug.

This was also brought to extended while doing a merge from standard last year.
Unfortunately, the only solution I know of is to disconnect from network mode once, such as by loading a save, and then reconnect. (Do not close the game.)
Players who don't know this are complaining about this bug they cannot play the network game. But this doesn't always happen to certain players.


I suspect that this bug was introduced to extended since the following code in simumain.cc was merged.

Code Select Expand


if(  args.has_arg("-pause")  ) {
if( env_t::server ) {
env_t::pause_server_no_clients = true;
}
else {
pause_after_load = true;
}
}

Another place where pause_after_load = true is executed hasn't changed for more than 10 years.
At least I haven't run the -pause option. Because offline game doesn't stop at the start.

[prissi]

You mean you started a game with pause, and then cannot connect to a server? That worked for me on a test.

I think you are looking at the wrong place, After loading a game, the client waits for the server to unpause it in void nwc_sync_t::do_command(karte_t *welt) in network_cmd_ingame.cc line 697 onwards. (by executing line 787ff). The only reason this could fail if (socket_list_t::is_valid_client_id(client_id)) fails. Since we obtained this socket just before the transfer SOCKET sock = socket_list_t::get_socket(client_id);, this failing means the network stack lost connection during transfer. In such a case the welcome message at the bottom of the screen will never appear.

If this happens with connected clients, that have already joined, then it may be due to the server never receiving the nwc_ready message.

In both cases this looks like network trouble. On loading the game, the condition is only continueing if the game was sent sucessfully, Thus is looks like some messages never arrived, e.g. some instances on the route (maybe a IP6 to IPv4 light converter at the provider) acknowledged receiving this packet already even though it has not reached the client yet, and never did.

It could also happen if the server fails to send the game, because it could not open the savegame it just created (due to disk space issues etc.). But that would desync all clients.

Finally, there are many tcp timeout on established connections. But these are rather long (15min to hours).

EDIT2:
Digging deeper, I found clear_command_queue() in karte_t::load() This may be the reason for trouble, if the client is much slower loading the map than the server. It makes no sense to clear the command queue on a client, since the commands will be anyway received in right order due to tcp! Check r10495

[Ranran(retired)]

Code Select Expand

You mean you started a game with pause, and then cannot connect to a server?
Sorry, the title was subject to a character limit.
I explain in bullet points:
- Correct connection is made
- Connected clients remain paused forever
- Connected clients can operate the tools
- When the connected client runs the tool, the server side correctly executes the process. For example, destroying a building will destroy the building on the server side. However, the client will not notice that it has been destroyed because no action is taken.
- I don't know if it will disconnect from the server side. At least it seems to be connected continuously, but the pause state continues forever.

Anyway, since it is in a paused state and no action in the game is reflected, it falls into a state where it can not be determined at all whether it is connected or not.


For example, according to a post on the Japanese simutrans wiki
https://japanese.simutrans.com/index.php?%B4%CA%B0%D7%B7%C7%BC%A8%C8%C4%2F%BC%C1%CC%E4

Code Select Expand


steamの最新版(123.0.1 r10333)でネットワークプレーのテストをしているのですが、1台のコンピュータに2個（サーバーとホスト１つずつ）simutransを起動すると、ホスト側が一時停止状態（||マーク）になっており、ホストで線路などを敷設してもホスト側に一切情報が反映されません。steamでの参加者を考慮すると、ダウングレード以外で解決を図りたいのですが、どのようにすれば良いでしょうか？ -- 2022-01-08 23:52:26
参考までに2つ起動した時の状況です。左がホスト、右がサーバーでサーバーは動いているのですがホストは一時停止状態（右下に||マークがついている）になっています。 ttps://gyazo.com/811b16c5cb75a222304637157d2be599 -- 2022-01-08 23:53:45
検索してみたところ、一時停止マークがついているのは同期中という可能性があるとありました。しかし、テスト接続（1台のコンピュータにサーバーとホスト1つずつ起動）して約10時間後も一時停止マークがついたままで、全く同期されていません。同じ端末で動いているので10時間もすれば同期は終わっているはずです。これはr10333特有の不具合なのか、設定が誤っているかのどちらでしょうか？設定が誤っている場合、どこに誤りがある可能性が高いでしょうか？なおメモリやCPUの不足はないと考えて良いです。 -- 2022-01-16 14:08:42

He seems to be suffering from the same symptoms. I should have seen a similar report on social media, but unfortunately I can't remember where I saw it. IIRC, he said he solved it in some way.
Also as the Japanese are always strange in their behavior, they tend not to use newer versions. Thus they may be less likely to get into such a situation compared to the number of players.

What I have found is that if I load an unrelated save, that is, exit the server once myself, and then reconnect, it unpauses correctly. Hence why I believe this is not my connection environment or memory or disk space issue.

I think you are looking at the wrong place

Maybe. I was looking for a place when the pause was executed anyway.

Check r10495

Thank you. I'll check in later.

[makie]

- Correct connection is made
- Connected clients remain paused forever
- Connected clients can operate the tools
- When the connected client runs the tool, the server side correctly executes the process. For example, destroying a building will destroy the building on the server side. However, the client will not notice that it has been destroyed because no action is taken.
- I don't know if it will disconnect from the server side. At least it seems to be connected continuously, but the pause state continues forever.

I have see this too, some times ago.
So far i remember, this happens if the announcement to the Server listing server fail.
After time out, it is too late to running. The Server go ahead.

[prissi]

If the client loading and donloading is much slower than the server, it could be that the client recieved the sznc command than would restart the client. However, karte_t::load clear the command queue including the oending sync command. Then the client would never recieve the command to start the simulation, but can send command to the server (which assume the client is running, since the connection remains). The tiny change is now to clear the command queue only on the server, so the client can catch up with commands recieved in between. I hope that was the problem, but there could be other causes.

[Ranran(retired)]

Code Select Expand


if(  env_t::server  ) {
// since the sync should have been the last command on the clients due to tcp, only clear command queue on the server
clear_command_queue();
}

if(  env_t::server  ) {
step_mode = FIX_RATIO;
if(  env_t::server  ) {

There seems to be a series of identical if statements.

[prissi]

There was a second useless if below, thanks