View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
---|---|---|---|---|---|---|---|---|---|
0006039 | Spring engine | General | public | 2018-09-11 02:10 | 2018-11-08 18:21 | ||||
Reporter | sprung | ||||||||
Assigned To | Kloot | ||||||||
Priority | low | Severity | minor | Reproducibility | always | ||||
Status | resolved | Resolution | fixed | ||||||
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 | |||||||||
Attached Files |
|
![]() |
|
sprung (reporter) 2018-09-11 17:13 |
Related: 0005138 |
Kloot (developer) 2018-09-11 20:37 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. |
sprung (reporter) 2018-09-12 18:31 |
>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 v1.6.5.6 (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. |
Kloot (developer) 2018-09-12 19:04 |
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. |
![]() |
|||
Date Modified | Username | Field | Change |
---|---|---|---|
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 |