not_at_target is currently triggered through the main scene rather than in the aync lsl command thread. So it will fire
at least every 1/11 of a second. For some reason, the target check is also performed at
SceneObjectGroup.ScheduleGroupForUpdate() so it may fire even more often.
Looking briefly at the web, sources only mention that not_at_target may fire multiple times before reaching a target.
They say nothing about the periodicity of such firing.
On 18/07/12 00:45, R.Gunther wrote:
On 2012-07-18 01:31, Justin Clark-Casey wrote:
If you want to increase timer resolution the current thing to do would be to
change
cmdHandlerThreadCycleSleepms = 100;
Intressting, then i get the question why it seems the event " not_at_target"
seems to have o restriction.
with that function i always get some sort if filled query. not_at_target can
fire at the same speed as do/while
It looks like its getting faster called then processed. i think "timerevent" is right now
to slow and "not_at_target"
is way to fast and seems to require lots of lsl time.
The whole event triggering is sometimes tricky.
------
in AsyncCommandManager.ReadConfig(). It appears that configurability was
disabled almost 4 years ago for reasons
unknown.
The fact that it's 100 means that you can never get timers that fire less than
100ms apart. Moreover, timers are tied
into the general AsyncCommandManager.DoOneCmdHandlerPass(), which performs
operations for listeners, sensors and
dataserver events as well as timers. So the resolution will be even less
accurate. At some point I think it may be
good to do some of these in separate threads to reduce the variability of
performance.
However, even if these issues were to go away, the timer events would still
have to be fired through the event
mechanism. I'm not sure how efficient firing lots of timers is, or what impact
it would have on other scripts in the
region.
On 16/07/12 15:13, R.Gunther wrote:
I work on some project that move prims.
Right now i do it with small do/while loop. thats the fastest way to move a
prim smooth.
But have technical some problems.
If i move the prim with timer event. and i have set it to 0.01 because its
anyway not seems todo much below 0.5
not sure whats the lowest working setting. And thats also the problem. the
object moves way slower != smooth compared to
do/while loop.
Would be nice if there's option to speed the timer event up. But need to agree
i dont know the effects.
A timer thats doing lets say 0.01 sounds better then a do/while loopt thats
running 20 meters with steps of 0.5 meters.
would be nice if the timers where a bit faster. But maby i make a thinking
error to. Still dont see why i cant get the
same result with both ways.
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
--
Justin Clark-Casey (justincc)
http://justincc.org/blog
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
