Client's clock could be behind or ahead of the server's, take this into account. Note that this code has been tested over night and only had a few hits when new baseline snapshots were applied on the server, or when there was a clock drift. It still requires an actual playtest with several players on low and high latency to determine if this is even needed.
- Check and clamp if commandTime is above serverTime (too far in future).
- Check commandTime delta before checking if above serverTime or below lastCommandTime.
- Make sure cmdTime is never lower than last.
- Make sure delta doesn't exceed maxUnlag.
- Make sure latency gets clamped to maxUnlag (clamp appears to be missing in the engine).
- Only check for cmdTime if we are not discarding the cmd; previously, already processed queued cmd's got checked before being discarded.
Temporary lag compensation exploit fix by clamping the difference. Exploiter could carefully control the detonation time of a grenade, or alter the ability cool downs by altering the 'CUserCmd::command_time' field before sending it up.
The implementation in the engine always took/returned signed 64bit size types, but I made a mistake when reversing the virtual function table. All types have been changed to what they should be (mostly signed 64bit, very few unsigned), and usage in-SDK has been adjusted accordingly.
Removed for:
* base_tickinterval_sp
* base_tickinterval_mp
* sv_updaterate_sp
* sv_updaterate_mp
* cl_updaterate_mp
Cvar 'cl_cmdrate' is deprecated in the engine and SDK since the CL_Move rebuild, and therefore has been removed entirely.
A string was constructed, but only for checking if its empty. This can be done on the char pointer itself. Made a inline helper func to reduce duplicate code.
Possible crasher is to send a stringcmd >= 512 in size with funny UTF8 characters and have CUtlBuffer::ParseToken() read past it. Apparently seems to be mostly a problem on 32bit? I was unable to initiate a crash, though one string caused interesting behavior before, and there was one report of the dedicated server being 'crashed' with this. There is no reason to tokenize it up to 512 bytes if the game is only ever going to allow 128, so clamp it to 129 and if the user exceeds it then they still get the message and we just jettison it.
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.
Nice to implement at some point, but its not a priority. The current system just disables itself if its under attack (requires action from server owner to re-enable).
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.
Move all classes deriving from ConCommandBase to a single file, and split out CCommand, CCvar, CCvarUtilities etc to their own files. This makes it possible to use CCommand and stuff in external tools without linker errors/warnings.
