[SBARINFO?] Scripting the Face

[Project Shadowcat]

A simple request that could probably be more complex to implement, but it's like this.
Through ACS can one actually script DoomGuy's face? This would be extremely ideal for first-person cutscenes, such as he shows his concern for an object or NPC, or (god forbid) he actually talks. The modder of course would have to take the time to create any required graphics.

The idea can be expanded to the point where DoomGuy can show his evil face when he gets an awesome powerup (again, on modder request). This one could be used in DECORATE.

[XutaWoo]

Yeah.

The best way would probally just putting graphics together (for bloodiness of the face) and giving them a name, plus adding inventory.pickupface and ChangeFace(str facename) functions.

If I was the DoomGuy, I would start laughing maniacly as soon as I got the BFG9000. Non-serious TPs could have the DoomGuy doing something silly when he picks up a weapon or achieves something. If was the DoomGuy, I'd start :ving if I beat a Cyberdemon with only my fist, pistol, shotgun, chaingun, and rocket launcher.

[Blzut3]

If a way for me to get the player's method of death comes along then I might as well add support for forcing a mug shot state. But until then I don't see a reason not to continue using an ACS method of doing this. (Either way you're still using ACS. )

[Graf Zahl]

The means of death (a.k.a. damage type) is stored in the player actor's DamageType field so it's already accessible.

[Project Shadowcat]

But until then I don't see a reason not to continue using an ACS method of doing this. (Either way you're still using ACS. )

Thing is I want to replace the face altogether when an "event" comes up, not overlap it with a HudMessage. I don't care if I have to use ACS to do it or not, I just thought it would add a neat detail of interactivity.

[Blzut3]

The means of death (a.k.a. damage type) is stored in the player actor's DamageType field so it's already accessible.

I guess I missed this in the change log. I suppose I should get to work on mug shot states then (well as soon as I get everything set up again).

[CaptainToenail]

I'm for this, sounds quite funny and could be ueful for a weapon mod I'm thinking of making.

[Project Shadowcat]

Everyone's thinking weapons and I'm just trying to get his lips to move. o_o;;

[Blzut3]

Well I got something working for death states right now (well it doesn't figure out the damage type just yet). Here is the syntax so far:

Code: Select all

mugshot Death
{
	DEAD0 -1;
}

mugshot XDeath
{
	XDTH0 10;
	XDTH1 10;
	XDTH2 10;
	XDTH3 10;
	XDTH4 10;
	XDTH5 -1;
}

If anyone notices, I did adjust the speed of the xdeath animation since now that I can see the status bar I realized just how slow it originally was (at least I think it was set to 53 tics per frame). Oh if anyone reading this has a copy of the Play Station or Jaguar version of Doom and wants to tell me the proper speed of the animation please do so.

One I get everything done I'll be exporting (at least some of) the animations into the ZDoom pk3.

[Project Shadowcat]

With that method, is there any chance of defining additional states -- just like Actors and their custom states?

Then perhaps call them with ACS? That way it'd be a bit more effective when DoomGuy's still breathing, too, you know?

[Blzut3]

With that method, is there any chance of defining additional states -- just like Actors and their custom states?

It already "supports" custom states it just doesn't use them for anything. It would just be a matter of an ACS function which set currentState in the SBarInfo status bar to point to some mug shot state.

[Project Shadowcat]

So then we're only waiting on an ACS command... thanks for the partial add-in.

[Blzut3]

Still no ACS command, but I think I have everything else in (including custom damage type support for Pain, Ouch, Death, and XDeath). Here is the code for all the mug shots:

---

Code: Select all

mugshot "Normal", health2
{
	{ST00, ST01, ST02} 17;
}

mugshot "Pain", healthspecial, directional
{
	{TR00, KILL0, TL00} 35;
}

mugshot "Rampage", health
{
	KILL0 1;
}

mugshot "Ouch", health
{
	OUCH0 35;
}

mugshot "Grin", health
{
	EVL0 70;
}

mugshot "God"
{
	GOD0 -1;
}

mugshot "GodAnimated"
{
	{GOD0, GOD1, GOD2} 17;
}

mugshot "Death"
{
	DEAD0 -1;
}

mugshot "XDeath"
{
	XDTH0 10;
	XDTH1 10;
	XDTH2 10;
	XDTH3 10;
	XDTH4 10;
	XDTH5 -1;
}

Here is a build of ZDoom with this implemented. Anyone want to volunteer to search for bugs and/or memory leaks that may have been caused by the re-write of the mug shot system? If anyone wants to try out the custom damage type support the syntax is "State.DamageType".
http://blzut3.maniacsvault.net/mugshots.zip

(Sorry if this post sounds rushed, my wireless connection is constantly dropping.)

[MartinHowe]

Is there or will there be any way to specify the mugshot graphic independently of everything else, but only if one is in use?

Now that ZDoom modders can create custom player classes and morph artefacts, you would think the "face" property of regular old-skool skins would be included as a player class property, but it is not. This means that, for example, I can create a morph weapon in DOOM (not Heretic or HeXen) that changes the player into a chicken; heck, by spawning a monster that does nothing except fire a morph fx projectile at the shooter, it could even be a power-up that, for example, changes the player into a monster - say an ALIEN or a Maulotaur. If under that circumstance the user is using even the regular DOOM built-in statusbar, let alone a custom one, the player will be a chicken but have a marine mugshot!

Here's a ChaseCam screenshot of a powerup I made that morphs the player into a black cat -- but it leaves the SAS commando mugshot. See the problem?


It would make player class modding for DOOM a lot more clean if one could include an SBARINFO that adds to whatever one is already in use and contains nothing but a mugshot command that only applies (a) to a specified player class and (b) only if mugshots are being drawn at all by whatever statusbar is in use.

Alternatively, maybe Randy or Graf could add the regular SKIN face property to player class definitions in order to overcome this problem.

[Blzut3]

{Stuff about morphing}

You should probably open another feature request for this.