| Rev | Author | Branch | Log Message | Date | SHA |
|---|---|---|---|---|---|
| r24097 | 
Dutchman101 |
1.7 | Force rebuild Needed to fix unjust integrity violations |
16 May, 2026 | |
| r24096 |
Dutchman101 |
1.7 | Force rebuild |
11 May, 2026 | |
| r24095 |
Dutchman101 |
1.7 | Revert d184e39 due to backwards compat with setPlayerName (it could trigger Protocol Error 25) |
11 May, 2026 | |
| r24094 |
Dutchman101 |
1.7 | Force rebuild |
10 May, 2026 | |
| r24093 |
Dutchman101 |
1.7 | Force rebuild |
10 May, 2026 | |
| r24092 |
Dutchman101 |
1.7 | Force rebuild |
10 May, 2026 | |
| r24091 |
Dutchman101 |
1.7 | Force rebuild |
10 May, 2026 | |
| r24090 |
Dutchman101 |
1.7 | Use fail-safe ReadBit overload in join packet parser |
9 May, 2026 | |
|
Dutchman101 |
1.7 | Addendum to 614638d: Reject backtick in IsNickValid to match server-side CheckNickProvided |
9 May, 2026 | ||
| r24088 |
Dutchman101 |
1.7 | Force rebuild |
9 May, 2026 | |
| r24087 |
Dutchman101 |
1.7 | Reliability fixes for nickname valid-checks on client and server Fix 1: Backtick validation gap (client) Added strchr(szNick, '') != nullptrcheck to the client's CheckNickProvided, matching the server's version in Shared/Utils.cpp. Previously, a nickname containing a backtick passed all client-side checks, was serialized correctly, and then got rejected server-side with INVALID_NICKNAME. ... |
9 May, 2026 |