Crouching sprites for players with >1 sprite type

[Enjay]

The basic crouch sprite definition merely specifies the name of the sprites to be used in place of the normal ones when the player is crouched.

eg, the default

Player.CrouchSprite "PLYC"

replaces every PLAY sprite with a matching equivalent PLYC sprite whenever the player is crouched.

As far as I can tell, there is no way to tell the game to use different crouch sprites based on which ones are used in the normal player. Specifically, I have a complicated player definition that needs more than the standard number of Doom sub-sprites (ie more than A-Z+[\]) and the way to do this would be to use different sprite names for different parts of the player definition. Ideally, something like

Player.CrouchSprite "crouchname", "normalname"

would solve this problem but I don't think it exists.

eg

Player.CrouchSprite "PLYC", "PLAY"
Player.CrouchSprite "PLC1", "PLY1"
Player.CrouchSprite "PLC2", "PLY2"

So I'm wondering is there a different way to achieve what I want?

[Nash]

I remember having a similar problem waaay back when crouching was first introduced and Graf simply said that the system that's in right now is all we'll ever get.

Psst... Enjay... maybe it's time for you to write a looooong rant PM to Graf again. ;) ;) ;)

[NeuralStunner]

Hmm, well I was curious so I looked into ACS functions and found [wiki]GetActorViewHeight[/wiki]:

For a player, this corresponds to the Player.ViewHeight property, modified by crouching if needs be.

So here's an odd (hacky) idea: Could you define no CrouchSprite, and instead supply a second set of sprites, which are the sprites you want for crouching but stretched 2x vertically? Then using a global script called from Decorate, check every tic (!) whether the player's ViewHeight is lower than it should be. If so, give them an Inventory-based flag to chck for. This would be a pain for complex player definitions, especially for the animated states to run "uninterrupted". And there might be the occasional visible jump from the squished standing sprite to the correct crouch sprite. It would also be computationally intensive...

Personally, I think your sprite-for-sprite approach would be a good one. I know I would certainly use it... That would cut away the limits of class spriting, as one could supply frames for different weapons, or have a single character that can change class and appearance.

I remember having a similar problem waaay back when crouching was first introduced and Graf simply said that the system that's in right now is all we'll ever get.

Wistful sigh.