StrifePlayer additional states?

[Gez]

Aha! So, cutting the AltSkin* states and stuff, adding the Disintegrate state

You don't need to add Disintegrate or remove AltSkin stuff, you just need to have the FireHands* states in the same sequence and as many states in both.

[InsaneFury]

Aha! So, cutting the AltSkin* states and stuff, adding the Disintegrate state

(...) have the FireHands* states in the same sequence and as many states in both.

This latter part still confuses me. I suppose it means I have to make sure both of these states have the same number of sprites, and matching durations so they can ' sync'?

Also, I removed the 'Goto Fire' line and indeed, when testing it with a Fire DamageType, the function performs as it should. I basically just added the Goto to test the behavior with normal deaths (without having to script a Fire damagetype thing to kill me off).

Furthermore, as the behavior is linked to the Fire death, I suppose trying to make a freeze death state which would act similar (but with different sprites) is out of the question with the current code? Like having a FreezeHands (hands freezing) and FreezeHandsLower (~shattering) wouldn't be possible if A_ItBurnsItBurns can only be used in relation to the Fire state.

I don't know if it's far-fetched, but perhaps a (derivative) function like A_CrispyPlayer can be introduced in a future version of ZDoom, being more generic to allow for parameters specifying the states to jump/goto, as well as the sound to play (and whether or not the sprites should be bright)? IMO that would be extremely sweet!

[Gez]

I suppose it means I have to make sure both of these states have the same number of sprites, and matching durations so they can ' sync'?

Yes.

Each "sprite" is a state. For example, this is two states. The pain state is just the first of them. These states are Pain and Pain+1 respectively.

Code: Select all

  Pain:
    PLAY G 4
    PLAY G 4 A_Pain
    Goto Spawn

[NeuralStunner]

So I've been subject to a confusion in terms between a State and a Frame.

The states are and were identical to the StrifePlayer ones, so I thought the problem was something else. But using a standard fire death, instead of jumping from a regular death, does the job apparently...

[InsaneFury]

So I've been subject to a confusion in terms between a State and a Frame.

Tomato and Tomayto eh?

The states are and were identical to the StrifePlayer ones, so I thought the problem was something else. But using a standard fire death, instead of jumping from a regular death, does the job apparently...

In my understanding, performing a goto to another state would equal actually getting the actor to that state. Either this isn't the case (which explains the crash), or it was, but the 'burning while already dead' (as the Death state had been reached previously) mixed it up.

[NeuralStunner]

In my understanding, performing a goto to another state would equal actually getting the actor to that state. Either this isn't the case (which explains the crash), or it was, but the 'burning while already dead' (as the Death state had been reached previously) mixed it up.

Probably right. AFAIK, putting a Goto right after a statelabel effectively removes that state, using the "gone to" state's frames instead. Sounds like StrifePlayer has specific handling to not go into the "death drop" immediately when reaching the Burn state?