Pama´s Deadly Furniture (scripts)

[z3r0]

I did some disecting of the files a few years back.

I managed to find the behavioural flags, and exactly how they work but I lost the data.

 

Will try and mine it again.

 

But I vaguely remember that you needed to set some flags in the hkx file as well, with the HAVOK tools when creating the animation.

[z3r0]

Found it!

 

It was actually hidden in the extra guards paired animation, the one that stands behind the victim and pushes him/her down.

What this means is:

The actual decapitation is handled by the extra guard. You could try and add a dummy actor to handle it or simply add it to the victims animation.

My guess is, the execution animation you tried to edit did not have the proper flags in it.

 

Might be worth a try.

 

Quote

<?xml version="1.0" encoding="ascii"?>
<hkpackfile classversion="8" contentsversion="hk_2010.2.0-r1" toplevelobject="#0045">

    <hksection name="__data__">

        <hkobject name="#0046" class="hkMemoryResourceContainer" signature="0x4762f92a">
            <!-- memSizeAndFlags SERIALIZE_IGNORED -->
            <!-- referenceCount SERIALIZE_IGNORED -->
            <hkparam name="name"></hkparam>
            <!-- parent SERIALIZE_IGNORED -->
            <hkparam name="resourceHandles" numelements="0"></hkparam>
            <hkparam name="children" numelements="0"></hkparam>
        </hkobject>

        <hkobject name="#0048" class="hkaSplineCompressedAnimation" signature="0x792ee0bb">
            <!-- memSizeAndFlags SERIALIZE_IGNORED -->
            <!-- referenceCount SERIALIZE_IGNORED -->
            <hkparam name="type">HK_SPLINE_COMPRESSED_ANIMATION</hkparam>
            <hkparam name="duration">20.000000</hkparam>
            <hkparam name="numberOfTransformTracks">99</hkparam>
            <hkparam name="numberOfFloatTracks">4</hkparam>
            <hkparam name="extractedMotion">null</hkparam>
            <hkparam name="annotationTracks" numelements="99">
                <hkobject>
                    <hkparam name="trackName"></hkparam>
                    <hkparam name="annotations" numelements="2">
                        <hkobject>
                            <hkparam name="time">3.333333</hkparam>
                            <hkparam name="text">AnimObjDraw.DecapitationNeckGore</hkparam>
                        </hkobject>
                        <hkobject>
                            <hkparam name="time">3.366667</hkparam>
                            <hkparam name="text">AnimObjDraw.DecapitationHeadGore</hkparam>
                        </hkobject>
                    </hkparam>
                </hkobject>
                <hkobject>

 

[t.ara]

Lot of information which is possible to be handled inside of the skyrim animation behavior is not accessible by using FNIS. One aspect is the fail of alignment of all idle-animations, there are a bunch more which all caused to get new ideas so to surround artefacts, that´s it. You can begin to deal with all this if you are able to edit the original animation behavior of skyrim, which is not (official) possible - you can edit it-but you don´t have the working file-which is needed if you want to change or add stuff, store it again and use it in game. And you need Bethesdas´s converters to be able to write out suiting stuff. You can use the skyrim original skeleton inside of the HAT but you can not load a character´s mesh into it.

You can use and play all the humanoid animation idles and start with a new skyrim humanoid behavior work-theoretically-practically...you have to work on this for month and years....

 If you edit such parameters inside of an FNIS-idle- file, it won´t be played. That´s why you can create the head-chopping ideal by using the vanilla animations and the other stuff has to be done with TRICKS and code.

It´s important to understand that FNIS is not offering the complete integration of animation-idles into skyrim.

 

And let me mention that the skeleton´s ragdoll-contraints inside of skyrim is not working "too much ideal" together with the body-mesh and the ragdoll effect in whole looks sometimes weird. So I think are the result of PAMA´s work really well sorted and a quite optimal working series of exotic options, to let your character or NPCs die. If there are artefacts, this depends simply on the unthankful-way the ragdoll is acting inside of this game. Quite a professional work to edit and correct miss-aglignment of the ragdolling by editing collisions and fixing nonsence by scripting, as usually.

 

 

 

 

If interesting, here is some introduction into the built of the ragdoll physics-maybe this is helping somehow-anyway it explains the terms, which is useful for modding and specially for physics-freaks: (The HCT-tool (3d-studio-max 9/3dsmax10) has also a very detailed and perfect GUIDE)

 

 

 

• Behaviors: This is an asset you'll compose inside HAT. It is the creation, editing, and testing of behaviors which is the primary focus of the program so you'll be spending most of your time working on behaviors. The Characters Tab, Graph View and the various Scratch Pad Editors are used for editing behaviors. Behaviors are compositions of animations, states, transitions, events, variables and sequences which allow the character to behave in different ways in the game. HAT allows only a single behavior per file. The project can load multiple behavior files however.

• Animations: This asset type is generated outside of HAT in programs such as 3ds Max, Maya, or Softimage and exported using their Havok Content Tools plug-ins (see Exporting from the Havok Content Tools).

 

 

 

 

 

Working with Physics

Within a behavior graph physics modifiers can be used so that the behavior of a character can be influenced by physics as well as animation. There are several modifiers you may use. In this section we'll examine the Powered Ragdoll Controls Modifier, Rigid Body Ragdoll Controls Modifier, and the Get Up Modifier. We'll also look into the Pose Matching Generator. We'll explore the details of a sample behavior which uses each of these to understand how they work together.

Concepts

There are a few terms used that are worth understanding before we begin.

Rigid Bodies

Rigid bodies are the basic building blocks of Havok simulations; for an object to be simulated, it must be a rigid body. A simulated rigid body contains both dynamics (rigid body) and collision (shape) information. Each modeler supported by the Havok Content Tools allows rigid body and/or shape information to be attached to any object in the scene.

Ragdolls

Ragdolls are an articulated system of rigid bodies representing characters. These are commonly employed in HAT for physical simulation of characters.

Ragdoll Physics

The Powered Ragdoll Controls Modifier and Rigid Body Ragdoll Controls Modifier can be used to turn on the ragdoll. They each expose a set of control properties that determine how the ragdoll will behave. These control properties become data which flows through the HAT behavior graph. The behavior graph can then blend this data while blend nodes and transitions are playing. The system will process this data after updating the behavior graph in order to drive the ragdoll.

Example Usage

An example of the use of these modifiers and generators in HAT is the sample behavior 5.0_Ragdoll_Test.hkb. The behavior combines animation and physics and allows the character to idle, stagger, run, fall to the ground as well as get up. This behavior has five states as shown below:

 

The Idle, Stagger, Running and Get Up states use the Rigid Body Ragdoll Controls Modifier. These closely match the input clip node. The Dying state uses the Powered Ragdoll Controls Modifier and the Pose Matching Generator. The Get Up state also uses the Get Up Modifier and the same Pose Matching Generator as the Dying state. You can see that the Pose Matching Generator is shared because they appear in italics in asset view. If you select one of them the other will appear highlighted in a lighter blue:

 

Idle, Stagger and Running are quite simple—they use the Keyframe Bones Modifier to keyframe the bones. Keyframing makes the rigid bodies in the ragdoll get positioned and oriented exactly with the bones of the animation to which they are mapped. These states also use the Rigid Body Ragdoll Controls Modifier to pick up "momentum" from each of their associated clip nodes. For example the Running state has a clip node with a running loop. Its Rigid Body Controls Modifier takes that as input and gathers the momentum from it. It saves this information in the track data which flows through the behavior. This momentum is used when a transition to the Dying state is made. Without the Rigid Body Ragdoll Controls Modifier the character would simply fall straight to the ground rather than more realistically falling forward as he would do when running.

 

The Rigid Body Ragdoll Controls Modifier is used when you want a close match of the input pose (for example the animation from a clip node) but want it to respond to "hits" in the environment. It is often used to eventually transfer "momentum" to the ragdoll so when the physics begin the previous motion has been imparted to the ragdoll.

The Dying state is a bit more complex. It uses the Powered Ragdoll Controls Modifier, which allows it to collapse to the ground but using the momentum from the previous state.

Tip: The Powered Ragdoll Controls Modifier is particularly useful for effects like driving muscles during death or driving the ragdoll to a specific pose to get up from.

The Dying state uses the Pose Matching Generator as the pose to modify:

 

In this example the pose matching generator has two child clips: one for matching the character when he has collapsed on his stomach and one for when has collapsed on his back. Initially the Pose Matching Generator is in its "Matching" mode. In this mode it looks at the first frame of each of its child clips and determines which is a more accurate match for how it collapsed on the ground. If the character is closer to the "on his back" clip, then that will be used to generate the animation when "Playing" mode is entered. If the character is better matched by the "on his stomach" clip, then that will be used to generate the animation when playing mode occurs. The Pose Matching Generator gets triggered to enter its "Playing Mode" when it receives the "Start Getting Up" event. When it does, it begins playing the clip that was determined to be the best match. Note that in our sample behavior this is the same event that's used by the transition from Dying to Get Up. Thus that event is raised, and playing mode is entered, when the transition from Dying to Get Up occurs. The Get Up state shares (references) the same Pose Matching Generator node as Dying. So the "knowledge" about which was the best pose match is available in both states.

Get Up is also an interesting state. Here's how it appears in asset view.

 

It uses the Rigid Body Ragdoll Controls Modifier. Driving it is the Get Up Modifier, which modifies the pose generated by the Pose Matching Generator. This Pose Matching Generator is shared with the Dying state. The Dying state determines which of the clips to use to get up. As mentioned above, the event raised for the transition from Dying to Get Up will also cause the pose matching generator to switch to playing mode, where it will play either the "getup_from_die_backward_Extract_FB.hkx" or "getup_from_die_forward_Extract_FBLRT_RefFrame.hkx" animation. This gets pumped through the Get Up Modifier which gradually (according to its duration property) aligns the character's world from model up vector so it is pointing upward again. This causes the character to become correctly aligned to get up. This is then input to the Rigid Body Ragdoll Controls Modifier, which stores the track data necessary to actually drive the ragdoll into his standing position.

You can test this out by simulating the behavior. The Stagger state will generally cause the character to fall to his back during "dying", while the Running state will usually cause the character to fall on his stomach while "dying". When you transition away from Dying to Get Up you'll see HAT uses the correct get up animation as chosen by the Pose Matching Modifier.

Summary

Physics nodes can be used so that the behavior of a character depends on physics as well as animation. HAT provides two blend-able physics modifiers. These are the Powered Ragdoll Controls Modifier and the Rigid Body Ragdoll Controls Modifier. These modifiers do not directly drive the ragdoll. Instead, they introduce physics control data into the stream of data that is being processed by the behavior graph. This control data is blended along with the pose data by blend nodes and transition effects. The system will then automatically interpret this data to turn on, drive, and turn off the ragdoll.

 

 

(this is a smart part of the GUIDE of the Havok Animation Tool)

[z3r0]

A few years back I tried to fully understand how the animations are handled by the game, but I was allways left with blank spots.
I disected all the files I thought could have anything to do with it. I had to re-do some of the digging to jerk my memory, but you are right.

 

Seems the only way the community could abandon the workaround measures is with either the game source code, or all of the tools used to develpo the game to understand what is actually going on.
 

Pamatronic is doing an exceptionaly good job of bringing something new to the table, with the limited information available.

Also the resources you developed for the game t.ara are mind boggingly diverse.

 

Thank you for the information and help.
I hope I will be able to piece together this puzzle.

[Pamatronic]

17 hours ago, z3r0 said:

Found it!

 

It was actually hidden in the extra guards paired animation, the one that stands behind the victim and pushes him/her down.

What this means is:

The actual decapitation is handled by the extra guard. You could try and add a dummy actor to handle it or simply add it to the victims animation.

My guess is, the execution animation you tried to edit did not have the proper flags in it.

 

Thats odd

usually, the vanilla decapitation works just fine when you trigger the victims Animation, even without an executioner or Guard present. thats what the Guiloitine does and there are no problems whatsoever.

Also, the example i described earlier used the unaltered vanilla animation (directly extracted from the bsa). which further convinces me that there is something missing within the behavior, rather than the animation itself.

 

(still no idea though, why the guard has those lined within his animation. Probably a leftover?)

[t.ara]

4 hours ago, z3r0 said:

A few years back I tried to fully understand how the animations are handled by the game, but I was allways left with blank spots.
I disected all the files I thought could have anything to do with it. I had to re-do some of the digging to jerk my memory, but you are right.

 

Seems the only way the community could abandon the workaround measures is with either the game source code, or all of the tools used to develpo the game to understand what is actually going on.
 

Pamatronic is doing an exceptionaly good job of bringing something new to the table, with the limited information available.

Also the resources you developed for the game t.ara are mind boggingly diverse.

 

Thank you for the information and help.
I hope I will be able to piece together this puzzle.

This doesn´t mean we´re at the end of the tunnel.

If you like to share any further ideas on the animation-system of skyrim, I would like to invite myself to this party. But not here.

 

[z3r0]

10 hours ago, Pamatronic said:

 

Thats odd

usually, the vanilla decapitation works just fine when you trigger the victims Animation, even without an executioner or Guard present. thats what the Guiloitine does and there are no problems whatsoever.

Also, the example i described earlier used the unaltered vanilla animation (directly extracted from the bsa). which further convinces me that there is something missing within the behavior, rather than the animation itself.

 

(still no idea though, why the guard has those lined within his animation. Probably a leftover?)

Well what I could piece together is that the executioner guard has the gore effects attached and the executioner has the sound effects attached.
The actual victim has nothing in its animation that looks like it would handle either.

I will check some of the killmove animations to see how thoose handle it.

 

EDIT: Did some poking, did some proding. You are right, it is handled by the behaviour files.

[buzzyxoom]

Would it be possible to make a sawing-in-half furniture from the sawmills? I know that actually dividing a body in half requires tooling that simply isn't available, but faking it with a decal and blood effect or something and everyone just understanding that true cutting can't happen should be possible.

 

And a saw can have many different positions from a single furniture.

 

(I had asked t.ara a similar question on the ZAP9 thread, which is how I know real cutting isn't possible)

 

[z3r0]

6 hours ago, buzzyxoom said:

Would it be possible to make a sawing-in-half furniture from the sawmills? I know that actually dividing a body in half requires tooling that simply isn't available, but faking it with a decal and blood effect or something and everyone just understanding that true cutting can't happen should be possible.

 

And a saw can have many different positions from a single furniture.

 

(I had asked t.ara a similar question on the ZAP9 thread, which is how I know real cutting isn't possible)

 

Well if you use two actors (original and a clone) that equip two custom head and body meshes and make it a paired animation it could work.

On the downside the quality would be craptacular, or very hard to properly implement.

[Pamatronic]

well, t.ara is pretty much right on this one. there is no practical way of doing it.

a "fake" approach would have some resemblance to Deadly mutilations, but anything that involves partitioning the torso in any way whatsoever would be an absolute nightmare to do.

you would have to create nifs of the individual bodyparts and create bodyslide data for them, so they match the actual bodytype of the actor. Problem with that is, that you will likely have different body-types / body-textures in your game, so you are almost guaranteed to have terrible mismatches when trying this (and this is of course ignoring the fact that it wouldn't work with any type of clothing / restraints / accessories, unless .

And this is something even AAA-Games struggle with. For example: have you ever played Witcher3 ? there is a killmove that cuts straight through the torso. this will make one bodyhalf invisible and equip a bloody rim (this could be realistically reproduced). BUT: for the "cut off" half, it will always spawn in the same assets, which often leads to some horrible visual mismatches.

the reason for this is of course that they didn't want to account for the different body's/clothing.

 

And if a Giant company like them thinks its not worth the effort, I´m sure as hell not taking on the nightmare of doing it on my own, sorry. ?

[buzzyxoom]

12 minutes ago, Pamatronic said:

well, t.ara is pretty much right on this one. there is no practical way of doing it.

a "fake" approach would have some resemblance to Deadly mutilations, but anything that involves partitioning the torso in any way whatsoever would be an absolute nightmare to do.

you would have to create nifs of the individual bodyparts and create bodyslide data for them, so they match the actual bodytype of the actor. Problem with that is, that you will likely have different body-types / body-textures in your game, so you are almost guaranteed to have terrible mismatches when trying this (and this is of course ignoring the fact that it wouldn't work with any type of clothing / restraints / accessories, unless .

And this is something even AAA-Games struggle with. For example: have you ever played Witcher3 ? there is a killmove that cuts straight through the torso. this will make one bodyhalf invisible and equip a bloody rim (this could be realistically reproduced). BUT: for the "cut off" half, it will always spawn in the same assets, which often leads to some horrible visual mismatches.

the reason for this is of course that they didn't want to account for the different body's/clothing.

 

And if a Giant company like them thinks its not worth the effort, I´m sure as hell not taking on the nightmare of doing it on my own, sorry. ?

 

Ah, I wasn't clear: I don't mean even trying to fake a cutting using duplicate bodies or other kluges. But leaving the body completely intact, putting a dark red decal (or something) along the cut, and then making use of a magical technology called "suspension of disbelief" ?.

 

Distinctly less than what one might hope for. But then a lot of things have been Good Enough faked that people are willing to accept the flaws in the simulation.

 

[buzzyxoom]

21 minutes ago, buzzyxoom said:

 

Ah, I wasn't clear: I don't mean even trying to fake a cutting using duplicate bodies or other kluges. But leaving the body completely intact, putting a dark red decal (or something) along the cut, and then making use of a magical technology called "suspension of disbelief" ?.

 

Distinctly less than what one might hope for. But then a lot of things have been Good Enough faked that people are willing to accept the flaws in the simulation.

 

This might be easier to justify if - instead of the sawmill - it were a magical furniture of some sort.

 

"The Soul Slicer".

 

But ultimately I'm just another person who has no idea how to mod, poking those who do. Feel free to tell me to buzz off ?

[z3r0]

On an unrelated side note....

Every single time I see Pamatronics name I get reminded on this gem:

 

[Pamatronic]

15 hours ago, z3r0 said:

On an unrelated side note....

Every single time I see Pamatronics name I get reminded on this gem:

Well, the name is actually derived from a relative´s electronics company, so, close enough

[Pamatronic]

On 7/7/2020 at 12:03 AM, buzzyxoom said:

Ah, I wasn't clear: I don't mean even trying to fake a cutting using duplicate bodies or other kluges. But leaving the body completely intact, putting a dark red decal (or something) along the cut, and then making use of a magical technology called "suspension of disbelief" ?.

 

Distinctly less than what one might hope for. But then a lot of things have been Good Enough faked that people are willing to accept the flaws in the simulation.

Nah, i dont know...

 

as you and z3r0 already mentioned, the maximum achievable quality would be sub-par.

And since there are a lot of other devices in the game which could be realized in a much more satisfying way, i think my time is better spent doing just that.

(I still want to make that enhanced "Bad Ends" at some point, but there are only so many hours in a day ?)

[Deadly Kitten]

This and other "functional" mods have become a must in my load order. Still need more quests to tie them in, but at least i could turn on DAYMOL or something and just end up dead. Lol. Appreciate the time you've spent on this so far.

[CeBlue123]

Hi pama thank you again. I tested your beat version and find some bugs:

 

1. collision bug:

 

1) the corpse has some possibility that still attach to the hole position after execution or simply launched away, or stucking in the guillotine and twitching.

 

2. visual bugs

 

1) the duplicated invisible victim still shows her feet or torso.

 

 

2) cut section of the neck on duplicated head might disappear. Till now i didn't find similar bug on the neck-body end.

 

 

3) a not really important bug: NPCs nearby might react to the invisible corpse, so it looks like they reacted to the air

 

3. the blade might disappear after you reset the blade. (I just reminded that I might be able to punch it again to fix it)

[Pamatronic]

@Erholung Thank you for your testing:

 

1. the collision Bug and stuck corpses.

This is caused by the collision geometry of the Blade part, and therefore is out of my control. t.ara knows about this and will hopefully make some changes in the final version

 

2. visible dupes and missing cut-section.

those seem to be caused by a race condition when the dupe´s 3D isn't loaded fast enough. This problem didn't happen to me during testing, since i only use the default cbbe body with the relatively small textures. But using larger textures or more complex meshes will increase the likelihood of this error occurring.

But i think i know a workaround for this.

 

3. disappearing Blade:

small oversight, already fixed

 

People reacting to invisible corpse:

yeah, not sure about that . i have to dump it somewhere, usually i would select a fixed point when placing it in the CK, but for the spawnable ones i have to assume they could be placed somewhere confined, so i have to dump it close by.

 

 

[CeBlue123]

1 hour ago, Pamatronic said:

@Erholung Thank you for your testing:

 

1. the collision Bug and stuck corpses.

This is caused by the collision geometry of the Blade part, and therefore is out of my control. t.ara knows about this and will hopefully make some changes in the final version

 

2. visible dupes and missing cut-section.

those seem to be caused by a race condition when the dupe´s 3D isn't loaded fast enough. This problem didn't happen to me during testing, since i only use the default cbbe body with the relatively small textures. But using larger textures or more complex meshes will increase the likelihood of this error occurring.

But i think i know a workaround for this.

 

3. disappearing Blade:

small oversight, already fixed

 

People reacting to invisible corpse:

yeah, not sure about that . i have to dump it somewhere, usually i would select a fixed point when placing it in the CK, but for the spawnable ones i have to assume they could be placed somewhere confined, so i have to dump it close by.

 

 

thank you for replying. then i think a new bug would also because of the handling speed problem. I think I have already known how it works: creat an invisible chopping block and let it handle the decapitation, use some tricks to get the actuall visual effect. the key process is the synchronisation of actuall beheading and the visual smokescreen, therefore I think the following bug was also caused by the handling desynchronisation:

 

I spawned 5 guillotines in Zbf test zone and after the execution i got really a mess, sorry I talk like this but the sence was way too hilarious ?

I guess due to the computer needs to handle so many smokescreens at the same time so it appears desynchronisation. I got visual body parts again and the decapitation of duplicated invisible victims get delayed or canceled, and these "souls" all were going to kill me for a revenge?, and it caused the heads appeared in weird postions. I guess that's because I killed too many poor girls simultaneously? and some of the guillotines won't work, simply no reactions when i put the release trigger. I guess for the same reason.

 

 

 

 

another weird bug is when I tried to punch the guillotine beam for its self-construction, the smokescreen seemed to fail again:

 

 

I think I got the reason why sometimes the route for NPCs using the guillotine was blocked. its was blocked by the invisible chopping block and the invisible corpse.

 

Thanks again for your great work. I'm just reporting these bugs and I don't want to push you or let you rush on the works! ?

[Pamatronic]

Oh boy, seems you really did some stress testing there.

 

since it uses an alias to handle the dupe, its not really designed to handle multiple executions simultaneously. using a slotting system to make that possible wouldn't be impossible, but i thought i would be a bit of a fringe case when used normally.

 

But in general, many of the visual problems on display here are caused by script lag. seems i have to increase the tolerances...

 

thank you again for going trough the trouble of doing this.

this is one of those system specific problems that simply don't occur for me, so im glad i have  someone who can get me a detailed report like this

[Surverx]

Nice!

[Evanness]

Hello, I ran into some minor problems with the chopping block.

 

When I use setfavorstate to assign a character to the block, the game only manages to find the executioner and not the executionerguard. It simply says "no link to executionerguard" regardless of how many npcs in the testzone (guard or not).  The animation would still play fine, just without the executioner guard. Everything works perfectly fine for my own character though, executioner and executionerguard are found quickly.

 

 

[Pamatronic]

@Evanness when assigning a random NPC, the script will always try to register your current follower as the executioner Guard.

so do you maybe have an active follower somewhere outside the current cell?

 

another possibility would be that the NPC which got assigned as the Guard was sitting on a chair at the moment. (slight side-effect of allowing for multiple successive executions)

if you tried this in the testzone, try removing the chairs first.

[Evanness]

1 hour ago, Pamatronic said:

@Evanness when assigning a random NPC, the script will always try to register your current follower as the executioner Guard.

so do you maybe have an active follower somewhere outside the current cell?

 

another possibility would be that the NPC which got assigned as the Guard was sitting on a chair at the moment. (slight side-effect of allowing for multiple successive executions)

if you tried this in the testzone, try removing the chairs first.

Hi Pama, thanks for the rapid response.

I did not have any follower at all when I tested, I simply spawned like 5 guards and executed one to see if it worked properly. Using the same method, I tried again with one follower, and then several followers, but it stills show the "no Link to executionerguard" text when an actor is sent to the chopping block. I'm guessing the script attempts to locate an executionerGuard but fails to find one for whatever reason.

But if it was the player's character, then the executionerguard would be located almost immediately, after around 3 attempts at most.

[zergface]

Is this SLE only? or it works with SSE aswell?