Limits frames at a much higher level of precision than 'fps_max' and 'fps_max_gfx', probably ideal to reduce input latency even more. Also changed the logic of the NVIDIA Reflex frame limiter, to which it would use the desktop's refresh rate if set to '-1'. The new render thread frame limiter has a similar behavior. Using desktop refresh rates on the render thread or NVIDIA Reflex frame limiter requires 'fps_max' to be set to 0 (unlimited), as it would otherwise result in a major performance drop due to a contest if fps_max_(gfx/rt) is set to a similar number as fps_max.
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.
Removed all extraneous copies by adding the class 'InterfaceReg' which will construct a new interface, and link it to the engine's static register. The Source Engine macro 'EXPOSE_INTERFACE_FN' will help utilizing this. The game module from the plugin is not obtained through the process environment block, so the executable is no longer sensitive to names.
Renamed to 'm_bUseLocalSendTableFile'. If set, the 'CClientState::ProcessSendTable()' method drops the SVC_SendTable message, and keeps using the local file instead.
Added 2 comments that speaks for them self's, and 2 additional checks for the second loop as I had triggered several cases where it would loop indefinitely still, as we break out of the parallel loop and continue into the old school loop for the remainder of the outSeqNr - currentIndex frames. This should fix all problems related to this function. After numerous of tests with varying arbitrary outSeqNr values that were vastly larger than the current packet flow index, the bug was no longer triggered. A similar test had also be performed were multiple clients would do this at the same time, and even then; the server frame time(s) remained identical and the whole thing never hung.
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.
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.
RCON occasionally did NOT disconnect, but only if the socket has been closed improperly. If the server/client crashes for example, the connection remained open in RCON; pendingLen on the initial peek recv < 0 while socket isn't blocking means socket has been closed unexpectedly.
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.
