Difference between "config.cfg" and "autoexec.cfg" - And their management

[talisa]

very much true. autoexec.cfg gets loaded after config.cfg,
and you should actually rarely ever touch config.cfg.

the only time ive ever touched my config.cfg was when i wanted to quickly change the key a certain action was bound to, and found it easier to just change it directly instead of first having to unbind the key and then rebind the action to another key through console

[Mindf!3ldzX]

I dont unbind squat, I just reassign in-game. This is really the easiest method I think. It's really easy to folly a config file, however the client will rarely folly itself.

[MadGypsy]

What you need to understand is that autoexec.cfg is run AFTER config.cfg

Yeah that's the whole point. I'll use Qung Fu as an example, it comes with an autoexec.cfg that has a few lines in it

chase_active        1
chase_back          60
chase_pitchangle    48
chase_up            30

If I put that in a config.cfg, people would have to overwrite their entire engine config (or modify it) just to play. All their controls, eye candy, etc wiped out (or needed to be modified) just to make it 3rd person. The alternate scenario is that their autoexec could potentially be set up to eliminate (ex) chase_active (with 0) and the config.cfg with those commands would not be read. Autoexec is for the developer to modify on a per game basis. Doing it this way, you can dump your config into a mod and keep all of your controls, etc, but the developer has a way to add functionality.

Edit: so yeah, I agree config.cfg should not be touched (especially by the developer) but if a user is using autoexec to config their game, what does the developer use?

[Mindf!3ldzX]

the developer provides options and does not dictate the variables imposed on the user of the client.

[Spirit]

No developer should ever be so bold to put a autoexec.cfg in the user's id1/ .
Many mods come with an autoexec.cfg bundled.

splitterface: Aliases are not saved in the config.cfg. And as I said (not clear enough I guess), it depends on the engine what variables are saved in the config.cfg. The default set does not include all variables that exist in the engine.

hkBattousai: # is not the comment escape in Quake's .cfg files, // is.

For your problems:

maxplayers, see the multiplayer menu and try to make it use more than 4 players
listen: works for me
joystick: does not exist in quakespasm
joybuttons: does not exist in quakespasm
external_ents: works for me, not sure why you want to re-set its default value
max_edicts: works for me, not sure why you want to re-set its default value
viewsize: works for me, not sure why you want to re-set its default value

I would only use the autoexec.cfg to set important things and not play with things that are already using good default values.

[R00k]

config.cfg is the file that the engine will automatically save all settings you change from your last game.
autoexec.cfg is just a placeholder for any settings you want to have perminantly. and if it is present will be executed when the game starts.

you can use any console command/cvar in autoexec.cfg same as config.cfg

[Mindf!3ldzX]

hence, edit autoexec and leave config.cfg alone. 90% of those variables are saved when you close the client,so modify them via console : let the engine do the work. Then you avoid PEBKAC issues.

[MH]

It's not about what should or shouldn't be done where. It's about how Quake uses these files.

There are two types of setting in Quake - settings that are saved and settings that aren't. Any setting that is saved goes into config.cfg and next time you start Quake you'll have that setting back.

Some settings don't get saved (for various reasons). If you want to force a specific value for one of these settings you put it in autoexec.

Another use for autoexec is if you have a bunch of mods. Each mod will have it's own config.cfg which may contain some settings that are specific to that mod. But you might want some other settings that are global and applied to everything, so you use an autoexec in id1 and put those settings in there.

Spirit is right about how mods should never come with an autoexec.cfg, and I'd even extend that to saying that they should never come with config.cfg either. If there are any mod-specific settings that the mod author wants, then there's another more appropriate place for them. config.cfg and autoexec.cfg belong to the player, not to the mod author and anything else is disrepectful of the settings the player may prefer.

[golden_boy]

This thread is confused.

What is the best place for evil developers like me to force chasecam for their 3rd person fighting game?

and yes, it makes a lot of sense to force 3rd person when it's the entire point of your game. After all it might not even have viewmodels anymore.

[hkBattousai]

It's not about what should or shouldn't be done where. It's about how Quake uses these files.

There are two types of setting in Quake - settings that are saved and settings that aren't. Any setting that is saved goes into config.cfg and next time you start Quake you'll have that setting back.

Some settings don't get saved (for various reasons). If you want to force a specific value for one of these settings you put it in autoexec.

Another use for autoexec is if you have a bunch of mods. Each mod will have it's own config.cfg which may contain some settings that are specific to that mod. But you might want some other settings that are global and applied to everything, so you use an autoexec in id1 and put those settings in there.

Your this message made everything clear to me. Thank you.

Some settings don't get saved.

Is there a list of the saved and non-saved settings?

[MH]

What is the best place for evil developers like me to force chasecam for their 3rd person fighting game?

quake.rc after the "exec autoexec.cfg" line I would guess.

Is there a list of the saved and non-saved settings?

The list of saved settings is anything that's in your config.cfg - by definition if it's in there then it's a saved setting, and anything else may be safely assumed to be not saved.

[hkBattousai]

included are my autoexec and config files from my ID1 folder

Your autoexec file contains some commands which I'm not familiar with (like corpse-gibs settings, weapon recoil settings and particle effect settings). I added them to my autoexec file and it messed up (game engine (QuakeSpasm) ingnored all the commands in autoexec.cfg). They look interesting features, who do I use them? Do I need a different engine?

[talisa]

@hkbattousai

those settings are special settings from seven's small mod compilation.
in normal quake they do absolutely nothing if you change them.

if interested in what those things do, take a look at seven's amazing mod:
http://quakeone.com/forums/quake-mod...mpilation.html

its an amazing piece of work, it enhances quake by adding features which were missing in original quake, like nails sticking into walls, being able to blow up corpses, new effects and completely redone particle-effects which look a 100times better then originals, multiple skins per monsters, physics, weapon recoil, enemies being affected by acid and lava, and a lot more


the small mod compilation is a darkplaces-only mod though

[Baker]

This thread is confused.

What is the best place for evil developers like me to force chasecam for their 3rd person fighting game?

quake.rc after the "exec autoexec.cfg" line I would guess.

default.cfg is for the mod defaults.

[Yeah that doesn't lock them ... I do think mods should be able to lock cvars, but I wouldn't trust many modders to use such an idea wisely otherwise you get someone doing r_drawviewmodel 0 as locked when the right way is to null to view model in QuakeC. Like Warpspasm runs your id1\config.cfg in its autoexec as an another example.]

[golden_boy]

Two different answers by two engine coders.

Can we make an effort to clear this up? I respect that certain things should not be hardlocked by the developer. Like movement keys etc.

But some things make a lot of sense to lock; examples:

- 3rd person camera for a 3rd person fighting game
- sv_bigcoords (FTE) if your game has huge maps
- other variables that are needed to basically make the game work.

We should ideally come up with a list of stuff that developers should NOT touch. That would help. We should also agree on one place where devs can put their stuff.