Advice required - Players glide until a trigger is activated then animate properly

#1 Have you tried spawning them with a z + 0.05 or so?

#2 I see this "occaisionally" and have never quite worked out why. Try moving the spawnpoint/node/marker up so they drop on to the ground more and see if that makes a difference (no promises).

[edit] Chris types faster! :D

#3 This could be a networking issue - it deals with triggers and animation.
Try running with TORQUE_DEBUG_NET and TORQUE_DEBUG_NET_MOVES.

#4 I have this same issue, suddenly. Can't point at a cause though, it didn't pop up in the previous two but seemed to start happening after I moved the spawn point. Moving the spawn point again hasn't seemed to clear it up, and since adopting the habit of hitting the space bar on zone in, I stopped seeing it (that's bad isn't it? Bad developer bad!)

I'll try those suggestions later.

#5 I'm still having this issue, although spawning has changed completely since I first saw it (with the stock code base) as fixed spawn points are no longer in use in my game (after modifications).

I still get the stuck, non-animating player model. Non-player characters seem to enter their animation loop immediately on spawn.

I have tried spawning vertically higher, lower, and sideways (as best I can manage) and my player still "skates" when they hit the ground--moving but not animating when movement keys are pressed. Ivan's suggestion is still a little over my head at the moment.

I thought it would do little harm to necro the thread and see if anyone has figured out what causes this in Beta 3, as I did not see it in 1 or 2.

#6 When you spawn, try adding (maybe with a 50m/s schedule or something)

%this.settransform(%this.getTransform());

And yeah ... I know that sounds stoopid, but see if it makes a difference.

#7 If I'm not mistaken, this bug caused by this:
http://www.torquepowered.com/community/forums/viewthread/121225

Try reverting and look if that fixed your issue.

#8 Yes,currently this fixes the script setactionthread calls,but breaks the c++ ones for the Ais. I found this today.
A simple solution is to revert the changes and define your script animations to be after NumTableActionAnims in your TSShapeConstructor.
The c++ called sequences should be before NumTableActionAnims.

#9 Thanks for the suggestions, Steve and Fyodor. I implemented them both last night when the day quieted down, but I am still stuck in a glide until I hit the spacebar and invoke the "jump" animation, at which point the run animation will operate as normally expected.

I think I'm going to have to install a clean Beta 2 and a clean Beta 3 and go through the player.cpp file and the afxspawn.cs file from those versions with WinMerge to see where they differ exactly from what I have written.

Must be making some progress though: I can almost interpret what Ivan just wrote! :)

Thanks again, all.

#10 Also, try adding
mJetting = false;
to the Player constructor as this is initialized to random garbage in stock T3D and can cause problems as it's used in the action animation selection routine.

#11 Thanks Guy--after looking up "constructor" to verify you meant what I thought you meant--I put your suggestion in what I believe was the correct location (Player::Player() in player.cpp) as well, but still no go.

Tomorrow I should have time to pull Beta 2 up again and will attempt to determine the difference between the player.cpp files, else I shall file this under "currently unsolvable" and come at it again at a later date.

#12 I think I have found the problem.
For those who still see floating players above the terrain,try this:
In Player::updateActionThread() locate this

if (mActionAnimation.action == PlayerData::NullAnimation ||
       ((!mActionAnimation.waitForEnd || mActionAnimation.atEnd)) &&
       !mActionAnimation.holdAtEnd && (mActionAnimation.delayTicks -= !mMountPending) <= 0)
   {
      //The scripting language will get a call back when a script animation has finished...
      //  example: When the chat menu animations are done playing...
      if ( isServerObject() && mActionAnimation.action >= PlayerData::NumTableActionAnims )
         Con::executef(mDataBlock, "animationDone",scriptThis());

    pickActionAnimation();
   }

and replace with this:

if (mActionAnimation.action == PlayerData::NullAnimation ||
       ((!mActionAnimation.waitForEnd || mActionAnimation.atEnd)) &&
       !mActionAnimation.holdAtEnd)
   {
      //The scripting language will get a call back when a script animation has finished...
      //  example: When the chat menu animations are done playing...
      if ( isServerObject() && mActionAnimation.action >= PlayerData::NumTableActionAnims )
         Con::executef(mDataBlock, "animationDone",scriptThis());

    pickActionAnimation();
   }

In pickActionAnimation() locate this:

if (mContactTimer >= sContactTickTime) {
         // Nothing under our feet
         action = PlayerData::RootAnim;
      }

And replace with this:

if (getControllingClient() && mContactTimer >= sContactTickTime) {
         // Nothing under our feet
         action = PlayerData::RootAnim;
      }

Hope this helps.

#13 Thanks, Ivan, for putting that up. The problem still persists, for me at least, though. I don't know what's causing it (obviously), but picking over the player file in my spare moments over the last couple weeks has been beneficial in and of itself.

It's not so much that the player is "floating"--it's that he's locked into the last frame of the drop crouch position, and moving forward isn't triggering the change to the run sequence until some other animation sequence is played--in my case, I press "space" to get him to jump, and then the run sequence triggers normally on forward motion.

A question for you: on line 3 of your pickActionAnimation() replacements above, is "basicPlayerData" an internal variable of your own definition? In the engine as shipped, it seems to be "PlayerData" which is named.

Thanks again.

#14 Actually this fix is for the AIs,not the player.And it works for me.
It seems your problem deals with the 'hold' animation flag.
When you press space,the jump code will call setActionThread() directly and will handle the new sequence,this is the reason why it works.

Also pay attention if your animation is marked as non-cyclic.This can be a potential problem.

Your problem happens in updateActionThread()
This is the place where pickActionAnimation() is called.
When your player is floating,put a break point right before the call,where the animation flags are tested.This will show you why pickActionAnimation is skipped.

#15 @Guy:
Thanks for pointing out the missing mJetting. I've created ticket THREED-1415 and have put the fix into 1.1 Final.

@Ivan:
Are you sure you want to remove

(mActionAnimation.delayTicks -= !mMountPending) <= 0

from your pickActionAnimation() check? That is used to make sure that the Player doesn't switch to a different action animation sequence if its mount hasn't yet come through the network.

I've hit that before when I create a mount (like a toboggan) and immediately mount the Player to it. It can take a couple of cycles before the client receives the mount shape.

- Dave

#16 This code works well for the player,but is causing troubles with the AIs: floating AIs,wrong animations ...
When I removed that code all these problems disappeared.Since I am not using mounting in my game,this is not a problem for me.
This problem still need a further investigation.

#17 I still see it in my initial player spawns, but I have noticed I don't see the refusal to shift from the idle to a running animation if the player is later "moved" by moving the camera and spawning again with the F8/F7 keys.

#18 try unmounting a vehicle without pressing forward.

you unmount next to the vehicle in a sitting position till you fire a shot,
or move in any way,
then you go to the active animation.

this is with or without the above fixes.

the fixes dont go to this area, I dont even know where that area is, no-one does, it seems.....

#19 @deepscratch:
Did you try my fix in this thread: www.garagegames.com/community/forums/viewthread/123711 I know I initially mentioned multiplayer only, but I later back pedaled and said it may also work with single player. What you're describing is exactly what I also saw, and would recommend you at least give the fix a try. Or, wait for 1.1 Final. :)

- Dave