Timers in opensimulator are usually limited to 0.5 seconds minimum duration. There is a ini setting to change it at the simulator level, however, I've found that using the not_at_target() event gives better results as it will fire once per simulation frame which is probably what you would want anyway.<div>
<br></div><div>Using llSetPos() and friends is probably not a good idea as it generates a *lot* of network traffic and overhead in the client stack code in the simulator. I've heard several LL engineers lament the use of these functions for motion but "the cat is out of the bag now" and there's not much they can do about it except promote the use of llSetKeyFramedMotion().</div>
<div><br></div><div>I've had difficulties with the opensimulator implementation of llMoveToTarget() and I've written my own velocity feedback loop in LSL (which is kind of an abstract PID controller) and I use it on both SL and opensimulator. I usually only have to change one constant to get it to behave the same on either platform. I use not_at_target() and llApplyImpulse() to correct velocity at each simulation frame. I don't use any timers at all. It works in all 3 global axes so object rotation doesn't affect velocity, and motion is fairly constant and smooth. I have made attempts to understand the existing PID code in opensimulator but it's unfortunately not very well documented and has a lot of commented out code and much of the code uses variable names that are not very descriptive, so I haven't been able to successfully modify it to work as well as my LSL solution. I'm also somewhat hesitant to commit any changes to that code as I don't really have much experience with scripting LSL physics and I don't have confidence that I would make changes that would break other's scripts. I'm also not sure if any of the PID controller code affects vehicle functions or not, or if it just applies to llMoveToTarget() and agent motion.</div>
<div><br></div><div><br><br><div class="gmail_quote">On Thu, Jun 7, 2012 at 12:09 AM, Mike Higgins <span dir="ltr"><<a href="mailto:mike@kayaker.net" target="_blank">mike@kayaker.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="im">
On 6/6/12 12:48 AM, Bengt Falke wrote:
<blockquote type="cite">I am also interested in physics for vehicles mainly
for creating working yacht and for making my free moving scripted
animals to work in a smooth way.
<div>If there is a way I can contribute I will try to do so.</div>
<div><br>
</div>
</blockquote></div>
Also at the recent OpenSim developers meeting,
Andrew Hellershanks said (about llSetTImerEvent minimum time limits)
"Not sure why you would want to use something other [less] than
1.0". I think the developers need to know that there are 1000's of
scripters in SL DESPERATELY trying to find ANY WAY to make simple
things like a fish move smoothly through the water at a constant
velocity. In SL you can usually get timer() events as often as once
every 0.2 seconds, which is not quite often enough for smooth
looking motion. timer events more often would be one way to get
smoother looking motion. I've seen people write scripts that had
abominations like: while (1) { moveit(); llSleep(0.05); } The
OpenSim developers need to throw these guys a bone so they will NOT
DO THAT HERE!<br>
<br>
Of course, LL only recently threw them the
llSetKeyframedMotion() bone. Before that, people tried to use
physics and llMoveToTarget() which was NEVER DESIGNED TO GENERATE
LINEAR MOTION (it is always damped). Although you can play games
with it and find reasonably linear portions of the curve. But that
requires accurate llSetTimerEvent durations to stop the
llMoveToTarget part way through a damped move. And in OpenSim,
llMoveToTarget is damped 9 times faster than SL (mantis issue 5968)
which requires pushing it nine times harder to try to capture a
linear section and even more accurate llSetTimerEvent times to
prevent the object from running away from you...<br>
<br>
The only other way in SL (before llSetKeframedMotion) to get
something to move smoothly at a constant velocity is to make it a
vehicle. Which is sort of like using a 4 ton hydrolic press to
insert thumbtacks in a cork board. And even in SL, the vehicle
functions are really squirrely.<br>
<br>
So the major reason I am testing the OpenSim vehicle routines is
to see if I can find a reliable subset of them, or a set of
workarounds, that will allow me to move a fish smoothly through the
water at a constant velocity.<br>
<br>
So far I have found a few problems and some workarounds:<br>
1) Vehicles crash and burn at the sim boundary, the workaround is to
add code to detect the sim boundary before the vehicle gets there
and prevent it from even getting close. But if llSetTimerEvent is
not accurate, if your timer() event is not called regularly to do
this check, the vehicle runs into the sim boundary and goes crazy.<br>
2) The angular motor rotates around the wrong axes, but you can
workaround that by multiplying your vectors by llGetRot (mantis
issue 6039). I'm guessing that nobody noticed this before because
cars and boats and helicopters are usually horizontal and their
local Z axis is aligned with the region Z axis.<br>
3) The linear motor vector is clamped or projected onto the region
XY plane. (mantis issue 6040) A car or a boat or a helicopter might
never notice this, but with no Z values allowed in linear motors,
how can airplanes glide up or down? Someone please tell me how to
get this to work!<br>
<br>
<br>
</div>
<br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br></blockquote></div><br></div>