Damage and Destruction: Part6 - Player Bits and Pieces

If you look within the Player datablock you'll notice these fields

debrisShapeName = "art/shapes/actors/common/debris_player.dts";
debris = playerDebris;

The PlayerDebris datablock and the debris_player.dts have been passed down through engine iterations ever since Tribes2, they've just been unused. They are to be used in order to "blowup" a player into chunks/gibs. Back in Part 2 of the Damage & Destruction series of Resources I demonstrated how to make use of a Debris Object when an object is destroyed and how it was different from the Explosion Debris. In response to a couple of questions on the Forums we noticed that this feature for the Player wasn't usable like it was for other Shapebase derived classes. This functionality is technically applicable to all ShapeBase derived classes, however the Player class overrides the inherited damage state control so that the Player class has no idea of the destroyed state sequence which can trigger an explosion and object breaking apart (simulated by debris).

I wanted to make this feature usable once again. Instead of rewriting the Player's damage state handling to follow that of the ShapeBase methods and have a suitable onDestroyed callback, I felt that it would be easier to simply make the Shapebase blowUp() method available to be used within script. This way you retain all forward/back functionality of the Player in your projects after applying this Resource. This gives us a practical demonstration of how to make use of that unused and undocumented debris_player.dts shape.


In shapebase.h find virtual void blowUp(); and move it down to within public: space instead of private:

In shapebase.cpp lets create our new console function which will allow us to call blowUp() from script. You can place it at the bottom of the file or located near all of the other damage/energy methods.

DefineEngineMethod(ShapeBase, blowUp, void, (),, "@brief Explodes an object into pieces.")
{
	object->blowUp();
}

Recompile.

Now in script, assuming a Full Template (or derivative project), we'll be looking at scripts/server/player.cs as well as making use of the aforementioned PlayerDebris datablock and player_debris.dts shape.

For a quick and simple demonstration let's introduce a modification to Armor::damage() where we will check for the Suicide damageType and blow the player into chunks. I placed the following within the if(isObject(%client){...} statement:

if(%damageType $= "Suicide")
{
   // This guy went to bits and pieces!
   %obj.blowUp();
         
   // Hide the player object.  onDisabled() will do further cleanup.
   %obj.startFade(50, 0, true);  
}

Save the script. Start the game, jump in a mission, and hit Ctrl+K to kill yourself: witness the body parts fly everywhere! Literally. The stock properties of the PlayerDebris datablock sends these things flying!

Just throw in some blood particles and maybe a bloody decal and you can make the effect look even better!

You could call blowUp() when a certain amount of excessive damage is taken in one hit, or upon a specific damagetype. I've written an Improved PlayDeathAnimation Resource that I think would be a great place to drop a player blowUp() call into. You could even use it as an admin option against naughty players! And of course you should modify the PlayerDebris datablock to your liking.

The player_debris.dts shape looks nothing like the soldier's bodyparts, and is untextured as well, but it will do for demonstration purposes. Check it out for an example of how to setup your own player debris shapes.

Quote: from Rex of BrokeAss Games:
The first boulderDebris.DTS [...] seemed to have some trouble 'breaking apart'. I think this was due to the shape's hierarchy. My first sample had a totally 'childless' chain in the hierarchy, or what I refer to has a 'flat' hierarchy; there is no 'parent' node in the Scene[or each node is a parent with no children]. This sample file didn't break up upon 'explosion'|'blowup', you got one single piece of geometry in the effect [...]

For the second sample [...], I changed the hierarchy slightly. I left the 'Root' node in the object to act as the 'parent' node and all of the geometry nodes were child nodes of the 'Root'. This seemed to give the shape it's needed hierarchy to 'explode' into fragments. I used Milkshape3D to export the DTS shape and with that exporter, you get a generated node for each piece of 'rigid' geometry[that geometry weighted to a SINGLE node influence]. I am not sure if a 'skinned' mesh object will act as a 'fragment' or not; the geometry may need to be 'rigid' or at least an 'object' in the shape's properties....sorry to toss some art babble into the code discussion, Michael, but I think it part of the exercise.