0004571: Server query sometimes returning corrupted data

Notes
(0024618) Ru5tK1ng (updater) 2025-11-02 22:31	The project should be filed under Doomseeker; I unfortunately cannot set it.

(0024619) duke (reporter) 2025-11-02 23:43 edited on: 2025-11-03 00:03	I think this is a Zandronum / Launcher protocol issue, not a Doomseeker issue. I described symptoms as seen in Doomseeker, but like I wrote it seems to impact all server browsers.

(0024620) duke (reporter) 2025-11-03 00:10	Fused told me: "Kaminsky suspects it's the way Zombie Horde 2 is put together. I am using the cooperative gamemode, but I enabled teams through the GAMEMODE lump" This does seem like the likely culprit to me. Server query responses need to be parsed differently depending on if the game mode is a team game or not, but browsers rely on game modes to know that (eg. there are separate gamemodes for Deathmatch and Team Deathmatch). Since ZH2 uses Cooperative but also has teams, this can cause browsers to parse query responses wrong. If this is indeed the problem, then I guess there are multiple ways to resolve it: 1) Consider it a mod issue – in this case ideally Zandronum should error out when mod authors try to have teams to non-team gamemodes 2) Allow teams in non-team gamemodes, but don't send team info in server query responses in that case to keep the protocol compatible 3) Change the Launcher protocol to avoid the ambiguity

(0024621) Ru5tK1ng (updater) 2025-11-03 05:27	First option isn't a real option because that limits the modding ability of Zan. Most likely the best course is to go for the third option.

(0024622) Fused (reporter) 2025-11-03 10:11	Zalewa is looking into this. He confirmed that the server showing an error is due to the mod using cooperative with teams enabled, and having at least 1 player in the server. He's going to take a look at the packet data and if Doomseeker must fix this or if this is a bigger issue.

(0024623) Kaminsky (developer) 2025-11-03 13:15	Quote from duke 2) Allow teams in non-team gamemodes, but don't send team info in server query responses in that case to keep the protocol compatible FYI, servers already don't send out team information in responses when the current game mode isn't team-based, even if launchers request it:'https://foss.heptapod.net/zandronum/zandronum-stable/-/blob/branch/default/src/sv_master.cpp?ref_type=heads#L804 [^]' However, if these bits are still enabled in the response, then it should be good enough of an indication to know if the game mode sent in the packet supports teams. The issue here is that Doomseeker always assumes that cooperative is a non-team-based game mode (not necessarily a bad assumption, but Zandronum allows customizing built-in game modes and their flags via GAMEMODE, so team-based cooperative game modes are possible): -'https://bitbucket.org/Doomseeker/doomseeker/src/766e704023aac917f829608bb0996ec977e0f84b/src/plugins/zandronum/zandronumgameinfo.cpp?at=master#lines-79 [^]' -'https://bitbucket.org/Doomseeker/doomseeker/src/766e704023aac917f829608bb0996ec977e0f84b/src/core/serverapi/serverstructs.cpp?at=master#lines-402 [^]' -'https://bitbucket.org/Doomseeker/doomseeker/src/766e704023aac917f829608bb0996ec977e0f84b/src/core/serverapi/serverstructs.cpp?at=master#serverstructs.cpp-390 [^]' As a result, when a mod is running cooperative with teams, Doomseeker parses the packet data erroneously because SQF_PLAYERDATA also sends every player's team index, which it isn't accounting for. Quote from duke 3) Change the Launcher protocol to avoid the ambiguity In principle, a new query flag (e.g. SQF2_TEAM_GAMEMODE) could be added to protocol that returns a boolean to verify if the game mode returned via SQF_GAMETYPE allows players to join teams. Though, if the flags that correspond to team information are already disabled in responses when the game mode isn't team-based, then I don't think this is necessary.

(0024625) duke (reporter) 2025-11-03 14:58	> FYI, servers already don't send out team information in responses when the current game mode isn't team-based, even if launchers request it: I meant in particular the extra "team" byte in SQF_PLAYERDATA - I think that is the most problematic part, as you need to know whether to expect it or not. The wiki says it's "returned on team games", but doesn't specify how to find out if that is the case. The problem with using a SQF2 flag to disambiguate is that SQF_PLAYERDATA comes much earlier in the response. You already need to know whether to expect the extra byte (team) for each player before you get to parse SQF2 flags. But asking for a SQF_TEAMINFO_* flag and checking whether it is returned does seem like a functional way to find out early enough how to parse SQF_PLAYERDATA. It does make the protocol a bit more convoluted though, since it's not obvious that you must ask for SQF_TEAMINFO_* and check if it's returned just to be able to parse SQF_PLAYERDATA properly.

(0024626) Kaminsky (developer) 2025-11-03 15:49	Quote from "duke" But asking for a SQF_TEAMINFO_* flag and checking whether it is returned does seem like a functional way to find out early enough how to parse SQF_PLAYERDATA. It does make the protocol a bit more convoluted though, since it's not obvious that you must ask for SQF_TEAMINFO_* and check if it's returned just to be able to parse SQF_PLAYERDATA properly. If a bold disclaimer was added to the wiki to make it clear that checking if team-related query flags are returned is a more reliable way of verifying if the current game mode is team-based, then would be the enough? The alternative (i.e. "change the launcher to avoid the ambiguity") could mean adding the boolean to SQF_GAMETYPE instead, but that will break every launcher that won't expect it, and I'm really not sure if that's worth addressing a rare issue like this.

(0024627) duke (reporter) 2025-11-03 16:05	I agree, changing the protocol to make this cleaner probably isn't worth it. If this solution relying on SQF_TEAMINFO_* is documented I think it's reasonable.

Only registered users can voice their support. Click here to register, or here to log in.
Supporters:	No one explicitly supports this issue yet.
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2025-11-02 16:45	duke	New Issue
2025-11-02 16:45	duke	File Added: 2025-11-01_20-07-47.png
2025-11-02 22:31	Ru5tK1ng	Note Added: 0024618
2025-11-02 23:43	duke	Note Added: 0024619
2025-11-03 00:03	duke	Note Edited: 0024619	View Revisions
2025-11-03 00:10	duke	Note Added: 0024620
2025-11-03 05:27	Ru5tK1ng	Note Added: 0024621
2025-11-03 10:11	Fused	Note Added: 0024622
2025-11-03 13:15	Kaminsky	Note Added: 0024623
2025-11-03 14:58	duke	Note Added: 0024625
2025-11-03 15:49	Kaminsky	Note Added: 0024626
2025-11-03 16:05	duke	Note Added: 0024627

Relationships