Having to manually request the list, with two buttons (get new
list, refresh list) is somewhat confusing. Also since it looks
like there are no servers, users might not try to figure out
how to get the server list.
The first time viewing a master server list in Team Arena UI,
automatically request a new server list. After that the cache
will be available with a timestamp of the last refresh time.
I think this will make it easier to understand how the menu
works.
This may cause unneeded updating of the server cache because the
last refresh timestamp is per-fs_game but the server cache is
shared by all games. This will only occur once for each game
though so it's not a big concern.
Resolve master server addresses every 24 hours instead of keeping
result forever. Don't clear sv_master[1-5] cvar if the address fails
to resolve; it might work later.
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
Need to be able to specify minimum Mac OS X version outside of the
Makefile to avoid conflicting CFLAGS.
Moved -mmacosx-version-min LDFLAGS into the Makefile.
Moved -arch x86_64 from OPTIMIZEVM to CFLAGS to fix linker errors
(previously make-macosx-ub.sh passed it to CFLAGS manually).
Save argument instead of using a pointer to cmd token memory that
might be overwritten when Cmd_TokenizeString() is called.
No known method for causing the issue without engine changes.
Cmd_TokenizeString() is called by FS_PureServerSetReferencedPaks()
in CL_Disconnect() but it's not an issue because the string is
blank.
Thanks @mickael9.
Check for truncated paths which could allow loading a library with
a non-standard extension. Also provides a better message for why a
valid library with a long path would fail to load.
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.
- 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
