Putting barriers around QC

Discuss programming in the QuakeC language.
Post Reply
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Putting barriers around QC

Post by mh »

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! :D
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
MauveBib
Posts: 634
Joined: Thu Nov 04, 2004 1:22 am

Re: Putting barriers around QC

Post by MauveBib »

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.
Apathy Now!
Urre
Posts: 1109
Joined: Fri Nov 05, 2004 2:36 am
Location: Moon
Contact:

Post by Urre »

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 was once a Quake modder
ceriux
Posts: 2230
Joined: Sat Sep 06, 2008 3:30 pm
Location: Indiana, USA

Post by ceriux »

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. :)
Chris
Posts: 79
Joined: Sat Aug 05, 2006 5:31 am

Post by Chris »

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.
mankrip
Posts: 924
Joined: Fri Jul 04, 2008 3:02 am

Re: Putting barriers around QC

Post by mankrip »

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.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
Urre
Posts: 1109
Joined: Fri Nov 05, 2004 2:36 am
Location: Moon
Contact:

Post by Urre »

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.
I was once a Quake modder
Dr. Shadowborg
InsideQC Staff
Posts: 1120
Joined: Sat Oct 16, 2004 3:34 pm

Post by Dr. Shadowborg »

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.) :wink:
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Putting barriers around QC

Post by mh »

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. :lol:
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.) :wink:
I like the way WarpSpasm did it, with a custom autoexec that called into the ID1 autoexec.
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
Downsider
Posts: 621
Joined: Tue Sep 16, 2008 1:35 am

Post by Downsider »

Isn't the config stored on a per-mod basis in the mod's folder anyway?
GiffE
Posts: 170
Joined: Sun Oct 08, 2006 3:39 pm
Location: USA, CT
Contact:

Post by GiffE »

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.
Post Reply