Some specific paks are loaded through code (common.rpak, ui.rpak. etc). We have implemented a system that also loads 2 common rpaks that are of our own (common_sdk.rpak and ui_sdk.rpak).
There is al additional syustem we had implemented earlier that allows you to mount rpaks during level load, which will get loaded before the actual level rpak, this is useful as when we port a map that has evolved slightly from its original one, only needing 20 new models, it makes more sense to load the original rpak + a new one that contains the 20 new models to save disk space.
This is also useful for mounting paks specific to mods for a certain map, however since we have some core mods (flowstate) we have to add it to the settings for for each level. These paks also get dropped and reloaded each time on level changes causing longer load times and more memory usage during level loads.
This system mounts paks after all common paks are loaded (from both the engine and sdk), and keeps them active just like the common paks throughout level changes until they are either manually unloaded, or the game has been closed.
16 was causing the clients to get kicked when they hover and moving their cursor over the characters in character select very fast. The scripts tell the server to update the view to other clients but unfortunately the system relies on string commands (ClientCommand) and is pending a rewrite to incorporate a proper RPC just like Server and UI has. For now we increase the limit to 32 as 32 is still outside the exploitable range when the game is ran without dev tools enabled.
CServer::GetClient() will never return NULL as it returns address of client in array. Removed extraneous checks as its misleading, and added const where possible.
The game can now be ran fully offline by providing '-offline' to the command line arguments. The engine will auto execute 'system/autoexec_offline.cfg' which overrides other autoexecs to ensure the game runs offline. The system/autoexec_offline.cfg file only overrides the variables it sets.
CustomPakData_t::numHandles was never decremented on unload, causing pakId == PAK_INVALID_HANDLE to be true and triggering the assert. Due to this, we either never unload resources properly on subsequent unloads and loads, or we would run out of pak slots as numHandles will reach MAX_CUSTOM_PAKS. Also added a comment explaining why this loop isn't ran in reverse.
Changing the load/unload system to FILO caused a crash when loading 3 level paks, either through request load or level settings, and then unloading them in reverse order. This is a regression caused when the pak loading and unloading system was reworked. Changing the system back to FIFO fixes the issue.
Netmessage SVC_SetClassVar allows the server to change class settings securely on the client. This was implemented due to popular demand, and previous approaches using a combination of ClientCommands (Cbuf and NET_StringCmd) were deemed insecure and unreliable.
Change callbacks actually take a structure of 2 pointers, one being for the callback itself, and the other being 'userdata' which typically is used to sync the ConVar with VGUI slider elements. This issue was noticed after implementing the ADS scalars and attempting to hook them up to VGUI, only to find out it would crash due to this lacking detail. All change callback prototypes had to be adjusted.
Properly load it from CServerGameDLL::DLLInit (and new in this commit, the client's shared globals from CHLClient::Init), this way we can also avoid the double dereference which improves performance. Also performed an architectural change where anything outside Game DLL code uses the shared interface pointer instead of the objects directly.
There was always a problem dealing with core integral types accros various projects, since we typically only use IDA's pseudo definitions for rebuilding decompiled functions. It however did define almost all the integral types we use throughout the SDK. These types have been commented out and a new header has been made that defines everything we need (and we can add more in the future if this deems necessary). This new header is included with tier0/basetypes.h, so all projects have access to it and the tier0 headers will work out of the box without defining anything new.
Allow the user to reconnect to a server by running 'reconnect', this also allows for reparsing all client side scripts while debugging the game on a dedicated server.
Make it more obvious what we are loading and what not (instead of checking if its client only, check if the server should load it since the client needs everything). This will also make sure that we never load other lumps even if they are present in the VPK or disk (they aren't for dedi builds).
Some users complained about not being able to practically retrieve the installed netkey from the application's console as it bets buried under newer logs (and eventually cleared). This ConCommand allows the user to query the installed key without having to look through session logs.
Unbind the game from the platform system, which is useful when developing for or debugging the game. This was supposed to make it into the SDK back in 2021, but wasn't due to the ability to spoof usernames. This is no longer possible on servers requiring authentication as the player's name is actually checked along with the Nucleus ID.
Unclamped CBitRead::ReadBits() call on stack buffer of MAX_USER_MSG_DATA bytes. Function has been rebuilt with additional clamping to mitigate the problem.
- Fixed stack smash in CClient:ProcessVoiceData (oob read on bitbuf).
- Fixed stack smash in CClient:ProcessDurangoVoiceData (oob read on bitbuf).
- Fixed ability to bypass team check on Durango voice packets if forced as reliable from the sender (client).
- Incorporated the following missing checks in the durango version of voice broadcasting:
- Enforce chat between multiple teams using cvar 'sv_alltalk'.
- Ability to also disable Durango voice data with cvar 'sv_voiceenable'.
- Ability to echo voice with Durango voice data using cvar 'sv_voiceEcho'.
Code actually doesn't need to be ran in the server frame thread. All the code really does is preparation work. Run it in the main thread but do join the server frame thread (FCVAR_SERVER_FRAME_THREAD) as we can't do concurrent work on the server VM.
Previously we did sq_pushroottable() and a subsequent sq_call() after compiling the text buffer, but this didn't work for code that was threaded, or using Get/SetNetVar* functions.
The second issue was that the callback for the "script" command was ran in the main thread. Server script should always run in the server frame thread, the Set/GetNetVar* functions check thread id to retrieve the correct VM context, so running server script from the main thread ended up with Set/GetNetVar* functions retrieving the client VM context rather than server's, causing undefined behavior.
Script commands are now queued to the server frame thread, ultimately fixing this bug.
Also fixed a small bug with function 'sq_compilebuffer()'; it takes an extra argument but this wasn't taken into account in the SDK.
Decoupled from net_usesocketforloopback since we actually don't want this to be tied with that of the game. Now it by default does not bind to the loopback socket unlike the game.
Can be toggled with the new cvar 'host_autoReloadRespectGameState', and used in combination with the new server script func 'SetAutoReloadState( bool state )'. This makes sure that even when the timer reaches 'host_autoReloadRate', it would wait with the reload until the game itself is finished (which is when SetAutoReloadState( true ) is being called from scripts).
