InsideQC Forums

This is a (perhaps crazy) idea I've had for some few months now, and I'm interested in feedback from modders about it.

Description of Problem

QC as it stands is very powerful. It has the ability to issue any command and set any cvar. Now, I'm of the opinion that QC has no business issuing certain commands and setting certain cvars, and that these commands and cvars belong to the player, not to the mod developer.

The ones I'm thinking of here are ones that affect a player's personal settings. They might have their keybindings set up a way they like them, they may have chosen some settings for performance or compatiblity reasons. A rule of thumb is that if a cvar is written to config.cfg then it should belong to the player (there are exceptions, of course, like skill, which QC needs to be able to set in the start map; maybe a few others).

I'd be quite unhappy if some QC changed my vid_mode, switched around all my keybindings, connected me to a remote server and did a few other things, all without my authorisation. Wouldn't you? And yet it's possible.

What I'm saying is that with power comes responsibility, and also a level of trust. If you download and run a mod you implicitly trust it not to mess with your settings. However, with nothing to enforce that responsibility and trust you have no way of knowing (until after the event) whether or not your settings have in fact been messed with.

Proposed Solution

Certain cvars and commands are flagged as "protected". If QC attempts to set one of these cvars and/or issue one of these commands it is stopped cold in it's tracks.

A bypass mechanism is implemented so that players can revert to the original behaviour if they wish.

The list of protected cvars and commands should be agreed on by all, but the "config.cfg" rule of thumb might provide a good starting spot.

____________________________

Anyway, like I said, opinions of modders on this are being sought!

mh wrote: I'd be quite unhappy if some QC changed my vid_mode, switched around all my keybindings, connected me to a remote server and did a few other things, all without my authorisation. Wouldn't you? And yet it's possible.

All well and good for a standard quake mod, but something like DiD2 relies on forced on +strafe and certain key bindings. Other mods like The Ascension of Vigil also require forced bindings and cvars in order to work.

Some mods are so different from quake that they just need to force cvars etc in order to work.

Using CSQC, you wouldn't have to force as much.

I can agree on it being a little nasty, not so much because I'm afraid a modder is going to mess up my binds, but more because it's not very pretty. On the other hand, some abilities this sort of forcing capability provides are rather awesome, such as the connecting to a remote server thing you mentioned, as it allows for a semi-mmo kind of game if you like.

Given how long Quake has been around, complaints about a modder forcing certain things have been so rare I think it's a non-issue. Some things like forcing fov and such have been really nasty, but that's about the only thing I can think of modders forcing upon you, so far.

In general, I prefer that the power stays with the modder, since it's essentially their game which they want to present in their own way. If it's not to your liking, don't play it, or whine about it until the modder comes to his/her senses.

its an understandable idea, but id have to agree that it should be up to the modder because of the facts that have already been presented. although you could still do it just to show it off.

There is already enough barriers in qc as it is not being able to access the server entity list just to read the data from csqc without going through the task of sharing them all out and then providing your own visual logic for them.

qc has been around for a long time, I'd say its tried and proven fine as is and adding any more barriers short of say implementing OOP features such as classes which in turn are ARCHITECTURAL barriers is just silly and if anything at a detriment to any modder here.

mh wrote:If you download and run a mod you implicitly trust it not to mess with your settings.

Actually, when I run a mod I know I'm giving it permission to mess with the settings.

And each mod has its own config.cfg, so it shouldn't be a problem.

mh wrote:A bypass mechanism is implemented so that players can revert to the original behaviour if they wish.

Players don't want to think about the settings. There's a higher chance of them thinking your engine is buggy and switching to another engine than them thinking "there must be something in the options to fix this".

If implemented, this flagging mechanism should be disabled by default as to not affect the engine's compatibility.

Actually, a mod coming with a config.cfg is a bad idea, as that means the mod can't inherit the config.cfg from id1, with all the users graphical settings and whatnot.

Urre wrote:Actually, a mod coming with a config.cfg is a bad idea, as that means the mod can't inherit the config.cfg from id1, with all the users graphical settings and whatnot.

Which is why it's better to use default.cfg instead. (with good documentation, possibly even including replacements for the help lmps.)

mk wrote:If implemented, this flagging mechanism should be disabled by default as to not affect the engine's compatibility.

I agree with the "disabled by default" approach; it's important that everybody knows they're on common ground, and that behaviour is as predictable as possible.

Been thinking a bit more and wondering if perhaps I was just being paranoid about the whole silly thing.

Dr. Shadowborg wrote:Which is why it's better to use default.cfg instead. (with good documentation, possibly even including replacements for the help lmps.)

I like the way WarpSpasm did it, with a custom autoexec that called into the ID1 autoexec.

Isn't the config stored on a per-mod basis in the mod's folder anyway?

You could always make your config read-only. Would enable the changes while your in game but next time you join it will be back to how you like it.