Otherwise the snapshots may incorrectly be invalidated because a change of the `cl_dummy` variable is detected when connecting to another server after disconnecting while the dummy is active.
Send dummy ready and enter game when connection is online based on its state instead of when the security token is not unknown anymore, which should effectively be the same condition but more understandable. This is also how it's already done for the main connection so the `SecurityTokenUnknown` function can be removed as it's unused now.
The console was not keeping its current scoll position if entries from the backlog are removed due to being recycled when new entries are added. For this purpose, a callback function is added to the ringbuffer to handle popped items, so the scrolling position of the console can be updated based on the number of lines of the removed backlog entries.
Fix backlog corruption in `CConsole::PumpBacklogPending` when many backlog entries are allocated at the same time. When allocating many entries from the `m_Backlog` ringbuffer at the same time, the first entries being allocated may already have been recycled again, so the pointers to them being stored in the temporary vector of new backlog entries were pointing arbitrarily into the ringbuffer data, which could cause corruption of the structural and user data of the ringbuffer. Now, we iterate over the entire backlog and only update uninitialized entries instead of storing the new entries separately.
This was sometimes caught as a misaligned access with UBSan:
```
src/engine/shared/ringbuffer.cpp:160:14: runtime error: member access within misaligned address 0x00014126f4df for type 'struct CItem', which requires 8 byte alignment
0x00014126f4df: note: pointer points here
<memory cannot be printed>
0 0x5825349a6a1c in CRingBufferBase::Prev(void*) src/engine/shared/ringbuffer.cpp:160
1 0x5825334e8934 in CTypedRingBuffer<CGameConsole::CInstance::CBacklogEntry>::Prev(CGameConsole::CInstance::CBacklogEntry*) src/engine/shared/ringbuffer.h:59
2 0x5825334d13e6 in CGameConsole::OnRender() src/game/client/components/console.cpp:1259
3 0x582533bce058 in CGameClient::OnRender() src/game/client/gameclient.cpp:715
4 0x582532f3cc44 in CClient::Render() src/engine/client/client.cpp:894
5 0x582532f9d236 in CClient::Run() src/engine/client/client.cpp:2971
6 0x582533002e5e in main src/engine/client/client.cpp:4523
```
Fix out-of-bounds accesses when rendering ghost players, which use the client ID `-2`. This was causing the hook collision line of ghost players to be affected by real players, which is not correct, as ghosts do not interact with other characters.
Closes#8239.
Add optional filename argument to `start_video` command, to start recording to a video file with a specific filename, instead of always using the current timestamp.
Add log messages to `start_video` and `stop_video` commands to indicate success and errors.
Make the `CClient::StartVideo` function non-`static` and reduce duplicate code in the `Con_StartVideo` function.
Determine the video filename outside of the `CVideo` constructor, same as for demos.
Fix game times and prediction not being updated when only exactly two snapshots have been received, due to the conditions `m_aReceivedSnapshots[...] >= 3`. These specific condition are not necessary and replaced with simpler checks whether the current snapshot is set. Some duplicate nested conditions are also removed.
Pump the network first in `CClient::Update` before updating anything else, to ensure that snapshots are received from the network client before the game times and prediction are being updated based on the current snapshots.
Fix current and previous game tick always being `0` on the first call of `IGameClient::OnNewSnapshot` when two snapshot have been received. Now, the game ticks are properly initialized from the two initial snapshots.
Fix old inputs sometimes being used in prediction after changing map because inputs with tick `-1` were not being ignored.
Ensure all snapshots and game times are properly cleared when entering the game.
`GetConsoleMode` can fail with `ERROR_INVALID_HANDLE` when redirecting output to `nul`, which is considered a character file but cannot be used as a console.
The purpose of this condition is to only update the freeze time every 50 ticks so the freeze bar keeps being refilled after one second when standing in freeze, but it incorrectly prevented freeze from being applied during the first 50 ticks after the map has been loaded. Now, freeze is also applied if not currently frozen, so the behavior directly after changing the map is identical to subsequent respawns.