Page 1 of 1

Section for known desync mods.

Posted: Wed Oct 05, 2016 4:44 pm
by therealk1ll3r
Is there any way we could have a section on the forum added for the Multiplayer side.
Where people can post mod names that are known or they have found to be causing desyncs?

-Matt

Re: Section for known desync mods.

Posted: Wed Oct 05, 2016 5:08 pm
by aubergine18
Just create a topic in MP forum and start listing the mods (and their versions). I'm sure mod authors would also want to know if their mod causes desync.

Re: Section for known desync mods.

Posted: Thu Oct 20, 2016 7:12 pm
by kinnom
just create a bug report. mods should not be able to cause a desync

Re: Section for known desync mods.

Posted: Thu Oct 20, 2016 7:35 pm
by Klonan
kinnom wrote:just create a bug report. mods should not be able to cause a desync
Thats entirely not true, there are numerous ways a bad script can cause a desync

Re: Section for known desync mods.

Posted: Thu Oct 20, 2016 8:04 pm
by kinnom
Klonan wrote:
kinnom wrote:just create a bug report. mods should not be able to cause a desync
Thats entirely not true, there are numerous ways a bad script can cause a desync
such as?

Re: Section for known desync mods.

Posted: Thu Oct 20, 2016 8:21 pm
by Klonan
kinnom wrote:
Klonan wrote:
kinnom wrote:just create a bug report. mods should not be able to cause a desync
Thats entirely not true, there are numerous ways a bad script can cause a desync
such as?

Setting variables outside of events is a typical one, storing global variables not in the global.table is another, something as simple as this will desync the game:

Code: Select all

index = 1

script.on_event(defines.events.on_tick, function (event)
  index = index + 1
  if index == 10 then game.print("Hello") end
  if index == 20 then game.print("Goodbye") index = 1 end
end)
Now when player 1 starts the game, the index will be initialised from the script, and each tick it will go up by 1, and when it reaches 20 it will go back to 1,

However when someone else joins the game, index will be initialised as 1 for that player, regardless of the index in the first players game state, which means when the event runs, the index will be different, and different actions will occur, aka a desync.

Re: Section for known desync mods.

Posted: Thu Oct 20, 2016 9:12 pm
by aubergine18
Why does player 2 cause the script to reinitialise? I thought in MP there was one instance of the mod running for all players? Or does a copy of the mod run on every client (and also the server)?

Re: Section for known desync mods.

Posted: Thu Oct 20, 2016 9:46 pm
by daniel34
aubergine18 wrote:Why does player 2 cause the script to reinitialise? I thought in MP there was one instance of the mod running for all players? Or does a copy of the mod run on every client (and also the server)?
A copy of the mod runs on every client (and the server) independently from each other. That's the reason desyncs occur in the first place: two peers end up with different gamestates.
If there was only one instance of the mod running then all variables/tables and every action the mod took would have to be sent to other peers over the network (possibly every tick) and with mods that aggregate and process a lot of data and entities this would cause a lot of traffic.
This is also true for vanilla games as the game data itself is also considered a mod, the base mod.

Re: Section for known desync mods.

Posted: Thu Oct 20, 2016 10:46 pm
by aubergine18
Very well explained, thank you! I've been trying to wrap my head around how mods work in MP for ages and I think I finally get it!

Re: Section for known desync mods.

Posted: Fri Oct 21, 2016 8:01 pm
by GoldenPorkchop80
daniel34 wrote:A copy of the mod runs on every client (and the server) independently from each other. That's the reason desyncs occur in the first place: two peers end up with different gamestates.
Klonan wrote:Now when player 1 starts the game, the index will be initialized from the script, and each tick it will go up by 1, and when it reaches 20 it will go back to 1,

However when someone else joins the game, index will be initialized as 1 for that player, regardless of the index in the first players game state, which means when the event runs, the index will be different, and different actions will occur, aka a desync.
So, what i'm getting from all of this is that [most] factorio multiplayer runs off of a peer-to-peer system; There is no real host server, every system is connected to every other system, and a desync is a domino effect (although that when it comes to Factorio, this isn't true, since when my friend desyncs, there isn't a catastrophic network failure; other players will continue to play normally, since their seperate downloaded gamestate are isolated from the failure.)
But that is also the reason why desyncs happen. As the system the mods put in place may be the most relevant atm, it also causes the desync issue.

So, I was going to recommend a client-server model; all players are connected to a central server. That central server hosts the only gamestate running, everyone connecting only sees the current snapshot of the game and the area that the player is in. Every area that the players arn't in is saved to the Process ROM and dumped from RAM cache, and then de-rendered (except for processes that require the area to be rendered so that it will function even if the players arn't there.). Once they re-enter that area, callback for that area is activated; ROM gives RAM the latest data and creates a cache, and the area is subsequently rendered from RAM data, including all non-active processes. (Kinda like Minecraft's Render system.)
This system would eliminate desyncs, because as I mentioned earlier, the "game" that the player is running is just a snapshot of the current gamestate; the actual game running on the server does all of the work.
Which is its downfall, unfortunately.
If one person was connecting from, let's say, really far away, any actions that that person would do, like walking forward, would take a really long time to reach the server and once the data reached the server, it would take another long time to respond to that command. By the time that server data reached the player, it could take as much as 2 seconds to preform an action, which would really be annoying for something as simple as walking. :x
Plus, this would also affect everyone else that connected to the server, since the server would need every system's consent to move onto the next frame.

So, I was possibly thinking something along the lines of the Client-Server model, but with something along the lines of a message queue system. I'll leave a link for you guys to read about here: https://en.wikipedia.org/wiki/Message_queue

Also, please correct me if i'm wrong. I actually prefer constructive criticism. Just don't be an as*hole.

Re: Section for known desync mods.

Posted: Fri Oct 21, 2016 8:17 pm
by ssilk
Hm, What's really needed is some kind of player simulation, so that a modder can test the game, as if there are other players online.

Re: Section for known desync mods.

Posted: Sat Oct 22, 2016 6:12 pm
by kinnom
ssilk wrote:Hm, What's really needed is some kind of player simulation, so that a modder can test the game, as if there are other players online.
remember this?