ZDoom

Okay.

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.

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

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.

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.

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

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.

I didn't think the dmflag was important. I've noticed i broke the ALWAYSFAST actor flag. https://github.com/coelckers/gzdoom/pull/1273

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

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.

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.

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

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

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

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

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