Page 1 of 1

A counterpart to only_in_alt_mode for LuaRendering

Posted: Fri Aug 28, 2026 4:43 pm
by Morlot
The request
A LuaRendering object can be told to show only while alt mode is on, through only_in_alt_mode. There is no way to say the opposite: show only while alt mode is off. I would like to ask for that counterpart.
Why it is needed
Without it, a mod that wants to draw something only while alt mode is off has to ask the player whether alt mode is on -- LuaPlayer::game_view_settings::show_entity_info -- and decide from that whether to create the object at all. That is where it comes apart: the render object is game state, the value it was decided from is not.

show_entity_info is not part of the simulated state; it does not appear in the desync heuristic. A peer keeps it current for its own player and leaves the values of the other players as they arrived with the map. Two peers can therefore hold different values for the same player, and neither of them is wrong. But a mod that draws from it creates game state on one peer and not on the other.
What that looked like in practice
My mod Hover ALT Mode draws the alt mode icons for whatever the cursor points at while alt mode is off, and steps aside when it is on. A player reported repeated desyncs on his server, on Factorio 2.1.14 build 87180, and uploaded the desync report.

Both saves in it are from the same tick. In the tagged level dump, all 470 MB of it, the complete difference is two render objects: a recipe icon and its backdrop on an assembling machine, present on the server and absent on the client. Everything else that differs -- around 7000 values across a dozen mods -- is the knock-on effect of those two missing objects shifting every object id after them by two.

In the player block, exactly one byte differs, inside <game-view-settings>: the fourth of the eighteen booleans, which is show_entity_info. The client held true for that player, the server held false. The player it belonged to was not the one who desynced -- it was the other player on the server, whose value had gone stale on the reporting client.

The report and the analysis are here: https://mods.factorio.com/mod/hover-alt ... d791b494e9
What the workaround costs
I have fixed it in the mod by keeping my own copy in storage, written from on_player_toggled_alt_mode. That event does reach every peer in the same tick -- I measured it with a server and a client side by side before relying on it. Two costs come with the workaround:

- A save from before that copy existed cannot be migrated honestly. Reading the field to seed the copy is precisely the thing that cannot be trusted, so the mod now switches alt mode off for every player once, on the first load. Everyone who had it on loses it.
- Toggling alt mode now takes effect only once the input comes back confirmed. With only_in_alt_mode the engine resolves visibility locally and there is no wait at all. Mine has one, and it grows with the latency.

Both would disappear with the counterpart flag, and so would the whole copy.
If the flag is not wanted
Then may I ask for a line in the documentation of GameViewSettings instead, saying that these values may differ between peers and must not be used to decide anything that ends up in the game state. Nothing says so today, the value is freely readable, and reading it is the obvious thing to do. I checked against 2.1.17.

Re: A counterpart to only_in_alt_mode for LuaRendering

Posted: Fri Aug 28, 2026 5:44 pm
by Osmo
Please do not use AI when making requests, especially when it is just wrong.
game_view settings are in game state, and you can also use https://lua-api.factorio.com/latest/cla ... ml#players and https://lua-api.factorio.com/latest/cla ... ml#visible to have the object exist, but only visible when you want to.

Re: A counterpart to only_in_alt_mode for LuaRendering

Posted: Fri Aug 28, 2026 6:43 pm
by Morlot
The numbers below are from the desync report.

Report is from a player on 0.21.9, two peers, tick 38606324.

The heuristic file (level-heuristic-38606324, 56074 bytes on both sides) differs in exactly one byte, at offset 55595, inside <script-rendering>: 159 objects on the server, 157 on the client. Nothing else in that file differs.

The full tagged level dump holds two <game-view-settings> blocks, one per player. Player 1 is identical on both sides, player 2 is not:

Code: Select all

client  01 01 01 01 01 01 00 01 01 01 01 01 01 01 01 01 01 00
server  01 01 01 00 01 01 00 01 01 01 01 01 01 01 01 01 01 00
                 ^ index 3
The block is 18 bytes and GameViewSettings has 18 members with order 0..17, so index 3 is show_entity_info. The client had ALT mode on for player 2, the server had it off.

That accounts for the render count exactly: my mod stands aside while ALT mode is on, so the server drew two objects the client did not.

Which turns my question around. If game_view_settings is game state, then two peers holding different values for the same player is a bug — should I file this as a bug report instead of a request? For what it is worth, game-view-settings does not appear anywhere in the heuristic file, while that same file does dump chart-mode, zoom-data, surface-view-data, pins, quick-bar and the controller for each player.

On players and visible: both are fields of the render object, so setting visible from a value that differs between peers leaves the object present on both but with differing data — the same divergence, one level down, in the same script-rendering block. players I already use. What I was asking for is a flag the engine resolves for the viewer, the way only_in_alt_mode does, just inverted. If visible can do that and I am reading it wrong, I would be glad to be corrected.