MantisBT - Doomseeker
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004571Doomseeker[All Projects] Bugpublic2025-11-02 16:452025-11-03 23:48
Reporterduke 
Assigned ToZalewa 
PrioritynormalSeverityminorReproducibilityrandom
Statusneeds testingResolutionopen 
PlatformOSOS Version
Product Version1.5.1 
Target Version1.5.2Fixed in Version 
Summary0004571: Server query sometimes returning corrupted data
DescriptionDuring Danny's event on 1.11.2025 multiple people reported issues querying and joining the server via Doomseeker and I experienced the same firsthand.

Doomseeker would sometimes show <ERROR> for the server or it would give an error when attempting to join. Sometimes the query would work but show clearly corrupted data (see attached screenshot). The exact same corrupted data was shown in Doomseeker and on doomlist.net, which suggest the issue being server side, possibly some Launcher protocol edge case.

This only happened during some intervals and only during the Zombie Horde 2 segment (at least from what I saw). At other times the server queried fine.

At this point we don't know how to reproduce the issue and can only speculate about the cause, I'm entering this report just to put the issue on the radar.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filespng 2025-11-01_20-07-47.png (96,904) 2025-11-02 16:45
/tracker/file_download.php?file_id=3285&type=bug
png
Issue History
Date ModifiedUsernameFieldChange
2025-11-02 16:45dukeNew Issue
2025-11-02 16:45dukeFile Added: 2025-11-01_20-07-47.png
2025-11-02 22:31Ru5tK1ngNote Added: 0024618
2025-11-02 23:43dukeNote Added: 0024619
2025-11-03 00:03dukeNote Edited: 0024619bug_revision_view_page.php?bugnote_id=24619#r14600
2025-11-03 00:10dukeNote Added: 0024620
2025-11-03 05:27Ru5tK1ngNote Added: 0024621
2025-11-03 10:11FusedNote Added: 0024622
2025-11-03 13:15KaminskyNote Added: 0024623
2025-11-03 14:58dukeNote Added: 0024625
2025-11-03 15:49KaminskyNote Added: 0024626
2025-11-03 16:05dukeNote Added: 0024627
2025-11-03 19:22ZalewaProjectZandronum => Doomseeker
2025-11-03 19:22ZalewaAssigned To => Zalewa
2025-11-03 19:22ZalewaStatusnew => assigned
2025-11-03 19:24ZalewaNote Added: 0024630
2025-11-03 19:26ZalewaNote Edited: 0024630bug_revision_view_page.php?bugnote_id=24630#r14602
2025-11-03 20:31dukeNote Added: 0024632
2025-11-03 20:38dukeNote Edited: 0024632bug_revision_view_page.php?bugnote_id=24632#r14604
2025-11-03 20:42dukeNote Edited: 0024632bug_revision_view_page.php?bugnote_id=24632#r14605
2025-11-03 20:49ZalewaNote Added: 0024633
2025-11-03 20:51ZalewaNote Edited: 0024633bug_revision_view_page.php?bugnote_id=24633#r14607
2025-11-03 22:19dukeNote Added: 0024634
2025-11-03 23:48ZalewaNote Added: 0024635
2025-11-03 23:48ZalewaStatusassigned => needs testing
2025-11-03 23:48ZalewaProduct Version3.2.1 => 1.5.1
2025-11-03 23:48ZalewaTarget Version => 1.5.2

Notes
(0024618)
Ru5tK1ng   
2025-11-02 22:31   
The project should be filed under Doomseeker; I unfortunately cannot set it.
(0024619)
duke   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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   
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   
2025-11-03 22:19   
Gotcha. Sorry for my pedantry, I thought there was a misunderstanding
(0024635)
Zalewa   
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 [^]'