API returning index of the player the code is running on

Things that we aren't going to implement
Post Reply
Hornwitser
Long Handed Inserter
Long Handed Inserter
Posts: 80
Joined: Fri Oct 05, 2018 4:34 pm
Contact:

API returning index of the player the code is running on

Post 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.

Rseding91
Factorio Staff
Factorio Staff
Posts: 10331
Joined: Wed Jun 11, 2014 5:23 am
Contact:

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

Post 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
If you want to get ahold of me I'm almost always on Discord.

Hornwitser
Long Handed Inserter
Long Handed Inserter
Posts: 80
Joined: Fri Oct 05, 2018 4:34 pm
Contact:

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

Post 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.)

Boodals
Fast Inserter
Fast Inserter
Posts: 121
Joined: Sun Feb 11, 2018 7:10 pm
Contact:

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

Post 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.

Hornwitser
Long Handed Inserter
Long Handed Inserter
Posts: 80
Joined: Fri Oct 05, 2018 4:34 pm
Contact:

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

Post 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.

User avatar
Klonan
Factorio Staff
Factorio Staff
Posts: 4132
Joined: Sun Jan 11, 2015 2:09 pm
Contact:

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

Post 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.

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 3953
Joined: Tue Jul 12, 2016 9:03 am
Contact:

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

Post 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.
Author of: Hand Crank Generator, Screenshot Hotkey 2.0
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

mrvn
Smart Inserter
Smart Inserter
Posts: 4039
Joined: Mon Sep 05, 2016 9:10 am
Contact:

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

Post 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].

pleegwat
Fast Inserter
Fast Inserter
Posts: 178
Joined: Fri May 19, 2017 7:31 pm
Contact:

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

Post 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.

Rseding91
Factorio Staff
Factorio Staff
Posts: 10331
Joined: Wed Jun 11, 2014 5:23 am
Contact:

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

Post 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.
If you want to get ahold of me I'm almost always on Discord.

mrvn
Smart Inserter
Smart Inserter
Posts: 4039
Joined: Mon Sep 05, 2016 9:10 am
Contact:

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

Post 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?

Rseding91
Factorio Staff
Factorio Staff
Posts: 10331
Joined: Wed Jun 11, 2014 5:23 am
Contact:

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

Post 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.
If you want to get ahold of me I'm almost always on Discord.

mrvn
Smart Inserter
Smart Inserter
Posts: 4039
Joined: Mon Sep 05, 2016 9:10 am
Contact:

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

Post 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.

Post Reply

Return to “Won't implement”

Who is online

Users browsing this forum: No registered users