- Multiplayer support
- Updated weapon offsets with SkillFur's latest values
- APK contains and copies the glsl shader files now (no need to copy them separately)
- HUD models draw correctly now
- Increased the HUNK allocation limit so no more failues with Hunk_Alloc
- adjusted positional factor for adjusted worldscale
- scaled all weapons to 75% as that feels a bit better until such a time as better scaling/position is agreed
- world scale cvar - defaulted to 32.0
- extra latency mode enabled by default
- used sound implementation (OpenSLES) from RTCW which should eliminate the slight delay that SDL/OpenAL seems to have
- multiple cvar changes courtesy of vr_bummser
For lerped frames (refEntity_t frame not equal oldframe) IQM joint
matrices may have incorrect axis scale. This can cause significant model
distortion. The matrix lerp is linear causing each vector to move in a
straight line between frames instead of arcing like a circle. Each joint
frame can have a different scale so can't just normalize the joint
matrix.
Store joints as quaternions and spherical lerp between them and then
convert to a matrix. For my test model, setting up the skeleton is four
times slower now but it still seems to be fast enough to be usable.
Fix the output/behaviour of CVAR_CHEAT flagged cvars in case they are
also of type CVAR_LATCH (avoid the early latch case return to make it
work as intended).
This is exact root of q3msgboom bug http://aluigi.altervista.org/adv/q3msgboom-adv.txt
Unfortunately, server still need this ugly '1022 char limit' hack to support unfixed clients in some degree.
And as it affects MSG_ReadBigString() - unfixed clients can still be crashed by 8191-chars long configstrings that comes with gamestate
By default mingw-w64 uses Microsoft's broken _vsnprintf() in msvcrt.dll.
It can be overriden by defining __USE_MINGW_ANSI_STDIO but let's just
use the same behavior for both MSVC and mingw-w64.
Reported by @birdstakes.
My cvar latch system changes prevent the Game VM from changing
g_gametype when the value is out of range due to it being registed in
the engine. It's been pointed out as fragile method of security, which
was still exploitable, by Noah Metzger (Chomenor). It doesn't seem like
this is working out to be a good solution.
The issue of fs_game '..' on server being relicated on client via
systeminfo exploit is still fixed as it's not affected by latch.
There are a few cases from current values of fs_game are used which
ideally should use fs_gamedir char array which has been validated.
Revert "Don't let VMs change engine latch cvars immediately"
Partially revert "Fix fs_game '..' reading outside of home and base path"
Revert "Fix VMs forcing engine latch cvar to update to latched value"
A few commits ago I stopped VM's Cvar_Set() from instantly updating
latched values. Now VM can't call Cvar_Register() afterword to force
latched value to be used.
Reported by Noah Metzger (Chomenor).
VMs could set fs_game to '..' at anytime to access files outside of home
and base path. fs_game sent by server to clients could also be '..' to
access files outside of home and base path.
'..' was not caught by FS_CheckDirTraversal() as it expects filenames
not a single directory.
I've made fs_game be latched to prevent VMs from changing it with no
good way to validate it before it's used. com_basegame and fs_basegame
are now latched as well.
Additionally, it's now possible to change com_basegame while the engine
is running. game_restart or vid_restart will make it take affect.
com_homepath is now CVAR_PROTECTED to prevent VMs from changing it
to a directory traversal.
This requires my two previous commits for preventing VMs from changing
engine latch cvars and only Cvar_Get fs_game in FS_Startup (so CVAR_INIT
isn't added in serveral other places).
Reported by Noah Metzger (Chomenor).
If a VM increases sv_maxclients while a server is running the engine
will crash. The value should be latched until engine decides to update
the cvar; the same as when a user sets it.
VM could use Cvar_Register to set a protected cvar as user created and
was then able to use Cvar_Register with CVAR_ROM to change the value.
Don't allow Cvar_Register to affect protected cvars and prevent VMs
from adding internal flags to any cvars (creator, modified, protected,
nonexistent).
Reported by Noah Metzger (Chomenor).
There was an extra plus sign in Huff_Compress(). It wasn't causing any
issues as it does not affect the generated code. Removing it makes the
source code the same as Huff_Decompress().
The odd source code was brought to my attention by Tobias Kuehnhammer.
The use of signed types in these expressions lead to overflow, hence undefined behaviour. The "sum" aggregator in Com_TouchMemory isn't even used (and presumbably just exists to inhibit optimizations from removing the memory access).
Prevent reading past end of message in MSG_ReadBits. If read past
end of msg->data buffer (16348 bytes) the engine could SEGFAULT.
Make MSG_WriteBits use an exact buffer overflow check instead of
possibly failing with a few bytes left.
constructions like (dataMask & ~3) was used to protect against out-of-bound load/store when address is 4-byte closer to dataMask
but at the same time it effectively cut low address bits for ALL load/store operations which is totally wrong in terms of conformance to ALLOWED (i.e. generated by q3lcc from C sources) low-level operations like packed binary data parsing
- Paths to search for mods are now specified in an array
- Mods can now consist solely of ".pk3dir" folders and still be
considered valid
- The function now has a consistent style
