Anonymous | Login | Signup for a new account | 2024-04-18 02:01 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 | ||||
0001491 | Zandronum | [All Projects] Bug | public | 2013-09-08 13:09 | 2018-09-30 21:52 | ||||
Reporter | Dusk | ||||||||
Assigned To | Torr Samaho | ||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | 1.2 | ||||||||
Target Version | 3.0 | Fixed in Version | 3.0 | ||||||
Summary | 0001491: Spawn invulnerability conflicts with sphere invulnerability | ||||||||
Description | 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. | ||||||||
Steps To Reproduce | 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. | ||||||||
Additional Information | In p_mobj.cpp:4992:
It gives APowerInvulnerable, which is also given by InvulnerabilitySphere. It needs to give a subclass instead. | ||||||||
Attached Files | |||||||||
Relationships | ||||||
|
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 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 |
Copyright © 2000 - 2024 MantisBT Team |