1. Split your configuration up
How many times have you wanted to start a generic Deathmatch server, or a generic TDM server, or a generic CTF server, and simply copied the config file from another server? Now, assume that a new version of your port of choice comes out and suddenly, there is a neat new flag or feature that you want to enable on every single server. Or lets say that after some experimentation your players demand a change to a gametype (for example, changing the fraglimit on your TDM servers). You could go back through every single one of your config files and add those configuration pieces to every single file, hoping you don't skip one. Or you could harness the power of exec.
exec is a simple command that executes another config file, and is usually used at the end of a server startup string. However, it's just as usable inside of a configuration file. To wit:
// Execute base Team Deathmatch params
sv_hostname "[MS] My Servers || Doom 2 Cooperative"
Just keep all your TDM configuration inside of tdm.cfg, and you're golden.
2. Abuse the "working directory"
Now you're probably wondering. "That's awesome. However, what if I move my configuration files? Then they'll all break again!" Yep, absolute paths will do that do you. However, before you embark on using relative paths, you need to know something that will catch you off guard. If you specify a path in a config file and it references something other than an absolute path (i.e. one with a C:\ or / at the beginning), it will attempt to use a path relative to the location that the program was started. This is not necessarily the same thing as the directory the server binary is located in either, as you can run programs from any directory. For example:
$ cd /opt/skulltag
$ ./bin/98c/skulltag-server +exec "cfg/doom2-coop.cfg"
This will load /opt/skulltag/cfg/coop.cfg, not /opt/skulltag/bin/98c/cfg/coop.cfg, all because you started it from /opt/skulltag.
Neat-o, right? However, this doesn't just work for configuration files. It works for anything that uses a path. Observe:
$ cd /opt/skulltag
$ ./bin/98c/skulltag-server -iwad "wad/doom2.wad" +sv_banfile "list/banlist.txt" +exec "cfg/doom2-coop.cfg"
Now you're cooking with gas. Your server binaries are separated from your wad files, which are separated from your banlists, which are separated from your config files.
Putting it all together
Here is a sample skeleton config file that I use for my own servers. I put this in /opt/skulltag/cfg/skeleton.cfg and whenever I need a new server I simply copy the config file and then +exec it from the command line.
// SKULLTAG SERVER CONFIGURATION FILE
// by AlexMax
// INCLUDE FILES
// Do not remove any of these commands.
// GAMEPLAY INCLUDES
// Uncomment one of the following commands to select which flavor of doom
// gameplay you wish to use.
//exec "cfg/include/os.cfg" // Oldschool settings (-deathmatch)
//exec "cfg/include/os-altdeath.cfg" // Oldschool settings (-altdeath)
//exec "cfg/include/ns.cfg" // Newschool settings
//exec "cfg/include/st.cfg" // Skulltag settings
// GAMETYPE INCLUDES
// Uncomment one of the following commands to determine which gametype you
// wish to play.
// ADDITIONAL SETTINGS
// If there is a setting that is either not covered by the above includes or
// is a setting you wish to overide, you should place such settings here.
// Please read the Skulltag Wiki for a full list of possible server settings.
// MAP ROTATION
// Shuffle Maplist. If set, maps will be picked randomly from the available
// added maps.
// Add any maps that you would like to be included in the map rotation
// to the section below.
// -- START MAPLIST --
// -- END MAPLIST --
// Set the map that you want to be loaded when the server starts here.
// RESET CONFIGURATION FILE
// by AlexMax
// There should never be a reason to edit this file. This merely sets up sane
// defaults so your configuration doesn't keep any residual cvars from other
// GLOBAL CONFIGURATION FILE
// by AlexMax
// Put your configuration changes that you want to see across all servers
// in this file. You should keep this file hidden, for obvious reasons.
// Server title. This is used anytime you forget to set the hostname from
// the command line or another config file. I suggest using your server name,
// followed by "Skulltag Server" or something equally vague.
set sv_hostname "My Skulltag Server Farm || Skulltag Server"
// Host e-mail. If you want your users to be able to contact you via e-mail,
// put it here. Anybody who queries the server in a server browser can see
// this e-mail, so make sure it is an e-mail address that you don't mind
// being public-facing and unobfuscated.
// Message of the day. This message will display to your users when they join
// your servers. Line breaks can be used here by using \n.
sv_motd "Welcome to Skulltag!\n\nHave fun!"
// RCON password. This is used to obtain access to the Skulltag server
// console while you're playing on the server as a client or through an
// RCON utility.
// Server website. If your server has any custom WAD files and you wish for
// them to be downloaded by server browsers such as Odalauncher, IDE or
// Doomseeker when connecting to your server, put the URL where the files can
// be located here.
Take a good look at these config files so you can tell where files belong and what other config files you need to populate yourself, such as cfg/include/os.cfg and cfg/include/duel.cfg.
Finally, you need to start the server. I don't actually use shell scripts, but here's a sample one that ought to work, just substitute in your server parameters, and put it in the "root" directory of your skulltag installation.
Sample shell script
./bin/98c/skulltag-server -iwad wads/doom2.wad -file wad/WADNAME.WAD -useip YOURIP -port PORT +sv_hostname "YOUR SERVER NAME" +exec cfg/CONFIG.CFG +logfile log/LOGFILE.LOG