Desync issues with replicating an array.

[iUltimateLP]

So its getting hot now..
As some of you might know, I do the SimpleTeleporters mod. I made some changes to make the GUI syncronized (any player can open it invidually) (right now in the stable release, it works but if one player invokes the GUI, everybody sees it). This is now changed cause I created an array containing

guistates_per_player = {p = player, s = state (true/false), t = aimed teleporter, m = mode ("links", "wiki" or "current)}

This array is checked with several functions inside one gui_tick(currentPlayer) which runs every tick for every player. The most code part is then in control.lua and gui.lua (I marked the multiplayer stuff with comments).

So I know this is network bandwith heavy (I mean replicating one array every tick for every player), but Im not that performance guy and I don't know how to reduce that syncing to a mininum. Right now, you can't even join together because the player will immediatly reconnect because of the Desync and after 10 tries or so he disconnects.

Does any Modder have an idea how to do that? Help is really appreciated..

The source (with that desyncy part already on (Commit #9)): https://github.com/iUltimateLP/Factorio ... eleporters

Thanks!

[orzelek]

From what I know you are causing the desync by mod behavior. You can't make the game work differently for different players.
At least thats what I understood from some desync discussions - gui is part of game state so it needs to be identical.

[iUltimateLP]

From what I know you are causing the desync by mod behavior. You can't make the game work differently for different players.
At least thats what I understood from some desync discussions - gui is part of game state so it needs to be identical.

Hmm, so an GUI which can be opened and closed at every client seperatly would be not possible? Or are there some kind of workarounds?

[ratchetfreak]

From what I know you are causing the desync by mod behavior. You can't make the game work differently for different players.
At least thats what I understood from some desync discussions - gui is part of game state so it needs to be identical.

Hmm, so an GUI which can be opened and closed at every client seperatly would be not possible? Or are there some kind of workarounds?

actually all code is run on all clients.

guis for other players are suppressed and clicks on them passed to the other clients and all get the same on_gui calls

[iUltimateLP]

From what I know you are causing the desync by mod behavior. You can't make the game work differently for different players.
At least thats what I understood from some desync discussions - gui is part of game state so it needs to be identical.

Hmm, so an GUI which can be opened and closed at every client seperatly would be not possible? Or are there some kind of workarounds?

actually all code is run on all clients.

guis for other players are suppressed and clicks on them passed to the other clients and all get the same on_gui calls

yeah thats why I created this array so all in all its just a list of players who should See the GUI, and which not..

[iUltimateLP]

So to conclude what we need is a Server-Client model like in Just Cause 2 Multiplayer Server for example.
You got one client.lua and one server.lua, so that way we would move GUI stuff into the client and handling teleports into the server.lua.. Will post this as a wanted feature.

[Zeblote]

So to conclude what we need is a Server-Client model like in Just Cause 2 Multiplayer Server for example.
You got one client.lua and one server.lua, so that way we would move GUI stuff into the client and handling teleports into the server.lua.. Will post this as a wanted feature.

We do indeed need that as soon as possible, just running everything on all clients makes no sense for things like user interfaces. What you're doing with a gui is not relevant to the game state until you actually apply something, which can be sent to the simulation as a custom event/input.

That doesn't mean you can't do this with the current inefficient system, though. In gui click events you get a reference to the player that clicked them. So if you have a button that opens the gui you just add it to that player.gui and only he will see it. Look at a mod with a simple gui like blueprint string to get an idea of how it works

[Rseding91]

So to conclude what we need is a Server-Client model like in Just Cause 2 Multiplayer Server for example.
You got one client.lua and one server.lua, so that way we would move GUI stuff into the client and handling teleports into the server.lua.. Will post this as a wanted feature.

There is no client and there is no server. There are only peers.

You just react to the events as you would any player and store what you need to store in "global.something". your issue is you're storing the GUI state in a local variable and that's not saved to the game.

That causes the local variable to be set and then when the player saves the game, exits, and loads it that information is gone. The same thing happens when someone connects to the other peer - the local information is not saved and restored on the new connected peer and different stuff happens on each peer's simulation resulting in a desync.

If you want an example of a fully working multiplayer GUI you can look at the one I have I my Forcefields mod here: https://github.com/Rseding91/Force-Fiel ... ontrol.lua

[iUltimateLP]

So to conclude what we need is a Server-Client model like in Just Cause 2 Multiplayer Server for example.
You got one client.lua and one server.lua, so that way we would move GUI stuff into the client and handling teleports into the server.lua.. Will post this as a wanted feature.

There is no client and there is no server. There are only peers.

You just react to the events as you would any player and store what you need to store in "global.something". your issue is you're storing the GUI state in a local variable and that's not saved to the game.

That causes the local variable to be set and then when the player saves the game, exits, and loads it that information is gone. The same thing happens when someone connects to the other peer - the local information is not saved and restored on the new connected peer and different stuff happens on each peer's simulation resulting in a desync.

If you want an example of a fully working multiplayer GUI you can look at the one I have I my Forcefields mod here: https://github.com/Rseding91/Force-Fiel ... ontrol.lua

So you mean, actually instead of having local variables, just a change to global ones would do the job?