ZDoom

[quote="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[/quote]
Thank you. I agree.

[quote="edward850"]Issue 1: SetCvar disobeys the basic rule that saved games are a persistent state.[/quote]
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 [url=http://zdoom.org/wiki/CVARs:Audio]audio settings[/url] to gameplay altering like [url=http://zdoom.org/wiki/CVARs:Configuration]monster infighting functionality[/url]. 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.

[quote="edward850"]Issue 2: SetCvar also goes against how netgames are supposed to function (presently).[/quote]
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.

If it's worth interjecting a random modder's opinion, [i]the[/i] 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).

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:
[quote="GooberMan"]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.[/quote]
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.

[quote="edward850"]Do you even know what your talking about?[/quote]
I'm going to assume you're not a condescending moron and will actually reply to your post in a reasonable manner.

[quote="edward850"]Thus removing this feature from 33% of zdoom.[/quote]
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.

[quote="edward850"]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.[/quote]
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 [b]when it should be synced[/b] and [b]when it should be saved in the gamestate[/b]. This is pretty simple logic.

[quote="edward850"]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.[/quote]
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.

[quote="edward850"]Simulation Server CVars ... This makes even less sense.[/quote]
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.

[quote="edward850"]When could this have changed?[/quote]
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?

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.

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.

[quote="GooberMan"][list][*]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.[/list][/quote]
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.

[quote="GooberMan"]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.[/quote]
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).

[quote="GooberMan"]Others want to use it to do something as simple as Half Life 2 style TITLEMAP progression.[/quote]
And if they want that, they should suggest something the fulfills that specific situation. Not kludges left, right and center.

[quote="GooberMan"]And they're all for single player purposes.[/quote]
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.

[quote="GooberMan"]This then starts categorising CVars implicitly:

[list][*][b]Pure Client[/b] - Entirely superfluous to the game state. Mainly for physically interfacing the player to the game.
[*][b]Simulation Client[/b] - Defined by the mod author. Only ever used when the server is also the client.
[*][b]Pure Server[/b] - Engine state shared across multiple connected clients. These are the ones that require synchronisation to the client state when connecting to a server.[/list][/quote]
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.

[quote="GooberMan"]With a set up like that, and once stability is proven, the system can then be taken one step further with [b]Simulation Server[/b] 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.[/quote]
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.

[quote="GooberMan"](Of course, I could be assuming things the wrong way and [b]ZDoom could still be using the original P2P model that shipped with Doom.[/b] In which case, the Simulation Server category would be unfeasible. Pure Server CVars would still be synced easilly, however.)[/quote]
Of course it does. When could this have changed? Doom isn't made for an async netcode.

[quote="GooberMan"][quote="Gez"]the MAPINFO/GameInfo block[/quote]
That's a cross pollination of systems. KEYDEFS already exists to provide limited console functionality to any mod. This is where my [url=http://forum.zdoom.org/viewtopic.php?f=15&t=35742]defaultcvar[/url] suggestion comes in to play.
[/quote]


No, no, no!

KEYCONF is supposed to be deprecated for everything except what its name applies.
Assing new functionality to that mess of a lump is a very bad idea.

Stuff like this is supposed to be done with MAPINFO now because that's the one lump that's used to configure the engine for a mod.

[quote="Gez"]the MAPINFO/GameInfo block[/quote]
That's a cross pollination of systems. KEYDEFS already exists to provide limited console functionality to any mod. This is where my [url=http://forum.zdoom.org/viewtopic.php?f=15&t=35742]defaultcvar[/url] suggestion comes in to play.

[quote="Graf Zahl"]Since they are part of global engine state they currently violate one important rule: A savegame must be a self-contained state of a game session and restoring it must always start the game in the exact same state.[/quote]
And yet, I'm not sure it's an entirely applicable argument.

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. There's nothing inherently wrong with altering the persistent engine state if you put in a few rules as to what you can modify. I'm using CVars to alter text speed for cutscenes (as well as debugging ACS systems). Others want to use it to do something as simple as Half Life 2 style TITLEMAP progression. In cases like this, they're fairly safe unobtrusive uses of CVars. And they're all for single player purposes.

So from here, as I see it, the rules should be as follows:

[list][*]ACS cannot set CVars that haven't been defined by the user/mod author. EVER. No exceptions.
[*]ACS cannot create CVars from scratch. No exceptions.
[*]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.[/list]

This then starts categorising CVars implicitly:

[list][*][b]Pure Client[/b] - Entirely superfluous to the game state. Mainly for physically interfacing the player to the game.
[*][b]Simulation Client[/b] - Defined by the mod author. Only ever used when the server is also the client.
[*][b]Pure Server[/b] - Engine state shared across multiple connected clients. These are the ones that require synchronisation to the client state when connecting to a server.[/list]

With a set up like that, and once stability is proven, the system can then be taken one step further with [b]Simulation Server[/b] 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.

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

The way I see it, the MAPINFO/GameInfo block would contain a list of declared custom CVARs along with their default value. By being marked in a GameInfo block, the engine would then know they are relevant to the current game, and would allow SetCVAR to modify them. (Any CVAR, custom or not, not in this list would not be affected.) They'd be written in savegames and demos and synched on the network (unless explicitly marked as client-side).

This has been and still is on the #1 spot of 'won't ever be added' features. Executing console commands from a script is a big 'NoNo' for good reasons.

As for custom CVARs, the problem with that is that their handling at the moment is far from stable. Since they are part of global engine state they currently violate one important rule: A savegame must be a self-contained state of a game session and restoring it must always start the game in the exact same state.

Would a SetCVar with "user_" variables mean we could actually use MENUDEF to change settings for things like ACS-controlled HUDs instead of making binds for them? Because that'd be [i]amazingly[/i] less absolutely terrible.

Slightly off-topic, but...[quote]<NeuralStunner> Would it be reasonable for a "SetCVar" function to be limited to names starting with "user_"?
<NeuralStunner> That would inherently block out user-setting tampering.
<Blzut3> something like that yaeh[/quote]

[quote="The Zombie Killer"]Plus, I've never seen this be abused in Skulltag and Zandronum[/quote]
A few days ago I was debugging an ACS script for Zandronum. It forced cl_run on to fix "noob settings." Yes it's being abused.

Everyone here has said everything that needs to be said. Come up with a solution to do what you want to do that doesn't break demo or network sync, and can not violate save games being a complete save of the game state.

Gez has the right thinking: If there's something useful that can only be done with ConsoleCommand and nothing else, then it should be suggested as a feature of its own.

CVARs are the one big outlier, but otherwise I'm fairly certain that most cases of ConsoleCommand being used for something that can't yet be done is to work around limitations of Skulltag/Zandronum caused by the featureset being a bit behind (i.e. the functionality likely already exists in ZDoom proper). At least, the last time I discussed this with someone, everything it was used for in his case (sans cvars) turned out to be a case of "This can already be done". :P

[EDIT] Note that I'm talking [i]custom cvars[/i] here, not setting engine-side ones (unless someone's comfortable with whitelisting a few).