MantisBT - Zandronum
View Issue Details
0001491Zandronum[All Projects] Bugpublic2013-09-08 13:092018-09-30 21:52
Dusk 
Torr Samaho 
normalminoralways
closedfixed 
1.2 
3.03.0 
0001491: Spawn invulnerability conflicts with sphere invulnerability
When spawn invulnerability runs out, it cancels out the invulnerability given by an invulnerability sphere if a player has acquired such a sphere while being spawn invulnerable.
1. start an offline game with multiplayer emulation, or an online game with sv_cheats
2. make sure sv_norespawninvul is false
3. join the game, summon InvulnerabilitySphere
4. pick it up before your spawn invulnerability runs out. When it does run out, the invulnerability sphere's powerup gets instantly cut off.
In p_mobj.cpp:4992:

APowerup *invul = static_cast<APowerup*>(p->mo->GiveInventoryType (RUNTIME_CLASS(APowerInvulnerable)));


It gives APowerInvulnerable, which is also given by InvulnerabilitySphere. It needs to give a subclass instead.
No tags attached.
related to 0001346closed Torr Samaho ClearInventory in ACS removes respawn invulnerability 
Issue History
2013-09-08 13:09DuskNew Issue
2013-09-08 13:10DuskDescription Updatedbug_revision_view_page.php?rev_id=4012#r4012
2013-09-08 13:10DuskAdditional Information Updatedbug_revision_view_page.php?rev_id=4014#r4014
2013-09-08 14:43ArcoNote Added: 0007148
2013-09-08 16:00DuskNote Added: 0007149
2013-09-08 16:00DuskProduct Version => 1.2
2014-06-14 17:53WatermelonStatusnew => confirmed
2014-07-01 19:57DuskRelationship addedrelated to 0001346
2014-07-04 10:47EsumNote Added: 0009832
2014-07-04 10:47EsumNote Edited: 0009832bug_revision_view_page.php?bugnote_id=9832#r5263
2014-07-04 11:03DuskStatusconfirmed => needs review
2014-07-04 14:57Edward-sanNote Added: 0009835
2014-07-12 15:11Torr SamahoNote Added: 0009946
2014-07-12 15:11Torr SamahoStatusneeds review => feedback
2014-08-07 15:54EsumNote Added: 0010140
2014-08-07 20:24IvanNote Added: 0010142
2014-08-08 01:50ZzZomboNote Added: 0010143
2016-11-27 00:18Edward-sanNote Added: 0016331
2016-11-27 00:18Edward-sanAssigned To => Torr Samaho
2016-11-27 00:18Edward-sanStatusfeedback => needs testing
2016-11-27 00:18Edward-sanTarget Version => 3.0
2016-12-16 23:14Ru5tK1ngNote Added: 0016509
2016-12-16 23:14Ru5tK1ngStatusneeds testing => resolved
2016-12-16 23:14Ru5tK1ngResolutionopen => fixed
2016-12-16 23:14Ru5tK1ngFixed in Version => 3.0
2018-09-30 21:52Blzut3Statusresolved => closed

Notes
(0007148)
Arco   
2013-09-08 14:43   
Tested this online and off. The flickering given by the spawn invulnerability remains when I get the InvulnerabilitySphere. I wasn't able to get the InvulnerabilitySphere to stop along with the spawn invul, however.
(0007149)
Dusk   
2013-09-08 16:00   
hrm.. I had this happen in 1.1.1. In 1.2, the spawn invulnerability does indeed keep flickering when it should've ran out. I'd still recommend subclassing the powerup given by spawn invulnerability since it's clearly at least somewhat undefined behavior. :P
(0009832)
Esum   
2014-07-04 10:47   
Quote from IRC
<Esum>Dusk do you think there should be another actor for respawn invulnerability
<Dusk>PowerInvulnerable
<Dusk>yes
<Esum>Yes
<Dusk>it should be pretty simple
<Esum>So i must define another in the pk3 file anyway
<Dusk>actor PowerRespawnInvulnerable : PowerInvulnerable {}
<Esum>And add it the flag
<Dusk>with the undroppable flag and make the code give the player that
<Esum>Ok

According to this I suggest the following fix for both issues 1346 and 1491:'https://bitbucket.org/esum/zandronum-stable/commits/4572d764ba1877321fef3abf97d36b10be9a42f9 [^]'

(0009835)
Edward-san   
2014-07-04 14:57   
This should be fixed in zdoom, too.
(0009946)
Torr Samaho   
2014-07-12 15:11   
Esum, the change in inventory.txt needs to be marked with a comment and your initials, so that we know that this is not ZDoom code. Also, if we are creating a new actor for this, shouldn't we also move "invul->EffectTics = 3*TICRATE;" into the definition?
(0010140)
Esum   
2014-08-07 15:54   
Ok, I think we can remove "invul->BlendColor = 0;" as well. But maybe we should wait for it to be fixed in zdoom if they intend to do so.
(0010142)
Ivan   
2014-08-07 20:24   
Not sure if intended, but A_SetInvulnerable and A_UnsetInvulnerable also have a tendency to break the sphere invulnerability.
(0010143)
ZzZombo   
2014-08-08 01:50   
That's because the effects are implemented by a simple bitflag sum. I knew from the time I first read the sources it will eventually lead to this. The only way to fix it is to make a separate flag for each source of the effect. However, wouldn't it be better: instead of a bitflag sum we use an array of bitflags, each element in it is dedicated to separate effects (invulnerability, nogravity, etc); whenever an effect is granted, the value at the corresponding array element is calculated by using a simple bitwise |; for example, a player picks the invulnerability sphere, while already having spawn protection so the final value is (2^0 | 2^1)=3, where 0 is the position of spawn invulnerability in the enumeration listing possible sources of the effect, and 1 is the same for inventory-granted effects (there is also aforementioned A_SetInvulnerable/SetActorProperty(), they should have their own single source for our purposes). The generic code that cares if an effect is in place will just check against 0 in the array.

The end-user functions that are capable of unsetting a property should get an optional argument to forcefully do that.

I guess tho, it should be a ZDoom change.
(0016331)
Edward-san   
2016-11-27 00:18   
Ok, the backported fix (which was added in zandronum 3.0 upstream here:'https://bitbucket.org/Torr_Samaho/zandronum/commits/77e510a0cca2a840e0527e9fc515be4a6951dacc [^]') shows a new problem that I reported to zdoom here. In our case, the randomly fading effect doesn't disappear if we pick the invulnerability sphere before the respawn protection expires, only when the invulnerability sphere effect is expired.

I'm not particularly worried about this, as long as the original issues of this ticket and 0001346 were addressed, which are indeed now.
(0016509)
Ru5tK1ng   
2016-12-16 23:14   
Can confirm that Edward's fix works as he described.