+1. I think thats the most sensible approach. Time Dilation is the one
case where the changes really changed the *meaning* of a value as
opposed to just the number. I would keep it SL compatible for LLXXX
lsl functions and define a new one to return the new value that was defined.
Mike
On 04/26/2015 04:11 PM, Melanie wrote:
I would like to use the opportunity to toss in my $.02 regarding
time dilation in scripts.
Time dilation as a LL function is defined to return a value between
0 and 1, which, while not as informative as the new dilation stat,
is useful to make scripts perform better under bad simulator conditions.
I would postulate that the only case in which any script in OpenSim
uses this function is if it was copy/pasted from SL. Since the
return value is a constant 1, I doubt any software written for
OpenSim specifically even uses it.
A SL compatible return value would improve the copy/pasted scripts
from SL and not adversely affect OpenSim scripts which don't use it
anyway.
I would therefore like to propose to change the return value of the
LL function to return an SL-compatible value and, should there be
interest, maybe introduce a companion OS function returning the raw
value, including the positive values greater 1.
- Melanie
On 26/04/2015 13:28, Maxwell, Douglas CIV USARMY ARL (US) wrote:
Good Morning All, in previous email I described the simulator statistics
reporting adjustments we have been working on. This group requested that we
avoid sending a major code drop, so we have staggered the code updates into
three different stats patches. You could call the first patch a dry run of
sorts to allow us to ensure proper formatting and integration on your side.
Looks like all we need to do is sort out the white spaces issue in the patch
and we will be good to go.
For your planning purposes, here is the roadmap for all three stats patches:
Patch 1: Simulator FPS, Physics FPS, Total Frame Time, Physics Frame Time, and
Simulation Time.
Patch 2: correct the broken user login freezes, XEngine Thread Count, Util
Thread Count, System Thread Count, Proc Mem, Frame Dilation (previous the
proposed Time Dilation).
Patch 3: network reporting: UDPIn, UDPOut, UDPInError, PktsIn, PktsOut, Avatar
to IP list, Server-to-Client Ping, and Average Server Ping (External).
The attached screenshot shows Patch 1 in action on the MOSES grid. Based on
your feedback, we did not affect how the script engine reports Time Dilation,
however the simulator frame rate is reported accurately. This is demonstrated
via a scripted object (green box). The statistics window reports Time Dilation
accurately and is a constantly changing value based on simulator load,
specifically physics interactions. (Forgive the low client frame rate, I took
the screenshot on an older laptop.) Some of you have seen this screenshot, I'm
providing it again for context.
What's next? Physics & Networking. Just tossing physical balls into a pit or
logging in a few dozen bots isn't an adequate test. There are too many variables at play
and even simulator<->physics engine integration code is wickedly complex. We need
to be able to rely on the reporting of the simulator's behavior so we can know what
adjustments are meaningful. We don't yet know if PhysX is better than Bullet, but
thorough and accurate testing is the only way to find out.
What's the potential payoff for you? Imagine being able to hold an event like
the OSCC in a single large var region. Imagine having lots of people being
able to log into a region simultaneously, rather than in serial like today.
Wouldn't it be nice to be able to actually plan for what hardware and network
support you need for a grid, rather than just guessing and buying the best you
can afford - not what you actually need?
This is what we are working towards. If we can agree that these changes are
valid and necessary, then I invite you to inspect our work. If you object to
the way we have implemented the changes, then we welcome feedback and will work
with you to find a more compatible path.
In approximately 9 months, we will begin testing some new simulation based
training material that involves large numbers of people and I would like to
have a version of MOSES ready in time to support. My only alternative is to
continue licensing a very expensive proprietary engine. It is my desire to
cancel that license and devote those funds to open simulator development, but
only if the MOSES can handle the work.
Douglas Maxwell, MSME
Science and Technology Manager
Virtual World Strategic Applications
U.S. Army Research Lab
Human Research & Engineering Directorate
Simulation & Training Technology Center
(c) (407) 242-0209<tel:%28407%29%20242-0209>
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
