commit 93e9633382 "Port step smoothing code from r1q2." ported
r1q2 stair step smoothing for ranges that are equivalent to 8, 12 and 16
units/step.
Later in commit 7f996cc "Don't smooth half height steps" we removed
step sizes 8 and 12, because it appeared to make an elevator in hangar2
(over the water, after jump'n'run sequency) stutter.
However, in reality what made them stutter was the broken comparison
for velocity with an illegal cast, that we later fixed in
e30f82494 "Don't cast the array itself but it's content."
So now restore the smoothing for step sizes 8 and 12, which hopefully
fixes bug #923, and definitely does *not* break the elevater in hangar2.
The steps when loading a savegame are:
1. The server loads the map.
2. Loading the map spawns all entities, i.e. their spawn func is called.
This loads the models, precaches the sounds, etc.
3. The savegame is loaded and all the entities in the edict are replaced
by the entities read from game.ssv.
When the monster footstep sound were added in cfb86ac, new sounds were
added to the spawn functions of most monster entities. This alters the
sound indices of all sounds precached at a later time. When a savegame
from an older version is loaded, the entities read from game.svv still
reference the old sound indices. This leads to the wrong sound getting
played.
Work around this by lazy loading the footstep sounds. Instead of loading
(precaching) them in the spawn function, load them at their first use.
This has the nice side effect of preventing the "missing sound" messages
when running without the footsteps.pkz file in baseq2/. It might lead to
short stuttering when the sound is played for the first time, though.
Closes#917.
Fixes crash when entering "multiplayer" -> "player setup" menu with a skin name len > 16
Fixes "playermodels" cmd, which showed "(null)" as a final skin for every model
It seems to return -1 if the leaf is in the void; sometimes it
also seems to happen when you're just close to a wall, maybe due to
(mis)prediction.
ASan complains about this, but in practice it probably can't cause
issues, as the byte left to the mask array (from CM_ClusterPVS() or
CM_ClusterPHS()) will either belong to another global variable or
padding between them. Fixed it anyway.
