GooberMan wrote:- ACS cannot read or write CVars during multiplayer. No exceptions. And too bad if you think you have a use for it, because you don't.
Thus removing this feature from 33% of zdoom. 66% if demos are included (they follow mostly the same rules as netgames at the moment). This means that the feature would only ever work in on very specific case: You are playing single-player and you aren't recording the game.
GooberMan wrote:Let's ignore the fact for the moment that such a "complete game state" is not saved at the moment thanks to the fact that GetCVar exists within ACS.
It's not relevant to this anyway. GetCvar exists only for 2 reasons: It can't go anywhere without breaking older mods (Ultimate Simplicity comes to mind), and it can safely retrieve relevant gamestate data anyway (such as dmflags).
GooberMan wrote:Others want to use it to do something as simple as Half Life 2 style TITLEMAP progression.
And if they want that, they should suggest something the fulfills that specific situation. Not kludges left, right and center.
GooberMan wrote:And they're all for single player purposes.
If something is for "single player only" is irrelevant. Why add features that only work for only one part of Zdoom? That would start to become maintenance hell.
GooberMan wrote:This then starts categorising CVars implicitly:
- Pure Client - Entirely superfluous to the game state. Mainly for physically interfacing the player to the game.
- Simulation Client - Defined by the mod author. Only ever used when the server is also the client.
- Pure Server - Engine state shared across multiple connected clients. These are the ones that require synchronisation to the client state when connecting to a server.
Do you even know what your talking about? "Server is also client". What server/client? Everybody has the exact same gamestate. The only difference is how input data is handled, and that info is irrelevant to any mod, especially if how input is handled changes. This counts double for peer2peer, when your concept is automatically thrown out the door as to whom the "server" is.
GooberMan wrote:With a set up like that, and once stability is proven, the system can then be taken one step further with Simulation Server CVars. These CVars would be user defined and synchronised across the network. Only the server would ever have permission to write them during a multiplayer session.
This makes even less sense. If not all nodes had permission to write cvars, this would instantly destroy the gamestate. All nodes presently need to have the exact same data. If a controller changes the dmflags, everybody has to write this data.
GooberMan wrote:(Of course, I could be assuming things the wrong way and ZDoom could still be using the original P2P model that shipped with Doom. In which case, the Simulation Server category would be unfeasible. Pure Server CVars would still be synced easilly, however.)
Of course it does. When could this have changed? Doom isn't made for an async netcode.