5

Upcoming Script Features And Changes

Kelly - Sansar

August 23, 2017 22:18

None

Follow

There are a lot of script features and changes in this coming release, and many of them are fairly advanced and technical. Here is a quick overview. I'll be posting more detailed information for some of these in their own threads.

Note: All of these features are not yet released, but are planned for future release. As such they are subject to change or may not ship at all.

Trigger Volumes

A new item in System Objects used with scripts to get enter and exit events for an area in a scene.

VR controller APIs

Get the hand and HMD position and orientation for avatars in the scene that are using VR tracked gear. Additionally the tracking of hands has been updated so they can interact with Trigger Volumes.

Script Console

View script log messages in the Sansar client without a helper logging script or commands.

Cached APIs

Some APIs whose data does not change now have their instances or data cached. This should remove the largest case of Null Internal Reference errors.

Coalesced RigidBody Set/Add Methods

Extremely rapid calls to RigidBodyComponent Set* and Add* methods are coalesced into a single action under the hood for improved performance and stability.

Throttled APIs

Some APIs are now throttled to prevent abuse. Calls to a method that has hit the throttle will throw a ThrottledException. Only MessageAllUsers, SendChat and CreateCluster are currently throttled.

Coroutine Limit

Scripts are now limited to 32 coroutines at a time, per script.

Performance Improvements

Newly compiled scripts should have minor improved performance and memory impact. Some extreme cases may see significant improvement.

Coroutine Scheduling Improvements

Reduces how often coroutines will yield to other coroutines within the same script.

16 comments

• 0
  
  Gindipple August 23, 2017 22:27

  No desktop trigger volumes?

   

• 0
  
  nebulae August 23, 2017 22:29

  Thanks for this! Especially excited for the VR controller APIs : ) 

• 1
  
  Kelly - Sansar August 23, 2017 22:30

  What do you mean by desktop trigger volumes? A trigger volume is a volume (shape) in the scene that can detect when avatars and dynamic objects enter or leave the volume. In addition to the normal avatar shape, VR controller "hands" have physics shapes (that is how they can knock things around) and the Trigger Volumes will detect those too. VR is not required for normal avatar or object interactions with trigger volumes.

• 0
  
  Gindipple August 23, 2017 22:39

  I guess I'm asking, are we going to be able to from the desktop be able to detect a "touch" event. Similar to what exist in SL?

  It sounds like this will give this for VR users, but not desktop mode.

   

• 0
  
  Kelly - Sansar August 23, 2017 22:49

  Touch-like interactions are not in this upcoming release. This version of Trigger Volumes is specifically for physics collisions, and it is more or less a happy coincidence that VR hands can interact with them too. More general "interaction volume" behaviors are further down the line.

• 0
  
  Gindipple August 23, 2017 22:59

  Can you give a sure heads up on when the 10 MB limit comes into play?

  I still really hope that is reconsidered, but would really like to know when / if it's about to land in our laps.

   

• 0
  
  Kelly - Sansar August 24, 2017 00:35

  You should expect memory limits to be enabled soon. It is nearly always beneficial to optimize for lower memory use regardless of the limits. The current consequence of overusing memory is a scene server crash and we would like to prevent that. Additionally we also need to account for a future where visiting users can also have attached scripts - and we would still like the scene to not crash.

  I do not expect to turn on the limit with this upcoming release but it will happen soon and you should plan for it.

• 1
  
  Gindipple August 24, 2017 01:31

  Don't suppose we could get the APIs to work with visual studio again could we?

   

• 1
  
  Galen August 24, 2017 01:31

  Thank you. This information is gold. We really appreciate it.

• 0
  
  Galen August 24, 2017 01:34

  I'm a little concerned about the CreateCluster() throttle. Is it a simple rate, like 1 per X ms? Or is it more in groups, like a burst of 1000 per X ms?

  I can see lots of applications that need to rez a modest number of objects all at once, like Gindipple's Bubble Breaker game. Adding a delay to each would reduce the quality of the experience in some cases without improving the performance of the system.

• 0
  
  GranddadGotMojo August 24, 2017 12:41

  How does the coroutine scheduling work?  Will we be able to prioritize or synch them in any way?

• 1
  
  gfcprogramer August 24, 2017 14:08

  Thanks for updating. We should extend this code to the limit.

  I'm half-ass coder because I have been so much into making my experiences better in light/grafics aspects.
  But Im glad i will be able to access some more of this features.

   

• 2
  
  LGG August 24, 2017 15:08

  This is very exciting, I hope it all pans out well.

  But most importantly I really appreciate the transparency.

• 1
  
  Kelly - Sansar August 24, 2017 15:36

  The coroutine is a very minor under the hood change that should be largely unnoticed: It is really just a reduction in how often a coroutine can be interrupted by other code within the same script. It came about from some scripts I'd seen others use that ran into issues with a coroutine or event happening while another was looping over a container.

  I do really like the idea of syncing coroutines and letting them "signal" each other. I have some longer-term plans for cross script messaging that I think can be coopted for that, so I'll make a note to explore it.

• 0
  
  Galen August 24, 2017 16:53

  Maybe a good old fashioned mutex or support for locking.

  Actually, I haven't tested whether lock() is supported, yet.

• 1
  
  Gindipple August 24, 2017 17:01

  I have, it's not allowed.