Author Topic: b.128.simutrans.entropy.me.uk (Read 16337 times)

Jaridan · « **Reply #35 on:** February 18, 2013, 02:57:45 AM »

it's desyncing like hell atm.

Fifty · « **Reply #36 on:** February 18, 2013, 03:07:02 AM »

For the third round of gaming in a row, the map on this server has started desyncing uncontrollably. (Just connect, and it will desync you within 30 seconds without doing anything). This map, again, is not nearly as developed as most netgame maps, including the one on the C server. What gives? Has this bug been fixed in the meantime? If not, would a developer please look into the cause of this problem? It's very annoying to have to give up gaming right when networks start to really develop.

Removing the pedestrians did not stop the bug from recurring last time. One thing I do know is that Jaridan was doing massive underground construction, if that caused a problem.

TurfIt · « **Reply #37 on:** February 18, 2013, 03:30:14 AM »

Last I looked into these desyncs, I couldn't duplicate when running my own server. Apparently these servers run some custom patches that may be the cause, but without the patches...

EDIT:
It is the same symptoms as with the c.64 server last fall, desync due to random number mismatch on the 4th NWC_CHECK. And also same as c.64, cannot duplicate with a virgin server.

benjad · « **Reply #38 on:** February 18, 2013, 02:00:08 PM »

+1 on underground being a possible issue. We had very few desyncs when there was little undeground. As the player started going underground, he started desync-ing a bunch, then it spread to everyone else.

Fifty · « **Reply #39 on:** February 18, 2013, 05:14:01 PM »

Thanks for looking into the cause of the desyncs, TurfIt. One thing I do remember is that the first time this bug appeared was when this headless graphics patch was added-- I wonder if it could cause an issue with underground or something else?

~~One other thing of note is that it only seems to affect pak 128.~~
Edit: nevermind, happened on 64 too, but I'm still tempted to say it's an issue with underground stations.

benjad · « **Reply #40 on:** February 18, 2013, 05:29:12 PM »

possibly related, every once in a while when placing an 'station addition' on a slope, i get a "fatal: missing ground" error (or something similar to that). Can't repeat it reliably.

Dwachs · « **Reply #41 on:** February 18, 2013, 06:41:06 PM »

Quote from: benjad on February 18, 2013, 05:29:12 PM

possibly related, every once in a while when placing an 'station addition' on a slope, i get a "fatal: missing ground" error (or something similar to that). Can't repeat it reliably.

Could be a double-click with the tool on the sloped tile. I.e. second click happened before building was placed.

benjad · « **Reply #42 on:** February 19, 2013, 01:42:42 AM »

(NOT double posting, thanks

)

Also one more thing I just noticed. Normally when desyncs occur, you can continue to manipulate the map behind the dialogues. You can move it, click on vehicles, stations, etc. and the appropriate dialogs appear.

With this desync, the map locks to user input, but continues to run underneath the dialogoues... though a bit faster.

Dwachs · « **Reply #43 on:** February 19, 2013, 07:29:03 AM »

Quote from: benjad on February 19, 2013, 01:42:42 AM

Also one more thing I just noticed. Normally when desyncs occur, you can continue to manipulate the map behind the dialogues. You can move it, click on vehicles, stations, etc. and the appropriate dialogs appear.

With this desync, the map locks to user input, but continues to run underneath the dialogoues... though a bit faster.

Then I do not understand, what you are talking about 'desyncs' here: The first description is the classical desync: Error messages are popping up, which tell you that something bad happened.

I do not understand you second description. It sounds like the game on your computer was lagging behind and then tries to catch up, thus running faster.

benjad · « **Reply #44 on:** February 19, 2013, 10:56:40 PM »

That is part of the odd behavior. Normally when a desync occurs, it appears that you could just close the dialogues and continue playing offline (as you used to be able to).

When this desync occurs, the UI elements behind the dialogues do not respond.

If we think it is still an underground issue, that is easy to test (sorry Jaridan). Bulldoze all the major underground works, and reload the map, see what happens.

Fifty · « **Reply #45 on:** February 20, 2013, 03:35:17 AM »

Quote from: benjad on February 19, 2013, 10:56:40 PM

That is part of the odd behavior. Normally when a desync occurs, it appears that you could just close the dialogues and continue playing offline (as you used to be able to).

When this desync occurs, the UI elements behind the dialogues do not respond.

I don't think this is anything different from a "usual" desync realted to the server running faster or slower than the client. You can't mess with what's behind the dialogs until you close the "Lost synchronization with server" popup, and then you can continue with the game offline. This is how it's always been, no?

This problem is just a desync- the game still runs just fine for me at least, and does not crash on either the client or server side as in the pedestrian bug. There are no error messages.

Jaridan · « **Reply #46 on:** February 20, 2013, 05:34:51 PM »

Quote from: benjad on February 19, 2013, 10:56:40 PM

That is part of the odd behavior. Normally when a desync occurs, it appears that you could just close the dialogues and continue playing offline (as you used to be able to).

When this desync occurs, the UI elements behind the dialogues do not respond.

If we think it is still an underground issue, that is easy to test (sorry Jaridan). Bulldoze all the major underground works, and reload the map, see what happens.

definitely something we could/should try. If i understand this correct fifty can play without problems? in that case you could hop onto my acc and bulldoze the underground stuff (pw is the same as in all games).

Fifty · « **Reply #47 on:** February 21, 2013, 03:46:59 AM »

I have problems too, but I might be able to quickly destroy your stuff, will see...

Vonjo · « **Reply #48 on:** February 21, 2013, 05:59:53 PM »

Quote from: TurfIt on February 18, 2013, 03:30:14 AM

Last I looked into these desyncs, I couldn't duplicate when running my own server...

Confirmed.
I tried to run the current savegame on a remote server, but it didn't have this desync problem. I can't reproduce the problem so far.

prissi · « **Reply #49 on:** February 21, 2013, 09:37:10 PM »

Maybe this instance of the serer uses a different farmes behind setting than the other instances (i.e. a left over in the simuconf.tab?)

TurfIt · « **Reply #50 on:** February 21, 2013, 09:51:16 PM »

I don't see how a different frames behind setting could cause this. Or any settings for that matter. These desyncs are a random number mismatch.

Since I can take the client savegame and run it on a server with no issues, 2 possibilities jump to mind:
1, the custom management patches applied to these servers are causing this. (or something else unique with the server build/environment).
2, the problem only appears after a server has been running for a while.
3, combination of above.

First thing I'd try is reboot the server! Second - try without any modification from trunk.
In any case, the ball's in Timothy's court as no one else can do anything...

Ashley · « **Reply #51 on:** February 21, 2013, 09:57:03 PM »

The only patch I have beyond the standard code is one to allow the process to daemonise. I am not sure how this could affect random number generation.

I can certainly try restarting it though. The B server is identical (using even the same binary hard-linked) as the A and C ones.

TurfIt · « **Reply #52 on:** February 21, 2013, 11:00:27 PM »

Assuming the server was restarted in the last hour, no change, still different randoms.

Ashley · « **Reply #53 on:** February 21, 2013, 11:10:55 PM »

Quote from: TurfIt on February 21, 2013, 11:00:27 PM

Assuming the server was restarted in the last hour

Yep.

Dwachs · « **Reply #54 on:** February 22, 2013, 07:32:03 AM »

How to proceed with this one??

Years ago I wrote some code to do automatic desync-debugging: Client and Server store all calls to random number generator. Upon desync they exchange messages to find the point of divergence. The patch was unstable, I did not continue to work on this. Branch is here:
https://github.com/Dwachs/simutrans/tree/debug-desync

In order to trace down the error, one still needs to add calls to log values of variables. That is, server and client needs to be recompiled & restarted regularly.

If the desync is due to some hardware error (memory failure) then we will not find anything ...

@Timothy: Would it be possible to add means to let us (developers) recompile the server from updated sources and restart?

Fifty · « **Reply #55 on:** February 23, 2013, 04:19:19 PM »

Hello B server players,

I've managed to create my own server fiftyserver.no-ip.org; I will continue the savegame of this b.128 server on that server as it seems to be stable. If there are any questions or ways I can help with debugging, please PM me.

edit: crashed, will be back in a few minutes Edit 2: working again

Ashley · « **Reply #56 on:** February 24, 2013, 11:36:47 AM »

Quote from: Dwachs on February 22, 2013, 07:32:03 AM

@Timothy: Would it be possible to add means to let us (developers) recompile the server from updated sources and restart?

Yes, but I don't have time at the moment to set this up :(

Vonjo · « **Reply #57 on:** March 18, 2013, 07:56:36 AM »

Here is the latest savegame from Timothy's+Fifty's+Vonjo's server:
http://simutrans-germany.com/files/upload/twelve01.sve
Simutrans 112.1 (r6212), pak128 2.2.0
Map dimensions: 512x512, current in-game date: March 2108 (starting date: January 1940)
99 towns, 3622311 citizens, 1091 factories, 1509 vehicles and 1311 stops.

Tell me if you want to continue serving this map or have problem with the savegame.