Open heinermann opened 9 years ago
My guess would be that this replay try to do things (giving an order?) on frame 0 when the game expect it to be impossible (meaning there's no code against it) before frame 1, and thus some code would get executed too soon, and before GameImpl::update since the workaround fail.
If it's not that, I don't understand why in the workaround the condition is "!this->isReplay()" when the crash described by the log should only happen in replay (and the condition seems to be "not in replay"). But I'm a Starcraft modder, maybe I just don't understand how BWAPI work in this case.
No, the issue is that it's writing the replay time (number of frames) as 0, so when it determines the progress bar % it divides by the maximum number of frames (which happens to be 0).
Here is a log of the crash.
We try to prevent it by using the following workaround: https://github.com/bwapi/bwapi/blob/master/bwapi/BWAPI/Source/GameUpdate.cpp#L199-201 . This is supposed to prevent saving replays with a 0 frame time. However this is apparently insufficient, as this replay has surfaced.
The replay in question is this one: http://bots-stats.krasi0.com/replays/Bot2/2015%2004%2022/Python%201.1_PVST_215041_225280.rep