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
0004135Zandronum[All Projects] Bugpublic2023-05-07 15:012025-03-25 12:57
ReportergeNia 
Assigned ToKaminsky 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version3.1 
Target Version3.2Fixed in Version3.2 
Summary0004135: cl_respawninvuleffect 0 makes players always invulnerable on spawn when sv_norespawninvul is false
DescriptionThe P_SpawnPlayer() function gives the player invulnerability item in some PvP gamemodes if sv_norespawninvul is false. Note that the code also gives a visual effect based on `cl_respawninvuleffect` value.

However, when the weapon A_Raise is called, it checks whether the player is allowed to be invulnerable with this weapon. If not, the item is taken away.

The problem is that the A_Raise code checks whether the player has respawn visual effect from `cl_respawninvuleffect` to make sure it is the respawn invul item. If there is no effect, the item is never taken away.
Steps To Reproduce- Set `sv_norespawninvul` to false and `cl_respawninvuleffect` to 0
- Respawn a player and try to damage him
- The player doesn't flicker visually but is invulnerable no matter what weapon he uses
Additional InformationSearch for "// [BC] Apply temporary invulnerability when respawned." for the P_SpawnPlayer() code

Search for "// [BC] If this player has respawn invulnerability" for the A_Raise code

Search for "// [BB] All clients need to be informed about some special iventory kinds" for SERVER_ResetInventory() code
Attached Files

- Relationships
related to 0004136resolvedKaminsky A_Raise can take away picked up invulnerability item instead of respawn invul 

-  Notes
User avatar (0022842)
geNia (reporter)
2023-05-07 15:04

 Forgot to mention, there is also a same invul effect check in SERVER_ResetInventory()
User avatar (0024247)
Kaminsky (developer)
2025-03-16 18:51

 'https://foss.heptapod.net/zandronum/zandronum-stable/-/merge_requests/274 [^]'
User avatar (0024250)
Kaminsky (developer)
2025-03-16 19:37

 'https://foss.heptapod.net/zandronum/zandronum-stable/-/commit/008b17e6477fc5d42f2869470467e2cc2cd9544c [^]'
User avatar (0024258)
unknownna (updater)
2025-03-20 10:03

 How do you test this? I started a regular DM server with 2 clients and didn't seem to notice any difference in behavior between 3.1 and 3.2. I also checked regular LMS, where it spawns the players with the plasmarifle and it still didn't display this behavior:

Quote from geNia
- The player doesn't flicker visually but is invulnerable no matter what weapon he uses
User avatar (0024272)
Kaminsky (developer)
2025-03-20 14:48

 IMO, the best level to test this on is SHOOT (the duel map). It's small and there's SSGs at every player spawn, so it should be easy to fire at another player within a few seconds of them respawning. As stated in the steps to reproduce: "sv_norespawninvul" must be disabled and "cl_respawninvuleffect" should be set to 0.

Without the fix linked above, you should notice that the player remains invulnerable for the full three seconds even when they have the SSG selected (which should remove it). With the fix, the player should lose respawn protection prematurely when they select the SSG, as expected.
User avatar (0024284)
unknownna (updater)
2025-03-20 22:26

 Strange, I'm still not able to reproduce it in 3.1: The SSG being brought up always removes the invulnerability from the player. Tested with 2 clients on a local server with said map.
User avatar (0024296)
Kaminsky (developer)
2025-03-22 14:19

 That's strange. I could reproduce the bug both offline and online with bots, albeit with earlier 3.2 betas (though, I don't believe there shouldn't be any noticeable difference in the respawn protection behaviour between 3.1 and 3.2 before the fix).
User avatar (0024300)
unknownna (updater)
2025-03-23 09:40

 I'm stumped as to why it doesn't happen to me, the SSG being brought up always removes the invulnerability.
User avatar (0024354)
Ru5tK1ng (updater)
2025-03-25 03:14
edited on: 2025-03-25 03:14

 I believe you have to connect to the server already with cl_respawninvuleffect 0 since it's one of the cl variables that don't sync with the server on change.
User avatar (0024355)
Combinebobnt (reporter)
2025-03-25 03:28

 I don't know if I understand what the actual bug is here, and what to do to reproduce it. I set `sv_norespawninvul` to 0 and my `cl_respawninvuleffect` to 0, and made sure to reconnect with that cl var set to 0 to account for Ru5tK1ng's post. I was testing with a human opponent in shoot!.wad deathmatch, were I saw no difference in zan v3.1 and v3.2-alpha-250323-2124. I would retain invulnerability on both versions while raising the ssg, but was able to die if the ssg was fully raised.
User avatar (0024356)
Kaminsky (developer)
2025-03-25 12:18

 I'm sorry, perhaps it's not easy to notice the difference here between 3.1 and 3.2-250323-2124 under normal circumstances. I still recommend testing on SHOOT with "sv_norespawninvul" disabled and "cl_respawninvuleffect" set to 0, but try also setting "sv_infiniteammo" to 1 and "sv_fastweapons" to 2. This way, you can fire the SSG continuously and rapidly, and it makes it easier to spot the issue.

I also uploaded a video to show the comparison between both versions:'https://www.youtube.com/watch?v=a6hueRe-nxs [^]'

You should notice that in 3.1, players remain invulnerable for the full three seconds (you can see this right at the start of the video). There were plenty of times the bot got the upper-hand because of this. In 3.2-250323-2124, players lose the invulnerability once they have the SSG selected and die quicker, as expected.

This happens offline, and online if "cl_respawninvuleffect" is set to 0 on the server's end, in 3.1.
User avatar (0024357)
unknownna (updater)
2025-03-25 12:51
Quote from Kaminsky
[...] online if "cl_respawninvuleffect" is set to 0 on the server's end, in 3.1.

Aha, so it's the server's "cl_respawninvuleffect" value that makes the difference. That's why I couldn't reproduce it. I was under the impression the client's value was affecting it somehow. Thank you for the video demonstration.

With your steps I was able to reproduce the issue and can confirm it's fixed.
User avatar (0024358)
Kaminsky (developer)
2025-03-25 12:57

 Awesome, thanks for checking!

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
2023-05-07 15:01 geNia New Issue
2023-05-07 15:04 geNia Note Added: 0022842
2023-07-09 03:11 Kaminsky Assigned To => Kaminsky
2023-07-09 03:11 Kaminsky Status new => assigned
2023-07-09 03:11 Kaminsky Target Version => 3.2
2023-07-09 03:13 Kaminsky Relationship added related to 0004136
2025-03-16 18:51 Kaminsky Note Added: 0024247
2025-03-16 18:51 Kaminsky Status assigned => needs review
2025-03-16 19:37 Kaminsky Note Added: 0024250
2025-03-16 19:37 Kaminsky Status needs review => needs testing
2025-03-20 10:03 unknownna Note Added: 0024258
2025-03-20 14:48 Kaminsky Note Added: 0024272
2025-03-20 22:26 unknownna Note Added: 0024284
2025-03-22 14:19 Kaminsky Note Added: 0024296
2025-03-23 09:40 unknownna Note Added: 0024300
2025-03-25 03:14 Ru5tK1ng Note Added: 0024354
2025-03-25 03:14 Ru5tK1ng Note Edited: 0024354 View Revisions
2025-03-25 03:28 Combinebobnt Note Added: 0024355
2025-03-25 12:18 Kaminsky Note Added: 0024356
2025-03-25 12:51 unknownna Note Added: 0024357
2025-03-25 12:51 unknownna Status needs testing => resolved
2025-03-25 12:51 unknownna Fixed in Version => 3.2
2025-03-25 12:51 unknownna Resolution open => fixed
2025-03-25 12:57 Kaminsky Note Added: 0024358




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker