[1.1.109] Low /perf-avg-frames impacts other players

[cliff_build]

What did you do?

In a multiplayer game, I experimented with running "/perf-avg-frames 1" and "/perf-avg-frames 100" with a friend.

What happened?

When either of us ran "/perf-avg-frames 1", it impacted the other as well. This has two impacts: one is that the FPS/UPS counters were hard to read/changing rapidly. The other is that scrolling around in map view using wasd becomes very jerky/not-smooth/unpleasant.

What did you expect to happen instead?

I expected running /perf-avg-frames would only impact the client that ran it, rather than all clients connected to the server.
Additionally, I wouldn't expect /perf-avg-frames to impact the performance of scrolling around on map view, but this is a minor issue if it only impacts the person who runs the command.

Does it happen always, once, or sometimes?

This happens every time I have tested it.

[PennyJim]

Factorio multiplayer works by lockstep computation. If one game does something, the other has to as well.

For the purposes of a command, every game has to react to anyone sending a command. In that reaction logic, there should be no way to determine if the player that ran it is the one running that instance of the engine (there might be engine side, but that opens up a high risk of desync issues).


That's the type of command that you just shouldn't run during multiplayer. Maybe it should have the permissions disabled by default or something, but permissions are a janky mess and I hesitate to assume anything about it.

[Rseding91]

Thanks for the report however I can't reproduce any performance issue with that command. Can you provide a save file that reproduces it?

[cliff_build]

ok, it took me a while to reproduce (which surprised me, because it reliably reproduced). But now I have a reliable reproduction.

It is likely related to either map generation or charting. Specifically, when those activities are happening, and `/perf-avg-frames 1` has been run, then scrolling around in map view is much choppier.

Here is a save file from right as the map is being explored in biterbattles, which reproduces the issue reliably for me. If a long time goes by (such that it is no longer doing any chunk generation/etc), then you can run `/instant-map-reset` to recreate the surface and make the issue reproduce again.

[Rseding91]

Ah yes that reproduces it. In this case the answer is simple: don't use that command if you don't want those side effects. I fixed the issue with it applying to all players when run (in 2.0 it applies only to the player who ran it).

* The numbers jumping around a lot - is exactly what you asked for. By setting it to 1, you asked for there to be no smoothing of the numbers and so there isn't. If you don't want to be hit, don't hit yourself

* The stuttering is also directly tied to the value being low: when rendering wants to draw those numbers it has to stop the game update logic from mutating the values so it locks the shared state, reads the values, and renders them. But if the game update logic is using them (for map generation numbers) then it has to wait for them to be finished - which is the stutter you see. Again the answer is simple, don't set it to 1 if you don't want this to happen.

[cliff_build]

Perfect! Thank you for the fix!

(I agree that it is silly to set the value to 1, and thus the performance-issue seems not terribly important)