Page 1 of 1
on_gui_opened latency in multiplayer?
Posted: Wed Oct 28, 2020 2:37 pm
by Deadlock989
I have been using on_gui_opened to override specific machine guis - usually just to cancel them with player.opened = nil but in another case to replace the machine's gui with a custom one.
Have been doing some multiplayer testing and found out that for non-hosting clients there is an appreciable delay in the gui being overridden. This is with two Factorio instances running on the same machine (Steam and zip) so latency should be pretty low. The "native" gui appears and is then either replaced or removed a significant fraction of a second later. In single player / for the host, this is invisible.
For other kinds of entity in the past I have used a custom input instead of on_gui_opened and notice a slight delay on that as well, but in those cases the entities don't have their own GUI (simple-entity-with-owner etc.) so it doesn't look as bad.
Is there a better way of doing this? Some other native way of suppressing a machine's gui that doesn't stop it being operable?
Re: on_gui_opened latency in multiplayer?
Posted: Sat Oct 31, 2020 12:51 pm
by Deadlock989
Anyone?
This bothers me because if it is expected behaviour then half of what I thought I knew about control scripts is wrong. I thought that every client runs its own copy of control.lua in lockstep with the host - that is why desyncs from variables outside of the global table are a thing. If the client is running and firing its own on_gui_opened then why is there is an apparent lag for clients?
This is the kind of thing I am doing in on_gui_opened:
Code: Select all
script.on_event(defines.events.on_gui_opened, function(event)
if event.gui_type ~= defines.gui_type.entity then return end
local player = game.players[event.player_index]
local selected = event.entity
if selected and selected.valid and some_condition_is_met(selected) then player.opened = nil end
if selected and selected.valid and some_other_condition_is_met(selected) then
do_something(selected)
end
end)
Re: on_gui_opened latency in multiplayer?
Posted: Sat Oct 31, 2020 1:58 pm
by DaveMcW
This is a latency hiding trick. The client user is allowed to peek at the gui, until they recieve the gui close command from the server.
If the client tries to do anything on the preview gui, it should stall until the server confirms that the gui is still open.
Re: on_gui_opened latency in multiplayer?
Posted: Sat Oct 31, 2020 2:51 pm
by Deadlock989
DaveMcW wrote: Sat Oct 31, 2020 1:58 pm
This is a latency hiding trick.
The irony.
I can live with losing some of these (the cancels) but the one I'm really interested in is an electric-energy-interface with gui_mode = "none" - which turns out not to be "none" at all but one of those pointless "here is a picture of the entity in a frame with no buttons to press except close" GUIs.
Oh well, it's not game-breaking.
Re: on_gui_opened latency in multiplayer?
Posted: Sat Oct 31, 2020 3:38 pm
by eradicator
Maybe you can prevent the opening from happening in the first place. For example by deselecting the entity in an 'open-gui' linked-control event. Or overlay an invisible second entity that steals all the clicks, or plain making the entity unoperable and drawing your own selection box so it doesn't look red... no, i don't have any nice ideas on this one, only ugly hacks.
Re: on_gui_opened latency in multiplayer?
Posted: Sat Oct 31, 2020 6:17 pm
by Squelch
I'm glad I'm not the only one to be experiencing this. I thought it was something I was doing wrong. Single player certainly is invisible, but not only do I see the GUI briefly in a MP scenario, but I also hear the sound - twice - once for the original, and again for my replacement.
I had asked in modding help before about replacing/modifying/enhancing the base GUI, and it was quickly shot down as a potential for bad actors and sabotage. Such a shame that the first thoughts on a potentially enabling thing are so cynical. Anyway, I do hope that there might be a solution that isn't so hacky or poorly performing.