If a lightning bolt killed a player or the first shotgun pellet that
hit a player killed them, the shot was not counted as accurate.
Check if shot player is alive for hit accuracy before dealing damage.
Only use the crusher for killing the bot's enemy. This doesn't
affect 1v1 very much but prevents the whole team of bots in CTF
from suddenly shooting at the crusher button. Entering the crusher
bounds was basically instant death.
Make bots activate crusher on q3tourney6_ctf and mpq3tourney6.
Check if player is inside the crush bounds instead of below the
crusher. There is a jumppad the goes under it in mpq3tourney6.
Make callTeamVote check for all command separators like in callVote.
It's not exploitable as the only vote option (leader) always uses an
integer argument.
Also the ioquake3 engine remove command separators from client game
commands in Cmd_Args_Sanitize().
The Team Arena code for giving defense bonus for fragging player
who recently damaged a skull carrier unintentionally applied to
the flag carrier.
The skull carrier case would of been handled by the flag carrier
block above it. However, Harvest mode doesn't call
Team_CheckHurtCarrier() so the skull carrier defense bonus does
not work.
This restores the pre-Team Arena behavior of not giving defense
score bonus to flag carrier.
Fix copy-paste error in the original Quake 3 code. The wrong values
are used for v1 and v2. v2 was previously set to distance of attacker
to flag base; which should be handled already.
The game now gives defense score bonus to player when they frag an
enemy near their team's flag carrier while the player is more than
1000 units from the flag carrier.
This may also fix not giving defense bonus when near carrier due to
checking if carrier and enemy (instead of attacker) are in PVS.
Found by @Razish.
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.
- Actually use the second 'force' pass in G_Spawn when out of
available slots.
- Make G_EntitiesFree return qtrue if we can open a new slot.
(Only used when spawning Harvester skulls.)
Fixes not spawning Harvester skulls when there are no 'open freed
slots', but we have other slots available to open.
The Team Arena menu uses red team for single player but q3_ui
(and mods could) use blue. Also handle all the game types, not
just the ones used by Team Arena. Fixes FFA and Team DM.
Processing a callvote command after a vote passed to change maps but
has not been executed yet will result in 1) map change immediately
happening 2) after new map loads players have vote HUD messages but
Game VM doesn't have a vote in progress. The phantom vote status will
only be removed if players start a new vote or run vid_restart.
The underlying issue is that a second callvote sets vote config
strings but a map change is executed before they are sent to clients.
Resulting in clients getting "cs" reliable commands with the config
string changes _after_ the map change. Out of sync config strings.
Even if the underlying issue was fixed, the second vote would be lost.
So it's best to not force a map change to happen immediately anyway.
Reported by Tobias Kuehnhammer.
gcc 6 with -Wall -Wextra warns:
code/botlib/l_precomp.c: In function ‘PC_NameHash’:
code/botlib/l_precomp.c:551:2: warning: ‘register’ is not at beginning of declaration [-Wold-style-declaration]
int register hash, i;
^~~
Modern compilers either ignore the register storage class when
generating code, or generate better code without it, so just remove
most of them.
The remaining uses are in third-party bundled libraries (libjpeg, zlib),
and in a PowerPC-specific inline function consisting of inline
assembler (because I'm not 100% confident that it doesn't have
some practical use there).
The goal of reproducible builds is that a rebuild of the same source
code with the same compiler, libraries, etc. should result in the same
binaries. SOURCE_DATE_EPOCH provides a standard way for build systems
to fill in the date of the latest source change, typically from a git
commit or from metadata like the debian/changelog in Debian packages.
This does not change anything if SOURCE_DATE_EPOCH is not defined;
the intention is that a larger build system like a Debian package
will define it.
Please see https://reproducible-builds.org/ for more information about
reproducible builds.
Bot's lastkilledplayer was set to -1 after carrying out an ordered kill.
Later in BotChat_Random() the PlayerName function was passed -1 which
caused a "Error: PlayerName: playernum out of range" message.
I think the reason it was set to negative one is so that if the bot is
ordered to kill the player again, the bot will not say it's done and
drop the goal. Though, if the bot killed the player based on it's own
decision, it will just say it's done and drop the goal (bug?).
Let's check the time of the last kill to see if it happened since the
team order was received instead of setting lastkilledplayer to -1
after completing the team ordered kill. This fixes bot dropping goal
if target player was the last player they killed and the PlayerName
out of range error.
