Don't add the same bot to multiple teams until there are as many
bots on the server as there are bot types.
Previously each team would have unique bots until all bot types
were added to the team but other teams may have the same bot. Now
there will not be any duplicate bots until there are more bots than
bot types.
Now Quake 3 (32 bot types) in 16 vs 16 bot CTF will not contain
duplicate bot types. (You have to increase memory in code/game/
g_mem.c in order to add 32 bots though.)
I had to change G_AddRandomBot() to use 'addbot random' or else the
same bot could be added to red and blue teams. The bot was selected
and stored in console command buffer so game doesn't know not to
select the bot again.
If there are two bot infos in scripts/bots.txt then each team can
only add two random bots via bot_minplayers or addbot random.
Pick random bot info from least used bot infos instead of only ones
that are used by zero players. That way a random bot can always be
added to the game.
This rarely affected Quake 3 since there is 32 bot infos. It could
easily affect new games though.
Team Arena's Overload gametype has red and blue team Obelisk base
objects. It uses separate entities for visual and damage. Only the
damageable entity was dropped to floor. Leaving model floating off
the ground.
Team Arena's Harvester base has the same problem. Model entity
floats in air but trigger entity drops to floor.
Drop all Team Arena team base models to floor. Fixes CTF, 1Flag,
Overload, and Harvester base models.
There are various issues caused by not knowing the initial team for
the local client and bots when they connect. This is can be reproduced
by starting a team game from the main menu.
When g_teamAutoJoin is enabled, bots and local client join a random
team at connect and then execute their team command a few frames
later. This may result in the player being killed if they specify a
different team. In Team Arena's Harvester mode this causes harvester
skulls to be spawned at the beginning of the game.
When g_teamForceBalance is enabled, the local client and bots may not
be able to join their desired team. This may result in them being
spectators. If g_teamAutoJoin is also enabled they may be left on
the opposite (red/blue) team they were meant to join.
There is a hack for including bot's team in their player info string
(used by cgame for which team skin to use) before the bot joins
their desired team. Bots aren't guaranteed to join their desired team
(as may happen when both g_teamAutoJoin and g_teamForceBalance are
enabled) so clients may see them as being on the wrong team!
----
Add teampref userinfo option for team preference. If teampref is set
it will be used for attempting to join the team immediately at connect.
Bots now join team at connect using teampref userinfo. So remove
the hack for setting bot's team in player info string before the bot
joins the team.
To avoid the client sending teampref userinfo to all network servers,
the local client uses a g_localTeamPref cvar. The g_localTeamPref
cvar is cleared after it's used so it doesn't get used when starting
another server later. Another reason not to use a teampref userinfo
cvar is there isn't a reliable way to clear it in CGame/UI which are
likely loaded from baseq3 pk3.
Make it so g_teamAutoJoin doesn't affect clients who specify
teampref. If teampref is invalid, the client will join a random team
like g_teamAutoJoin.
Don't apply g_teamForceBalance to the local client or bots. Otherwise
they may be left as spectators when starting team game from menu.
The start server menus use team command and g_localTeamPref to set
the human player's team. This way it's compatible with vanilla Q3
game VMs and the new setting team at connect feature.
Bots did not notice player disconnected, so they kept attacking
the last known position.
Checking if entity is valid in BotEntityVisible might fix other
similar issues too.
