Runtime loadgame during multiplayer sessions?

[Nash]

The only way to load saved games in multiplayer is at the command line. What's stopping GZDoom from allowing load games during a play session? I take it it's not as easy as "just" loading the game for every node at the same time?

[Rachael]

If I were to code this, I would have the person loading the game actually distribute the game state to all clients in order to ensure everyone has the same copy of the game. It does not need to even be stored on the disk temporarily for this.

I believe something like this is doable, however care must be taken to ensure that every possible part of the game sim is reset properly on all client computers when the load is completed, in order to ensure proper determinism and synchronization.

So in short, doing something like this would be quite an undertaking. It is very difficult to tie up all your loose ends for this.

[Graf Zahl]

Trivia: Most of the Build games outright block savegames in multiplayer. For a P2P networking implementation this is a non-trivial issue to ensure that all nodes end up with a compatible state

[Nash]

So the Doom engine is superior in that department.

[Rachael]

Barely.

If you have your ducks lined up in a row it'll work. But it's a house of cards. It doesn't take much more than a stiff breeze to make it come tumbling down.

Determinism is great for things like Chess where the rules are simple and mathematical and the possible outcome of every game is, though quite numerous, still limited. For any sort of FPS where the divergence factor is exponentially greater, it just barely works as it is, nevermind introducing things like game saving/loading into the mix. A state replication system (i.e. Quake, Zandronum, etc) would be far superior for a game like Doom, overall, and would make things like this a lot less burdensome to implement.

[Graf Zahl]

Exactly. Unfortunately, Doom's entire setup is the antithesis of doing such a thing, there's a reason why Zandronum is probably stuck in the past forever.
There's also a reason why I deem multiplayer in Raze unfeasible. The amount of work needed to get this running is simply too large.
C/S systems also have their disadvantages - either you get a game like Quake 1 or 2 which has been built from the ground up as C/S or your C/S parts become too invasive as in Zandronum or even worse you have to brute force it like EDuke32 where the entire objective becomes to shrink down the entire global game state into something transmissible with as little time spent as technically possible - this requires several 100's of megabytes of intermediate storage! This can be done for an engine with a limited state set but would be impractical for Doom, where game state consists of lots of dynamic objects - never mind all the custom HUD code which want access to all parts of the playsim, meaning you cannot cut down on non-essential data.

So my approach to MP is - what you see is what you get. The feature set as-is won't get expanded but don't expect anybody to actively work on this code.