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

[The Zombie Killer]

I've been trying to do quite a few neat little things with ZDoom lately, but many of them require the ConsoleCommand ACS function in order to work.
I read the wiki entry and it states the following:

ConsoleCommand has often (6 times at least) been requested to be implemented into ZDoom. However it has been declined by the developers due to security risks. Because ConsoleCommand gives map authors access to the player's settings, it could easily be abused. An example would be a script that executes on the closing of the map which uses "unbind all", thus removing all of the player's current binds when he exits the game and later gets confused next time he boots up ZDoom.
For this reason, do NOT request this feature again!

By saying this, the article contradicts itself, since right above this it says:

The following commands may not be used with ConsoleCommand.
unbindall
unbind
bind
quit
exit
logfile
alias

The unbind command can't be used at all anyway!

Plus, I've never seen this be abused in Skulltag and Zandronum, so why would it be abused here? The only place I could see it be abused is in a Terrywad, and anyone in their right mind wouldn't play them anyway...

So, I plead the devs, can you please implement this function? The benefits outweigh the risks by miles.
Thank you for reading.

-TZK

[Gez]

The unbind all thing is just an example; that it doesn't apply isn't really important. In fact it's possible it applied once. There has been abuses in the past, which forced Skulltag to add more to the black list. See this discussion to see that Zandronum itself wants to deprecate it.

ACS and console are two things that should remain fully separate. The ability to query CVARs in ACS is bad enough, stability-wise (it can easily create multiplayer desyncs).

A much better approach is to request new ACS functions that cover features that only exist as console commands. The console is a cheat/debug/configuration/utility thing; it is not a gameplay thing!

[GooberMan]

I've been trying to do quite a few neat little things with ZDoom lately, but many of them require the ConsoleCommand ACS function in order to work.
...
The benefits outweigh the risks by miles.

Here's the problem with your post:

What exactly are you trying to do with console commands? There's zero indication of what you're trying to do, so how can any programmer reasonably assess your claims?

[Nash]

I see that Torr started work on SetCVar in that thread. Hopefully when its implementation is complete, we can have it backported to ZDoom for persistant mod data...

[Blue Shadow]

I'm fine with creating and manipulating custom CVARs, but not the engine's own ones. No, those are off-limits (this applies to console commands, as well).

[Nash]

Agreed... game engine cvars and especially player settings should never be touched, ever. I remember being annoyed back in the days of Skulltag when I ran mods that did weird shit to my config...

[Xaser]

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

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

[Blzut3]

Plus, I've never seen this be abused in Skulltag and Zandronum

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.

[NeuralStunner]

Slightly off-topic, but...

<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

[GFD]

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 amazingly less absolutely terrible.

[Graf Zahl]

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.

[Gez]

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

[GooberMan]

the MAPINFO/GameInfo block

That's a cross pollination of systems. KEYDEFS already exists to provide limited console functionality to any mod. This is where my defaultcvar suggestion comes in to play.

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.

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:

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

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.

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.

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

[Graf Zahl]

the MAPINFO/GameInfo block

That's a cross pollination of systems. KEYDEFS already exists to provide limited console functionality to any mod. This is where my defaultcvar suggestion comes in to play.

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.

[edward850]

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

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

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.

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.

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.

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.

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