Allow listing about 273 .arena filenames for loading in q3_ui instead
of only about 136 that fit in a 2048 byte buffer (average 15 bytes per
file name).
The buffer for filename list runs out of space long before the buffer
for arena file content does. There is no warning for file list out of
space but there is a warning for arena file content.
This was requested by a user with many maps.
Team Arena's mpteam6 map has a shader textures/base_wall2/space_concrete
that contains an opaque stage, two non-lightmap blendfunc filter stages,
a blendfunc add stage, and a lightmap stage. The lightmap was attached
to all four of the non-lightmap stages causing the filter stages to
darken the lightmap multiple times.
Change setting up the lightall GLSL shader to only use lightmap if it's
the first stage or not a blendfunc filter stage. Now only the opaque
and blendfunc add stages of the mpteam6 shader use the lightmap.
Reported by Alexander Nadeau (wareya).
Newer versions of BSPC such as 2.1h included with the Quake 3 GPL source
code create AAS files containing areas in cluster 0 if the area has no
reachabilities.
The AAS files included with Quake 3 and Team Arena do not contain areas
in cluster 0. It's apparent that BSPC would not create them. Instead it
created clusters with no reachability areas.
It seems the intention was to check if the areanum and goalareanum have
reachable areas using AAS_AreaReachability(areanum) everywhere before
calling AAS_AreaRouteToGoalArea(). This prevents adding cluster 0 to
the routing cache and portal cache. However, it is not checked
everywhere and including some places in the Game VM.
Fix AAS_AreaRouteToGoalArea() instead of trying to wack-a-mole with all
the places that call it.
Cluster 0 access reported by Thomas Köppe (github @tkoeppe) as causing
crashes in rare cases.
A negative timelimit value or a value that would overflow the
multiplication by 60000 caused an endless map change/reload.
Based on patch and description by @vloup.
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.
Use an absolute path as required by systemd. Distro packages will need
to change it. (Reported by @andreyv and @zeroxfourc.)
Link to server documentation on the wiki instead of maintaining a subset
in the service file.
Windows API ignores all trailing spaces and periods which can get around
Quake 3 file system restrictions. QVM opening 'uix86.dll.' actually
opens 'uix86.dll' which allows QVM to write native code.
This is done in the low-level Sys_FOpen() instead of the function
directly used by VMs ( FS_FOpenFileByMode() ) in case there are engine
commands now or in the future that can read or write arbitrary files.
Reported by Noah Metzger (Chomenor).
* Don't try to embed manifest (it causes build to fail because it's
specified in win_resource.rc).
* Fix curl include path.
* Compile sys_autoupdater.c.
* Make quake3 debug link to msvcrtd.lib instead of msvcrt.lib to fix
unresolved external symbol __imp___CrtDbgReportW.
* Fix q3_ui dll output directory.
* Fix opus path filter.
* Use UseOfMfc false and CharacterSet NotSet.
* Fix header paths and remove non-existent files.
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.
It seems to improve framerate and still work on x86 and x86_64. I
haven't tested ppc64 as I don't have the hardware. ppc64 isn't built
into the universal bundle either.
I noticed this because compiling opus warns it may be slow due to
optimization being disabled.
