|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006039||Spring engine||General||public||2018-09-11 02:10||2018-11-08 18:21|
|Product Version||104.0 +git|
|Target Version||Fixed in Version||104.0 +git|
|Summary||0006039: Reconnecting disobeys AssignPlayerToTeam|
|Description||Reconnecting players are put back in their original startscript team, not the one they were Assign'd to.|
|Steps To Reproduce||Startscript: playerID 0 in teamID 0|
Lua: Spring.AssignPlayerToTeam(0, 1)
Player 0 quits and reconnects
-> He's back in team 0 as in startscript, not 1 whither he was assigned.
|Tags||No tags attached.|
|Checked infolog.txt for Errors|
Last edited: 2018-09-11 20:40
this makes little sense.
AssignPlayerToTeam is a synced callout, so upon reconnecting the client will simply execute it again. you are either claiming that it doesn't get called a second time or that the second invocation has no effect, paths which should both lead to a rapid desync. provide more evidence as well as a *minimal* testcase.
>you are either claiming that it doesn't get called a second time or that the second invocation has no effect
I'm claiming neither. Let's assume Assign happened at time T and the reconnection started at time T+X.
The reconnecting client reaches T. He correctly invokes Assign again and it correctly changes his team. There is no desync.
Then he (and other clients) reaches frame N+X upon which something happens that reverts the team. This happening seems to be synced as well since there was no desync in the replay. I believe it's this line https://github.com/spring/spring/blob/30862626214bd263b1c4489bb197ef1c3dbc0738/rts/Net/GameServer.cpp#L2886
Here's a replay (non-minimal but fairly short) in which player 3 [hokomoko] is affected: https://zero-k.info/replays/20180623_174023_La%20Isla%20Bonita%20v1_104.0.1-287-gf7b0fcc%20maintenance.sdfz Zero-K v188.8.131.52 (engine is old-ish maintenance but I believe the relevant parts were not touched since)
I'll try to prepare a minimal replay if that's not enough.
it may be sufficient to move the SendData loop after the SendJoinTeam.
I am however not going to touch this or any other issue so long as ZK remains on 287.
|2018-09-11 02:10||sprung||New Issue|
|2018-09-11 17:13||sprung||Note Added: 0019345|
|2018-09-11 20:37||Kloot||Note Added: 0019346|
|2018-09-11 20:40||Kloot||Note Edited: 0019346||View Revisions|
|2018-09-12 18:31||sprung||Note Added: 0019348|
|2018-09-12 19:04||Kloot||Note Added: 0019350|
|2018-11-08 18:21||Kloot||Assigned To||=> Kloot|
|2018-11-08 18:21||Kloot||Status||new => resolved|
|2018-11-08 18:21||Kloot||Resolution||open => fixed|
|2018-11-08 18:21||Kloot||Fixed in Version||=> 104.0 +git|