Many flight assists rely on llSetBuoyancy(1.0) to keep the avatar hovering above the false flight ceiling. Release of Havok4 with this bug would affect thousands of MystiTool users.

However, it still exists at low altitudes for some avatars - low altitudes such as 20-50 meters. Even when I detach ALL attachments and relog, ensuring that my buoyancy was set to 0.0 first by my last attachment, I still drift slowly downwards at low altitudes.

I have one relatively clean testing alt (only has worn MystiTool in her life) which does not exhibit any of these problems. Could this be the result of some scripted effects persisting even after "Detach All" + relog?

In any case, an avatar should not drift downward at low altitudes after removing all attachments and relogging.

test script ....

integer Toggle = FALSE;

default
{
state_entry ()

touch_start (integer num) {
Toggle = !Toggle;

if (Toggle == FALSE)

else

}
}

put the script in a prim. when touched.. the object should turn physical... and neither sink nor float... but
remain neutral. Place the object at normal ground height.. somewhere around 20 meters high.
Now... if you touch it... it's behavior seems rather erratic. When standing on the prim above which the
item is placed.. the item sometimes floats up to a certain height.. and then may stay there.. or sink back
down again. When 'flying' in place next to it, it often will remain in place.. not floating or sinking. This applys not only to the owner.. if someone else moves near it while not flying, it often will start floating up
again. If the prim isn't over another prim... but over land or water... it will not float up when activated. If a prim is created beneath it... it will not raise or sink.. but if you move the test object over the new prim, and
are standing on the new prim beneath it, it will become erratic again (sometimes sinking.. sometimes floating), when activated. These effects are also not consistant. The one constant seems to be that
llSetBuoyancy(1), is completely erratic now, and no longer produces the effect of 'neither sinking nor
floating' in a physical prim in world. This has a major effect on lifestyle elements and products
throughout the world, including my personal item, free roaming physical swimming fish.

Please please please.. someone give us consistant neutral buoyancy in physical items back.

Hell no, it's not resolved.
Please see the two test scripts.

Well, the only good thing about this is that unlike SVC-2013, you didn't partially fix this one with a z movelock, so llApplyImpulses seem to work. But this bug is still far from being resolved. The second test script is specially problematic.

Both problems can now be tested with that one script.

buoyancy, impulse, and flying vs not flying are whacked.

i have a rideable creature that bobs up and down on alternating animation cycles.

1: buoyancy routine:
llSetBuoyancy(-1.2);
alternating with
llSetBuoyancy(1.2);

this works when the avatar is standing. it does absolutely NOTHING to the avatar height when the avatar is in fly mode (not moving).

2: impulse + buoyancy routine:
llSetBuoyancy(1.0);
llApplyImpulse(3.0, FALSE);
alternating with
llSetBuoyancy(1.0);
llApplyImpulse(-3.0, FALSE);

when flying, this works to bob the avatar up and down, though with slightly more 'up'ness.
if you press the Stop Flying button, you get a LOT more 'up'ness and start to rise faster. shouldnt you be more likely to FALL if not flying? i'd think so. (this routine is applied when AGENT_IN_AIR)

note, when flying forward (or 'falling' forward) no change in buoyancy/impulse force was noted.

[2008/11/03 18:15] Simon Linden: (Saved Tue Nov 4 02:08:23 2008) I have passed the bug internally to another developer, so hopefully it will get some attention

After that I sent three IMs and one notecard to Simon to try to know the name of that developper, so that the 48 other voters and 7 other watchers of this bug here can get a better idea of what's going on, but all I got as a reply is :

[2008/11/04 18:05] Simon Linden: (Saved Wed Nov 5 04:31:07 2008) Hi everyone
[2008/11/04 18:05] Yukinoroh Kamachi: ... wrong window ?
[2008/11/04 18:05] Second Life: User not online - message will be stored and delivered later.

So, I don't know what to think about what Simon told me... It looks like this bug is still in limbo. I'm hopeless.

Someone is playing with the maths, when they really need to look at how it was implmented.

Every fligh assist i have either floats up or down under havok4. Their are laggy work-arounds but it is much better to just fix the function.

Yes, that's really annoying. It's so long time till this is reported, Lindens, could you pleeeaase put this in between of your other tasks to be done and fix this eventually? Thx

Andrew stop messing with graverty. I know that Q from star trek could alter the gravertational constant of the universe, but you are not Q. So put it back where it should be. The the flow on effect breaks every other physics function that relies on this universal constant! What were you thinking? honestly? Altering graverty?

Messing with graverty is not the answer to people falling through prims. there was a point in havok4 when we could tunnel through prims by moving fast, elevators didnt turn phantom to the avatar after too many collisions, and flight assists didnt drift. Then somone yelled griefer about an old orbit cage and elevators got broken in an attempted fix, followed by fligh assists and god knows what else.

If you want to alter somthing, remove the silly 200-300 meter limit on flying. It was created in the early days of SL to keep people close to the ground for social reasons. We have millions of people now so it is not needed. Removing the flight limit will remove the need for flight assists. Think of all those flight assist scripts that can be removed and the lag that will be removed with them!

(noted that some people will use super speed flight assist scripts, but at least we dont NEED them which is the case right now)

Darling Brody.

Why not use laggy work-arounds for things that could be so easy. To let run lot of residents heavy timer scripts shouldn't be any problem for the underchallenged server performance.