0001491: Spawn invulnerability conflicts with sphere invulnerability

Notes
(0007148) Arco (updater) 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 (developer) 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 (reporter) 2014-07-04 10:47 edited on: 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 (developer) 2014-07-04 14:57	This should be fixed in zdoom, too.

(0009946) Torr Samaho (administrator) 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 (reporter) 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 (reporter) 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 (reporter) 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 (developer) 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 (updater) 2016-12-16 23:14	Can confirm that Edward's fix works as he described.

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
2013-09-08 13:09	Dusk	New Issue
2013-09-08 13:10	Dusk	Description Updated	View Revisions
2013-09-08 13:10	Dusk	Additional Information Updated	View Revisions
2013-09-08 14:43	Arco	Note Added: 0007148
2013-09-08 16:00	Dusk	Note Added: 0007149
2013-09-08 16:00	Dusk	Product Version	=> 1.2
2014-06-14 17:53	Watermelon	Status	new => confirmed
2014-07-01 19:57	Dusk	Relationship added	related to 0001346
2014-07-04 10:47	Esum	Note Added: 0009832
2014-07-04 10:47	Esum	Note Edited: 0009832	View Revisions
2014-07-04 11:03	Dusk	Status	confirmed => needs review
2014-07-04 14:57	Edward-san	Note Added: 0009835
2014-07-12 15:11	Torr Samaho	Note Added: 0009946
2014-07-12 15:11	Torr Samaho	Status	needs review => feedback
2014-08-07 15:54	Esum	Note Added: 0010140
2014-08-07 20:24	Ivan	Note Added: 0010142
2014-08-08 01:50	ZzZombo	Note Added: 0010143
2016-11-27 00:18	Edward-san	Note Added: 0016331
2016-11-27 00:18	Edward-san	Assigned To	=> Torr Samaho
2016-11-27 00:18	Edward-san	Status	feedback => needs testing
2016-11-27 00:18	Edward-san	Target Version	=> 3.0
2016-12-16 23:14	Ru5tK1ng	Note Added: 0016509
2016-12-16 23:14	Ru5tK1ng	Status	needs testing => resolved
2016-12-16 23:14	Ru5tK1ng	Resolution	open => fixed
2016-12-16 23:14	Ru5tK1ng	Fixed in Version	=> 3.0
2018-09-30 21:52	Blzut3	Status	resolved => closed