Graf Zahl wrote: ↑Sat Aug 12, 2017 1:23 am
Well, unfortunately this will be very hard to find because I got no idea where the backslash gets misinterpreted as a filter character.
For now, all I can recommend is not to use backslashes in the player name. The relevant CVar was smartly named 'name' so good luck finding where things go wrong.
What I need is some information about when this broke, due to the generic naming here there's little chance to find anything by looking for variables.
Turns out this bug isn't related to filtering and is not specific to names at all. I found out what causes this while debugging a similar bug, Somagu saw my explanation of the issue and pointed this bug report out.
This is caused by how the userinfo block gets sent to peers. The function in question is
D_GetUserInfoStrings and whatever the receive counterpart is. It uses backslashes as a marker. Any string user CVar with backslashes in it can and will break things.
Why couldn't Graf reproduce it? Why did it suddenly start desyncing for Somagu? Probably random chance, maybe also related to loaded mods and the names of the CVars they define.
It also behaves differently between game start and mid-game user CVar changes because of the "compact" mode. (verbose mode seems to be used exclusively at game start) [Edit] This wasn't correct, verbose mode is only used for demos. Mid-game CVar changes seem to be handled separately and DO escape the backslashes.
(I found this while trying to figure out why someone's mod would cause the player's name to somehow turn into whatever their movebob value is set to when they had a CVar named
hwatcom_c defined, that contained a backslash in its value)
[Edit] I just checked this further and realized there's a
D_EscapeUserInfo function... It's got only 3 uses in the code, in
D_UserInfoChanged, in the
special handling for playerclass and in the
special handling for skin... Why doesn't it escape everything?
Also noticed some things about compact vs verbose mode.