[2.13] Mission overrides for cvars

[stgatilov]

There are two ways to override cvars in a mission:

• mission.cfg file can set non-archived cvars (starting with 2.12).
• sys.setcvar in game script can override cvars (starting with 2.13 / dev17044-10746).

Of course, there has never been any effort to classify cvars into public and private, no thinking of backwards compatibility of relying on cvars, etc. So overriding cvars should be considered a last resort feature.

mission.cfg allows to statically override cvars on FM level.
The change takes effect during all missions in a campaign and all briefings/debriefings/menus.
However, you cannot adjust cvar value during gameplay, so only one constant literal value can be set.

The implementation is simple:

• mission.cfg file is executed from your mission when TDM engine starts
• all non-archived cvars are reset to their defaults when TDM engine restarts (due to FM change)

sys.setcvar allows to override cvars on gameplay level.
These overrides behave like the variables in game scripts, i.e. they are saved/restored to savefile and reset on game start/end.
You can adjust the same cvar several times with different values, and savefile will capture the override that is currently active.
The minor downside is that these overrides automatically don't carry over between missions in campaign, and they cannot work in briefings/debriefings/menus.

Note that sys.setcvar has been available for a long time already, but previously it had different meaning.
Previously it set the cvar as if the player set it himself. So the values stuck between restarts, missions, FMs (even saved to darkmod.cfg for archived cvar). Now it always sets the "mission override" for cvar.

You can test cvar mission overrides manually using two new console commands:

• setm {cvarname} {newvalue} --- set mission override for the cvar with given value
• unsetm {cvarname} --- drop mission override for the cvar

It is not perfectly obvious what should happen if mission-overridden cvar is changed by user.
Right now the main value of cvar is changed and mission override is broken/erased in this case.
So be wary that user can mess with your overrides just like you can mess with his cvars.

See also: 5453

[stgatilov]

The remaining questions from my side:

• Do we need the ability to override cvars during briefings/debriefings/menus?
• Do we need sys.unsetcvar script event which works like unsetm console command?

[datiswous]

49 minutes ago, stgatilov said:

Do we need the ability to override cvars during briefings/debriefings/menus?

I would like to know in what cases this could be useful, considering how (I think) limited briefings/debriefings currently are.

But maybe you don't know either.

[stgatilov]

25 minutes ago, datiswous said:

I would like to know in what cases this could be useful, considering how (I think) limited briefings/debriefings currently are.

Yes, I'm asking because I'd like to know that too

[nbohr1more]

Perhaps my imagination is failing me but the only use-case I see for GUI provoked cvar changes at the mission level are for something like Heart of Lone Salvation where players can choose “difficulty levels” that also impact performance. Still, lod_bias seems to be a better way to toggle such differences. Perhaps we need to create new lod_bias entity args like:

“lod_bias_cvar” “r_something, 1”

which change the specified cvars based on lod_bias min / max behavior

 

[stgatilov]

3 hours ago, nbohr1more said:

Perhaps my imagination is failing me but the only use-case I see for GUI provoked cvar changes at the mission level are for something like Heart of Lone Salvation where players can choose “difficulty levels” that also impact performance.

This can't be done with mission.cfg anyway.

[stgatilov]

I suggest deleting mission.cfg support and reworking all missions to use scripts + mission overrides instead.

Because right now people assume it works and get surprised when it does not.

[stgatilov]

Or alternative solution is to replace mission.cfg with cvars.txt with a different format (just cvar + value instead of "set" commands) and handle it directly, with a completely separate code. But this probably won't happen in 2.14.

[Amadeus]

Perhaps this would be a good reason into looking at running scripts before void main()? 

[nbohr1more]

I feel like I am in a loop.

Unless I am mistaken, mission.cfg was supposed to only temporarily apply cvars while a mission is installed. I do recall a great deal of back and forth on this. In the original Doom 3 you could add a doomconfig.cfg file to your mod pack to override default cvars and this config would only be active when the mod was active.

[Wellingtoncrab]

10 hours ago, stgatilov said:

Because right now people assume it works and get surprised when it does not.

Yeah I am a bit confused myself - shouldn't we be surprised it doesn't work as seemingly intended?

On 5/25/2024 at 2:52 AM, stgatilov said:

mission.cfg allows to statically override cvars on FM level.
The change takes effect during all missions in a campaign and all briefings/debriefings/menus.
However, you cannot adjust cvar value during gameplay, so only one constant literal value can be set.

The implementation is simple:

• mission.cfg file is executed from your mission when TDM engine starts
• all non-archived cvars are reset to their defaults when TDM engine restarts (due to FM change)

What are we actually missing? Is the distinction some cvars are this "archived" variety and others are not?

[stgatilov]

11 minutes ago, Wellingtoncrab said:

Yeah I am a bit confused myself - shouldn't we be surprised it doesn't work as seemingly intended?
What are we actually missing? Is the distinction some cvars are this "archived" variety and others are not?

Cvar is archived if it is saved in darkmod.cfg and persists between TDM runs.
Non-archived cvars are not saved anywhere and are reset to default automatically on full TDM restart.

For instance, decl_fix_mission_override is non-archived, r_shadows is archived.

[Wellingtoncrab]

2 minutes ago, stgatilov said:

Cvar is archived if it is saved in darkmod.cfg and persists between TDM runs.
Non-archived cvars are not saved anywhere and are reset to default automatically on full TDM restart.

For instance, decl_fix_mission_override is non-archived, r_shadows is archived.

Well that's still rather confusing - if the mission.cfg is supposed to work with archived cvars, and unarchived cvars just reset when the game restarts anyway - why are there cvars which don't work with the mission.cfg?

[STiFU]

Could we not simply automatically replace any occurence of "set" in mission.cfg with "setm" and we are done?  

[stgatilov]

1 minute ago, STiFU said:

Could we not simply automatically replace any occurence of "set" in mission.cfg with "setm" and we are done?  

Nope:

1. Mission override is part of gameplay state. It is saved/restored to savefile, and it is dropped on game start/end. If you run setm on engine start, it will be dropped when game starts.
2. While missions can be updated to use "setm" instead of "set", the engine definitely should not do it automatically. For the engine, any .cfg file is like a .bat file on top of game console. Making its behavior special depending on filename is an awful idea.

So it needs some new development, some new rules.
Add "cvars.ini" file which is in INI format (we already have parser). Add function which loads and applies it as mission overrides. Put the call of this function in various places... not even sure in which exactly.

[STiFU]

Ok, got it. I guess we should evaluate how many missions there are that use a mission.cfg and whether they set any archived cvars. We would need to patch those missions then, but what should the engine do, when it encounters a mission.cfg because somebody has an old mission lying around? Would that FM be kind of broken then, according to the author's intent? 

[stgatilov]

54 minutes ago, STiFU said:

I guess we should evaluate how many missions there are that use a mission.cfg and whether they set any archived cvars.

There are 8 missions + Displacement I think.

Quote

We would need to patch those missions then, but what should the engine do, when it encounters a mission.cfg because somebody has an old mission lying around?

It's either nothing (because reading mission.cfg should be deleted in the code), or "something" just like now.
I prefer the first case.
 

[stgatilov]

Right now there are the following important points:

1) Engine initialization: that's where mission.cfg is loaded just before autoexec.cfg.
I can replace it with setting mission overrides from cvars.ini.
Also, should user's autoexec.cfg break mission overrides in case of collision?

2) Starting new game.
Right now mission overrides are reset to "none" here, I can change it to setting them to the state stored in cvars.ini.

3) Shutdown of a game.
Right now mission overrides are dropped here to, I can change it and set the state from cvars.ini.

4) Save/load game.
Here state of mission overrides is saves to savefile or reset from it.
No need to change anything here.

As far as I understand, this will achieve more or less what mappers want for simple and global cvars control.
Of course, user can accidentally "break" mission override without noticing.

[Wellingtoncrab]

7 minutes ago, stgatilov said:

Also, should user's autoexec.cfg break mission overrides in case of collision?

I believe mission.cfg was conceived in part to remove the potential for cvar overrides done via scripts and def files from superseding a users autoexec file.

It's not important to me personally and seems like a mixed bag, as there is probably an accessibility angle to some user’s overrides, but if a mission is designed around a certain setting loading it seems like you'd want to be certain it would load.

[stgatilov]

There is a problem with overriding pm_something cvars using the new mechanism.
They are also controlled using spawnargs on player entity.
When both mechanisms are used together, it causes chaos.
 

[datiswous]

On 2/3/2026 at 7:41 PM, stgatilov said:

Right now there are the following important points:

1) Engine initialization: that's where mission.cfg is loaded just before autoexec.cfg.
I can replace it with setting mission overrides from cvars.ini.
Also, should user's autoexec.cfg break mission overrides in case of collision?

2) Starting new game.
Right now mission overrides are reset to "none" here, I can change it to setting them to the state stored in cvars.ini.

3) Shutdown of a game.
Right now mission overrides are dropped here to, I can change it and set the state from cvars.ini.

4) Save/load game.
Here state of mission overrides is saves to savefile or reset from it.
No need to change anything here.

As far as I understand, this will achieve more or less what mappers want for simple and global cvars control.
Of course, user can accidentally "break" mission override without noticing.

Why do you need to set anything on game shutdown?

[stgatilov]

I changed the way mission.cfg works in trunk: https://bugs.thedarkmod.com/view.php?id=6674
Now the values are converted to mission overrides and take effect outside game as well.

 

Speaking of pm_* cvars.

If I'm not mistaken, the spawnarg mechanism is customized in missions:

• gemcutter
• hazard
• moongate
• prize
• snowed_inn

The mission.cfg mechanism is used in missions (bold shows which missions override pm_* cvars with it):

• cauldron_v2_2
• gemcutter
• imperial_sword
• iris
• krampus
• lookwhosmoving
• painterswife
• scrooge

What I can suggest here is:

1. Delete pm_* from the core atdm:player_base and the accompanying C++ code.
2. Update the missions which use these values by adding mission.cfg with these values

As the result, TDM 2.14 and later will be able to set mission overrides for these cvars. At least I hope so
If it works properly, then the missions will work in 2.14 just like they did previously.
TDM 2.11 and earlier will work just as they worked at that time.
As for TDM 2.12 and TDM 2.13, I have no idea what happens. Perhaps the custom values will leak.

UPDATE: pm_* spawnargs on player have no effect starting from beta214-03.