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
