Kitely Forums

I'm starting to get complaints from Kitely customers that my vehicles don't "return to the beach" like they are supposed to.
On my world Panthalassa, surfboards that have been rezzed for a long time return correctly.
If I rez a fresh one, it fails to return, as reported by my customers.
I narrowed the problem down to a call to llSetLinkPrimitiveParamsFast. The call does not get an error, calling llGetPos afterwards returns the new position, but the prim does not move. I tried this in the SW corner of Panthalassa, and in mega areas, it fails in any location type.
Here is the routine I use to return boards to the beach: Fortunately, the llGetPos returns the desired position of the prim, or this would loop forever!
Similar calls to change the prim's rotation also fail at the same time.

I tried putting diagnostics in one of the surfboards that was retuning correctly, to see why. As soon as I re-compiled it, it started failing to return like the new copies do.

I tried writing a simple program to show llSetLinkPrimitiveParamsFast failing, but this test worked correctly and moved a single prim. I tried putting this simple test in a surfboard, it still works. So I can only repeat the problem in objects with a big complex script so far...

Is there some change in the recent system updates that can make this very basic function fail?

Hi Kayaker,

We did upgrade to OpenSim 0.8.2 a couple of weeks ago, so that may have had something to do with this. When did this problem begin?

OK, I found the problem.
Apparently I have a race condition between llSetKeyframedMotion and llSetLinkPrimitiveParametersFast
I expected the llSetKeyframedMotion to be done when I moved the board back to the beach.
And this expectation used to work, until something changed in Open Sim 0.8.2.
Here is what is happening to me now:
When I call llSetLinkPrimitiveParamsFast, it does work and the board returns to the beach,
but then llSetKeyframedMotion ticks one last time and moves the board back to where it was last used.
I can fix this, by forcing llSetKeyframedMotion to stop, instead of assuming it is done. Probably a good idea anyway.
However, this means I have to make this change in every vehicle script and RE-DELIVER EVERY VEHICLE I HAVE EVER SOLD! AHHH!
I suppose this is the price of hanging out on the bleeding edge of the cutting edge.

Edited later:
It's not as bad as I thought, only the surfboard has this problem. All the other vehicles do things in a different order and already have a call to stop llSetKeyframed motion. WHEW!

Yes, it is prudent to not asume a speciffic run order when calling functions that work asynchronously...

Hi Kayaker,

It's good that you found the problem, because I've been looking at the implementation of llSetLinkPrimitiveParamsFast and I didn't see any substantive change...

But there are a couple of other things that can be done to improve this script.

First, it should be moving LINK_ROOT, not LINK_THIS. Since the script is working I assume it's running in the root prim, but this way it will work even if it's running in a child prim.

Second, and more important, this script will use very high CPU power because it's running a tight loop without any delays. You shouldn't use llSetLinkPrimitiveParamsFast in a loop; use llSetLinkPrimitiveParams instead. The non-fast method has a 0.2 second delay, which is important to allow the server to continue processing the rest of the sim (avatar movement, etc.). I'm actually surprised that Linden Lab have even allowed a function to exist that doesn't have a delay: every other function that I can see does have a delay. I've looked at the world Panthalassa yesterday and it was using a lot of CPU compared to the usual level for idle worlds (40% vs <10%), and this script might explain the reason.

By the way, our next release will include changes that make the "Top Scripts" dialog much more effective in identifying scripts that cause high server load. It will be interesting to see what the new dialog shows in this world.

Hi Kayaker.

You might want to consider using something like this:
As you can see, this uses a similar principle but only has one call each to llSetLinkPrimitiveParamsFast(), llVecDist() and llGetPos(), greatly increasing the efficiency. I use this function wherever I need to move objects more than 10m within a region.

Yeah, after I posted that code it occurred to me that it was a terrible example in several ways.
It was a hack that I wrote when I discovered that llSetRegionPos() does not work in Mega Regions.
I assumed that llSetRegionPos would soon be fixed and I would call that inside my function.
I knew that the way I did uses lots of CPU resources, but it is only executed infrequently, when someone steps off a surfboard and it is set to return to the beach.
Handy's MoveTo function harks back to the bad old days in SL when we had several different warpPos and PosJump routines to do what llSetRegionPos should do now. warpPos had a clever binary-doubling trick to decrease the number of times the Params string got modified. PosJump was based on a strange response of PRIM_POSITION to floating point numbers like NaN and INF in vectors! Makes me shudder now just to think about counting on that...