velocity/speed control of non-phys prims

Hi, llMoveToTarget is only for physical prims. How can non-physical-prims be moved to a specific pos with a constant and controlable speed?

Cant see any posibillities, so..
physical and phantom seams a b a d combination - (try:)
That behavior is 'rarely' wanted* ..
Could that somehow be avoided -Then those prims would be speed controlable with llMoveToTarget.. but.. :/


*The one situation where it could be wanted: Your mother-in-law in on the floor below.. The piano is made physical and phantom..
Then again.. phantom.. It wont -really- do any 'job' .. :)

what you need to do is use llSetPos() in a timer loop. something like this:

float speed=1;//speed in meters per second
float FPS=5;//we'll use a "FPS" of 5 with a speed of 1m/s since there's an inherent .2s delay for llSetPos(). you can use a distributed system using multiple scripts to bypass this delay, but we'll stick with just a single script for the example.

state default
{
     state_entry()
     {
          llSetTimerEvent(1/FPS);
      }

     timer()
     {
          llSetPos(llGetPos()+llRot2Fwd(llGetRot())*(speed/FPS))//get where the object is now, and move it forward along the positive x axis of the root prim the distance it should travel during each "frame" we calculate.
     }
}

I wrote this without checking for compilation errors, but the concept is still there. you figure out how many times per second you want your object to update it's position, and you move it forward accordingly based on the speed you want. you can combine this simple "engine" with input controls that modify the speed, and set the rotation of the object so that you now have a basic non-physical vehicle. you can also add in friction of sorts by doing some math in the timer event to slow the speed down at a regular pace.

basicly the right combination of llSetPos will make non physical stuff act like physical objects if done right

Just be aware that fast loops executing llSetPos() (especially done from multiple scripts simultaneously to get around the script delay problem) are very hard on the sim. They will use up a TON of script time and contribute quite a bit to lag.

Remember that every one of those position change causes a potential object update for the client of every resident around. For physical objects the system could POTENTIALLY interpolate position and even physical interactions, but not for this sort of thing.

Thank you all!
it is a litle 'weak' that movement towards target is restricted to physical obj, that is most likely a havoc-thing.. :/
For later reference , this new thread addres the same isue -moving with timers
/54/ab/266136/1.html.
BR ab

That may change in the future. Havok can do nice nonphysical motion, and a Linden has expressed interest in playing with it, but it's not on any sort of official roadmap.

Similiar thread started by Abraxis a while ago:
/54/cb/264350/1.html

Also Hewee, I consider the massive amounts of object packet updates for physical movement to be more important for minimization than a quick position change on the simulator side. Network lag concerns come before simulator lag.

Of course when multiple scripts are being used to go faster than the llSetPos call even allows for then it is quite outrageous.

Abraxis it might help better if you explain what/where you are going to use this for. Thus we could apply more wiser directed help.

Agreed. You may want to re-read my post. I wasn't talking about a single call to llSetPos().