|
|
|
[
Permlink
| « Hide
]
Harleen Gretzky added a comment - 04/Sep/08 04:21 PM
Can you give examples of content that is now broken by this?
Edit:
>> The most noticeable is buoyancy. A buoyancy of 10 should send any prim high into the air fly upwards, but on a physical 10x10x10 it falls to the ground like a heavy rock. I can repro this. Even a 5x5x5m prim is enough. With buoyancy of 10 it flys some meters up and then falls down. This is a bug. And I tested llMoveToTarget(llGetPos()+<0.,0.,50.>,1.);. Even with a 5x5x5m prim it doesn't work/move anymore. There are many decorative vehicles such as trollys that use llMoveToTarget to achieve a smooth movement effect that also can move people around between places. Most of these are fairly large and therefore cannot function anymore. Even basic movelock on avatars doesnt behave as responseively with this change.
To give better detail of scope, it seems that any physical function that requires a force to be applied each frame, does not behave as expected under the new changes. The original object was a large hemisphere platform that used to float up and down very slowly using the move to target function, it had to be made non physical because it fell to the ground and rolled off sim. Ok, this explains some of the strange content behavior I've been seeing. Voted.
I wondered why emDash's /gravity tool changed without me touching the code. Voted.
emDash was the first content I was thinking of.
I really really wish Havok 4 had been properly cleaned up before Mono was tossed into the act. This looks like an energy issue ... my initial experiments aren't showing any difference between 1.23 and 1.24, but a 10x10x10 (or 5x5x5) cube using llMoveToTarget() just won't get to the goal and stay there.
BTW, here's a hint for builders: call llApplyRotationalImpulse(<0,0,0>, FALSE) any time you want to re-set the energy level. It's a residual bug from Havok1 days that I had to re-implement in Havok4 to prevent breaking content. I really hope we can get rid of the #$@ energy system someday. I'm not sure how we can do that without breaking stuff, but it's a pain. FYI I ran some tests - made two 5x5x5 physical cubes.
Cube A has the script: integer floating = 0;
default
{
state_entry()
{
}
touch_start(integer total_number)
{
if ( floating == 0 )
{
llSay(0, "Moving up");
llSetBuoyancy( 10 );
floating = 1;
}
else
{
llSay(0, "Off");
llSetBuoyancy( 0 );
floating = 0;
}
}
}
Cube B has the same script but uses llMoveToTarget( llGetPos() + <0,0,10>, 0.5 ); instead of llSetBuoyancy() I tried them on 1.19.2 Server (Havok1), 1.23 Serer (Havok 4, pre-Mono) and 1.24 Server (Mono). Both cubes behaved the same - they would rise a bit, then fall back to the ground. If you add a timer and a call to llApplyRotationalImpulse(<0,0,0>, FALSE) it works the way you'd expect (the buoyancy cube goes through the roof, etc). I realize that's a hack, but might be useful for builders. Can someone point me to an object that is definitely behaving differently? Sorry, I did not know that the 'physics functions don't work at high masses' problem is a pre havok4 one. Unfortunetly I don't have old differently behaving stuff.
But would be nice to make llSetBuoyancy/llMoveToTarget etc. run on any objects regardless their mass. Thanks for the work-around so far Simon Linden was unable to repro.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Scripted Physics functions no longer function on prims with mass since 1.24
