View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004140 | Spring engine | General | public | 2013-11-10 15:32 | 2016-11-05 21:29 |
| Reporter | REVENGE | Assigned To | hokomoko | ||
| Priority | high | Severity | feature | Reproducibility | sometimes |
| Status | closed | Resolution | unable to reproduce | ||
| Product Version | 95.0 | ||||
| Summary | 0004140: Silent desync occurs during demo playback | ||||
| Description | *It is unknown if this issue occurs in every replay on every machine* In the following demo, at some time past midway point, game is noticeably de-synced. Units which are supposed to be dead don't die, etc. Replay ends with enemy team still alive. View auto demo here: http://replays.springrts.com/replay/b9837f52493e3344a228a7421cdf4421/ My copy of the replay is also attached. | ||||
| Steps To Reproduce | 1. Play a game. 2. View the replay. | ||||
| Additional Information | BA 7.84 | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Checked infolog.txt for Errors | |||||
|
|
"Units which are supposed to be dead don't die, etc. Replay ends with enemy team still alive." thats not the effect of a desync. a desync is, when players started the same game but have different results in the end. units which don't die are mostly broken and thats a game (BA) bug... |
|
|
If there is a desync bug (WHICH CAN ALSO BE IN LUA CODE!) then multiple runs of the same replay should produce two or more different outcomes over time. Which is time-consuming to verify, so if you feel like it... |
|
|
There are no desyncs occuring online in BA 7.84, or in BA for years now afaik. I think what he is trying to say is that when he watched the replay (and only then) different things happened to what happened in the real game. I haven't yet watched any 95.0 replays so can't confirm/deny. |
|
|
DemoRecorder broken? afaik it was changed to prevent LOS cheating. |
|
|
Could be but that change applied to the exploit of watching a demo (with second client instance) while a game was still in progress, which is not really possible anymore since as of 92.0 demos are recorded in-memory. "I think what he is trying to say is that when he watched the replay (and only then) different things happened to what happened in the real game." That still implies multiple runs of the same given replay have non-deterministic evolutions/outcomes though. |
|
|
sorry, its not the demo-recorder, i meant the demo-reader: afaik the following commit contains a simple protection that will make the demo desync if the file grows during playback: https://github.com/spring/spring/commit/00a8e692f87a0f3bce8cf4dc089d0aaf61c63c6a see #3319 not sure if this "protection" is somehow triggered or if the code still exists at all. but atm sounds that this could be the cause. edit: ah, zerver pm'ed this all devs |
|
|
Sorry for the confusion guys. I realize that it is symptomatic of a desync, but offline. It is as Kloot describes where a run of the replay results in a different outcome than the game that was played, but I am not sure yet whether it is a deterministic problem where some commands are possibly dropped, or an issue with the sim. |
|
|
is it possible to store checksums in demo? maybe just 1/10 or to reduce space usage but to detect desyncs. |
|
|
already did that, see https://github.com/spring/spring/blob/develop/rts/Net/NetCommands.cpp#L452 and https://github.com/spring/spring/blob/develop/rts/Net/GameServer.cpp#L1280 |
|
|
yes, but its only enabled for debug builds?! so atm not really useable to debug this imo. thats what i meant with "maybe 1/10 ...", just store a checksum every 10 seconds or make the rate configureable with a reasonable default?! |
|
|
this is too old to really debug |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-11-10 15:32 | REVENGE | New Issue | |
| 2013-11-10 15:34 | REVENGE | File Added: 20131110_045831_Green_Fields_v4_95.7z | |
| 2013-11-10 17:59 | abma | Note Added: 0012040 | |
| 2013-11-10 18:27 | Kloot | Note Added: 0012041 | |
| 2013-11-10 18:40 | Kloot | Note Edited: 0012041 | |
| 2013-11-10 19:00 | silentwings | Note Added: 0012042 | |
| 2013-11-10 19:03 | silentwings | Note Edited: 0012042 | |
| 2013-11-10 19:03 | silentwings | Note Edited: 0012042 | |
| 2013-11-10 19:04 | silentwings | Note Edited: 0012042 | |
| 2013-11-10 19:04 | silentwings | Note Edited: 0012042 | |
| 2013-11-10 19:14 | abma | Note Added: 0012043 | |
| 2013-11-10 19:14 | abma | Note Edited: 0012043 | |
| 2013-11-10 19:32 | Kloot | Note Added: 0012044 | |
| 2013-11-10 19:50 | Kloot | Note Edited: 0012044 | |
| 2013-11-10 19:58 | abma | Note Added: 0012045 | |
| 2013-11-10 19:59 | abma | Note Edited: 0012045 | |
| 2013-11-10 20:05 | abma | Note Edited: 0012045 | |
| 2013-11-10 20:08 | abma | Note Edited: 0012045 | |
| 2013-11-10 22:25 | abma | Note Edited: 0012045 | |
| 2013-11-11 02:58 | REVENGE | Note Added: 0012048 | |
| 2013-11-11 03:45 | abma | Changeset attached | => spring develop e8593e65 |
| 2013-11-11 03:45 | abma | Assigned To | => abma |
| 2013-11-11 03:45 | abma | Status | new => resolved |
| 2013-11-11 03:45 | abma | Resolution | open => fixed |
| 2013-11-11 03:46 | abma | Status | resolved => new |
| 2013-11-11 04:17 | abma | Assigned To | abma => |
| 2013-11-14 01:49 | abma | Severity | major => feature |
| 2013-11-14 01:50 | abma | Note Added: 0012126 | |
| 2013-11-14 02:10 | Kloot | Note Added: 0012127 | |
| 2013-11-14 02:52 | abma | Note Added: 0012128 | |
| 2016-11-05 21:29 | hokomoko | Assigned To | => hokomoko |
| 2016-11-05 21:29 | hokomoko | Status | new => closed |
| 2016-11-05 21:29 | hokomoko | Resolution | fixed => unable to reproduce |
| 2016-11-05 21:29 | hokomoko | Note Added: 0016854 |
