Forum

Putting barriers around QC

Discuss programming in the QuakeC language.

Moderator: InsideQC Admins

Putting barriers around QC

Postby mh » Fri Jan 02, 2009 12:55 pm

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

Re: Putting barriers around QC

Postby MauveBib » Fri Jan 02, 2009 2:47 pm

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

Postby Urre » Fri Jan 02, 2009 4:08 pm

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
User avatar
Urre
 
Posts: 1109
Joined: Fri Nov 05, 2004 2:36 am
Location: Moon

Postby ceriux » Fri Jan 02, 2009 4:22 pm

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. :)
User avatar
ceriux
 
Posts: 2223
Joined: Sat Sep 06, 2008 3:30 pm
Location: Indiana, USA

Postby Chris » Fri Jan 02, 2009 8:48 pm

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

Re: Putting barriers around QC

Postby mankrip » Sat Jan 03, 2009 1:09 pm

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

Postby Urre » Sat Jan 03, 2009 3:30 pm

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
User avatar
Urre
 
Posts: 1109
Joined: Fri Nov 05, 2004 2:36 am
Location: Moon

Postby Dr. Shadowborg » Sat Jan 03, 2009 4:00 pm

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:
User avatar
Dr. Shadowborg
InsideQC Staff
 
Posts: 1110
Joined: Sat Oct 16, 2004 3:34 pm

Re: Putting barriers around QC

Postby mh » Sat Jan 03, 2009 5:33 pm

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

Postby Downsider » Sat Jan 03, 2009 6:40 pm

Isn't the config stored on a per-mod basis in the mod's folder anyway?
User avatar
Downsider
 
Posts: 621
Joined: Tue Sep 16, 2008 1:35 am

Postby GiffE » Sat Jan 03, 2009 7:27 pm

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.
GiffE
 
Posts: 170
Joined: Sun Oct 08, 2006 3:39 pm
Location: USA, CT


Return to QuakeC Programming

Who is online

Users browsing this forum: No registered users and 1 guest