I've set up a server for me and some friends. My server.cfg is:
g_gametype 4
seta sv_hostname "Wursttheke"
seta sv_maxclients 8
capturelimit 8
timelimit 30
fraglimit 0
seta g_motd "Klatscht gleich"
seta g_quadfactor 3
sv_pure 0
sv_maxRate 10000
seta g_inactivity 0
seta bot_enable 1
set d1 "map q3ctf1 ; set nextmap vstr d2"
set d2 "map q3ctf2 ; set nextmap vstr d3"
set d3 "map q3ctf3 ; set nextmap vstr d4"
set d4 "map q3ctf4 ; set nextmap vstr d1"
vstr d1
addbot sarge 4 red 20
addbot major 4 red 20
addbot klesk 4 red 20
addbot bitterman 4 red 20
My .bat file to start the server is:
quake3.exe +set dedicated 1 +set com_hunkmegs 26 +set net_port 27960 +exec server.cfg
Now i have the following questions:
1) in the .cfg file...when to i just a set, when a seta and when do i not?
2) when i set up a password with g_password, in which file do clients put the password, and how?
3) When clients connect via "Specify" can they add a dns too or must it be the ip? 4) The main problem: When the server is being started, the defined bots are initialized and then quake starts to add random bots...how can i turn that off? I just want my bots and no others?
nice thanks everybody for the quick input!!! everything the way i want it to be now...except for one more thing: the players joining over the net have a real bad game speed which makes precise aming impossible. for players in my lan quake runs fine and smoothly
...i guess that's not normal (otherwise none of you would be playing online)?? what can i do about it...would increasing the hunkmeg (currently 26 for ctf) help? any suggestions?
You might want to increase com_hunkmegs to 32 (usually only necessary if you run custom maps). If you've got the bandwidth, set sv_maxrate to 10000 or 12000 and sv_fps to 30.
thanks a lot...it's a lot better now...with sv_maxrate at 12000 and hunkmegs at 32. i also set the sv_fps to 40 now. 30 was still some stumbling and stuff. can you explain me what exactly those values do? the description in the variable listing don't tell me much...that would be the last thing
and again...thanks to everyone for the input!!! :icon31:
com_hunkmegs determines the memory used by the server (but you probably knew that). sv_maxrate sets the max BPS (bits per second) that'll be sent to clients. sv_fps is the number of server frames per second. Each frame evaluates physics so the more, the merrier because it makes the game smoother but it'll also require more bandwidth.
I found this about the difference between set and seta:
The values in the config files can be set by two different methods. They are "set" and "seta". The command is followed by a variable name and then the value associated with that name, usually enclosed in double quotes (example: seta name "WarMonger"). Q3 logic looks up these names when need and gets the values associated with them. There is a very important difference between "set" and "seta" that, if not used correctly, can seemingly corrupt you config files.
As a rule, it is always a good idea to keep a backup of your config files before making any major changes, just in case.
Values set using the "seta" command are automatically written out to the config file the second they are changed ("seta" means 'set archive'). If you look in the q3config.cfg file generated by Q3 you will notice that they are all set using the "seta" command.
Values set using the "set" command are effective only for the current session of the game. They are not auto archived. Any changes that you want to make permanent, you would manually have to edit the config file with any plain text editor and re-save.
This begs the question--why not use "seta" for everything and make it easy. The problem is that using "seta" will auto archive the values only to the q3config.cfg file. Although you may have multiple config files, the changes made to variables using "seta" will be saved only to q3config.cfg. However, there is a limit to how big a config file may be. The config file is read all at once by the Q3 engine and if this limit is exceeded, Q3 will automatically switch to default settings for everything.
By using "seta" for every possible variable, especially for Coliseum2, you will quickly exceed this limit. Also, Coliseum2 added additional client side variables that are, by their intended design, auto archived (rail type, weapon hand, announcer sounds, hook bind key, etc.). Careful testing was done to make sure that the additional auto archived variables along with the ones created by Q3 will not exceed the allowable limit.
However, even if a variable was set using "set" in a config file, the user may override this by bringing down the console and change that variable by using "seta". This will cause that variable to be written out to q3config.cfg. Be careful not to do this since you may inadvertently cause q3config.cfg to exceed the file limit. No matter how the variable was originally set, using "seta" in the console will cause it to write to q3config.cfg.
thanks for the quick reply...
nice 