Stopping the Splat (preventing 'falldown' anim)

I'm scripting up some fun jumping behavior for my avatar, and I'm uncertain of how to proceed. Launching myself through the air at various trajectories and velocities is no problem, it's the landing - the 'sudden stop at the end' so to speak. How can I keep that blasted 'falldown' animation from playing when I hit the ground moving fast? I can reliably detect the point at which I *hit* the ground, and I've already tried llStopAnimation("falldown", no dice. I am aware that I can just create a custom animation with the priority jacked up to override it, but I don't think that's sufficient: even if the animation were overridden, it seems like the Sim prevents you from moving while the animation's playing.

So as far as I can tell, I need to prevent the animation from triggering in the first place. I've got some ideas, but I don't like them and I was wondering if an elegent solution has already been found so I don't waste my time finding it over again. My best guess right now is to use a quick-firing timer to constantly monitor my distance above the ground, and drop my velocity with llApplyImpulse at the last moment. Of course, if the sim lags while I'm hurling myself through the air it's likely that I'll splat against the ground anyway.

So how 'bout it? Any ideas?

P. Spoonhammer

Does the sim disallow movement because of the animation, or beccause of the impact? I suspect the latter, meaning no amount of messing with animatiosn will avoid the need to cease moving temporarily after a fall.

That's exactly what I was thinking, I just wasn't terribly clear I suppose. So my best guess right now for preventing the impact is nulling out my velocity with llApplyImpulse just before I hit the ground, so that when I *do* hit the ground I won't go splat. But I can't think of a reliable way to trigger that impulse at exactly the right time, so I was hoping somebody had been there and done that, so to speak.

P. Spoonhammer

I'd planned similar by checking the distance from the ground and using complex mathematical equations to deal with it. Though, I'm a newbie scripter and never managed to get it to work, I think it was dealing with the actual ground height, and so wouldn't work with prim ground (say, the roof of a building). I guess you could shoot a prim downwards and see if it collides with anything, then compare the distance between the prim and yourself, but I'm sure there's a better way of doing it.

It might actually be due to the former, as ridiculous as that might sound.

Way back when we were playing with animation overriders, we found that if you played a looping animation that overrode your falldown animation, you'd just get stuck indefinately.

If you check the animation overrider I released, it actually starts a clock when it starts overriding a falldown animation, and after some amount of time (3 seconds?) it stops the animation explicitly. That's just to get around this "stuck forever" problem.

The only non-hack solution I can think of off the top of my head is to sit in a vehicle, instead of bouncing your avatar around. Let me know what you come up with, I'm curious myself

Oy. Which would mean explicitly coding logic to do walk/turn/run and play all the right animations, essentially reimplementing the standard movement behavior as a vehicle. I really don't want to do that, but if it comes to that I may - having such an implementation would come in handy in a number of situations. Another pet project of mine also requires this in order to be really useful (the old gigantic-moving-ship problem).

Well, I may end up doing that, but I'm going to try some other methods first. Right now, I have a predefined 'trajectory' vector which I just scale by a factor related to how long you hold down 'up' before releasing it, and that determines the impulse you get. Nice and simple, but it's pretty hard to guesstimate the length of time to hold in order to jump to a particular location. So instead, I'm going to try to do a 'jump-to-target' sort of thing, where you pop into mouse look and just stare at the bit of ground/prim/whatever you want to land on, and some math takes care of the rest. If I do it that way, I'll know the landing point before hand, and can use llTarget or some such to trigger my velocity cancellation. If I can work out the math, duration of time that 'up' is held could determine height of the apex of your parabola through the air. I suspect this will take some experimentation...

P. Spoonhammer

There are animation states behind actions. When you falls down from some height, the animation state changes like that "Falling Down" -> "Standing Up" -> "Standing". And we have no way to stop performing the states.
I'm not sure how you did, but if you used some event, such as moving_end and abruptly stopped your animation with using overriding animation just when it landed, the state might be stuck at "Standing Up".

Using llTarget() would work if you could calculate ahead of time where your point of impact was going to be based on your trajectory. Of course figuring out objects and landing points ahead of time is kind of complicated. The best idea I can think of is, as suggested earlier, you fire a prim ahead of you to figure out if there are any things you'll hit. If you could make a prim that's the same mass as your avatar and launch it at the same force in the same direction ahead of your avatar, it would collide with anything in your path and give you a reasonable indication of where you'll splat. Then you need a corresponding llListen from the time you launch the object to the time you hear something from it. Then you know where abouts you'll hit and can set a target appropriately to slow/stop you.

Hey now, that's an interesting idea. I'm not going to get my hopes up until I try it, but it might be crazy enough to work most of the time. And in that case, I don't even need to mess with llTarget(). As long as the prim in question is the right distance away from me, I can decelerate myself as soon as I receive notification that it's slammed into something. Even better, I'll know the difference between ground and prim, and can probably even get surface normals and such, which would let me do all kinds of cool things with custom animations depending on what I hit (slam into a near-veritical face, play an animation that has me twisting to take the impact on the feet, and springing backwards, for example). I doubt this is anywhere near air-tight, but the occasional failure is no big deal - even olympic gymnasts face plant every now and again

I'm at work and I'm lazy - anyone have a quick link to how the mass calculations are done for the various prim types so I can rez an object that will be the same mass as my avatar?

P. Spoonhammer

Believe it or not, I'd actually suspect that the sim disallows movement due to the falldown animation being played. There's a precedent for this kind of thing: llGetAgentInfo() will tell you the agent is typing using the AGENT_TYPING stauts, but if you stop the typing animation in order to start another replacement animation, AGENT_TYPING goes away immediately.

This may not be how the falldown/gluedown thing happens, but for the sake of completeness, I'd try stopping the animation as well as overriding it with a priority-4 animation. See if that disguises the front end of the animation that plays before you can llStopAnimation() it, and then see if stopping the falldown animation lets you walk sooner.

FWIW, in a controls-based AO I wrote recently, I actually detect the falldown and stop all of my custom animations that might override it, allowing the splat to happen. That's because I like the look of the splat. I use changes in AGENT_IN_AIR from llGetAgentInfo() to detect when a splat might be happening, and then llGetAnimationList() to detect whether the splat is actually playing, which seems like a more efficient way of doing it than actually calling llGetAnimationList() repeatedly.

Interesting. Have you ever successfully stopped the falldown animation? Because that's the very first thing I tried, and the animation did not stop. I was not actually verifying with llGetAnimationList that the animation was playing (just had an llSleep() that I figured would give it enough time to start) though, so I'll give it a shot again with some better debug output so that I'm sure of what's going on, whether it works or not.

P. Spoonhammer

Ok, had some time to experiment. First off, the animation that I want to stop is not, in fact, 'falldown.' It's 'standup.' Hopefully my mistake there wasn't too confusing. I have tried llStopAnimation("standup" after checking to verify that the animation is playing in the first place, and the animation does not stop. Unless someone knows otherwise, I'm going to assume that the animation cannot, in fact, be stopped. This surprises me a bit I suppose.

So, I'll move on to firing a prim along my anticipated flight path and using it to find out where I'm going to land. I'll report back with results.

As I said, you are stuck in the animation state, not the animaion. You can never control the state by any function.
It happens according with how you try to override animations. I've experienced it when I used moving_end event, but I don't know how you're doing.

For anyone who's interested, it appears that mass is meant to be in the ballpark of 10 * prim volume. I say in the ballpark because it's usually significantly different from what it should be if that formula actually held. Presumably prim volume is approximated with sort of witchcraft or voodoo magic?

This avatar on SLExchange says it has an animation overrider that causes you to crouch instead of splat on a fall:

http://www.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=63935

Yes.