Player class "face" property without clobbering SBARINFO

[MartinHowe]

Please refer to this thread for problem description in detail, but basically, we can now create custom player classes (and also custom morph weapons/powerups in DOOM as well as in Heretic and HeXen) and this has exposed a problem with status bars, both custom and original DOOM.

A mod that needs its own SBARINFO can create customised sections by player class, but there appears to be no way for a player class defined in a generic mod, such as a weapon pack, to use a specific three letter code instead of STF ONLY for that player class and ONLY if the SBARINFO currently in force (i.e., without having to know what it is or attempt to interact with it) is using one. The screenshot in the referenced thread shows an example of the sort of problem that occurs.

The predecessors of player classes, old-skool skins, have a "face" property, so surely proper player classes should also? This should be a simple replacement for the built-in STF graphics and ONLY used where they would be; if the user has the statusbar hidden or has currently loaded a custom status bar that does things differently, then the player class's STF replacement should be ignored because the original DOOM one would be as well.

Please can this be added or a clean alternative way of doing it (e.g., a standalone SBARINFO command that overrides STF only if the current status bar is using them)?

[Xaser]

As far as I can tell, there shouldn't even need to be any SBARINFO at all to define a new face, just add a "face" property, am I right? Basically telling the game that anywhere it would normally use STF***, regardless of SBARINFOs in other wads, it should use the correct face instead? Your description had me a little confused, but I figure that's what you mean.

I'm all for it, either way. I'm quite surprised there is no "face" property to begin with -- could've sworn there was, or at least, there should be.

[MartinHowe]

There shouldn't even need to be any SBARINFO at all to define a new face, just add a "face" property, am I right?

Exactly. The objective here is that player classes should be able to replace the STF***** graphice cleanly, without risking the messing up of the operation of an in-use status bar; in other words, to have whichever status bar is currently in force operate on the face of the currently in-force player class wherever it would otherwise have used STF*****.

Generally speaking (i.e., this is not just a reply to Xaser), the idea here is that player class STF***** replacements should override the original STF***** before the processing of all other mugshot logic, including SKINs and SBARINFO. Thus any manipulation of the original mugshots by player skins and/or SBARINFO should feed off the ones supplied by the player class (some means of ensuring a refresh whenever the player class changes might be needed, depending on how far up the chain it is implemented).

Simply having the WAD with the player class supply STF***** isn't enough, because a WAD might not actually change the player's class (e.g., 2-player DM and neither player uses the "become a tapeworm" weapon during the entire game) and because unlike with SKINs, there could legitimately be more than one player class defined inside one WAD anyway.

[MartinHowe]

OK, I have an experimental build of ZDoom in which this works, but it needs refinement and also testing to ensure full compatibility with additional SKINs and SBARINFO. Basically it adds a "Face" property to the PlayerPawn class and replaces the STF items wherever they would have been used, via the PlayerClass base skins array and SetFace() (only doom statusbar and descendants implement a non-empty version of this method; others do nothing, which is good).

What I need before spending any more time developing it is some indication of how welcome it will be; in other words, if Randy/Graf are reading this - how likely is this to be NO'd or WFDS'd?

[Nash]

A "Face" property per player class was definitely suggested way back then when Grubber first introduced custom player classes into ZDoom... I'd definitely like to see this implemented. :)

[MartinHowe]

OK, this is what I have now. It has been tested in the presence of skins and on its own, and it works across morphing and unmorphing back again, but has NOT been tested with an SBARINFO loaded, due to a problem in the status bar logic generally. So it's not quite ready to add; in any case, I need to see how SBARINFO is shaping up, and SBARINFO right now is a moving target that I need to consider before refining this to the point where I feel confident enough to ask that it be added.

For example, one of 'Weasel's sbars, the "lizard" one, paints a face using SBARINFO, but it uses STF. In this case, SBARINFO is being used to position the regular status face, rather than replace it. Thus, there ought to be a way for the SBARINFO mugshot declaration to specify "inherit whatever STF replacement is currently in use if STF has been replaced by a SKIN or PlayerPawn".

So consider this attachment (SVN diff against r846) purely for discussion and suggestions at the moment.

[Blzut3]

Thus, there ought to be a way for the SBARINFO mugshot declaration to specify "inherit whatever STF replacement is currently in use if STF has been replaced by a SKIN or PlayerPawn".

Deprecating the first argument and making it optional. If the first argument is present over ride everything besides skins. That's my idea anyways.

[MartinHowe]

Deprecating the first argument and making it optional. If the first argument is present over ride everything besides skins. That's my idea anyways.

OK I get the basics, but what exactly does "adjust itself to skins" mean? It'd take me a while to go through all of the source code for SBARINFO, so please could you say here what that means?

DrawMugShot <default>, <accuracy> [, flags, ...], <x>, <y>

Draws a mug shot at the specified location. It will prefix the image to what is specified in default and will automatically adjust itself to skins. Accuracy can be a number 1-9 which specifies how many blood levels there are before death.
...

As with most sections and declarations in script languages, we cannot just omit the first argument; however, since only three characters are allowed for "default" by the nature of DOOM, perhaps explicitly specifying "" could be used instead. So for example:

• DrawMugShot "STF", ... would mean to use "STF" literally
• DrawMugShot "XYZ", ... would mean to use "XYZ" literally
• DrawMugShot "", ... would mean to use "STF" unless a SKIN or player class face is in use, in which case use whatever it would use

How about that?

[Blzut3]

Deprecating the first argument and making it optional. If the first argument is present over ride everything besides skins. That's my idea anyways.

OK I get the basics, but what exactly does "adjust itself to skins" mean? It'd take me a while to go through all of the source code for SBARINFO, so please could you say here what that means?

Currently SBarInfo uses the default specified unless the skin has a face. The check is done on line 92 of sbarinfo_display.cpp, but I don't think you need to worry about this. Down at line 683 is where I'm calling the function. I'm passing cmd.string[0] in right now (this is the first arg of drawmugshot). This needs to be changed to a three character string from the player's class. So, you just need to do an if(cmd.string[0] != ""){ /* Current code */ } else { /* New Code */ }. Or something to that effect.

{stuff about the syntax}

No one needs to know the old method still works. I would just add an if(sc.CheckToken(TK_StringConst)) to the beginning of the parsing for drawmugshot. By default the strings will be set to "". Think of it as an overloaded function.

[Xaser]

DrawMugShot "STF", ...[/b] would mean to use "STF" literally

Wouldn't that defeat the purpose though? An example:

Let Wad A be a weapon modification with two player classes (one male, one female, w/corresponding face graphics).
Let Wad B a seperate mapset with a custom SBARINFO hud (complete with mugshot display).

In Wad A, the male character uses the standard STF***** graphics for the mugshot, but the female character uses said new "face" property to change the graphics to "FEM*****".

If Wad B uses DrawMugShot "STF" (which I assume is the normal way of doing it), wouldn't it be wise to still take into account Wad A's "face" property anyhow? If "STF" is processed literally, then Wad B's HUD would still show the male character's face sprites regardless of which character is actually being played.

Ideally, shouldn't the "face" property be absolute in terms of replacing "STF"? In this example, if Wad A's female character is used, shouldn't all instances of STF***** be replaced with FEM*****?

But what if Wad B replaces the STF graphics as well, intending to use a cyborg character's facepic? Would it be right, then, to still use Wad A's facegraphics regardless? To put it simply, yes. That would be a mistake on Wad B's part -- should an author want to make a hud which absolutely uses a certain facepic no matter what, just have SBARINFO use DrawMugShot with a value other than "STF". Using "CYB" for instance in Wad B would make the cyborg character face appear regardless of Wad A's character setting is -- exactly what the author intends. To me, this would be the ideal priority.

To sum it up, in SBARINFO, all DrawMugShot definitions should be absolute except for STF -- seeing that it's the default, a special case needs to be made. The "face" property should override all instances of STF but only STF. You see my point, right?


I'm sure this is what you guys intend anyway, but I wanted to clarify this point a little from a non-programming perspective.

[MartinHowe]

I think we're all getting a bit confused between what happens now, my erroneous comments earlier and what ought to happen Can we all step back and focus on what should happen before a final decision is made? Taking into account the above, I guess the priority should be something like this?

• If no STF graphics are available (i.e., Heretic/HeXen,Strife), start with NO face at all.
• If STF graphics are available, start with them. Since SBARINFO is intended for all games, somebody making an SBARINFO for Heretic or HeXen could easily make a "time travelling marine goes into the past to fight demons" mod - indeed this has been done several times in DOOM by importing Heretic/HeXen monsters into DOOM via DeHackEd (e.g., Herian and Herian2). A maker of such a mod might call the faces STF even in Heretic "because that's what DOOM does" and we need to beware of this possibility.
• Get the face from the current player class if there is one and use that instead of STF.
• If a skin is loaded and includes faces, use that instead of STF or player class face.
• For each WAD that contains an SBARINFO activate that, overriding/adding over the previous one. The "default" is used if no faces have yet been defined. It should not be a fatal error if no face is present at all - SBARINFO should simply draw the face box with no face; you don't want to abort the game just for that.
• To cope with Xaser's comments above, like the cyborg, perhaps "force override" should be one of the DrawMugShot flags.

When a player is morphed, the morphed player class's base skin face should take priority (morphing like the chicken and pig) is a special effect and should temporarily override whatever face is currently in use, then return to it. This is what my experimental player class "DECORATE Face property" build does, but it needs to get the current face from SBARINFO if any - so I still need to know where exactly SBARINFO stores the "current face" if it is supplied from SBARINFO and not from a skin or player class.

Thus, it is really really needed for the next version of the SBARINFO code to provide an internal "refresh current mugshot" function that other parts of ZDoom can call to redraw the correct SBARINFO mugshot without having to know what it is and without having to access the internal data of SBARINFO. If there already is, please tell me what it is, cos I haven't found it yet

[MartinHowe]

Making progress...

In todays "Sun": Join the Increment and kill a demon!!!


It's my cat's 12th birthday today, so...

The above is an example of a face changing when morphed and restored back.

Cutty does the Weasel lizard HUD:


The SAS guy is a regular player class, the cat is morphed from the SAS guy (and subsequently unmorphed), while the cutty guy is a plain old-skool skin. These also work with the regular DOOM2 statusbar.

And no, this one is NOT photoshopped:

[MartinHowe]

OK, this (see attachment) is what I have so far. Along with the bugfixes in the other thread, this gives:

• A Face property to the PlayerPawn class like the one in S_SKIN
• Integration of PlayerPawn faces and S_SKIN faces with the new SBARINFO face ("mugshot") logic
• Faces of all three kinds are properly changed and restored across morphing
• Enough sanity checks that SBARINFO faces even work (up to a point) in HeXen!!

I feel this is enough to justify adding it.

If so, I ask that the thread not be closed yet, though. There are still some minor problems to be sorted out, particularly the health issue - notice how in the screenshot, the cat's face shows damage, even though he's at his max health. Some cleaning up of the morphing subsystem is in order - there's too much hardcoding and suchlike in the way it works now, so it's quite inflexible; making a "morph" power-up class should be possible; heck, with a morph projectile, you can't even specify the duration of the morphing! The included diff does a little bit of refactoring of the morphing subsystem, but it really needs a thorough cleanup.

Any comments?

[wildweasel]

making a "morph" power-up class should be possible

You mean like Rise of the Triad's God/Dog Mode powerups? Hell yes!

[MartinHowe]

OK, got a basic Morph power-up working, but the usual debugging has to be done whenever one messes with engine internals The AMorphPower class must keep a copy of the Owner->player because P_MorphPlayer() clears it. Yuck. At least the morphed actor has a "tracer" field for the original mo, I wonder why there's no "original player_s" field Still, it's not worth bloating the standard object classes any more than I have to...