These files are configuration files that TFC uses to set up the game. They can be used for a number of things, including setting the game's internet, video, and sound settings, as well as the commands that are executed when you press keys on your keyboard or use your mouse or joystick. You can open them with Notepad or any other text editor, edit them, and save them back into your TFC folder, and the game will use them for those settings. Shoe -TPF- posted an excellent explanation of config files on our own forums, which is what follows, if you have any specific config questions that aren't addressed here, please feel free to send in those emails:

THINGS THAT MAKE YOU GO HMMMM.CFG

The config files TFC uses can be pretty confusing if you don't know how they work - and even then the same questions keep cropping up again & again in the forums. Here's an attempt to answer most of those questions, and offer some pointers about how best to set up your configs and avoid the common mistakes. Talking of mistakes, if you spot any in here, please let me know ([email protected]) so I can put things right. If you'd like this text in a Word document with nicer formatting, drop me a note. What I'm not going to do here is attempt to explain what all the things inside the config files mean - so if you don't know the difference between a bind and an alias, read up on them first. There are plenty of good sites, http://half-life.pcgame.com/console/index.html is a great place to start.

In summary, or in case you really want to wing it:

· An alias is simply a way of allocating a short name to a longer set of commands. E.g.:

alias fillsentry "use tf_weapon_spanner; wait; +attack; wait; -attack; wait; menuselect 1"

· A bind links a keypress or mouse movement to a particular action or alias. E.g:

bind c dropitems

or

bind m +fillsentry

· A setting allocates a value to one of HalfLife's internal variables, e.g.:

hud_centerid "1"

or

sensitivity "6.600000"

OK then, here we go - once upon a time…

TFC holds all it's settings, key bindings and aliases in files with the .cfg suffix. All the .cfg files live in your Sierra/Half_Life/tfc directory.

Once in a while Half Life screws up - when it does, it has a history of taking certain config files with it, so once you've got the configs set up as you want, take a backup - just copy all the .cfg files away into a spare directory somewhere.

THE VARIOUS CONFIG FILES

autoexec.cfg

This is executed once, when TFC first starts up. It's a good place to configure settings, such as +mlook for mouse look, but it's not a good idea to put binds or aliases in here. Any settings or binds done in here could potentially be over written by the next thing to run (config.cfg).

A couple of good settings to put in autoexec are the following, which control when the other config files run:

setinfo "ec" "1" //exec {classname}.cfg automatically when loading a class

setinfo "em" "1" //execs {mapname}.cfg automatically when joining or switching maps.

Setting any of these to "0" disables it

config.cfg

This is the one that causes all the pain! All the current settings and bindings, including any changes you've made using TFCs configuration menu, will be saved in here automatically when the game quits. The problem is that config.cfg runs three separate times as TFC starts, after most of the other configs, sometimes overwriting settings that you may have put into other files. As an example, if you currently have key x bound to "discard", and then you add "bind x +detdispenser" to autoexec.cfg, when you load up TFC you'll find that x still does a discard. This is because config.cfg, which contains the settings from the last game, ran AFTER autoexec, and rebound x back to discard. A quick & dirty way to fix this is to pull down the console after joining the game and manually "exec autoexec.cfg". X will now be bound to +detdispenser, and when you quit the game, config.cfg will be updated. Subsequent games should then work OK. There are much better ways to do it than this though, see later. Another point to note is that by default, config.cfg contains no settings and a complete key binding list, but no aliases at all. More on this later too.

mapdefault.cfg

This doesn't exist by default, but if you create it it'll run when you first join a game and also whenever the map switches - regardless of which map it switches to. This can be useful, since neither config.cfg or autoexec.cfg run when the map switches. If you want to put things back to default settings after running special configuration for a particular map, this is a good place to do it.

{mapname}.cfg (e.g. well.cfg, 2fort.cfg, totalwar.cfg)

This loads just after the map called {mapname} loads, either when joining a map or when the map changes from one to another. These config files useful for setting up configurations which are specific to a particular map, such as communication sets for Hunted, or even a different brightness level for a particular map. Remember though that if you change anything unusual, such as brightness, you're going to have to reset it somewhere when the next map loads. Know what the next map to load will be? No chance - so to avoid having to have a {mapname}.cfg for EVERY possible map, and reset the brightness in ALL if then - just do it in mapdefault.cfg.

{classname}.cfg (e.g. medic.cfg, soldier.cfg)

One of these files loads whenever you become a particular class - i.e. when joining a game, after the map changes, or when you switch classes or teams in the middle of a map. The best thing about the classname.cfg is that it's the very last config file to run in all these cases. You can be sure that anything set up in here won't be overwritten bythe damned config.cfg running again. Because of this, many people edit add a line to every {classname}.cfg which calls out and exec's another config file - let's call it classdefault.cfg - in which you can set up all sorts of things which will now apply to all classes.

SO EXACTLY WHAT ORDER DO THE CONFIG FILES RUN IN?

When joining a game:

(TFC loads)

autoexec.cfg

config.cfg

config.cfg again

("Player has joined the game" appears)

mapdefault.cfg

{mapname}.cfg (if "em" has previously been set to 1)

config.cfg

(The map intro text appears, and you click to continue)

(You select your team)

(You select your class)

{classname}.cfg (if "ec" has previously been set to 1)

(You enter the game)

When the map changes:

mapdefault.cfg

{mapname}.cfg

(You select your team & class)

{classname}.cfg

When switching classes or teams:

{classname.cfg}

WHERE ARE THE BEST PLACES TO SET THINGS UP?

autoexec.cfg - Set up "ec","em" , and any other settings that can't be controlled from the configuration menu

mapdefault.cfg - Set up aliases for default communication sets aliases (don't bind)

{mapname}.cfg - Set up (overwrite) aliases for map specific comm sets (don't bind)

{classname}.cfg

Exec classdefault.cfg (see details below)

Exec binds.cfg (see details below)

Do class specific comm aliases

Do class specific binds

classdefault.cfg - Define general purpose aliases, and also any aliases specific to a particular class (make sure they're all uniquely named) - avoid binds if possible.

binds.cfg - set up binds for default comm aliases and actions that aren't class specific

config.cfg - If you follow the setup above, you should never have to modify config.cfg. Just make sure you've got it backed up anytime you change a setting using the configuration menu.

WHY SET THEM UP THAT WAY?

Because if you're like me, you're naturally lazy. These are the principles I set out with when trying to figure out how best to set this stuff up:

· I want standard key bindings to apply unless I override them with class specifics.

· I want to be able to define key bindings which apply only to a specific class

· I want my default comms sets to apply unless I override them with map or class specifics.

· I want to be able to easily define a new comms set specific to a class or to a map

· I don't want to have to create a {mapname}.cfg unless I wan't specific comms for that map.

· I don't want to have to define identical aliases in more than one place.

· I want to be able to change key bindings easily, without even having to look at the aliases.

· I don't want to have to exec things manually from the console when joining, or at map or class change.

· I want to be able to restore my configs easily if things go wrong.

So with those principles in mind, here's how the setup above actually works. I'll just set up one or two things to show how it fits together, a real example would be much bigger...

I join a game and autoexec.cfg runs. It contains:

setinfo "ec" "1" //exec {classname}.cfg automatically when loading a class

setinfo "em" "1" //execs {mapname}.cfg automatically when joining or switching maps.

Next, config.cfg runs. Twice. It puts my settings and binds to the way they were when I last quit the game - note that depending what map & class I was playing, that might not be what I want now.

Mapdefault.cfg runs. It contains aliases for default comm sets:

alias msg1 "say_team Enemy Incoming!"

alias msg2 "say_team Enemy Incoming via water tunnel!"

alias msg3 "say_team Enemy Incoming via battlements!"

Let's say the map is CanalZone - the next one to run is cz2.cfg, which overwrites the default comm aliases with map specifics:

alias msg1 "say_team Taking flag to CP1"

alias msg2 "say_team Taking flag to CP2"

alias msg3 "say_team Taking flag to CP3"

Now let's say I start to play as a medic. Medic.cfg will run next. The first thing done in medic.cfg is to exec classdefault.cfg. Classdefault.cfg sets up general, AND class specific aliases, but ideally doesn't bind them to any keys:

// toggle crouch

alias crouchon "+duck;alias crouchtoggle crouchoff"

alias crouchoff "-duck;alias crouchtoggle crouchon"

crouchoff

// auto medikit

alias +heal "tf_weapon_medikit; +attack"

alias -heal "-attack; lastinv"

Next, from within medic.cfg, binds.cfg is run - this sets up binds for default comm aliases and actions that aren't class specific:

bind F1 +msg1

bind F2 +msg2

bind F3 +msg3

bind ctrl crouchtoggle

Next thing in medic.cfg is to set up any class specific comm aliases:

alias medmsg1 "say_team If you're infected, Stand still and call for a medic"

And finally, any class specific binds:

bind F4 +medmsg1

bind MOUSE2 +heal

Thats it - you're playing CZ2 as medic with a comm set tailored to the map and the class, and key bindings tailored to the class. If the map changes, or you switch class - no problem. All the settings will take care of themselves.

The example above is fairly simple, and only uses single key comm sets. Personally I have a two-key system, but it still works fine. I use keys F1-F8 for the general comm sets - do for example, the default message for commset1 is "Enemy incoming via XXX". The second keypress selects the XXX from an on-screen menu. In my cz2.cfg, using the same principle as above, I overwrite the commset1 aliases with "Flag needed at CP XXX", and the second keypress enters the number.

WHAT IF I DON'T WANT TO SET THEM ALL UP MYSELF?

Well, if you really want, I can send you mine. Mail me at ([email protected]). The only one I won't send is config.cfg, because if you've followed the above you'll realise you don't need it. Not happy with the keys I use? - no problem. All you'll have to change is the binds.cfg file. Want to write a commset for a new map? - easy - only one {mapname}.cfg to write. And once you've done it, you can share it with me!

ODDS & ENDS

A couple of hints that didn't seem to fit anywhere else:

Fancy configs take up more memory. Make sure the command line you launch halflife from includes -zone 2048. That applies to the gamespy command line too!

Watch out when testing you configs on a LAN game - config.cfg isn't executed at the same time as when you join a WAN game. Follow the guide above, and it shouldn't matter - otherwise you mat get unexpected results.

TFC doesn't behave well when you're low on disk space. Symptons include connecting to a server, waiting ages, and then failing, and also the config and/or autoexec files being deleted. Clear out a bit more space on the disk or try a defrag, then restore your backed up cfgs. You did back them up, didn't you??

Phew - that's it. Hope it helps - have fun!

Shoe -TPF-

18/11/1999