If the code was ran in the main thread, it would never fire the actual check logic. This patch changed the code so it would always fire from the start of the frame. Also fixed a memory leak that occurred when passing in an external banned list to SV_CheckClientsForBan (previously, 'SV_CheckForBan'); the code always allocated a new banned list, but only freed it if no external banned list was provided. This patch changed the code so it only allocates it if no external one is provided.
Fully implemented ConVar class so we could statically construct all SDK convars, this avoids a level of indirection, and allows for creating ConVar's everywhere in the project.
This patch also removed the settings tab of the ImGui server browser, as it has threading issues, while it technically never caused a crash yet, it has been removed as there was no point keeping it vs the work required to make it thread save (it only managed 2 convars which are perfectly manageable through cfg's or the in-game console).
Also temporarily disabled the creation of ConVar's in the mod system due to a memory leak, we would allocate and register a convar based on details parsed out of a mod file definition, but never unregister and free it.
- Upgraded hashing algorithm to SHA-512, and store the raw hash instead of a string copy, which is way cheaper to compute and compare.
- Only ever close sockets once in CRConServer::SetPassword().
- Made the game server & game client RCON singletons static.
- Added calls to gracefully shutdown RCON server and RCON client on Engine/SDK shutdown.
- Added more prints so RCON user knows when its shutdown, or when their password change is in effect, etc.
- Fixed bug where we could tokenize an empty string when we dispatch a console command.
* Move member vars to correct place, to match it with the engine.
* Added out-of-band network message ID's for the R5 engine.
Also implemented 'ServerDataBlockSender::SendDataBlock()' and 'ClientDataBlockReceiver::AcknowledgeTransmission()'. NOTE that these are currently not tested, and also not in use! The code uses the version stored in the vftable which is what the engine itself provides. These have been implemented for reference only. If they need to be used, they need to be thoroughly tested first!
This patch partially rebuilds the data block sender/receiver. The receiver leaks memory if the sender sends a bogus LZ4 packet, it would allocate memory to copy the encoded data into, from which it would decode it to the scratch buffer, but it would never deallocate this temporary buffer is the LZ4 decoder failed. This has been fixed. The second reason to rebuild these was to look into potential compression optimization. The data block rebuild now also features the latest LZ4 codec.
Avoid heap memory allocation and a level of indirection. This allows the compiler to optimize the program even more. No logic has been changed in this patch.
Originally, we store the search results in a CMemory instance which we then assign to the actual function pointer. CMemory is just a pointer class; we can assign the results directly to the actual function pointer. This commit reduces a lot of code verbosity, and also reduced roughly 2KiB worth of static pointers in the resulting executable. This commit also officially deprecates the support for any GameDLL's below S3 (Season 3), since it makes more sense to port the assets from earlier/later games back to the version this SDK supports.
This should in theory fix the server and client desync that takes place after multiple hours of uptime without disconnecting or reloading. Note that in this version of the engine the server tick is only send on connect (Titanfall 2 does seem to send it every tick, as this netmsg is also responsible for updating the server percentage on the 'cl_showfps' HUD, which does work as designed). The patched code still writes a 'statistics only' server tick update every tick, but only sends full if the interval time has been reached for that particular client instance.
Utilize the new IDetour::DetourSetup() code, IDetour::Attach and IDetour::Detach have been removed in favor of this (significantly reduces chance of user error). Since the template check happens in the idetour header, it is much more aggressive on type mismatches, such as a difference in parameter types, between the function and detour, will now raise a compile time error. As a result, some type mismatches have been fixed in this commit as well.
The game internally obtains a auth token from Origin. On connect to a gameserver, it will send it to the masterserver. The master server will create a JWT token and send this back to the client. The client stores this token in 3 userinfo cvars (token, sig1, sig2). the sig1 and sig2 cvars are there to compensate for the truncation caused by sending the cvar, as each cvar string length could be up to 255 (byte max). The server verifies this token (the signature, timestamp, expiry); if they are valid, the has successfully authenticated and will connect.
Use CUtlVector, and remove every copy caused by passing vectors by value. CUtlVector does not support copying. Also removed all extraneous std::string copies caused by calling itoa instead of std::to_string, or std::stoll, etc. All features have been tested and work as designed.
Command string buffer contains "sv_cheats" and value buffer contains "sv_cheats 1". Ideally value buffer only contains "1", and we just concatenate to "sv_cheats 1" for 'Cmd_Dispatch()' to avoid confusion on the netconsole's programmer side. This will be refactored in the future.
This member was in the class when RCON was added to the r5sdk, but it was never utilized. Now, each netconsole can toggle whether they are input only or not, the server only sends logs to netconsoles that are not input only. This patch also contains a fix in which the listen server sends logs to the client of its own process, causing an infinite recursive call to DevMsg.
CConnectedNetConsoleData was allocated and deallocated manually, but std::vector is able to do it on its own. The vector type has been swapped out with CUtlVector as this removed the need of having to cast size types to a 32bit int to make it more compatible with the other sdk/engine types without throwing compiler warnings.
* Moved dedicated server command line parameter init to 'init.cpp'.
* Registered 'SV_Main' on the client, this is engine code (lower level 'local' server wrappers).
* Disabled registration of Weapon_Bolt, although this is shared game code, this particular file is only used for the SERVER at this moment.
* Added the '-noserverdll' command lien parameter to instruct our loader.dll to load the client.dll instead.
* Adjusted the loader and sdklauncher project to support the loading of client.dll.
Move all server convars out of the EbisuSDK lib, the min/max name len are now parameterized. This also makes it possible to use the code on the client if ever needed.
CClient array is part of the CPlayer class. The array has been added, filling up most of the 'unknown' gap. Vtable override functions have been added as the array is static, and therefore requires an implementation of the vtable, these are just stubs however, since the vtable pointer points to the implementation in the engine.
Find regex pattern:
inline auto ([a-zA-Z0-9_]+) = ([a-zA-Z0-9_]+)\.RCast<([a-zA-Z0-9_:<>*]+) *\(\*\)\(([^)]*)\)>\(\);
Replace regex pattern:
inline $3(*$1)($4);
This commit also removes the unnecessary initialization (which was required to type the auto variables),
and therefore removed 6kb of unnecessary dynamic initialization code.
This commit fixes an engine bug where netmessages are getting copied into the replay buffer, while these messages should never be replayed. The engine performs an internal check on 'CNetMessage::m_nGroup', and if its NOT 2, the message is getting copied into the replay buffer. All messages returning false in 'ShouldReplayMessage' are not getting copied into the replay buffer anymore. This exploit has been used in the past to route clients that were watching a replay to an arbitrary server, which essentially forms an info leak as the client attempts to connect to the arbitrary server on its own. The exploit also allows for some form of remote code execution, depending on if the client was launched in developer mode or not.
