Watch Cvar

[Baker]

Concept ...

0. Create a global cvar_t *watched_cvar;
1. Create command "cvarwatch"
2. cvarwatch takes the first argument, find the cvar by name (if no arguments, set watched_cvar = NULL;)

Code: Select all

watched_cvar = Cvar_FindVar (var_name)

3. If the 2D drawing segment in SCR_Update, display the cvar name and value on-screen

Code: Select all

if (watched_cvar)
    Draw_WatchedCvar ();

[Spike]

for?

[Downsider]

Debugging?

[leileilol]

yeah someone needs to learn the whole breakpoints concept.... msvc makes that fun!

[Baker]

I thinking of making a number of cvars only acceptable for "developer 1" or single player, thinking about the demo playback security vulnerability, mods that send the client hacky stuff and too some degree what Quakeworld calls "rulesets" (i.e. permitted client settings).

Console variables are generally user settings, not really something that you'd set a breakpoint for. But sometimes this stuff gets altered without your knowledge or awareness.

(This was kind of a raw thought thread, I could make cvar value changes noisier. I have some ideas on cvars that aren't really unusual compared to, say, what FTEQW already does. But require a lot of supervision during testing to see how the engine reacts. I don't, for instance, think a "ruleset" should change a cvar value but supercede it. I believe in your config writing on exit by default and it should not write values that you didn't "decide".)

[Spike]

even unmodified NQ has a cvar flag that causes changes to be broadcast, as a server ruleset-change-notification feature.

FTE has a concept of latched cvars, which mean that the cvar change request/command was understood. But will be ignored temporarily. Cvars which are set from the server will actually take effect, but the value the user wanted will be remembered until the client disconnects or the server resets it to the default.
This means that fov and zoom functions works almost intuitively. User sets a fov, server changes it, server reverts it, user gets the fov he chose back.
However, in order to support stuff like that, you also need to track when a cvar_set call is invoked due to a stuffcmd. Which means you need to somehow separate server and client console commands (if you do so, you also get to block such fun commands as unbindall and download-enable features, so is worthy in its own right).

Rulesets in FTE are implemented by latching certain cvars from the time an f_ruleset command is issued to the end of the map. If noone checks, you can use whatever rules you want, the ruleset is only applied once someone actually bothers to check. This is a somewhat pessimistic view of social interaction, I admit, but it does remind people that if you actually care, you have to check (does a falling tree still make a noise if there's noone to hear it, kind of thing).
Changing cvars ensures that all queries by the user, the engine, csqc, etc, all report the current value (menuqc sees the latched value in order to ensure it doesn't try bulk-applying the wrong setting). But it'll be reset as soon as its unlatched.

[Baker]

even unmodified NQ has a cvar flag that causes changes to be broadcast, as a server ruleset-change-notification feature.

Yeah, the server variable flag. I did a poor job of explaining myself in both posts.

Mostly because I don't have just a single interest in cvars, but a broad set of various ones including rulesets. I'll look in the FTE latched cvars. [I did not know the purpose or meaning of latched cvars, to be honest].

One thing I do care about is a consistent player experience where you don't have some clients with arguably cheat-like features enabled, but want maximum flexibility for some things in some circumstances.

Case in point, r_wateralpha can absolutely ruin the DM3 intended experience, but in coop r_wateralpha is highly desired if the map is supposed to support it.

And I want to shut out some of the developer cvars even in most forms of single player or coop without developer mode enabled at the start of the level. You can use r_drawentities 0, for example, to help find secrets in a map ... which is cheating. (Yeah, yeah god and noclip are cheats too, but sort of expected cheats for players frustrated with a level). I've played some console games that actually do not have ANY cheats available.

Mostly because I really don't believe in "settings", honestly, aside from simple input preferences and hardware oriented performance settings (like maxfps). However, the alternative -- remove the settings can be detrimental from a mod developer point of view.

Anyways ...

Changing cvars ensures that all queries by the user, the engine, csqc, etc, all report the current value (menuqc sees the latched value in order to ensure it doesn't try bulk-applying the wrong setting). But it'll be reset as soon as its unlatched.

Will investigate further ... I've seen funny cvar comments in FTE like "semi-cheat"