Forcing monsters to wake up on any damage

[D2JK]

This is just a minor peeve, but still: what would be the best way to ensure that a monster, in their Look state, wakes up immediately when it takes any damage? Right now, sometimes monsters seems completely oblivious to the fact that someone shot them (or are clawing them or punching them or something), and they may 'tolerate' a surprising amount of damage before reacting.

I tried to look for a flag in the Behavior section in the wiki, but couldn't find anything. What I suppose I could do, would be to make them constantly check if their health has dipped from their spawn health value... but maybe there is another option, preferably with no unrelated side-effects?

[Cherno]

Hmm, are you sure that this "lazy" behavior is not related to the monster's A_Chase frame lengths?

[D2JK]

No, that shouldn't be it... if I've waited for a few seconds for a reaction, that should rule it out.

In one extreme case, I shot a rocket at monster's leg, and expected him to wake up, but nothing happened. In this particular case, there was no line-of-sight directly from the centre of the monster to the centre of my player pawn.

That's not to say only LoS matters. In another case, a monster chased an idle monster in an open room. The chasing monster could land a few melee blows before the idle monster reacted to the beating.

[Void Weaver]

Well, if you wnt to consider specific cse for the some specific monster then PainThreshold 0 WITH PainChance 256 would be excelent solution, but since there is no wy to change PainChnce vlue so isn't option.

Other inversive way to hit monster with +FORCEPAIN missile\puff, but it can cause painlock for a some fast-sequnced attacks, so that isn't good solution too.

For other hcky way you can try to hit missile\puff with +HIT(POINTER) flag and specific DamageType "Harmful", and then make check for POINTER's hp (A_JumpIfHealthLower), nd IF its hp less than 100% of its SpawnHelth then swithch DamgeType to regular one like "None" via A_SetDamageType for exmple.
The trigger to awkening would be 'PainChance "Harmful", 256' property for each monster. Yep, it's too hacky but it should work I guess.

I'm sure that ZScript should provide a much smooth way to lwys awake monsters.

[Boondorl]

Depends on the tool you use. I actually fixed this myself in ZScript:

Code: Select all

override int DamageMobj(Actor inflictor, Actor source, int damage, Name mod, int flags, double angle)
{
    int newdam = super.DamageMobj(inflictor, source, damage, mod, flags, angle);
		
    if (health > 0 && newdam > 0 && SeeState && target && InStateSequence(CurState, SpawnState))
    {
        A_PlaySound(SeeSound, CHAN_VOICE, 1, false, bBoss ? ATTN_NONE : ATTN_NORM);	
        SetState(SeeState);
    }

    return newdam;
}

Now, this was used for a set of custom monsters so you couldn't just throw it in a DamageMobj function if you want it to be universal, but you could probably use similar checking in an Inventory item and then give it to every monster on spawn via an event handler.

The health checking in the Spawn state isn't the worst solution, honestly. You wouldn't want to check against its spawn health but rather against its health from the previous frame.

Looking through the source code, I know exactly why this happens too. Normally when a monster takes damage it's always supposed to wake up, but there's a small error present. This snippet is the error:

Code: Select all

if (target->state == target->SpawnState && target->SeeState != nullptr)
{
    target->SetState(target->SeeState);
}

The person who wrote this is checking wrong. This will only be true if the monster is in the first frame of its Spawn state. This causes it to work only half the time since most monsters will have two frames in their Spawn state. To fix this it would need to check if its current state was within its entire Spawn sequence. The reason it's like this is because that's also how it was in the original Doom code, likely due to the way state sequences were structured.

[D2JK]

Thank you, I was also curious if it would be possible to find the cause in the source code, but didn't quite get around to that yet... and there it is.