ZDoom

Did you ever have a closer look at this mess? The entire user info stuff is some of the most awful code in the entire engine. It really needs a complete rewrite from the ground up - and ultimately should use JSON to send the data, not some hacked together and obviously non-functional homegrown format.

I only recently did a partial refactoring here because the original code depended on side effects from specific compiler assumptions.

[quote="Graf Zahl" post_id=1013902 time=1502522593 user_id=75]
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.
[/quote]
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 [url=https://github.com/ZDoom/gzdoom/blob/e3f8230/src/d_netinfo.cpp#L741][c]D_GetUserInfoStrings[/c][/url] 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. [s]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)[/s] [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 [c]hwatcom_c[/c] defined, that contained a backslash in its value)

[Edit] I just checked this further and realized there's a [url=https://github.com/ZDoom/gzdoom/blob/e3f8230/src/d_netinfo.cpp#L97][c]D_EscapeUserInfo[/c][/url] function... It's got only 3 uses in the code, in [url=https://github.com/ZDoom/gzdoom/blob/e3f8230/src/d_netinfo.cpp#L542][c]D_UserInfoChanged[/c][/url], in the [url=https://github.com/ZDoom/gzdoom/blob/e3f8230/src/d_netinfo.cpp#L783]special handling for [c]playerclass[/c][/url] and in the [url=https://github.com/ZDoom/gzdoom/blob/e3f8230/src/d_netinfo.cpp#L788]special handling for [c]skin[/c][/url]... Why doesn't it escape everything?
Also noticed some things about compact vs verbose mode.

Moving to "on hold" since this one is going to be particularly tricky to track down.

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.

gzdoom.exe -host 2 -skill 4 -port 27015 -noautoload

The two names I used were \Akkari-n/ and \Test.

[code]gzdoom.exe -host 2 -skill 4 -port 27015 -noautoload[/code]
Was alternately tested with variations including the mapset Fragport, the gameplay mod Reelism, and on port 7707. Always with two players, always over a net connection and not locally. Desynced after roughly 20-40 seconds of normal gameplay, which always indicated actual desyncs between players as opposed to superficial ones that might be skin or sound related. Tested with all 3 people (2 player netplay again each time) and with mod and map permutations afterwards and the desyncing ceased after my name was changed to not contain a backslash.

[edit]Also, always peer to peer netmode and not packet server.

Curiously, it doesn't happen if the name is changed to contain a backslash [b]during[/b] gameplay, only if it's started as such. Netplay works fine with all 3 players otherwise. No tunneler programs are in use.

[editx2]Using the 32-bit and 64-bit Windows versions both have the same result, in matching or differing pairs between the two players.

I cannot reproduce this. Could you please specify exact player's name and command line used?

If netplay is started and one of the players has a name containing/beginning with a backslash, the game will consistently desync after about 20-40 seconds. Confirmed on both 3.1.0 stable and the most recent published build as of this moment. (gzdoom-g3.2pre-399-g04be9fe)

Confirmed with three separate people, and is consistently repeatable. Can also confirm this was not the case previously, as I had used that name years ago with no issue.