Anonymous | Login | Signup for a new account | 2025-04-18 07:15 UTC | ![]() |
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0004135 | Zandronum | [All Projects] Bug | public | 2023-05-07 15:01 | 2025-03-25 12:57 | ||||
Reporter | geNia | ||||||||
Assigned To | Kaminsky | ||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||
Status | resolved | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | 3.1 | ||||||||
Target Version | 3.2 | Fixed in Version | 3.2 | ||||||
Summary | 0004135: cl_respawninvuleffect 0 makes players always invulnerable on spawn when sv_norespawninvul is false | ||||||||
Description | The 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 Information | Search 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 | |||||||||
![]() |
||||||
|
![]() |
|
geNia (reporter) 2023-05-07 15:04 |
Forgot to mention, there is also a same invul effect check in SERVER_ResetInventory() |
Kaminsky (developer) 2025-03-16 18:51 |
'https://foss.heptapod.net/zandronum/zandronum-stable/-/merge_requests/274 [^]' |
Kaminsky (developer) 2025-03-16 19:37 |
'https://foss.heptapod.net/zandronum/zandronum-stable/-/commit/008b17e6477fc5d42f2869470467e2cc2cd9544c [^]' |
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 |
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. |
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. |
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). |
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. |
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. |
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. |
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. |
unknownna (updater) 2025-03-25 12:51 |
Quote from Kaminsky 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. |
Kaminsky (developer) 2025-03-25 12:57 |
Awesome, thanks for checking! |
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. |
![]() |
|||
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 |
Copyright © 2000 - 2025 MantisBT Team |