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!
Putting barriers around QC
Putting barriers around QC
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Re: Putting barriers around QC
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.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.
Some mods are so different from quake that they just need to force cvars etc in order to work.
Apathy Now!
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.
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.
I was once a Quake modder
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.
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.
Re: Putting barriers around QC
Actually, when I run a mod I know I'm giving it permission to mess with the settings.mh wrote:If you download and run a mod you implicitly trust it not to mess with your settings.
And each mod has its own config.cfg, so it shouldn't be a problem.
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".mh wrote:A bypass mechanism is implemented so that players can revert to the original behaviour if they wish.
If implemented, this flagging mechanism should be disabled by default as to not affect the engine's compatibility.
-
- InsideQC Staff
- Posts: 1120
- Joined: Sat Oct 16, 2004 3:34 pm
Which is why it's better to use default.cfg instead. (with good documentation, possibly even including replacements for the help lmps.)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.
Re: Putting barriers around QC
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.mk wrote:If implemented, this flagging mechanism should be disabled by default as to not affect the engine's compatibility.
Been thinking a bit more and wondering if perhaps I was just being paranoid about the whole silly thing.
I like the way WarpSpasm did it, with a custom autoexec that called into the ID1 autoexec.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.)
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for