
StrifePlayer additional states?
Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. This forum is archived - please use this set of forums to ask new questions.
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. This forum is archived - please use this set of forums to ask new questions.
StrifePlayer additional states?
According to the [wiki=Classes:StrifePlayer]StrifePlayer[/wiki] article, two new states were added to the class in r1125 - 'Firehands' and 'Firehandslower'. I assume this is in relation to the special player burn death discussed in the past. Can anyone shed some light on their function, and wether or not this is part of an effort to implement POV death sprites or similar? 

Re: StrifePlayer additional states?
I'll give this a bump. Anyone (particularly devs) able to assist?
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49223
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: StrifePlayer additional states?
Those are the burning hand 'weapon' sprites. They are referenced by the StrifePlayer's A_ItBurnsItBurns and A_CrispyPlayer code pointers (great names, btw.)
Re: StrifePlayer additional states?
Thanks for replying, Graf. Sorry for not being clear enough - I know what they do and that they are referenced by the aforementioned action functions, but I was curious as to why they only appeared as part of the player's DECORATE definition recently (at least in relation to how long we've had Strife support). Is there a generic POV death sprite implementation in the works / is A_ItBurnsItBurns et al being exposed for generalised DECORATE usage?
Based on your comments in the linked thread above, it appears that a generic implementation of 'death hands' was feasible from as far back as May 2007.
Based on your comments in the linked thread above, it appears that a generic implementation of 'death hands' was feasible from as far back as May 2007.

- InsaneFury
- Posts: 105
- Joined: Mon Nov 23, 2009 6:51 am
Re: StrifePlayer additional states?
I'm bumping this one a bit, as I'm looking into using the A_ItBurnsItBurns() and A_CrispyPlayer() for a playerclass-based DooM2 project. I'd like to have some light shed on how these features can be used, as the Wiki is quiet about them so far...
- XutaWoo
- Posts: 4005
- Joined: Sat Dec 30, 2006 4:25 pm
- Location: beautiful hills of those who are friends
- Contact:
Re: StrifePlayer additional states?
From what I'm guessing, A_ItBurnsItBurns causes your weapon to go to the player's Firehands state, while A_CripsyPlayer causes it to go to the Firehandslower state.
You'll need to inhereit from StrifePlayer if you want to use them, I'm guessing.
You'll need to inhereit from StrifePlayer if you want to use them, I'm guessing.
- NeuralStunner
-
- Posts: 12328
- Joined: Tue Jul 21, 2009 12:04 pm
- Preferred Pronouns: No Preference
- Operating System Version (Optional): Windows 11
- Graphics Processor: nVidia with Vulkan support
- Location: capital N, capital S, no space
- Contact:
Re: StrifePlayer additional states?
Yes. These code pointers are declared native to StrifePlayer in Decorate.XutaWoo wrote:You'll need to inhereit from StrifePlayer if you want to use them, I'm guessing.
- InsaneFury
- Posts: 105
- Joined: Mon Nov 23, 2009 6:51 am
Re: StrifePlayer additional states?
I'd like to see if I can use the effect in DooM2, but I can't seem to get it to work.
The player displays the Burn animation, but the Waving hands only seem to display very shortly. Basically in the Death state, I put Goto Fire state, which plays correctly until A_CrispyPlayer is called. ZDoom crashes right there (Report).
I uploaded a test wad here, could anyone have a look & see what's broken?
Note that I copied the sprites from Strife 1:1 without touching the palette (which for demonstration purpose shouldn't matter much).
The player displays the Burn animation, but the Waving hands only seem to display very shortly. Basically in the Death state, I put Goto Fire state, which plays correctly until A_CrispyPlayer is called. ZDoom crashes right there (Report).
I uploaded a test wad here, could anyone have a look & see what's broken?
Note that I copied the sprites from Strife 1:1 without touching the palette (which for demonstration purpose shouldn't matter much).
- NeuralStunner
-
- Posts: 12328
- Joined: Tue Jul 21, 2009 12:04 pm
- Preferred Pronouns: No Preference
- Operating System Version (Optional): Windows 11
- Graphics Processor: nVidia with Vulkan support
- Location: capital N, capital S, no space
- Contact:
Re: StrifePlayer additional states?
Hmm...
A_ItBurnsItBurns is what tells the engine not to immediately drop dead, and is supposed to start the hand waving animation (FireHands) instead. A_CrispyPlayer apparently tells it that the player is now dead, and to drop him to the floor immobile, while lowering the waving arms (FireHandsLower). Without it, you can still "walk" around and open doors after "dying".
Since the hand wave animation doesn't play, (and God only knows why,) I think this might be why the latter codepointer crashes.
A_ItBurnsItBurns is what tells the engine not to immediately drop dead, and is supposed to start the hand waving animation (FireHands) instead. A_CrispyPlayer apparently tells it that the player is now dead, and to drop him to the floor immobile, while lowering the waving arms (FireHandsLower). Without it, you can still "walk" around and open doors after "dying".
Since the hand wave animation doesn't play, (and God only knows why,) I think this might be why the latter codepointer crashes.
Re: StrifePlayer additional states?
Here's some code. Note that P_SetPsprite is the function that sets the "player sprite", that is to say, the various HUD sprite thingies (weapons, weapon flashes, targeter powerup, etc.).
Okay, so yes, A_CrispyPlayer does set the player state to "dead" (the PST_DEAD line).
The interesting thing is after that. There's a horrible hack. It adds up the state numbers of the current weapon sprite and the FireHandsLower state, and substract from that the state number of the FireHands state. So, be sure to declare the states in the same sequence as they are in StrifePlayer: FireHands then FireHandsLower, and as many states for either.
Seems pretty straightforward. Little hack as it sets the player to be still alive. Then it hijacks the Psprite weapon "channel" to display the fire hands, while nullifying your weapon so you can't attack, and preventing you from changing to another weapon. Also makes you all shiny (extralight = 3).
Rather simple as well: it lowers the vertical offset of the weapon Psprite (remember that 0 is at the top, so increasing the offset means going further downward, so a high value means a low offset), and if the Psprite offset becomes so low that the weapon can't be seen anymore, then just remove that sprite altogether. Also, makes the player less shiny by decreasing extralight.
Code: Select all
DEFINE_ACTION_FUNCTION(AActor, A_CrispyPlayer)
{
if (self->player != NULL && self->player->mo == self)
{
self->player->playerstate = PST_DEAD;
P_SetPsprite (self->player, ps_weapon,
self->player->psprites[ps_weapon].state +
(self->FindState("FireHandsLower") - self->FindState("FireHands")));
}
}
The interesting thing is after that. There's a horrible hack. It adds up the state numbers of the current weapon sprite and the FireHandsLower state, and substract from that the state number of the FireHands state. So, be sure to declare the states in the same sequence as they are in StrifePlayer: FireHands then FireHandsLower, and as many states for either.
Code: Select all
DEFINE_ACTION_FUNCTION(AActor, A_ItBurnsItBurns)
{
S_Sound (self, CHAN_VOICE, "human/imonfire", 1, ATTN_NORM);
if (self->player != NULL && self->player->mo == self)
{
P_SetPsprite (self->player, ps_weapon, self->FindState("FireHands"));
P_SetPsprite (self->player, ps_flash, NULL);
self->player->ReadyWeapon = NULL;
self->player->PendingWeapon = WP_NOCHANGE;
self->player->playerstate = PST_LIVE;
self->player->extralight = 3;
}
}
Code: Select all
DEFINE_ACTION_FUNCTION(AActor, A_HandLower)
{
if (self->player != NULL)
{
pspdef_t *psp = &self->player->psprites[ps_weapon];
psp->sy += FRACUNIT*9;
if (psp->sy > WEAPONBOTTOM*2)
{
P_SetPsprite (self->player, ps_weapon, NULL);
}
if (self->player->extralight > 0) self->player->extralight--;
}
}
Re: StrifePlayer additional states?
So the Strife burning hands are the most hacktacular thing ever made. 

- NeuralStunner
-
- Posts: 12328
- Joined: Tue Jul 21, 2009 12:04 pm
- Preferred Pronouns: No Preference
- Operating System Version (Optional): Windows 11
- Graphics Processor: nVidia with Vulkan support
- Location: capital N, capital S, no space
- Contact:
Re: StrifePlayer additional states?
Aha! So, cutting the AltSkin* states and stuff, adding the Disintegrate state, and removing the state jump from Death makes it work. Thanks Gez!Gez wrote:The interesting thing is after that. There's a horrible hack. It adds up the state numbers of the current weapon sprite and the FireHandsLower state, and substract from that the state number of the FireHands state. So, be sure to declare the states in the same sequence as they are in StrifePlayer: FireHands then FireHandsLower, and as many states for either.
So, this works as it should:
Spoiler:In the future though, I'd hope a much less hacky method could be adopted...
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49223
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: StrifePlayer additional states?
Ceeb wrote:So the Strife burning hands are the most hacktacular thing ever made.
Not the most but this a pretty dirty effect. So dirty in fact that ZDoom had to add some new code pointers to do them. Strife originally did some of this effect in an even more hackish way. What ZDoom does is rather tame by comparison.
- InsaneFury
- Posts: 105
- Joined: Mon Nov 23, 2009 6:51 am
Re: StrifePlayer additional states?
Ok, so in order for people to (ab)use these functions, they'll have to steer clear of any new player states (like freeze-/fire death, per-damagetype pain-/deathstates?
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49223
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: StrifePlayer additional states?
No. If you inherit from the Strife player all you need to do is call these functions in the proper places. They don't depend on anything external.