[PATCH] Disappearing lag makes the game fast forward for all players

[elexis]

Disappearing lag As noted by sanderd17 in comment 3, the issue described below appears always when lag disappears: ​http://wildfiregames.com/forum/index.php?showtopic=18797 By doing fast forward the game tries to compensate the previous slow motion caused by lag. However the game should never exceed the defined game speed, so that players can always issue commands.

Fast Forwarding Replays If you change the game_speeds.json file to support 20x speed, you will observe the following bug when doing a visual replay. If you try to set the gamespeed back to 1x and the replay has been playing for a while with 20x speed with bad performance, then the units are still walking in 20x speed over the screen while the simulation is only updated with 1x speed. So you basically can't set it back to regular speed instantaneously, but have to wait until all simulation updates were rendered.

See Game.cpp line 389:

// At the normal sim rate, we currently want to render at least one
// frame per simulation turn, so let maxTurns be 1. But for fast-forward
// sim rates we want to allow more, so it's not bounded by framerate,
// so just use the sim rate itself as the number of turns per frame.
size_t maxTurns = (size_t)m_SimRate;

The function CGame::Update or one of its assets must be changed somehow to fix this, so that people can replay with arbitrary game speeds.

Maybe the game can also skip the rendering of frames, so that you can actually fast forward with 20x speed if your CPU but not the graphics card supports it.

[elexis]

The m_DeltaSimTime variable will become bigger and bigger over time (when replaying with high speed when its 'laggy'). Its value is increased in the beginning of CNetTurnManager::Update

m_DeltaSimTime += simFrameLength;

and then reduced afterwards:

// Set the time for the next turn update
m_DeltaSimTime -= m_TurnLength / 1000.f;

but if it can't keep up with the selected speed, then the value is not reduced sufficiently. It won't reach zero anymore as it ought to be but grows instead.

---

This problem is reproducible in singleplayer mode too, where you can change the speed live and make the game laggy by producing many units with cheats.

Possible solution: If you have reproduced the issue, enabled time warp mode, hit backspace for rewinding a bit, and select the game speed again, then the issue is fixed!

That time warp mode however can cause the game to crash:

CCmpPathfinder.cpp(595): Assertion failed: "m_Grid->m_W == m_ObstructionsDirty.dirtinessGrid.m_W && m_Grid->m_H == m_ObstructionsDirty.dirtinessGrid.m_H"
Assertion failed: "m_Grid->m_W == m_ObstructionsDirty.dirtinessGrid.m_W && m_Grid->m_H == m_ObstructionsDirty.dirtinessGrid.m_H"

(experienced on r16797).

[elexis]

An example replay file to reproduce the issue (produces lag by spamming trade carts). Edit game_speeds.json to support 20x speed. Enable time warp mode in the develoeprs overlay, hit backspace and change the gamespeed to fix the described bug.

[elexis]

Resets m_DeltaSimTime to zero when changing the game speed and also sets back the next turn to currentTurn + 1. Works.

[sanderd17]

This problem ought to be solved on a more general level. It happens whenever there's lag, followed by turns without lag. See ​http://wildfiregames.com/forum/index.php?showtopic=18797 as example.

So the deltaSimTime should probably be capped in some way. On one side, it's nice to catch up the lag when a turn took just a bit more time than it was given, but it's not nice if the catchup accumulates to a level where it will take multiple turns at full speed to catch up.

[elexis]

In multiplayer mode m_DeltaSimTime also increases over time. However if the lag is gone, then the variable is set back to zero and the game continues in the desired speed instantaneously.

Reproduce:

1. Start a multiplayer game with debug output for m_DeltaSimTime, 20x speed and a second client.
2. Create hundreds of units and move them somewhere.
3. Notice that it lags and that m_DeltaSimTime increases.
4. Alt + doubleclick on a unit to select and delete all of them.
5. Notice that the lag has gone and that m_DeltaSimTime is set back to zero that moment..

If you do the same with only one client, then the effect doesn't happen.

---

If there is lag in multiplayer that disappears at a later point and if all clients have perfect performance, then all players will try to catch up with the expected simulation time and thus will go in fast forward mode.

But as noted on the forum thread above, this doesn't make sense at all, since the user can't issue any more orders.

Therefore the simulation speed must be reset as soon as the user can issue commands, i.e. the next turn. This can be achieved by just caping the expected simulation time (defined relatively in m_DeltaSimTime).

We speculated on IRC that multiplayer games will always lag in situations of disappearing lag (as described above). But in case where lag disappears, there won't be any lagging. The only thing that won't happen anymore is that the clients won't try to fast forward to compensate. Rather it will always go with the currently defined game speed, which is expected (contrary to fast forwarding).

[Itms]

This sounds like a change that could have unpredicted effects. I have nothing against it but I propose to push it to A20 and integrate it quickly.

If Philip has some time and can take a look at the proposal, it would be quite reassuring.

[elexis]

Rewrote the patch this way, so its easier to read it and added a comment. Today on IRC there was a discussion about this patch with Philip. We concluded that it should work this way, but it should be tested more. A lagging client should be able to fast forward for a brief amount of time (at least 2 * turn length) to catch up with the other clients.

[elexis]

Since r17019 we can fast forward in visual replays with 5x, 10x or 20x speed, see ps/trunk/binaries/data/mods/public/simulation/data/settings/game_speeds.json​.

It doesn't go OOS, but this problem of fast-forwarding even if you don't want to remains.

I propose to at least fix this for visual replays, so that we can safely fast forward without having to worry for a never-ending fast forward. I will upload an according patch.

[elexis]

Sample replay for r17078 that has disappearing 'lag'. Duration: 2min 30s.

[elexis]

Same thing but only for singleplayer and replays. Limits the current gamespeed by the selected gamespeed.

[elexis]

Reproduce the unwanted fast-forwarding by replaying the file above and

1. Select 20x speed from the dropdown.
2. After 2min, select 0,1x speed from the dropdown.

-> Notice the speed is way faster than 0,1x, unless you have the patch.

I don't demand the issue to be fixed in a19 for all cases, but at least we should fix it for the non-networked case and then push it to a20.

Also notice Philip already reviewed it.

[elexis]

._.

[Josh]

Replying to elexis:

Reproduce the unwanted fast-forwarding by replaying the file above and

1. Select 20x speed from the dropdown.
2. After 2min, select 0,1x speed from the dropdown.

-> Notice the speed is way faster than 0,1x, unless you have the patch.

I don't demand the issue to be fixed in a19 for all cases, but at least we should fix it for the non-networked case and then push it to a20.

Also notice Philip already reviewed it.

Which patch did Philip review? If it has been reviewed, tag it and we will commit it.

[elexis]

This bug is inacceptable, both for playing and replaying games.

• Ever tried playing on 2x speed? Or even 5x? This makes playing a match in singleplayer mode impossible, especially since frames are skipped and the screen only being updated every fifth second.

• If you want to fast forward a long game to see some bug or interesting event in the game that happened minute 50, that's basically impossible to do without waiting 50 minutes. It will not stop to fast forward once you get close.

• It is a fundamental function of the game that is broken.

---

The issue can be reproduced in roughly 3 minutes:

1. downloading the patch (30 seconds)
2. applying the patch (30 seconds)
3. compiling (60 seconds)
4. fast forward a replay (30-60 seconds) and switching to slow motion

---

If noone has time or the will to look at the actual patch, then push it before releasing, but please don't reduce the priority without explanation.

---

You don't even need to verify that the logic does anything sane. Only assure yourself that this line of attachment:t3309_cap_expected_simTime_v3_for_replays.patch​ works (which is trivial):

if (isVisualReplay)

This way we could at least fix the bug for replays and if it breaks visualreplay, you can blame me! After that commit I wouldn't disagree to push it to a20.

[elexis]

Also notice Philip already reviewed it.

Which patch did Philip review? If it has been reviewed, tag it and we will commit it.

attachment:t3309_cap_expected_simTime_v3.patch​ was the one Philip reviewed.

It was his idea to allow this fast-forward-persistance in order to catch up with other clients for the maximum duration of at most 2 turn lengths.

The discussion can be found in ​http://irclogs.wildfiregames.com/2015-08-31-QuakeNet-%230ad-dev.log

Commiting that version will cover singleplayer, multiplayer and replays safely.

[JoshuaJB]

In 17159:

Fix #3309 by capping m_DeltaSimTime in NetTurnManager.cpp. Patch by elexis. Review by Philip.

[Josh]

Thanks for the patch.

[elexis]

(set component to network)