Reverse of Super::State?

[Matt]

I've got a setup where a class of things would all call a few common functions before beginning their animations.

I used to have it set up so that a common parent actor would have its spawn state call all the common functions, then jump to a custom "spawn2" which would be the spawn animation itself. Each of the derived actors - i.e., the ones that actually appear on the map - would have a spawn2 but no spawn state defined, and when they call their inherited spawn state they would then jump to their own, individually defined spawn2. (This behaviour would contrast with goto, which would call the parent's state whether the current actor had anything defined or not.)

Unfortunately this no longer works: whether I use goto or A_Jump, an inherited spawn state would go to the parent's spawn2 state leaving all of the derived items looking exactly the same. I can, of course, just define the entire spawn state for each item individually, but given the number of things I have that took advantage of the old jump rules and the sheer amount of spaghetti that would result from being unable to inherit common sets of functions*, I'd like to ask if there's some other way to regain the old A_Jump functionality first.


*It occurs to me that I could have these things gain an item which has a use/pickup state that calls all the necessary functions saving me a lot of copypasta, but it would add an ugly extra layer of complexity that would make my code even more impenetrable than it already is.

[Graf Zahl]

Actually this was never supposed to work like this. Sometimes it's really amazing how much persistence exists in this community to find and exploit ubintended behavior. The monster pack's Afrit gives me headaches to this day because its mere existence prevents fixing a nasty bug in the projectile logic.

I recently changed the state parameter handling so that all states are resolved at compile time because the old system relied on too many side effects to work and most importantly prevented any kind of efficient error checks.

[Cutmanmike]

Actually this was never supposed to work like this. Sometimes it's really amazing how much persistence exists in this community to find and exploit ubintended behavior.

Sometimes that's what people have to work with in order to get what we want to work (because of either declined features or just general limitations). Also things not explained properly could cause people to think that they are working correctly (I don't know who you would blame for this though). I don't think that should stop you from fixing things though. Surely there's a work around for the afrit thing in decorate? People could just use afrit patch wad that replaces and fixes him up.

[Matt]

I'd always thought the old A_Jump/Goto distinction was intentional. >_>

What's this afrit thing?

[Cutmanmike]

It's a (over used) monster that comes from the monster resource wad. It's the Baron of Hell that floats around covered in flames and chucks fireballs and things at you.

[Graf Zahl]

And it only works because it abused a bug in the projectile ownership code. The thing is, this monster spawned a large amount of copycats and now we have the unpleasant situation that there's a semi-serious bug in the engine that can't be fixed.

[Cutmanmike]

Well that's a bit inconvenient. I have to say myself I have never seen/used this Super:State thing. What is it supposed to do and how many copycats are we talking roughly?

[Gez]

Super::State is a way to reach the parent actor's original state. This is borrowed from C++.

Say you have a modified zombieman that runs a special command when it dies, you can use this:

Code: Select all

Death:
    POSS A 0 A_DoSomethingCool
    Goto Super::Death

[bagheadspidey]

http://zdoom.org/wiki/go/using_inheritance

[Cutmanmike]

Super::State is a way to reach the parent actor's original state. This is borrowed from C++.

Say you have a modified zombieman that runs a special command when it dies, you can use this:

Code: Select all

Death:
    POSS A 0 A_DoSomethingCool
    Goto Super::Death

Oh so it just saves a bit of extra code? Suppose that's handy but I always copy the code over for states that I need to edit just in case.

[bagheadspidey]

I think the issue is that goto is resolved at compile time and A_Jump* was resolved at runtime. Assuming I understand all this correctly, that meant that a goto in a super class would go to the super's state even if the inherited actor had that state, while an A_Jump would always go to the final actor's state. I assume Graf is saying this is no longer the case?

[Spleen]

Super::State is a way to reach the parent actor's original state. This is borrowed from C++.

Say you have a modified zombieman that runs a special command when it dies, you can use this:

Code: Select all

Death:
    POSS A 0 A_DoSomethingCool
    Goto Super::Death

Oh so it just saves a bit of extra code? Suppose that's handy but I always copy the code over for states that I need to edit just in case.

I agree, please fix the code so that it works such that it's supposed to and let the people who made the Afrit and stuff use copy pasta

[Matt]

I think the issue is that goto is resolved at compile time and A_Jump* was resolved at runtime. Assuming I understand all this correctly, that meant that a goto in a super class would go to the super's state even if the inherited actor had that state, while an A_Jump would always go to the final actor's state. I assume Graf is saying this is no longer the case?

That's exactly it.

On another note, the big thing I originally needed it for turns out to have been made obsolete by [wiki=GetPlayerInput]something infinitely better[/wiki]