Damage HUD Indicators v1.0 (09/01/2023)
Forum rules
The Projects forums are only for projects. If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
Got a cool project idea but nothing else? Put it in the project ideas thread instead!
Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.
Please read the full rules for more details.
The Projects forums are only for projects. If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
Got a cool project idea but nothing else? Put it in the project ideas thread instead!
Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.
Please read the full rules for more details.
Re: Damage HUD Indicators v1.0 (09/01/2023)
Cool. I look forward to trying it.
I don't think I mentioned it before, but any thoughts on providing alternative styles/graphics? Just a suggestion really, a nice to have. If it's not something that interests you, that's fine.
I don't think I mentioned it before, but any thoughts on providing alternative styles/graphics? Just a suggestion really, a nice to have. If it's not something that interests you, that's fine.
- Major Cooke
- Posts: 8218
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: GZBoomer Town
- Contact:
Re: Damage HUD Indicators v1.0 (09/01/2023)
I'll consider it for the next version after this one.
Re: Damage HUD Indicators v1.0 (09/01/2023)
Fair enough. Thanks.
Re: Damage HUD Indicators v1.0 (09/01/2023)
I have just noticed something with the current release version and a specific set of circumstances that I wonder if it could be improved on.
Specifically, I am using it with a mod that has a system to "wake up" enemies that witness the death of a comrade, rather than standing around apparently blissfully unaware that their friend has just dropped dead beside them.
The system involves each enemy spawning a special alarm actor when they die. The alarm does a low amount of damage (of type "alarm") via an A_Explode pointer.
Enemies have a custom pain state that heals the small amount of damage they have received from the alarm and they then go to their see state label (i.e. they appear to start moving in response to their comrade dying). It's an older system adapted from an early version of Brutal Doom.
The player, of course, should not be affected by the alarm damage and they have been given a damage factor of 0.0 for Alarm damage.
However, I noticed with the damage HUD indicators active that sometimes, if I was reasonably close to an actor when it died, the HUD indicator would appear, even though I had not taken any damage (no health or amour reduction). Eventually, I realised that it must be to do with the alarm actor. I commented out the A_Explode line in the alarm actor and the damage indicators stopped appearing when enemies died.
I also use a derivative of the Alarm actor that gets fired by a flashlight beam so that the flashlight will wake up enemies (and encourage the player to turn off the flashlight when it isn't needed). Similar to the above, if the player walks towards a wall where the flashlight is shining, or they just point it at the ground, damage indicators appear even though the player is not taking damage.
So, short version, the damage indicators seem to be triggered by A_Explode even if the explosion does not damage the player at all (because they are immune to its damage type). They merely need to be inside the radius of the explosion. So, is there any way of making it so that the damage indicators do not respond to an A_Explode pointer if the player is immune to the type of damage that the explosion does?
Specifically, I am using it with a mod that has a system to "wake up" enemies that witness the death of a comrade, rather than standing around apparently blissfully unaware that their friend has just dropped dead beside them.
The system involves each enemy spawning a special alarm actor when they die. The alarm does a low amount of damage (of type "alarm") via an A_Explode pointer.
Enemies have a custom pain state that heals the small amount of damage they have received from the alarm and they then go to their see state label (i.e. they appear to start moving in response to their comrade dying). It's an older system adapted from an early version of Brutal Doom.
The player, of course, should not be affected by the alarm damage and they have been given a damage factor of 0.0 for Alarm damage.
However, I noticed with the damage HUD indicators active that sometimes, if I was reasonably close to an actor when it died, the HUD indicator would appear, even though I had not taken any damage (no health or amour reduction). Eventually, I realised that it must be to do with the alarm actor. I commented out the A_Explode line in the alarm actor and the damage indicators stopped appearing when enemies died.
I also use a derivative of the Alarm actor that gets fired by a flashlight beam so that the flashlight will wake up enemies (and encourage the player to turn off the flashlight when it isn't needed). Similar to the above, if the player walks towards a wall where the flashlight is shining, or they just point it at the ground, damage indicators appear even though the player is not taking damage.
So, short version, the damage indicators seem to be triggered by A_Explode even if the explosion does not damage the player at all (because they are immune to its damage type). They merely need to be inside the radius of the explosion. So, is there any way of making it so that the damage indicators do not respond to an A_Explode pointer if the player is immune to the type of damage that the explosion does?
- Major Cooke
- Posts: 8218
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: GZBoomer Town
- Contact:
Re: Damage HUD Indicators v1.0 (09/01/2023)
I can add a JSON system where you can make a list of damage types that will never trigger the indicator. I'll also add such list for source and inflictors, and what playerpawn type they apply to, as well as parent checks options.
That's about the safest thing I can do, because I do enjoy having invulnerability pop it up, but I can add a toggle for that as well.
Here's probably what the whole system will look like.
That's about the safest thing I can do, because I do enjoy having invulnerability pop it up, but I can add a toggle for that as well.
Here's probably what the whole system will look like.
Code: Select all
{
"mod_id": "MyModNameHere",
"no.damagetypes":
[
"fire",
"ice"
],
"no.sources":
[
"SpecialMarine:parent", // ":parent" will indicate to check the parent chain.
],
"no.inflictors":
[
"SpecialRocket",
]
"no.actors": // if a source or inflictor, will not trigger
[
"SpecialImp",
]
}Re: Damage HUD Indicators v1.0 (09/01/2023)
That's a very thorough solution. It will certainly cover my problem and then some. 
- Major Cooke
- Posts: 8218
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: GZBoomer Town
- Contact:
Re: Damage HUD Indicators v1.0 (09/01/2023)
Since I know this might be asked...
Second, and while this one doesn't really apply to this mod since it's far simpler, it'll allow for copying other definitions similar to how inheritance in DECORATE/ZScript works, in the event I do design something like that.
First, it's a carry-over from all my other mods, and that's mainly designed to ensure there's a difference and priority chain. Base mod is first, addons are added atop of it.Why is there a mod_id requirement?
Second, and while this one doesn't really apply to this mod since it's far simpler, it'll allow for copying other definitions similar to how inheritance in DECORATE/ZScript works, in the event I do design something like that.
Re: Damage HUD Indicators v1.0 (09/01/2023)
I guess the additional question to that is, how should the mod_id field be used?
Like, is it intended to be used if someone changes this mod to be something else?
Or does the name come from other mods that might be loaded with this (and, if so, how should that be done)?
Sorry if it's a daft question. You're significantly better at this stuff than I am.
Like, is it intended to be used if someone changes this mod to be something else?
Or does the name come from other mods that might be loaded with this (and, if so, how should that be done)?
Sorry if it's a daft question. You're significantly better at this stuff than I am.
- Major Cooke
- Posts: 8218
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: GZBoomer Town
- Contact:
Re: Damage HUD Indicators v1.0 (09/01/2023)
As long as it's not "DamageHudIndicators", can be whatever you want.
The whole idea is to prevent clashes with other mods and for debugging purposes. So if I need to rescan one of the files, or add a function to perform rescanning, I can do a quick iteration and simply refresh just that one, especially when it comes to saves, for example. That way you don't have to restart the map or the whole run just to get it to work - though that's much less of a reason for it here than it is with some of my other mods.
The whole idea is to prevent clashes with other mods and for debugging purposes. So if I need to rescan one of the files, or add a function to perform rescanning, I can do a quick iteration and simply refresh just that one, especially when it comes to saves, for example. That way you don't have to restart the map or the whole run just to get it to work - though that's much less of a reason for it here than it is with some of my other mods.
Re: Damage HUD Indicators v1.0 (09/01/2023)
Right, understood. Thanks for the clarification. 
