You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ingame UI doesn't allow players to place outside of their start box, but clients still send STARTPOS commands anyway, and the engine clamps/ignores them here.
Because the demo parser doesn't know the exact dimensions of the map, along with start box sizes always being on a scale of 0-200, but with STARTPOS position data being absolute map locations - I don't think this problem is solvable without a game or engine change.
Invalid start pos placement could be caught client side before they're sent over the network, but there could still be oddities with the final placement, e.g. if the player doesn't pick a spot at all and the game decides for them. So unfortunately I think the best solution to this problem is writing a gadget to SendLuaRulesMsg the one, true spawn position of each player's commander once the game starts, so it can be parsed from the replay.
The text was updated successfully, but these errors were encountered:
Randomly decided to investigate what's causing this bug more closely, which leads to incorrect start positions showing on the website:
I believe the culprit stems from this section of engine code: https://github.com/beyond-all-reason/spring/blob/2ef0794f99d9215f44c07ec7aae57fe8c4600caa/rts/Net/NetCommands.cpp#L517-L528
The ingame UI doesn't allow players to place outside of their start box, but clients still send STARTPOS commands anyway, and the engine clamps/ignores them here.
Because the demo parser doesn't know the exact dimensions of the map, along with start box sizes always being on a scale of 0-200, but with STARTPOS position data being absolute map locations - I don't think this problem is solvable without a game or engine change.
Invalid start pos placement could be caught client side before they're sent over the network, but there could still be oddities with the final placement, e.g. if the player doesn't pick a spot at all and the game decides for them. So unfortunately I think the best solution to this problem is writing a gadget to
SendLuaRulesMsg
the one, true spawn position of each player's commander once the game starts, so it can be parsed from the replay.The text was updated successfully, but these errors were encountered: