Page 1 of 1

API returning index of the player the code is running on

Posted: Tue Nov 12, 2019 5:43 pm
by Hornwitser
Yes, I know very well that doing any action that affects the vast majority of the game state from a value returned by such an API will desync the game, but as clarified in this bug report GUI state is too expensive to CRC check and can therefore differ between client and server without desyncing the game. So this does actually have a utility. If you have a GUI elements that shows real time values of some thing happening in the game the update for it gets expensive real fast in 100 player multiplayer games. You can reduce the impact by only updating the GUI element visible to the player the code runs under if there was an API to query which player the code runs for.

Re: API returning index of the player the code is running on

Posted: Tue Nov 12, 2019 5:47 pm
by Rseding91
There's no way in script to even do what your suggesting that wouldn't start off by instantly desyncing.

So, no. I'm not going to enable mods to do things wrong :P

Re: API returning index of the player the code is running on

Posted: Tue Nov 12, 2019 7:01 pm
by Hornwitser
Well, here's a Proof of Concept Scenario Script that does exactly what I'm suggesting and guess what it doesn't instantly desync. Is this wrong? Maybe, but this definitively demonstrates that what I'm suggesting not only is possible, it works just fine (even with heavy mode on!). (Please note that the hack used only works correctly when you start the scenario on a dedicated server via --start-server-load-scenario.)

Re: API returning index of the player the code is running on

Posted: Wed Nov 13, 2019 12:26 am
by Boodals
You seem to not understand what a desync is. A desync isn't "the game quitting because it detected something fucky", a desync is "data on one client is different to data on another client". Just because GUI data isn't periodically checked for desyncs doesn't mean it doesn't need to be synced. If the data is different on one client to another, any mod could read it and act on the data, and then that would be detected as a desync by the game and it would kick you to the menu.

Re: API returning index of the player the code is running on

Posted: Wed Nov 13, 2019 1:14 am
by Hornwitser
That is one way to view what is a desync. I have a more pragmatic view where I consider the game desynced when the state between the server and the client is uncontrollably diverging. If you were to take the "data on one client is different to data on another client" to its logical extreme you will find that no game is in sync, as even simple things like the # operator give different results on different clients when applied to sparse tables (this is also the reason why game.print(serpent.block(global)) can desync the game.)

I'm very well aware that if the divergent GUI state I made in my POC is read and acted upon by a mod it will desync the game in every sense of the word. This doesn't appear to be something that would be a common, most mods stick to only dealing with their own GUI elements. But it is possible to prevent mods from getting access to this divergent GUI state with a flag to the element that says it's write only.

The concept of divergent GUI state might be too niche and/or dangerous to be worth your time. Myself I feel that the limitation that GUI's should be updated for all players on all clients is just another reason to why mod GUI's feel like second class citizens in Factorio.

Re: API returning index of the player the code is running on

Posted: Wed Nov 13, 2019 10:54 am
by Klonan
Hornwitser wrote:
Wed Nov 13, 2019 1:14 am
The concept of divergent GUI state might be too niche and/or dangerous to be worth your time. Myself I feel that the limitation that GUI's should be updated for all players on all clients is just another reason to why mod GUI's feel like second class citizens in Factorio.
I don't really agree,
The game needs to know what is inside every players GUI, otherwise when a script says "Okay, john has entered a number, make that many biters", the game will say "I don't know what johns GUI is doing, I can't make those biters".

Syncing GUI state has posed absolutely no problem as far as I remember,
You just update player GUIs when you need to, using standard script usage.

Re: API returning index of the player the code is running on

Posted: Mon Nov 25, 2019 3:37 pm
by eradicator
Rseding91 wrote:
Tue Nov 12, 2019 5:47 pm
There's no way in script to even do what your suggesting that wouldn't start off by instantly desyncing.
That makes no sense. If the gui state is really not CRC checked, how could it ever cause a desync?
Klonan wrote:
Wed Nov 13, 2019 10:54 am
Syncing GUI state has posed absolutely no problem as far as I remember,
The only problem it causes is wasted performance. If Player 1 opens a gui with *lots* of elements this will cause a noticible lag spike for *everyone* instead of just the Player that opened the gui. Also even a visible=false gui used to affect FPS performance, though i'm not sure if that affects everyone in MP. For the @OPs case of just showing some data desync freeness could be enforced via "write only" gui elements, but honestly i think it'd be just fine to leave the worrying-about-desyncs to the mod authors in these cases.

Re: API returning index of the player the code is running on

Posted: Mon Nov 25, 2019 4:11 pm
by mrvn
I can see a use case for not syncing GUI elements.

For example Helmod lets you pick a recipe to add through a filter. Setting the filter then has to sort trough all recipes and build a table of all matches. In modded games this takes quite some time and this stops the game for all players. No other player is ever going to see the list of filtered recipes. It's a totally local thing. It would be nicer if the list would only be generated for the player that has the GUI open.

But I can see a maybe better solution there: Why not check if the GUI element is visible to the user running the script? The GUI element can remember the filter but simply not do the work unless it is a) already open or b) gets opened later [can't happen here].

Re: API returning index of the player the code is running on

Posted: Mon Nov 25, 2019 7:09 pm
by pleegwat
I think the ideal solution would be allowing for LUA to run in the UI layer (where all current LUA runs in the game layer). All function calls or structure writes from the UI to the game layer would have to be synced, but the UI layer itself could stay local. In turn, the game layer would no longer be able to generate UI elements directly.

Probably not feasible in this stage of development though.

Re: API returning index of the player the code is running on

Posted: Mon Nov 25, 2019 7:12 pm
by Rseding91
Note: the game doesn't make widgets for players that aren't the one actually looking at the game.

The basic information that Lua can read is stored. The actual widgets themselves only ever exist for the local player viewing his screen.

Re: API returning index of the player the code is running on

Posted: Thu Nov 28, 2019 11:49 am
by mrvn
Rseding91 wrote:
Mon Nov 25, 2019 7:12 pm
Note: the game doesn't make widgets for players that aren't the one actually looking at the game.

The basic information that Lua can read is stored. The actual widgets themselves only ever exist for the local player viewing his screen.
Then why does helmod freeze the game for everyone?

Re: API returning index of the player the code is running on

Posted: Thu Nov 28, 2019 2:02 pm
by Rseding91
mrvn wrote:
Thu Nov 28, 2019 11:49 am
Rseding91 wrote:
Mon Nov 25, 2019 7:12 pm
Note: the game doesn't make widgets for players that aren't the one actually looking at the game.

The basic information that Lua can read is stored. The actual widgets themselves only ever exist for the local player viewing his screen.
Then why does helmod freeze the game for everyone?
Probably because it's doing something very inefficient and hasn't been reworked/optimized to not do that.

Re: API returning index of the player the code is running on

Posted: Thu Nov 28, 2019 4:04 pm
by mrvn
Rseding91 wrote:
Thu Nov 28, 2019 2:02 pm
mrvn wrote:
Thu Nov 28, 2019 11:49 am
Rseding91 wrote:
Mon Nov 25, 2019 7:12 pm
Note: the game doesn't make widgets for players that aren't the one actually looking at the game.

The basic information that Lua can read is stored. The actual widgets themselves only ever exist for the local player viewing his screen.
Then why does helmod freeze the game for everyone?
Probably because it's doing something very inefficient and hasn't been reworked/optimized to not do that.
My point was that it is doing it on everyones computer. Not just where the widget is visible. The problem is not the visibility or existence of the widget but the work done when a player clicks something.