Bots take too much time to respawn

Hi,

I just compiled latest ioquake3 from git (commit bae86208), and started playing vanilla Q3 with bots on some tourney maps (e.g. q3tourney3 vs. Klesk). I noticed something odd. After I frag the bot, it takes a very long time to respawn (I don’t know how long exactly, but it’s about 20 seconds, possibly more).

I haven’t played Q3 for a very long time now, so my recollection may be fuzzy, but I think that the bots used to respawn more less immediately? Obviously it can make a big difference in 1 vs. 1, especially after a heated exchange, when freshly respawned player can immediately frag his weakened opponent even with the machine gun…

Is this behavior intended? If so, can it be switched off?

FWIW, I’m on Slackware-14.2, compiled ioquake3 with gcc-5.3.0, and SDL2-2.0.5. I really don’t know which details can be important here, so if there’s anything else I can provide, please tell me what. :slight_smile:

Bots usually respawn within 1 to 2 seconds. The game forces player respawn after 20 seconds (controlled by g_forcerespawn cvar). I’m guessing bots are failing to choose to respawn somehow. I don’t know why though.

As a workaround you could try setting g_forcerespawn 2.

I’m not able to reproduce the issue. If you want to try to debug it, I added some basic messages to try to tell if bot fails to ask to respawn.

cd ioq3
wget https://github.com/zturtleman/ioq3/commit/d47e3502aa5c6ba997ade91ac06fdf5e82f2695e.patch -O bot-respawn-debug.diff
patch -p1 -i bot-respawn-debug.diff
make
./build/release-linux-x86-64/ioquake3.x86_64 +set g_forcerespawn 20 +set sv_pure 0 +set vm_game 0 +set g_gametype 1 +devmap q3tourney3

Add a bot and kill it. Post the DEBUG messages here. Output should be something like this:

Sarge^7 ate ZTM^7's rocket
DEBUG: Bot 1 needs to respawn; current time 46.925999, respawn time 48.019783
DEBUG: Bot 1 wants to respawn; current time 48.023998, respawn time 48.019783
DEBUG: Bot 1 set ACTION_RESPAWN
DEBUG: Bot 1 waiting for game to respawn player; current time 48.127998
DEBUG: Bot 1 set ACTION_RESPAWN
DEBUG: Bot 1 waiting for game to respawn player; current time 48.223999
DEBUG: Bot 1 set ACTION_RESPAWN
DEBUG: Bot 1 waiting for game to respawn player; current time 48.327999
DEBUG: Bot 1 set ACTION_RESPAWN
DEBUG: Bot 1 waiting for game to respawn player; current time 48.424000
DEBUG: Bot 1 set ACTION_RESPAWN
DEBUG: Bot 1 waiting for game to respawn player; current time 48.535000
DEBUG: Bot 1 set ACTION_RESPAWN
DEBUG: Bot 1 requested respawn
DEBUG: Bot 1 has respawned; current time 48.624001

Thank you for your time.

I recompiled the game with your patch. The issue was reproduced, but I wasn’t seeing all the prints you were expecting:

Klesk^7 was machinegunned by arcctgx^7
DEBUG: Bot 1 set ACTION_RESPAWN
DEBUG: Bot 1 set ACTION_RESPAWN
DEBUG: Bot 1 set ACTION_RESPAWN
DEBUG: Bot 1 set ACTION_RESPAWN
DEBUG: Bot 1 set ACTION_RESPAWN
DEBUG: Bot 1 set ACTION_RESPAWN
DEBUG: Bot 1 set ACTION_RESPAWN
DEBUG: Bot 1 set ACTION_RESPAWN
...

See https://pastebin.com/MLZWpFP0 for full log.

Later I noticed that I have an old q3config.cfg lying inside baseq3/. I deleted all the config files, and after restarting the game without them the issue was gone. I don’t know why it didn’t occur to me yesterday. Guess I was tired. I’m sorry for wasting your time on this :frowning:

I wonder which setting from my q3config.cfg caused it…

Maybe try moving or renaming /home/arcctgx/.q3a/baseq3/qagamex86_64.so so that the newly compiled qagame in ./build/release-linux-x86_64/baseq3 will be used.

Hi again,

Sorry for necroposting, but after long experiments I have found the exact configuration option which affects this. It was com_maxfps. I had it set to 200, and after changing it to something else (switched to 166 now) the problem with bot respawn time is gone. I have tested this on the latest revision of the git repo (as of yesterday, 51e9aa2d).

It seems strange and counterintuitive, but maybe I shouldn’t be too surprised that framerate can affect gameplay given this: Why Your Framerate Affects Jumping. This is the reason I was using the value of 200, and switched to 166.

I don’t claim to understand the details, but I guess it can be really difficult case to debug. I’m posting this in case someone else will run into the same problem. Maybe my experience will be helpful.

Thank you for your support. :slight_smile:

1 Like