<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"> So I finally got around to playing
with not_at_target. As R.Gunther noted, timer is too slow and
not_at_target is too fast.<br>
I tried putting a sleep(0.1) in at the start of not_at_target, but
the motion was jerky. I tried putting it in at the end, still very
uneven.<br>
<br>
Then I tried the scheme in the following code. Where it says "move
your critter" I have 100+ lines to make the decision of where to
move next, with vector and rotation calculations.<br>
<br>
What worked for me was accumulating llGetAndResetTime() until
enough time has passed for the next move. With expected delays,
checking for 0.05 seconds or more typically takes around twice
that long, which is a respectable 0.1 or 10 moves a second. The
movement of a single critter was quite smooth, so I released 10 of
them. They still moved reasonably well! I feared that this much
script activity would lag the sim, but my FPS barely budged. (I
have a script that drops the FPS from 56 to 30 when just one of
them is running. And it is not my fault! I submitted it as a bug.
Mantis #
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<span class="small">0006080</span>). Top scripts shows this
not_at_target script up at the top, so this is not the perfect
solution yet. But the best I've seen so far!<br>
<br>
I left them running overnight and by morning they had all
stopped moving. I wondered if my llTarget call had timed out, so I
put another call to llTarget inside not_at_target to refresh it
every time. Same problem, they all stopped moving by the next
morning. I have scripts with timers that have been running for
months and survived server SIM restarts. So I put a call to
llTarget inside a timer to wake them back up when the
not_at_target stops getting calls. I just started them ticking, I
will find out tomorrow if this keeps them going. I should probably
report the failure of not_at_target as a bug in Open Simulator!<br>
<br>
//not_at_target mover<br>
float step=0.05; //how often to move in seconds (typically
takes twice this long)<br>
float time=0.0; //global to count time passed since last move<br>
<br>
default<br>
{<br>
state_entry()<br>
{<br>
llGetAndResetTime();<br>
llTarget(<300,300,0>,1.0);<br>
llSetTimerEvent(30.0); //use timer to refresh
llTarget<br>
} //state_entry<br>
<br>
timer()<br>
{<br>
llTarget(<300,300,0>,1.0); //refresh this every 30
seconds<br>
} //timer<br>
<br>
not_at_target()<br>
{<br>
time+=llGetAndResetTime();<br>
if (time<step) return; //ignore system if calls me
too soon<br>
time=0.0;<br>
//move your critter here. I use
llSetLinkPrimitiveParamsFast(LINK_THIS,[...]) at the end<br>
} //not_at_timer<br>
<br>
}<br>
<br>
On 7/17/12 4:45 PM, R.Gunther wrote:<br>
</div>
<blockquote cite="mid:5005F925.6020907@rigutech.nl" type="cite">On
2012-07-18 01:31, Justin Clark-Casey wrote:
<br>
<blockquote type="cite">If you want to increase timer resolution
the current thing to do would be to change
<br>
<br>
cmdHandlerThreadCycleSleepms = 100;
<br>
Intressting, then i get the question why it seems the event "
not_at_target" seems to have o restriction.
<br>
</blockquote>
with that function i always get some sort if filled query.
not_at_target can fire at the same speed as do/while
<br>
It looks like its getting faster called then processed. i think
"timerevent" is right now to slow and "not_at_target"
<br>
is way to fast and seems to require lots of lsl time.
<br>
<br>
The whole event triggering is sometimes tricky.
<br>
<br>
</blockquote>
<br>
</body>
</html>