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.
This is just a simple RSA public key digital signature thing built on
libtomcrypt. The gist:
Some admin will generate a public/private key with rsa_make_keys, keeping the
private key secret. Using the private key and rsa_sign, the admin will sign
the autoupdater manifests, generating manifest.txt.sig.
The public key ships with the game (adding 270 bytes to the download), the
.sig is downloaded with the manifest by the autoupdater (256 bytes extra
download), then the autoupdater checks the manifest against the signature
with the public key. if the signature isn't valid (the manifest was tampered
with or corrupt), the autoupdater refuses to continue.
If the manifest is to be trusted, it lists sha256 checksums for every file to
download, so there's no need to sign every file; if they can't tamper with the
manifest, they can't tamper with any other file to be updated since the file's
listed sha256 won't match.
If the private key is compromised, we generate new keys and ship new
installers, so new installations will be able to update but existing ones
will need to do a new install to keep getting updates. Don't let the private
key get compromised. The private key doesn't go on a public server. Maybe it
doesn't even live on the admin's laptop hard drive.
If the download server is compromised and serving malware, the autoupdater
will reject it outright if they haven't compromised the private key, generated
a new manifest, and signed it with the private key.
libtomcrypt is sort of a big pile of source code, so instead of putting it
in revision control, we have a script to download it. Most things don't need
it. It lives on GitHub, so we _could_ do a git submodule, but most people
don't need it, so why waste their disk and bandwidth? That said, when compiled
you end up with a few hundred kilobytes of binary code to verify a signature
and no external dependencies, so it seems like a win.
