Just start server locally and connect clients (via a symlinc) by fast doubleclicks.
I think this can happen, if the clients receive sync commands that have to be executed in the same sync step.
Still happening. Just make a link with the commandline "-load net:localhost". Fast starting clients will desync about 70% of them.
The problem is that a client receives the second sync command before it executed the first one. Then the second one is skipped due to coming from another world. And the client is out of sync, since it has done less save/reloads than the server.
If the server refused a client (due to fast joining) once it will never ever accept another client connection.
line 5444 in simworld.cc is superflous: "if( !umgebung_t::server ) {" could never happen, since this block is only called on a server. I think sometimes before the logic was broken here.
Finally if an nwc is not deleted, it will be never freed?
Quote from: prissi on November 13, 2010, 10:24:05 PM
If the server refused a client (due to fast joining) once it will never ever accept another client connection.
see patch. Does this help? It fixes a bug with rejected join attempt, but I am not sure whether it fixes also the bug reported by you.
Quote
line 5444 in simworld.cc is superflous: "if( !umgebung_t::server ) {" could never happen, since this block is only called on a server. I think sometimes before the logic was broken here.
yes you are right.
Quote
Finally if an nwc is not deleted, it will be never freed?
If it is not deleted at that spot, it is appended to command queue and will be deleted after call to do_command.
Seems to still refuse all connections after it failed once. Just start clients quickly, until joining fails => no further reconnects.
This should be fixed in 3960: sometimes the server closes its server socket -> no new connection accepted.
Thank you. Should the patch above go in anyway?
Imho, only one half is needed: I think if a client disappears while comparing paksets it may block the server such that no other client can do the comparing. For joining this is not needed I think.
Edit: I cannot produce this predicted error. Patch has to wait.
The fast joining and desynching (starting point of the thread) is not fixed yet.
Fast starting should work much better now (rev 3965).