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