activating "crouch" and "prone"?

#1 At a wild guess, an FSM?

0 = stand, 1 = crouch, 2 = prone, default = 0 etc

#2 Look at where fire is bound to increment $mvTriggerCount0...
Likewise altFire ($mvTriggerCount1), jump ($mvTriggerCount2), then you should similarly bind some key for crouch to $mvTriggerCount3 and prone to $mvTriggerCount4.

#3 All post like these need to be added to the how stuff works sticky, kudos and thanks.

#4 Hit mvTriggerCount [3] & [4] which would call the correct pose in code, maybe?

EDIT: Oh, already answered... should refresh more often :D

#5 I've added the following to default.bind.cs :

function goCrouch(%val)
{
   $mvTriggerCount3++;
}

function goProne(%val)
{
   $mvTriggerCount4++;
}

moveMap.bind(keyboard, b, goCrouch);
moveMap.bind(keyboard, v, goProne);

Crouching works so mvTriggerCount[3] is definitely working, but prone is just not playing. Any thoughts?

#6 My only idea is that perhaps you don't have a sequence called "prone_root" or if you do it isn't loading properly?

#7 You're right! I am just using gideon for testing and there is no prone_root. There is prone_EnterFromCrouch and Prone_Forward but no Prone_Root.

Problem solved! Kind of. Should he have a Prone_Root sequence?

#8 Um, im not sure why he would have a prone_EnterFromCrouch, but you can rename it to "prone_root". It might even be possible to do that from the Shape editor, otherwise you need to create a TSShapeConstructor for Gideon and do it with the help of its methods/fields.

#9 I was in the middle of making that change actually! Well, sort of. I just made a copy of the Prone_Forward sequence and named it Prone_Root from the shape editor giving the following in base.cs:

function BaseDts::onLoad(%this)
{
   %this.addSequence("Prone_Forward", "Prone_Root", "0", "11");
}

If I'm stationary and hold down the prone key, nothing happens. However, if I'm moving forward it does work (and if I stop moving forward while still holding down the prone key he stays prone):

#10 That's something I've been meaning to hook up in the FPS Kit, it just always slipped my mind... glad to see that it is working.

It is kind of problematic that Gideon doesn't always follow the standard that's been long established in Torque when it comes to player models.

#11 Feel free to keep playing around with this. There is probably a simple explanation.

Since I don't have time to fully debug it right now I'll log it for later if it turns out to be a problem.

Logging: Verify crouch and prone working correctly THREED-641

#12 sorry to ressurect, but does anyone know how to make a "toggle" version of this? toggle on or off crouching/proning?

#13 Probably something like this.

function toggleCrouch(%val)
{
   if ( %val )
      $mvTriggerCount3++;
}

moveMap.bind(keyboard, b, toggleCrouch);

Or even better support both.

function onCrouchKey(%val)
{
   if ( $toggleMode && !%val )
      return;

   $mvTriggerCount3++;
}

#14 Yes that worked great! Thanks =)

#15 "If I'm stationary and hold down the prone key, nothing happens."

i think that is because of non cyclic root animation.
%this.addSequence("Prone_Forward", "Prone_Root", "1", "11");
could fix the problem.


" There is prone_EnterFromCrouch and Prone_Forward but no Prone_Root."

where?
i just have searched all t3d version that i have.
no where i found any prone animation !!!!!!!!!!

#16 do the collission boxes alter when the player is prone or crouching?

i am not seeing any change of collision box during those animation on shape editor
or
that do not happen in shape editor?

#17 Each of the different poses have different bounding box properties on the PlayerData datablock:

• boundingBox
• crouchBoundingBox
• proneBoundingBox
• swimBoundingBox

So no, you don't set that up using the Shape editor. In fact, any collision defined within the shape file is ignored for the Player class. Everything comes from the PlayerData datablock.

Something to be aware of is these bounding boxes are world aligned boxes, not object aligned. So they do not rotate with the player. For standing and crouching this may not be much of an issue as a vertical cylinder shape is usually fine. But for prone and swimming you end up with a bounding box that is always much wider than the player.

- Dave

#18 Something else to keep in mind - you can't reliably derive datablocks from children of other datablocks. For example:

datablock PlayerData(BoomBotData : DefaultPlayerData)
{
    shapeFile = "art/shapes/actors/boombot/boombot.dts";
    boundingBox = "1.1 1.2 2.5";
    pickupRadius = "1.2";
    shootingDelay = 2000;
};

datablock PlayerData(MiniBotData : BoomBotData)
{
    shapeFile = "art/shapes/actors/minibot/minibot.dts";
    boundingBox = "0.5 0.5 1.5";
    pickupRadius = "0.8";
    shootingDelay = 1000;
};

This might work, and it might not. Best bet is to avoid this altogether. Just thought I'd throw that in there - caused me fits a few times.

#19 Any idea why that's going on? Could it be the order datablocks are loading in?

#20 @Richard:
That shouldn't be the case as it is just a copy operation. If you can find a reproducible case, feel free to post a GitHub issue. :)

- Dave