Duke4.net Forums: SOLVED Hardcoded enemy falling damage handled badly - Duke4.net Forums

Jump to content

Hide message Show message
Welcome to the Duke4.net Forums!

Register an account now to get access to all board features. After you've registered and logged in, you'll be able to create topics, post replies, send and receive private messages, disable the viewing of ads and more!

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

SOLVED Hardcoded enemy falling damage handled badly  "let's talk about it"

User is online   Trooper Dan 

  • Duke Plus Developer
  • 3,938


If an actor is an "enemy", EDuke32 has a hardcoded behavior for killing them when they fall from a significant height.

It sets the actor's hit points (extra) to 0.
It sets the actor's damage type (htpicnum) to SHOTSPARK1 (bullet).
It sets the actor's damage (htextra) to 1.

This will make the enemy die, regardless of how many hit points it had. Note that the falling height which triggers this is not very high -- even falling from the secret RPG to the ground in E1L1 will trigger it.

This is problematic because:

  • Falling damage is not appropriate for some enemies (including some enemies that actually do "fall" using the CON command)
  • It's an insta-kill, so even if fall damage were desirable, infinite damage is not typically desirable
  • AFAIK There's no flag or other nice means to eliminate the damage. You either have to not use the CON fall command, or you have to detect and circumvent the damage by monitoring certain structs before the actor calls ifhitweapon and then reset hit points to the amount from the previous tic

I'm also not sure if the feature is working as intended. I looked at the source for the fall command and found some code that does something similar, but it looks like it has some extra conditions in there which were not being met by my falling enemies. One other thing I'd like to point out is that there are various hardcoded differences between enemy and notenemy. In general, enemies move around and clip better, so it's not desirable define an actor as notenemy.

EDIT Additional notes: I do not know if the hardcoded fall damage is applied to the original Duke 3D enemies, or only to custom enemies. I also don't know if the feature is in DOS Duke, or if it was added to EDuke32 later. If it was added later, then it surely is affecting various mods in a bad way.

This post has been edited by Trooper Dan: 29 July 2018 - 02:21 PM


User is offline   Katrix Kytarix 

  • 106


I understand why this topic could be brought up, but I don't think this is too much of an issue. In vanilla Duke at least, it's not really common to see enemies in positions where they'd be able fall high enough to die on their own, in most elevated places the monsters are either in their stayput variants or they can fly (or don't actually take any fall damage, correct me if I'm wrong but I for myself don't recall any of these fellas dying from falling from great heights). Sure, it's inflexible but I don't think it was really an issue for people, never saw anyone complaining about it.

Don't waste your time or time will waste you.

User is offline   Jblade 

  • 1,881


I can't recreate this Dan - flying to the top of E1L1 and spawning a newbeast or pigcop doesn't kill it, and I've never encountered this happen with any of the user enemies I've coded into AMC (this is with the latest snapshot as well)

This post has been edited by Jblade: 01 August 2018 - 10:17 AM


User is offline   Forge 

  • 8,660


I could be wrong, but I think the enemy has to be wounded prior to the fall.

This post has been edited by Forge: 01 August 2018 - 11:19 AM


User is online   Trooper Dan 

  • Duke Plus Developer
  • 3,938


Well, it definitely happens with the "enemy" version of the bots (i.e. Dukebot and Shelly), even when I disabled my own fall damage code. The instakill would turn on or off depending on whether they were defined as "enemy" or "notenemy". Looking at the source code in the fall command, I was only able to find this which could possibly explain it:

if (A_CheckEnemySprite(pSprite) || (pSprite->picnum == APLAYER && pSprite->owner >= 0))
        if (pSprite->zvel > 3084 && pSprite->extra <= 1)
            // I'm guessing this DRONE check is from a beta version of the game
            // where they crashed into the ground when killed
            if (!(pSprite->picnum == APLAYER && pSprite->extra > 0) && pSprite->pal != 1 && pSprite->picnum != DRONE)

            actor[spriteNum].picnum = SHOTSPARK1;
            actor[spriteNum].extra = 1;
            pSprite->zvel = 0;

But if I understand this correctly, it would only apply if the actor is already dead. Yet it happens to the bots right out of the chute (literally from dropping down the chute at the beginning of E1L1 before they take any damage). I guess I'll have to investigate further.

User is offline   Doom64hunter 

  • 263


The only instance I have ever seen of an enemy being affected by falling damage in Duke Nukem 3D is when they were frozen and would shatter upon dropping from too great a height.

With the exception of this, I have never seen an enemy be affected by falling damage in any Build engine game. I don't think what you describe is intended.
For example, in vanilla Duke 3D, the enforcers in E3L2 that spawn in front of the window where the blue key is located sometimes fall down instead, but are completely fine afterwards.

User is offline   Mblackwell 

  • Evil Overlord
  • 875


what is htowner set to?

Music: The Rejected Applications (listen now)
EDuke32 || EDuke32 Wiki || Latest EDuke32 Snapshots
I'm getting too old for this shit...

User is online   Trooper Dan 

  • Duke Plus Developer
  • 3,938


View PostMblackwell, on 05 August 2018 - 11:37 AM, said:

what is htowner set to?

Not sure, but when I checked it, it was not -1 and not identical to the sprite taking damage.

I'm now pretty sure that the fall damage was caused by the source code I pasted above (the code that makes the actor take damage when they already have <= 1 health). I believe I screwed up and I was sometimes setting the bot's health to 0. This was due to a var I had added that tracks the bot's health and sometimes would set the bot's health to the value of the var. But the var was initialized to 0 instead of 100, so if the bot fell early in the game (say, down the E1L1 chute) this would lead to them having 0 health when hitting the ground, thereby activating the hardcoding.

I would still say it's a questionable feature, but it's not nearly as general as I implied and I was running into it only because of my carelessness. Nevertheless it can be troublesome: if you make a mechanical enemy !=DRONE and it dies in the air, it will make a squish sound and spawn blood when it falls to the ground.

Share this topic:

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

All copyrights and trademarks are property of their respective owners. Instead of reading this text, you could be playing Ion Fury! ;) © 2019 Voidpoint, LLC

Enter your sign in name and password

Sign in options