[ACS] ConsoleCommand, read the wiki entry, devs please read!

[Gez]

ZDoom actually has two different netcode modes (peer-to-peer and packet server), but don't ask me to explain in detail the differences between both. And of course there are all the CS ports derived from ZDoom out there.

[edward850]

Peer-to-peer has every node send a "tic command" to every other node. Input data/Consistency info + any other relevant commands (ie savegame commands). All nodes must have the "tic command" of all other nodes for a specific net-tic to allow that tic to process.
Packet server is exactly what it says on the tin. It's exactly the same as before except all the "tic command"s are routed by the net_arbitrator to all other nodes.

[GooberMan]

Do you even know what your talking about?

I'm going to assume you're not a condescending moron and will actually reply to your post in a reasonable manner.

Thus removing this feature from 33% of zdoom.

Four questions: Yeah? And? So? What? The obvious point you've missed from my entire post is that the entire thing needs a remodel. And you've also overlooked the fact that there's compatability options. Any multiplayer mods that previously need to call GetCVar can have an exception added (and let's face it, there can't be that many using stock ZDoom considering the proliferation of Skulltag and Zandronum). You'll notice compatability.txt isn't an underused file if you went looking.

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.

You've missed the broader implications of the post. A recategorisation of CVar scopes doesn't mean maintenance hell at all. in fact, strict categorisation cleans everything up and makes maintenance far easier. CVars flagged for specific purposes provide a solid, unbreakable description of when it should be synced and when it should be saved in the gamestate. This is pretty simple logic.

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.

I take it you've never tried programming peer to peer then. The term "server" gets discarded in favour of "authorative game state". The naive way of doing it is by ensuring everything is in sync before moving on - ie how Doom's network code originally works. A far nicer way of doing it is letting clients get out of sync if they're performing bad (both hardware and network wise), but rather than let them negatively effect everyone's performance either all peers can work out what the correct state to sync to is; or the best performing peer can act as an authority whenever the simulation is degrading enough. The latter option is the simplest one to implement. Peer opinion is a bit of a messy subject that not a lot of research has been done with.

Simulation Server CVars ... This makes even less sense.

If you have no idea about network models, or extensibile general-purpose engines like ZDoom. Splitting in to four categories like that keeps things in the engine and in the modification cleanly. As discussed prior, even using a naive network model it makes exactly clear what the purpose of a CVar is. But even using Doom's naive network model, an authority can be found - the first peer. For all intents and purposes, the first peer can take on the server role for being the authority in a gaming session. If ZDoom's networking code hasn't changed too much over the years, then that will be a solid assumption considering anyone dropping out will cause the network session to end. No need to worry about transferring ownership at all.

When could this have changed?

Since the source was released over fifteen years ago and anyone has been free to make modifications?

So here's some questions for you: Do you have anything to say apart from what you think can't be done or doesn't make sense? Are you a programmer or just an enthusiast? Am I going to get in to another argument with someone who doesn't know as much on the subject of networking as I do, or are you going to take a stab at contributing to ZDoom's source code and solving the CVar/network issue?

[edward850]

I feel as though doing a back in forth is going to get stupidly offtopic, especially since I think our responses are based off a miss-understanding (and I'm kind of confused as to where you even stand in this issue). So instead, lets just talk about the 2 issues I have seen presented.
Issue 1: SetCvar disobeys the basic rule that saved games are a persistent state. Seeing as saved games are a thing you can do literally any time (even demos), this presents a problem.
Issue 2: SetCvar also goes against how netgames are supposed to function (presently). While various Cvars could be marked as demo/net dependent at run time (as some already are), this also presents an interesting problem: What to do with conflicts? Cvars are not split up per-player.

Both of these could be partly resolved using virtual cvar states, but that would make the feature useless in most cases that people want it (the proposed Half-life esc title map switching), and netgames would still have a problem, seeing as there can only be one cvar total. There is no per-player handling (as of yet).
So what needs to be done from here?

Also, just one side note:

If ZDoom's networking code hasn't changed too much over the years, then that will be a solid assumption considering anyone dropping out will cause the network session to end. No need to worry about transferring ownership at all.

This hasn't been true since Vanilla Doom (and thus Zdoom). The peer-to-peer structure will happily allow any player to drop and the game will continue as is. Zdoom also sets the net_arbitrator to the next available node if the original happens to disconnect. Zdoom's Packet Server mode even tries this, granted with no foresight that the next available node can even be contacted and the game therefor has a chance to stop dead right then and there.
Also any nodes recording will stop recording as demos don't currently handle dropped players. That really should be sorted.

[Xaser]

If it's worth interjecting a random modder's opinion, the biggest limitation with GetCVar is that it doesn't work in netgames (though savegame persistence is just as important in practice, I'd wager). It's stopped me from adding custom user options in mods in the past precisely because different user options would breakify netgames pretty much immediately. The proposed suggestions with being able to declare CVars mod-side would be super-handy, particularly if they can be marked as savegame/demo/netgame persistent (though I guess I can see cases where a setting would want to be persisted outside of a save, e.g. a cvar that controls the density of weather effects for CPU-saving purposes or somesuch).

[GooberMan]

I feel as though doing a back in forth is going to get stupidly offtopic, especially since I think our responses are based off a miss-understanding

Thank you. I agree.

Issue 1: SetCvar disobeys the basic rule that saved games are a persistent state.

My stance here is categorisation of CVars. CVars are the handiest form of persistent data that exists in ZDoom. They can be created outside of a game instance and modified outside of a game instance. These range from mostly harmless like audio settings to gameplay altering like monster infighting functionality. These in-built variables can be categorised in a method that indicates how destructive they are on the gameplay and whether they should save with the gamestate or not. For simplicity's sake, client and server are the terms I've used as they immediately communicate to anyone what their functionality is. Client side variables and effects are things that have zero affect on the game state. Audio volume is the prime example there. Server side variables and effects are things that have a tangible impact on the game state. Monster infighting, for example, would radically affect a cooperative match. Server side varaibles would be expected to sync at the start of a multiplayer session. Preferably they would be immutable for the entire session too, however someone with admin priveleges could alter them and have them propagate across the session quite easily. Saving the game state would simply be a case of taking a copy of the relevant server CVars and restoring them on load.

As these variables originate from ZDoom, a further distinction of "Pure" can be placed on them. These variables are guaranteed to exist across all instances of ZDoom. Pure client variables can live in the INI file as they currently do. Pure server variables should have a bit of extra care added to them - upon starting a new session, they are reset to a set of values provided to them my the server creator. For a single player game, these values are hardcoded profiles. For a configurable multiplayer game, that's up to the session creator to alter. Having a set of defaults to work from is nice though, so for human usability it can steal them from the single player profile.

Mods (or "simulations" to use the term I used earlier) are a different story. It's not like the Quake days where you could load up some QuakeC or a DLL in Quake 2 and have things just work. Quake puts a lot more power in the modder's hands than ZDoom does. Persistent data can be tied up in CVars fairly simply, but straight away they won't be Pure. They're originated from a mod, and it should not be ZDoom's responsibility to maintain them all the time. The issue of synchronisation will pop up though. This can be quite simply solved by applying the same distinctions to Simulation CVars as Pure CVars. Simulation Client CVars would generally be harmless things like text speed, or client side effects that don't impact the game state. These can get saved in the appropriate section of the ZDoom INI (or a Simulation INI). Simulation Server CVars, likewise, would be stuff that gets synced upon session create/join and get saved to the game state. Things like (for a bare bones example) how often a custom item respawns would be Simulation Server settings and would require synchronisation across all game states, be they multiplayer, previously-saved, or demos.

This only leaves the question of what SetCVar can alter. Pure variables are out of the question. These are the responsibility of ZDoom, not the modder. Simulation Server variables should follow the same immutable rules as Pure Server variables. Simulation Client variables are the obvious choice. Suddenly, you can save the high score you always wanted so that it would persist across sessions. Or keep a track of character progress, either through levelling up or via mod progression.

It is true that this can be open to abuse - things you'd want to be persistent across a save state like the character's abilities at that point in time wouldn't work with Simulation Client variables. These, however, I think would benefit most from virtualisation. Simulation Client variables would vary for each connected player, but they also want to be saved in the gamestate. The server in this case would want to keep a copy of each client's variables and save/synchronise them as necessary. This requires the modder to program things correctly ACS side. But at some point, trust has to be given to the modder. Yes, it will result in questions on the forums and bugs that modders don't understand. Over time though, a collective knowledge base of best practices will emerge.

Issue 2: SetCvar also goes against how netgames are supposed to function (presently).

I got down here and was ready to detail more of what I mean, but then I realised it was completely covered with the above.