Cumulative damage for pain and gibbed death
Moderator: GZDoom Developers
Cumulative damage for pain and gibbed death
As far as I can tell, PainThreshold and gibbing do not take into account the cumulative damage from several pellets that hit a moster within one tic. Is it possible to introduce (probably, as an option in gameplay section for those who don't want it) the feature where all damage received within one tic, after taking into account damagefactors and such, would be taken into account when calculating whether it would "pierce" the painthreshold and whether the object will be gibbed?
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Cumulative damage for pain and gibbed death
This is far, far from trivial because it requires quite a bit of maintenance overhead.
Re: Cumulative damage for pain and gibbed death
If this is done anywhere, I think it should be done strictly ZScript side.
Is it possible to track the amount of damage done to an object if you set the +NODAMAGE flag on it?
If so - this would be a lot easier. Basically, you would set the flag in order to prevent GZDoom from processing the actor, and then run a tally of all the damage done in the current tic, along with keeping track of the inflictor. It would then retroactively apply that damage in the next tic, reusing the inflictors who did it.
Is it possible to track the amount of damage done to an object if you set the +NODAMAGE flag on it?
If so - this would be a lot easier. Basically, you would set the flag in order to prevent GZDoom from processing the actor, and then run a tally of all the damage done in the current tic, along with keeping track of the inflictor. It would then retroactively apply that damage in the next tic, reusing the inflictors who did it.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Cumulative damage for pain and gibbed death
+NODAMAGE calls the pain code. The entire point here is to do that without inflicting real damage.
The only real way to do this is to decouple the pain code from the damage code, and frankly, that's not going to happen, because too much depends on it. There is simply insufficient abstraction here.
The only real way to do this is to decouple the pain code from the damage code, and frankly, that's not going to happen, because too much depends on it. There is simply insufficient abstraction here.
- Major Cooke
- Posts: 8170
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: Cumulative damage for pain and gibbed death
I was about to suggest WorldThingDamaged but since that isn't called for < 1 damage, that does put a small hindrance in my idea. Perhaps an actor flag for monsters that would call it regardless when damaged would suffice. Then Kzer could utilize that to determine what happens to the monster - if that flags even needed. Then this for sure could be kept on the ZScript side.
However, if you don't need to take into account when damage is 0, then you could simply give an inventory item each time WorldThingDamaged is called to e.Thing.
However, if you don't need to take into account when damage is 0, then you could simply give an inventory item each time WorldThingDamaged is called to e.Thing.
- Matt
- Posts: 9696
- Joined: Sun Jan 04, 2004 5:37 pm
- Preferred Pronouns: They/Them
- Operating System Version (Optional): Debian Bullseye
- Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
- Contact:
Re: Cumulative damage for pain and gibbed death
The way I track this in HD is to have each bullet check for a specialized thinker that is targeting the victim, creating a new one if none already exists, and add its damage to that thinker's counter. Once that thinker expires (about 3-4 tics, I vaguely recall needing 2 to reliably get everything that I thought should have hit in the same tic), it does all the accumulated damage to the victim at once.
For a custom monster/player/target instead of a custom projectile, I can imagine something similar happening using the victim's DamageMobj where it never calls "super.damagemobj" unless the inflictor is that damage-aggregating actor (can't use a thinker in this case).
For a custom monster/player/target instead of a custom projectile, I can imagine something similar happening using the victim's DamageMobj where it never calls "super.damagemobj" unless the inflictor is that damage-aggregating actor (can't use a thinker in this case).