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.

(0024630) Zalewa (developer) 2025-11-03 19:24 edited on: 2025-11-03 19:26	The problem appears to be in Doomseeker alone and was explained by Kaminsky in comment 0004571:0024623 with accurracy. If I can rely on SQF_TEAMINFO_NUMBER to be 1 on teamgames and 0 on non-teamgames, then no change to the protocol is necessary.

(0024632) duke (reporter) 2025-11-03 20:31 edited on: 2025-11-03 20:42	It really is an issue or oversight in the Launcher protocol, which clearly didn't anticipate team-based coop being possible. But we found a workaround where no change in Zandronum is necessary except for documentation of the workaround. I believe the actual value of SQF_TEAMINFO_NUMBER is not useful here, because it only comes after SQF_PLAYERDATA in the query response. By that point you already need to know if there are teams or not, otherwise you can't properly parse SQF_PLAYERDATA to get to the value of SQF_TEAMINFO_NUMBER. So the idea is to request SQF_TEAMINFO_NUMBER and then check the header of the response to see if the flag was returned from the server at all. If it was returned, it's a team game and the actual value of SQF_TEAMINFO_NUMBER is unimportant (for the SQF_PLAYERDATA parsing issue anyway). From my preliminary testing this seems like it will work. Another possibility is requesting the deprecated SQF_TEAMSCORES flag instead, which is the only teams-related flag that actually comes before SQF_PLAYERDATA, but I guess there is no practical difference between these approaches.

(0024633) Zalewa (developer) 2025-11-03 20:49 edited on: 2025-11-03 20:51	Quote check the header of the response to see if the flag was returned This is what I meant. Sorry I was not verbose enough. When I asked about SQF_TEAMINFO_NUMBER being 1 or 0 I did not care about the value at all (which will usually be 2 or greater). I meant the SQF flag itself, i.e. the bit, i.e. 1 for "info is present" and 0 for "info is absent".

(0024634) duke (reporter) 2025-11-03 22:19	Gotcha. Sorry for my pedantry, I thought there was a misunderstanding

(0024635) Zalewa (developer) 2025-11-03 23:48	Zandronum plugin version 67 on the beta auto-update channel should carry the fix. 'https://bitbucket.org/Doomseeker/doomseeker/commits/9c3a475982997f2c9c66244e4cbac84bf5dc6692 [^]' Additionally, in order to support custom game mode names (0004107), the game mode recognition code went through some more intensive changes:'https://bitbucket.org/Doomseeker/doomseeker/commits/36f39fceaf92bab113137e2f197816bbe871039b [^]'

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
2025-11-03 19:22	Zalewa	Project	Zandronum => Doomseeker
2025-11-03 19:22	Zalewa	Assigned To	=> Zalewa
2025-11-03 19:22	Zalewa	Status	new => assigned
2025-11-03 19:24	Zalewa	Note Added: 0024630
2025-11-03 19:26	Zalewa	Note Edited: 0024630	View Revisions
2025-11-03 20:31	duke	Note Added: 0024632
2025-11-03 20:38	duke	Note Edited: 0024632	View Revisions
2025-11-03 20:42	duke	Note Edited: 0024632	View Revisions
2025-11-03 20:49	Zalewa	Note Added: 0024633
2025-11-03 20:51	Zalewa	Note Edited: 0024633	View Revisions
2025-11-03 22:19	duke	Note Added: 0024634
2025-11-03 23:48	Zalewa	Note Added: 0024635
2025-11-03 23:48	Zalewa	Status	assigned => needs testing
2025-11-03 23:48	Zalewa	Product Version	3.2.1 => 1.5.1
2025-11-03 23:48	Zalewa	Target Version	=> 1.5.2

Relationships