Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004483Zandronum[All Projects] Bugpublic2025-04-05 06:332025-04-13 17:04
Reporterunknownna 
Assigned ToKaminsky 
PrioritynormalSeveritytextReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version3.2 
Target Version3.2Fixed in Version3.2 
Summary0004483: [3.2] Winner names on scoreboard & intermission screen need to be frozen in case they disconnect
DescriptionWhile watching some Twitch stream featuring the latest 3.2 beta, I noticed that whenever a winning player disconnected during the intermission screen, the next player with the highest score would suddenly take over the win status and "win" the round. See the attached screenshot. IMHO, it would probably be better to freeze the winner text string, starting from the win sequence before entering the intermission screen. It would be a lot more intuitive that way.
Steps To Reproduce1. zandronum -iwad doom2.wad +deathmatch 1 +skill 4 +sv_cheats 1 +sv_nomonsters 1 +sv_weaponstay 1 +sv_itemrespawn 1 +alwaysapplydmflags 1 +map map01 +fraglimit 1
2. Add a bot into the game.
2. Kill the bot to win the round, then spectate either during the win sequence or intermission screen. The bot will "win" the round since the true winner spectated.
Attached Filespng file icon Screenshot_Doom_20250405_082817.png [^] (56,009 bytes) 2025-04-05 06:33


png file icon Screenshot_Doom_20250408_054749.png [^] (84,393 bytes) 2025-04-08 05:04


png file icon Screenshot_Doom_20250408_183340.png [^] (57,181 bytes) 2025-04-08 16:36


? file icon countdown_deathcount_01.wad [^] (944 bytes) 2025-04-10 20:20
? file icon countdown_deathcount_02.wad [^] (11,449 bytes) 2025-04-12 05:40

- Relationships
parent of 0004500resolvedKaminsky [3.2] Players erroneously think they take over lead if winner spectates during win sequences 

-  Notes
User avatar (0024386)
Kaminsky (developer)
2025-04-07 21:55

 This should be fixed now:'https://foss.heptapod.net/zandronum/zandronum-stable/-/commit/9fc051bff4eec60d695d89155394d6817b927039 [^]'
User avatar (0024389)
unknownna (updater)
2025-04-08 04:15

 Thanks, this seems to work, but I found some issues.

* The duel "champion" string is not frozen, though I'm not sure if it matters anyway right now, since the string is not even displayed in the intermission screen.
* It doesn't work right in LMS and Possession (though TeamLMS and TeamPossession seem fine), it always says "x has won with 1 win/point" even if the winlimit/pointlimit value is set higher than 1. This will affect the Megaman community since they seem to mostly play LMS-based modes.
I think this might partially be because the modes only check for the limits erroneously after win sequences in these modes instead of before like the other modes like TeamDM/CTF etc.
User avatar (0024400)
Kaminsky (developer)
2025-04-08 13:51
Quote from unknownna
It doesn't work right in LMS and Possession (though TeamLMS and TeamPossession seem fine), it always says "x has won with 1 win/point" even if the winlimit/pointlimit value is set higher than 1. This will affect the Megaman community since they seem to mostly play LMS-based modes.


This should now be fixed in this topic:'https://foss.heptapod.net/zandronum/zandronum-stable/-/commits/topic/default/clear-winner-multiple-rounds [^]'

Since I made a slight refactor of the code too, it'd be great if you can test this out thoroughly again to make sure everything's working correctly.

Quote from unknownna
The duel "champion" string is not frozen, though I'm not sure if it matters anyway right now, since the string is not even displayed in the intermission screen.


I'll see what I can do with this, but I imagine that also happens in 3.1 and earlier, right? It might not be too urgent to address this right now, also because the current champion isn't always the same as the winner of a duel.
User avatar (0024402)
unknownna (updater)
2025-04-08 14:34

 I tested it, and while it seems to have fixed the issue with LMS, the "x has won with x" string itself is now missing during the intermission screen in deathmatch, terminator and possession modes so far.

Quote from Kaminsky
It might not be too urgent to address this right now, also because the current champion isn't always the same as the winner of a duel.


No need to bother with this now since it's not even functional in the intermission screen.
User avatar (0024403)
Kaminsky (developer)
2025-04-08 15:05
Quote from unknownna
the "x has won with x" string itself is now missing during the intermission screen in deathmatch, terminator and possession modes so far.


I see. I made a couple of changes and amended the commit. Can you see if that issue's fixed now?
User avatar (0024404)
unknownna (updater)
2025-04-08 15:43

 Tested it, and it's still missing during the intermission screen in DM, Terminator and Possession if players enter the map as spectators. Also missing if winner spectates during win sequence in said modes.
User avatar (0024405)
Kaminsky (developer)
2025-04-08 16:13
Quote from unknownna
Tested it, and it's still missing during the intermission screen in DM, Terminator and Possession if players enter the map as spectators. Also missing if winner spectates during win sequence in said modes.


I'm sorry, but I can't seem to reproduce these issues on my end. At least, when I'm playing on these game modes, the "x has won with x" message appeared correctly during the win sequences and intermission when a player won and spectated/disconnected, both offline and online (note: in possession, if the winning player leaves during the win sequence, the game state changes, but this seems to be a separate issue).

What steps do you have to take to reproduce these?
User avatar (0024406)
unknownna (updater)
2025-04-08 16:36
edited on: 2025-04-09 17:25

 Interesting, I'm able to reproduce the issue following these steps:

1. zandronum -host +skill 4 +sv_nomonsters 1 +sv_weaponstay 1 +sv_itemrespawn 1 +alwaysapplydmflags 1 +sv_cheats 1 +deathmatch 1 +fraglimit 1
2. Connect 2 clients to the server and join the game with both.
3. Kill either of clients and notice how the string is missing during the intermission screen.

I also uploaded a screenshot depicting the issue.

Edit:
Does this issue have anything to do with players potentially not earning "victory" medals online?
Actually, I'm wrong here. The medal is only given in LMS, and not any other modes from the looks of it.
User avatar (0024409)
Kaminsky (developer)
2025-04-10 13:08

 Strangely, I still wasn't able to reproduce the issue by following the steps you provided above. Nonetheless, I changed my whole approach to fixing this problem and amended the topic just now. Hopefully this should work for you. If you can test everything again thoroughly, that would be great. Thanks!
User avatar (0024410)
unknownna (updater)
2025-04-10 18:36

 Since it didn't happen to you here either, I tried it with a fresh ini since it's a bit alarming if a client setting might affect it for itself and potentially others.
I found out the issue: It's caused by in-game clients using "cl_capfps 1". A client with capped FPS playing against other clients will not have the string displayed during the intermission screen, though this does not apply for spectators always.

I'll get to testing your latest fix now and see if it happens there.
User avatar (0024411)
unknownna (updater)
2025-04-10 19:37
edited on: 2025-04-10 20:20

 I can confirm that the latest fix took care of the missing win string, but:

* Deaths are now sometimes counted again during warm-up rounds in, but only displayed upon map reset. Might be caused by initial telefrags and "mdk" command, though other times the deaths aren't counted. Unable to reproduce reliably yet.

I think I was testing both builds at same time somehow. The new fix seems to be better.
Actually, I was right, the spawn-telefrags upon map changes erroneously count deaths on the scoreboard during warm-up countdowns.
User avatar (0024419)
Kaminsky (developer)
2025-04-11 04:54

 I'm thinking that in general, a player's death count probably shouldn't increment when they're spawn telefragged, just like how the player spawning doesn't earn a frag in this manner either. It doesn't seem fair that a player's death count goes up from something that's beyond their control (or the spawning player).

We can also assume that it's extremely unlikely that someone will get spawn telefragged in the middle of a game under normal circumstances, so spawn telefrags should generally happen right after a map change, or at the beginning or end of a countdown, when players respawn all at once.

I created a new topic to change this behaviour:'https://foss.heptapod.net/zandronum/zandronum-stable/-/commits/topic/default/death-count-spawn-telefrags [^]'
User avatar (0024421)
unknownna (updater)
2025-04-11 05:41

 I agree as long as spawn telefrags don't give out frags in general.

However, testing the pipeline build didn't seem to change too much from the old behavior:

* Spawn-telefrags still increment deaths with joining players in regular DM.
* Spawn-telefrags increment deaths when joining players telefrag others (LMS).
* Spawn-telefrags increment deaths when the map resets and players spawn-telefrag each other (LMS).
* Death counts no longer reset for players turning into real spectators (LMS). They retain their death count when joining the game again.
User avatar (0024426)
Kaminsky (developer)
2025-04-11 14:47

 I just amended the topic. It should fix all of those issues. Please let me know if it does for you too.
User avatar (0024428)
unknownna (updater)
2025-04-12 05:40
edited on: 2025-04-12 10:13

 I updated the example wad slightly to have overlapping player starts in all modes and tested the latest pipeline build with 2 clients on a server. For the invasion mode, go to MAP02 in the example wad. For survival invasion, enable "sv_maxlives 1".
Most modes seemed to work really well now, I found some separate unrelated (and ancient) issues and will make reports for them later, and made my notes below:

Coop: OK
Survival: OK
DM: OK
TeamDM: OK
Duel: OK
Terminator: OK
LMS: Broken, "x has won with 1 win" string bug returned during intermission screen with higher winlimit
TeamLMS: OK
Possession: Broken, "x has won with 1 point" string bug returned during intermission screen with higher pointlimit
TeamPossession: OK
CTF: OK
OneFlagCTF: OK
Skulltag: OK
Domination: OK
Invasion: OK
Survival Invasion: True and dead spectators' death counters aren't cleared when joining the game again when mission failed earlier and a new game begins
TeamGame (AOW2): Seems OK so far True spectators' frag counter not cleared when joining the game again if suicided in-game earlier.
User avatar (0024430)
Kaminsky (developer)
2025-04-12 16:21

 - The death counters not restarting at the start of a new game in survival invasion should be fixed in this topic:'https://foss.heptapod.net/zandronum/zandronum-stable/-/tree/topic/default/client-first-wave-countdown?ref_type=heads [^]'
- The true spectator's frag (or point) count not resetting to zero when they're negative should be fixed in this topic:'https://foss.heptapod.net/zandronum/zandronum-stable/-/tree/topic/default/spectate-frag-count-reset-fix?ref_type=heads [^]'

Note that the topic that fixed the winner name/score in (T)LMS and possession, and the topic that prevents the player's death count from increasing from spawn telefrags, are mutually exclusive because the issues aren't related to each other. So, testing any one of the pipeline builds isn't going to fix all issues mentioned here so far.
User avatar (0024433)
unknownna (updater)
2025-04-12 17:53
Quote from Kaminsky
testing any one of the pipeline builds isn't going to fix all issues mentioned here so far.

Ok, I see. It quickly becomes more confusing to test it thoroughly when the fixes are separate.

I tested both pipeline builds and can confirm it fixed the issues, but I noticed one more thing:

* Kills are not reset (though points are with sv_awarddamageinsteadkills) for true spectators when they re-join the game in regular invasion.
User avatar (0024435)
Kaminsky (developer)
2025-04-12 18:38
Quote from unknownna
Ok, I see. It quickly becomes more confusing to test it thoroughly when the fixes are separate.


To be fair, there's many different issues being discussed here that deviate from the original issue of this ticket (i.e. the winner's name/score appearing wrong on the scoreboard). Since these issues aren't directly related to each other, I want to keep them in separate topics so that I can later create a merge request for each of them. Going forward, I'd prefer if new tickets were created for each different issue, rather than trying to conflate everything into one ticket.

Quote from unknownna
Kills are not reset (though points are with sv_awarddamageinsteadkills) for true spectators when they re-join the game in regular invasion.


I amended the spectate-frag-count-reset-fix to also reset the player's kill count when they join spectators. Let me know if that fixes the problem for you.
User avatar (0024436)
unknownna (updater)
2025-04-12 18:55
Quote from Kaminsky
Going forward, I'd prefer if new tickets were created for each different issue, rather than trying to conflate everything into one ticket.

I understand, it just became a natural progression of ironing out the issues introduced by 0000404, and I wasn't quite sure if the issues in this ticket were regressions caused by the other fixes here.

Anyway, I tested the pipeline build and can confirm that the kill counters are cleared now in invasion. Thank you.

If the winner string issue is indeed fixed in its own branch, then I believe all the issues here are resolved.
User avatar (0024437)
Kaminsky (developer)
2025-04-12 19:46

 Sounds good! Thanks for reporting all of these issues and for testing everything thoroughly! I'll go ahead and open the merge requests for each issue so they get pushed in.
User avatar (0024439)
unknownna (updater)
2025-04-13 16:51

 I saw your fixes got merged into the main branch, I double-checked all modes, and it works good so far.

Coop: OK
Survival: OK
DM: OK
TeamDM: OK
Duel: OK
Terminator: OK
LMS: OK
TeamLMS: OK
Possession: OK
TeamPossession: OK
CTF: OK
OneFlagCTF: OK
Skulltag: OK
Domination: OK
Invasion: OK
Survival Invasion: OK
TeamGame (AOW2): OK
 
I noticed some minor issues that probably has to wait beyond 3.2:

* If the winner spectates during win sequences in DM, Duel, Terminator and Possession, the next player in line erroneously becomes the lead temporarily on their own end before the intermission screen. The leading player however still correctly thinks it leads.
* Deaths maybe shouldn't be incremented during win sequences in survival invasion since lives can't be taken away during them. Though this can be argued against, I'll probably ignore this one.

I'll make separate reports so it doesn't become too cluttered with separate issues here.

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2025-04-05 06:33 unknownna New Issue
2025-04-05 06:33 unknownna File Added: Screenshot_Doom_20250405_082817.png
2025-04-07 21:55 Kaminsky Note Added: 0024386
2025-04-07 21:55 Kaminsky Assigned To => Kaminsky
2025-04-07 21:55 Kaminsky Status new => needs testing
2025-04-07 21:55 Kaminsky Product Version => 3.2
2025-04-07 21:55 Kaminsky Target Version => 3.2
2025-04-08 04:15 unknownna Note Added: 0024389
2025-04-08 05:04 unknownna File Added: Screenshot_Doom_20250408_054749.png
2025-04-08 13:51 Kaminsky Note Added: 0024400
2025-04-08 14:34 unknownna Note Added: 0024402
2025-04-08 15:05 Kaminsky Note Added: 0024403
2025-04-08 15:43 unknownna Note Added: 0024404
2025-04-08 16:13 Kaminsky Note Added: 0024405
2025-04-08 16:36 unknownna Note Added: 0024406
2025-04-08 16:36 unknownna File Added: Screenshot_Doom_20250408_183340.png
2025-04-09 16:59 unknownna Note Edited: 0024406 View Revisions
2025-04-09 17:25 unknownna Note Edited: 0024406 View Revisions
2025-04-10 13:08 Kaminsky Note Added: 0024409
2025-04-10 18:36 unknownna Note Added: 0024410
2025-04-10 19:37 unknownna Note Added: 0024411
2025-04-10 19:53 unknownna Note Edited: 0024411 View Revisions
2025-04-10 20:20 unknownna File Added: countdown_deathcount_01.wad
2025-04-10 20:20 unknownna Note Edited: 0024411 View Revisions
2025-04-11 04:54 Kaminsky Note Added: 0024419
2025-04-11 05:41 unknownna Note Added: 0024421
2025-04-11 14:47 Kaminsky Note Added: 0024426
2025-04-12 05:40 unknownna File Added: countdown_deathcount_02.wad
2025-04-12 05:40 unknownna Note Added: 0024428
2025-04-12 05:45 unknownna Note Edited: 0024428 View Revisions
2025-04-12 10:13 unknownna Note Edited: 0024428 View Revisions
2025-04-12 16:21 Kaminsky Note Added: 0024430
2025-04-12 17:53 unknownna Note Added: 0024433
2025-04-12 18:38 Kaminsky Note Added: 0024435
2025-04-12 18:55 unknownna Note Added: 0024436
2025-04-12 19:46 Kaminsky Note Added: 0024437
2025-04-13 16:51 unknownna Note Added: 0024439
2025-04-13 16:51 unknownna Status needs testing => resolved
2025-04-13 16:51 unknownna Fixed in Version => 3.2
2025-04-13 16:51 unknownna Resolution open => fixed
2025-04-13 17:04 unknownna Relationship added parent of 0004500




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker