Player class "face" property without clobbering SBARINFO

[MartinHowe]

Getting better - fixed assertfail on de-morph (remove power from inventory before calling P_UndoPlayerMorph), still a crash on exit to fix. Anyway, time for some new screenies. I thought I'd make a Porkelator-like spinning bobbing artefact, but as a reflexive power-up instead of a transitive curse.

Behold - the Kitten of Killing!





Now for the $65536 question - should A_JumpIfInventory refer to the original mo or the morphed mo? The original has the power and only that, the rest (along with the player data) was moved to the morphed mo. Have to give it some thought.

[MartinHowe]

OK for the developers/interested among you, here's a diff vs 864 of what I have so far. The crashes are fixed - the entire inventory is held with the morphed player until the unmorph occurs. If you compile this, the following features become available:

PlayerPawn property Face - used instead of STF, must be three chars alphanumeric

MorphProjectile property MorphTime - time of morph effect in TICS

MorphProjectile property MorphStyle - effect behaviour; RAVEN is the default if not specified; max health limited to 30 once it falls below that. General weirdy behvaiour if you're not a chicken or pig. Other value is CURSE; max health taken from morphed player pawn. This is incomplete, though; the idea is that eventually CURSE will imply well-defined behaviour as to health, inventory keepability/usability etc; I just haven't defined them yet It might even be better as the default except for the egg/porkie, see this thread for discussion.

PowerMorph class for use with PowerupGiver class.

Existing Powerup property Duration used for time of morph effect in TICS
New Powerup property PlayerClass used for player class to morph to. The internal MorphStyle POWER is implied - like CURSE, but no specific limit on health; i.e., and all properties taken from the morphed player class (eventually).

Note that the morph styles are deliberately not available across all morph items; that would need a fair bit of discussion before allowing it; note that you could still make cursed morph booby traps by creating an item that looks like a cool power-up, but spawns a monster that immediately attacks the player with a morph projectile; a sort of trojan horse.

I still need to make the mugshot code not crash if the faces aren't available, eg, if ww-lizardhud used in HeXen by mistake (just display nothing) - just need to find the time to do it. It also needs a P_MorphPlayer() overload that suppresses the teleflash and sound for later use; e.g., an ALLOWMORPHFLASH flag or something like that.

Comments? Suggestions?

[Nash]

Question... what makes the property MorphTime and the existing Duration property different from each other?

[MartinHowe]

Question... what makes the property MorphTime and the existing Duration property different from each other?

The existing Duration property only exists in PowerupGiver, it didn't exist in MorphProjectile; MorphTime is just MorphProjectile's name for Duration, though in hindsight, perhaps MorphTime should be called Duration for the sake of consistency. Since this whole thing hasn't been accepted yet (assuming that Randy/Graf have noticed it) there's still time to fix syntax and other deficiencies.

[MartinHowe]

OK, renamed MorphProjectile.MorphTime to MorphProjectile.Duration for general syntax consistency.

Fixed some SBARINFO crashes when specified graphics don't exist. Running DOOM HUDs with HeXen is a strange thing to do but although one cannot expect them to work properly, they most definitely should not crash the engine; instead the missing graphics simply aren't displayed.

With the above applied, and using my goodguyz mod, I can now do the holy grail of weird doom modding - Bombay 72 in HeXen!!!!

Increment/SAS/SBS Training Manual Section 6.6.6:
Don't do drugs before a mission. They turn you into a giant cat and your vision is all f***ed up! Got that Soldier!?!?!

[Gez]

I think you need to use SlumpEd to turn your status bar graphics into PNG. Then the screenshots won't be that painful to see.

[Nash]

Martin, does this little modification of yours allows modders to hack an in-game class change feature by giving the duration time a stupidly large amount (or constantly morphing the player via an ACS loop or something)... ?

[MartinHowe]

I think you need to use SlumpEd to turn your status bar graphics into PNG. Then the screenshots won't be that painful to see.

Thanks for the tip! I'm looking for a scripted way of doing it, but as a manual hack on the compiled WAD file, SLumpEd works fine.

Martin, does this little modification of yours allows modders to hack an in-game class change feature by giving the duration time a stupidly large amount (or constantly morphing the player via an ACS loop or something)... ?

At the moment, you can't be morphed twice. I do plan some extra parameters or flags to suppress the sound and/or flash and I suppose there could be an "allow further change" flag too. I'm also thinking of allowing PlayerClass as "" to mean "unmorph if already morphed". The change-morph would likely have to be an internal unmorph then morph again - P_MorphPlayer probably isn't robust enough to modify it for direct morph class change and it would probably take a lot of work.

The morph subsystem uses a Duration of -1 internally to mean "until explicitly unmorphed", but this is only used internally by the PowerMorph class; I guess exposing it in DECORATE could work. Then again, this ought to be available for powerups too.

As for ACS, just giving the powerup should do it; if you want a proper ACS MorphPlayer() function, best ask one of the guys who knows ACS internals well. It'll be a while before this whole thing is good enough for me to ask for it to be added, though because I have a shitload of Real Life right now and because I really want the "what the player can use/pickup" thing defined in a clean way - that's why I didn't just stop at getting faces to work; the original motivation for faces was morphing, then I realised that the morph subsystem was in chaos and needed cleaning up. There is, I hope, a better chance of this mod being accepted into the engine if it gives some real benefit as well as just eyecandy support.

[Nash]

Sounds good Martin, but in my opinion if you can extend this enough to allow modders in-game player class morphing, I think that'd be too awesome not to merge into the main code...

At any rate, this is all so awesome already. Keep up the good work!

[Project Shadowcat]

Ported to DECORATE? Dude, if that were to happen, I know just how to abuse the fuck out of that, and it involves just cycling weapons.

Just think, DoomGuy can actually show what weapon he's carrying if people took the time to actually do that. What say you all?
(The faces could be changed but it would not make sense for this specific purpose.)

[Xaser]

Great Scott... net-safe Doom VWEP support? That's nuts, I say! XD

[MartinHowe]

Too late at night to test what I've just compiled (it's 01:22 am here in the UK right now ) but the next version will slightly change the MorphStyle property into a set of flags to make it a bit more extensible and so that what we have now could be added as is, if only for the status faces.

As for suppressing the flash, more flexible would be the ability to specify the morph effect flash actor (including "None"), like with pickup flashes, instead of assuming ye olde teleflash. But that will have to wait until tomorrow becasue I can't keep my eyes open any more. G'Night, all!

[MartinHowe]

Here is a message; mostly for Blutz3, but it's as well to take note generally.

It is clear to me that the morph powerup and improvements need a fair bit of work. I still want to do it, but it's gone way beyond the scope of this thread's original purpose. Furthermore, Graf has indicated in another thread that he believes that cleaning up the restrictions on player classes using things will be messy and complicated. Whatever I think about that, the issue directly affects morphing; however, there is still a lot of useful cleaning up that can (and IMO should) still be done with morphing without going that far and there's no technical reason why morph powerups and improved attacks can't be done without a lot of bloat - you have seen the code.

My point is this thread is nothing to do with status faces any more. I seem to have derailed my own thread; if I were a moderator I should have to ban myself Anyway, when I have the time, I will post here for attention of Blutz3 another SVN diff that does nothing except the status bar improvements and includes only those changes to the morphing code necessary to support them. The morphing subsystem cleanup will have to go in another thread.

[MartinHowe]

OK, this is the diff for the status face stuff only. Please could this be added?

[Graf Zahl]

Done.