This makes me wonder if the jump points in Suffugium will ever work in havok 4

It's significant to me that your methodology is "wearing an object that records the first time the horizontal velocity gets above 1m/s"... is it possible that the velocity change is not instantaneous for an avatar like it is for a prim? What I mean is, if you record several data points for each fall, does the velocity go any higher and settle on 10.0ish, or is it definitely sticking in these distinct bands?

I just did the test again, recording horizontal velocity on a while true loop in another attachment prim. I was expecting it to be constant whilst in freefall at the same horizontal velocity as the initial one just after the push.

It isn't, although it's not increasing to 10. It's decreasing over time. I get a bunch of readouts in a row of the same velocity value (presumably taken within the same physics frame, or at least between hits of whatever mechanism is damping things), then a bunch more at a lower value. The values go down each time by about 0.06, which handily explains the bands I saw before: we were getting some damping in before I see the first velocity. It doesn't quite explain why sometimes the initial velocity was a little bit higher than 10.0, but that must be a separate issue.

Anyway, the damping behaviour is trouble for anything needing to know the paths of avatars falling through the air. If we knew what the mechanism was and that it's deterministic, then we could work around it, but the behaviour really should be the same as for prims.

Maybe we're dealing with some kind of friction-like force here. I know in havok1, at least, there are some pretty quirky behaviors of avatars, especially if they're flying. I think a friction-like damping is an integral part of how LL controls an avatar's movement.

I hope they'll remove this friction while falling, though. It'll make things like your transporters and Suffugium's jump points MUCH more difficult. The jump points were already pretty difficult because they calculate their velocity using a trajectory formula that involves solving a quadric polynomial. Add in this bizarre friction, and it'd be nearly hopeless.

For Lindens reading this and debating whether or not to keep this friction, visit Suffugium, fly up to the rooftops, and walk over an arrow sigil spraypainted onto the rooftop. You'll find your avatar (no matter your mass) precisely tossed to a matching sigil on an adjacent building. If llPushObject() doesn't behave in a consistent manner that we can understand and code for, then we don't have a hope of keeping cool content like this.

The damping isn't just llPushObject. It also messes up a different project that uses llApplyImpulse to an avatar.

If there is some sort of constant damping term then as long as it really is constant, you get a different differential equation to solve, which should still be possible, but I really don't want to have different code depending if the object is an avatar or a prim...

////Script 1:
/////////////////this just spits out your velocity as frequently as possible
default
{
state_entry()
{
while(TRUE)

}
}

////Script 2:
///////////////when touched, this gives you a push to cancel your current velocity, and set it to <10,0,0>
default
{
touch_start(integer total_number)

}

To test, wear the attachment, fly up to some height, stop flying to go into freefall, then click the prim to give the push to set your velocity to <10,0,0>. After a second or so, stop the readout script from running. Then you can scroll back up the debug chat and see how the velocity changes. In particular, the horizontal velocity is damped in Havok 4 for avatars (but not prims). In Havok 1, horizontal velocity is not damped, at least for low speeds.

Without consistent avatar friction the announcers spend a lot of time pointing out things like Second Life is still in beta And when something works the way it was intended everyone is Greatly surprised because 9 times out of 10 it doesn't.

If you look at the archived races before Havok 4 on http://slcn.tv you can see the dramatic changes.
from consistency to anarchy in the latest races

We have an estimated 5,000 or more viewers watching the snail races every week.
You may want to fix this so we can start praising you again instead of you being the butt of a lot of the jokes.

How many votes do we need to get someone assigned to this? I'm sure I can get them.

CritterBall-- a game of tiny soccer with a huge soccer ball. The ball simply doesn't roll as it did under Havok 1. Very hard to push it, and once the push ends, the ball pretty much stops rolling. Hard to play soccer when the ball doesn't roll.

Ork Invasion-- a game of "shoot tinies across the sim to divebomb the orks"... the push stops anywhere from 50 to 120m. This is a shame, because it was one of our main tiny attractions.

Again, don't know if it's the same issue, a related issue, or a different issue, but push factors and "roll" factors just seem to not be working in Havok 4.

However, there seem to be a couple of other things going on as far as I can tell:

1) The vertical velocity I get from llPushObject never seems to be quite enough to get me where I want to go. Of course the velocity starts decreasing immediately so it's hard to tell if it would be at the desired speed but only for a physics frame that a readout script never has time to report on, or if it isn't pushing as hard as it should. I think it still isn't pushing as hard as it should in the vertical direction, because I consistently fall under my target (as calculated assuming a parabolic trajectory). Hm, I haven't checked to see if the value of g has changed from 9.8m/s^2, that would cause this problem too.

2) There seem to be some "ground effects" that are stronger than in havok 1. In havok 1, once the avatar is lifted off of the ground, and assuming the user isn't pressing any keys, the avatar behaves like an object in freefall. Currently, a fraction of a second after being lifted off the ground by an initial llPushObject and then pushed by the main llPushObject the avatar often stops dead in mid air and falls to the ground. This never happens if I am flying, stop flying to go into freefall then hit the main llPushObject.

I think this second issue is probably the main one affecting RacerX's use.