Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

Putting barriers around QC

| Inside3d Forums Forum Index -> QuakeC Programming

View previous topic :: View next topic
Author | Message
--- | ---
mh Joined: 12 Jan 2008 Posts: 910 |

Posted: Fri Jan 02, 2009 12:55 pm Post subject: Putting barriers around QC |

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!
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

MauveBib Joined: 04 Nov 2004 Posts: 602 |

Posted: Fri Jan 02, 2009 2:47 pm Post subject: Re: Putting barriers around QC |

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!

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Fri Jan 02, 2009 4:08 pm Post subject: |

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.
_________________
Look out for Twigboy

Back to top |

ceriux Joined: 06 Sep 2008 Posts: 969 Location: Florida, USA |

Posted: Fri Jan 02, 2009 4:22 pm Post subject: |

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. _________________ QuakeDB - Quake ModDB Group

Back to top |

Chris Joined: 05 Aug 2006 Posts: 78 |

Posted: Fri Jan 02, 2009 8:48 pm Post subject: |

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.

Back to top |

mk Joined: 04 Jul 2008 Posts: 95 |

Posted: Sat Jan 03, 2009 1:09 pm Post subject: Re: Putting barriers around QC |

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.
_________________
Makaqu engine blog / website.
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Sat Jan 03, 2009 3:30 pm Post subject: |

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. _________________ Look out for Twigboy

Back to top |

Dr. Shadowborg Inside3D Staff Joined: 16 Oct 2004 Posts: 726 |

Posted: Sat Jan 03, 2009 4:00 pm Post subject: |

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.)
_________________
"Roboto suggests Plasma Bazooka."

Back to top |

mh Joined: 12 Jan 2008 Posts: 910 |

Posted: Sat Jan 03, 2009 5:33 pm Post subject: Re: Putting barriers around QC |

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.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

Downsider Joined: 16 Sep 2008 Posts: 478 |

Posted: Sat Jan 03, 2009 6:40 pm Post subject: |

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

Back to top |

GiffE Joined: 08 Oct 2006 Posts: 141 Location: USA, CT |

Posted: Sat Jan 03, 2009 7:27 pm Post subject: |

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. _________________ http://www.giffe-bin.net/

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> QuakeC Programming | All times are GMT
Page 1 of 1

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2004 phpBB Group