Config.cfg file from Pak file

[Rest]

I downloaded a new pak0 file for my quake folder. While this gave me all the maps I needed, every time I exit the game, it resets the config file in my id1 folder. I am assuming the config file is being generated from the pak file. Any way to modify this. I have tried an autoexec and it does not work. Suggestions welcome.

[R00k]

There should NOT be a config.cfg in PAK0.pak. If so then erase it. (get pakscape to edit pak files)
Config.cfg is automatically written to the gamedir (default is id1/).
With the config.cfg in the pak0 folder it will be read 1st and any other config.cfg will be ignored.

[Lerster]

i'd recommend pakexplorer. : http://www.quaketerminus.com/tools/pakexplr.zip

Simple windows drag/drop tool. Like winrar/winzip/etc.

if it was a ctf pak it might of been my fault lol.

If it wasn't then not my fault

~Cheers.

[R00k]

pakexplorer is older than pakscape. Pakscape can handle pk3 files too, as well as other games.

[Baker]

There should NOT be a config.cfg in PAK0.pak.

Hmmm ... maybe useful technique for engine coding to make sure every time you load the engine that the default user setup is being used.

Maybe even useful idea for mod development.

[MH]

A mod messing with the players configs like this is extremely bad form.

I'm thinking that engines should maybe refuse to exec either config.cfg or autoexec.cfg from pak files - you're the player, it's your PC, your chosen configuration, and if a modder won't respect that then it's their tough luck.

This was also a major impetus behind my crusade against stuffcmd a coupla years back (unfortunately I don't see any acceptable solution to that one with Quake's architechture being the way it is).

[=peg=]

Just for the record, the actual file that gets executed on startup is quake.rc, which in turn executes the commandline options and config.cfg/autoexec.cfg.
Some mods provide a custom version of quake.rc inside a .pak.

quake.rc might be the file to look for if somehow the usual stuff does not seem to work as expected..

[MH]

quake.rc can be useful for mods - it's a good place to put some recommended cvars (r_maxedges for software Quake, r_wateralpha for GL, etc).

default.cfg belongs to the mod - these are the recommended defaults and a "Reset to Defaults" from the menu will restore it. Well-behaved mods should be putting their stuff in there (in preference to quake.rc, even). Players should not have any reason to go near this.

config.cfg belongs to the player. If the player makes a config modification and saves it back, a config.cfg in a PAK file will overrule even that in the next session.

autoexec.cfg firmly belongs to the player - the player must create it in the first place.

A mod should be very very careful about changing a cvar that's marked as "archive" because such a cvar will be saved to the player's config. Mods have no business whatsoever changing keybindings. That's like downloading one program and having it change system-wide settings that affect other programs, without so much as a by-your-leave. There's a name for that: badware.

It can be useful for a mod to change cvars while running in order to do something, but mods should be putting the values back when done. Unfortunately the current QC interfaces provide no way of letting this happen.

The trouble with using stuffcmd is twofold. First, it's open to abuse: "stuffcmd disconnect", "stuffcmd vid_mode 27", "stuffcmd kill", etc. Second, if it's used to change a cvar or issue a command, the desired result won't persist across sessions but will persist across different maps run in the same session. If a mod stuffs a fog setting but then you issue a changelevel immediately after, the fog will be kept (unless you're using an engine that wipes fog between maps). If a mod stuffs fog, you save, exit Quake, restart Quake, load - fog gone. Even the most ardent stuffcmd supporter should see the problem with this.

DirectQ has the ability to listen in on stuffcmd usage - set pr_show_stuffcmd 1 and run a few maps: you may be in for a shock. ID1 hardly ever uses stuffcmd; there's the odd "bf" but that's just about it. Many mods go completely overboard with it, including mods that provide their own custom engines and were therefore in a position to implement alternative solutions (like new QC builtins and protocol changes). One mod stuffs the very same command about a billion times on entry to a map. Nasty stuff.

These are all problems that, in a better world, would have been resolved back in 2001.

[R00k]

I agree that mods shouldnt force settings.

The only use of stuffcmd i use in my mod is for alias commands for impulses on the server. I dont require players to remember impulse is 102 for "warp".
Though in the past i have played on runequake and ended up with rune-delete bound to my X key ARG!

I wrote function to save alias commands to a file, so like i can jump on crmod, it will stuffcmds at me and i can do a writealias "crmod.cfg", and capture all the commands.
I can edit this or inspect it. Load it up just before connecting and i wont get re-"stuffed"

There's also the handy "unaliasall" command!

Spike mentioned that qw servers clear out alias commands between disconnect/connect...

[Rest]

Good now

"if it was a ctf pak it might of been my fault lol.
If it wasn't then not my fault "


It was your fault, Lerster =D
Thanks for the pak editor. Now I can undo your autoexec. Thanks, man!

[MH]

unaliasall is, I find, pretty much essential. I do a lot of testing with local ProQuake servers, and it's mildly unpleasant to pop the console, type 'q' then tab, only to get "quadcheat" instead of "quit".

I still haven't figured out what caused r_wateralpha to show a "disabled on this server" message with RMQ maps, but whatever it was, it caused me to miss a bug.

[Spike]

QW clients do indeed purge all alias stuffcmds on both svc_serverdata and disconnect.
stuffcmd(self, "alias quit \"echo hahaha\"\n");
is just too evil.
note that qw servers can change gamedirs/gamemodes on map changes and other weirdness where an alias makes sense on one map but not the next, meaning this is the most reliable option, even if not the most efficient.

FTE also resets cvars back to their prior values if the server stuffcmded a change to it.
This is also useful for mods that stuffcmd fov changes and then mess it up by assuming that 90 is default, but also useful for when you timeout on a server that set your screen to pure black or other unusability.

stuffcmd is evil, but often there is no other way.

[R00k]

unaliasall is, I find, pretty much essential. I do a lot of testing with local ProQuake servers, and it's mildly unpleasant to pop the console, type 'q' then tab, only to get "quadcheat" instead of "quit".

I still haven't figured out what caused r_wateralpha to show a "disabled on this server" message with RMQ maps, but whatever it was, it caused me to miss a bug.

MH pressing q{TAB} in your client brings up qcdebug!

the wateralpha is disabled is leftover from "alias r_wateralpha echo r_wateralpha has been disabled on this server" from runequake/crmod/cax servers

unalias r_wateralpha (done.)

[Lerster]

sorry i tried to release an up-to-date ctf pack with all maps / locs.

But i rushed it, and i must've missed the fact that i included a config.cfg an or /autoexec.cfg in the pak0.pak file.

As i often store my stuff in such a way that i can unload it from a dvd to my pc, and keep my configures.

Sorry.

PS: i may of forgot to include some locs X_X

[Cobalt]

Good points. With a ded server, are there advantages to putting stuff in quake.rc over autoexec.cfg? Also, is it possible to unbind / restore the keys that the player had before they connected to a server that auto-binds some basic keys? I guess I could re-write the alaising code and do a big motd explaining all the keys...but I read something that said some of the things may be ' archived ' which means when they disconnect, they do not revert back to what they were....I guess if someone just drops the con down and conects to a server , the keys are still bound to the server they just played on for example.

quake.rc can be useful for mods - it's a good place to put some recommended cvars (r_maxedges for software Quake, r_wateralpha for GL, etc).

default.cfg belongs to the mod - these are the recommended defaults and a "Reset to Defaults" from the menu will restore it. Well-behaved mods should be putting their stuff in there (in preference to quake.rc, even). Players should not have any reason to go near this.

config.cfg belongs to the player. If the player makes a config modification and saves it back, a config.cfg in a PAK file will overrule even that in the next session.

autoexec.cfg firmly belongs to the player - the player must create it in the first place.

A mod should be very very careful about changing a cvar that's marked as "archive" because such a cvar will be saved to the player's config. Mods have no business whatsoever changing keybindings. That's like downloading one program and having it change system-wide settings that affect other programs, without so much as a by-your-leave. There's a name for that: badware.

It can be useful for a mod to change cvars while running in order to do something, but mods should be putting the values back when done. Unfortunately the current QC interfaces provide no way of letting this happen.

The trouble with using stuffcmd is twofold. First, it's open to abuse: "stuffcmd disconnect", "stuffcmd vid_mode 27", "stuffcmd kill", etc. Second, if it's used to change a cvar or issue a command, the desired result won't persist across sessions but will persist across different maps run in the same session. If a mod stuffs a fog setting but then you issue a changelevel immediately after, the fog will be kept (unless you're using an engine that wipes fog between maps). If a mod stuffs fog, you save, exit Quake, restart Quake, load - fog gone. Even the most ardent stuffcmd supporter should see the problem with this.

DirectQ has the ability to listen in on stuffcmd usage - set pr_show_stuffcmd 1 and run a few maps: you may be in for a shock. ID1 hardly ever uses stuffcmd; there's the odd "bf" but that's just about it. Many mods go completely overboard with it, including mods that provide their own custom engines and were therefore in a position to implement alternative solutions (like new QC builtins and protocol changes). One mod stuffs the very same command about a billion times on entry to a map. Nasty stuff.

These are all problems that, in a better world, would have been resolved back in 2001.