[Fixed] Fast monsters too fast

[drfrag]

Monster reaction time is always 0 with fast monsters and not just in nightmare. This:

The fast monsters setting is automatically activated when playing using Nightmare! difficulty. In addition, Nightmare! difficulty also adds a special check in the monster behavior code causing all monsters to attack immediately on sight (on all other difficulties, monsters may or may not attack on sight, with the random chance weighted based on the distance to their target).

This report from doomworld: https://www.doomworld.com/forum/topic/1 ... an-prboom/

It's this code:

Code: Select all • Expand view

    if (actor->isFast() && actor->flags3 & MF3_ISMONSTER)
        actor->reactiontime = 0;


Code: Select all • Expand view

bool AActor::isFast()
{
    if (flags5&MF5_ALWAYSFAST) return true;
    if (flags5&MF5_NEVERFAST) return false;
    return !!G_SkillProperty(SKILLP_FastMonsters);
}

The skill settings are customizable and nightmare uses the Fastmonsters skill property, a new skill property should be used there instead i guess.
nightmarefast is a GAMEINFO property and it's something else. BTW why the !! operator? What does it mean, double negation? So same as nothing then.

[Rachael]

!! is a shorthand way to turn any integer into a boolean. !=0 always returns true, and ==0 always returns false.

[drfrag]

Okay but an integer can be used as a boolean too.
I've made a PR to fix this. https://github.com/coelckers/gzdoom/pull/1272

[Graf Zahl]

Okay but an integer can be used as a boolean too.

Correct, but back when the code was written, it produced a warning.

[Graf Zahl]

This should be reviewed by someone who actually plays on Nightmare or with fast monsters. The implementation itself looks ok, but the correctness of the semantics needs to be confirmed

[Rachael]

I just played Doom 1.9 on DOS and confirmed drfrag's findings. There's a definite noticeable difference between Nightmare skill monsters and monsters that are simply fast.

However, there's one concern I have:

Merging this may potentially break a lot of mods. The question is do we just live with it? Or do we apply this change going forward only to files that mark themselves somehow as being aware of this change?

Another major issue: This also affects all previous mods that have custom skill levels. With the open-ended way skills are defined, there is no reliable way without some sort of heuristics to distinguish between skill levels that previously were intended to be 'nightmare' and were not.

[Graf Zahl]

You are right about that concern. I think aside from having it as a skill flag we also need it as a dmflag then so that the respective skill settings can be replicated again. I do not think it will have much of an impact on scripting. Having behavior depend on script version isn't going to work because you can mix ZScript versions and the produced code knows nothing about its actual source version.

I'd not be too concerned about the impact on mods. This only affects one very specific skill setting that's normally not part of the menu. Hopefully the dmflag is enough to handle it - but since we do not have anything resembling a manifest there's no good way to handle this case automatically.

[Rachael]

I'll merge this and handle the dmflag myself, then.

[drfrag]

I didn't think the dmflag was important. I've noticed i broke the ALWAYSFAST actor flag.

Code: Select all • Expand view

    ALWAYSFAST
    The monster with this flag does not take a random number of steps before attempting an attack. In addition, the reaction time is reduced and actor states marked as FAST will have their durations halved.

https://github.com/coelckers/gzdoom/pull/1273

[Rachael]

I don't think that one is as important. You can just set ReactionTime to 0 for the same effect. If anything, this decreases modding capability.

[drfrag]

I don't now but then you should change the spec of the flag.

[Graf Zahl]

The flag's specs should not change, but if this is important it should be deprecated and replaced by something better so that it can be handled as a fallback, like some other flags. Of course, since this is a flag that's likely being set by scripts, it may be better to leave it alone and add a new flag that just turns on fast mode but not instant reaction.

[Rachael]

I agree with the first part, but the second part does not make sense to me. Either way, I am done with this issue. If you want to do that, I have nothing in process that will conflict with that code if you want to change it.

[drfrag]

I don't think it's important but the PR fixes the flag and i haven't deleted the branch.

[Graf Zahl]

I merged that PR. if a 'proper' fast flag is needed it should be different from the old one so that mods aren't affected that toggle it through DECORATE or ZScript.