ZDoom

fixed. Skip_Super simply forgot to clear the working state label list.

[quote="Graf Zahl"]The state jumps are resolved at compile time so of course they jump to the ImpWarlord's see state.[/quote]
OK, makes sense. Thanks for explaining.

[quote="Graf Zahl"]The deprecation warnings were there because Randy thought that this particular feature would have to be removed for custom state support. But I was able to implement custom states without removing it so the deprecation warnings could be taken out again. It's still not recommended syntax though.[/quote]
I think I remember reading that somewhere now. Again thanks.

The main issue though is a bug, right?

The 'related issues' are none.

The state jumps are resolved at compile time so of course they jump to the ImpWarlord's see state.
The deprecation warnings were there because Randy thought that this particular feature would have to be removed for custom state support. But I was able to implement custom states without removing it so the deprecation warnings could be taken out again. It's still not recommended syntax though.

I know that this is being discussed in the "Return from Oblivion" projects thread, but I think it's gotten to the point of a bug being identified. So to stop it disappearing...

[quote="Graf Zahl"]SKIP_SUPER is supposed to eliminate all state references to the parent[/quote]

Two actors in RFO (dragonfamiliar and batfamiliar) use SKIP_SUPER but still show the parent's missile/melee states (the parent is the impwarlord actor) when these are not defined in the child actors. This does not happen in 2.1.7.


Related issues:

When the actors finish the inappropriate attack state, there is a "goto see" instruction in the DECORATE for the attack being completed. The actors goto the impwarlord see frames rather than their own, and only revert to their own frames when they jump to a new state - eg their own melee/missile or death state. I'm not sure if that is a bug or not.

A stated DECORATE fix for the above (to use missile 0 or melee 0 outside the state block) gives a "deprecated, will be removed" warning at the console in 2.1.7 but not newer versions. Not sure whether deprecation is still an issue or not for this syntax.