Laaaaag! It’s everywhere, and we hate it. This mini article will provide some tips to avoiding the effects of sim lag in your show or production, specifically when using movers. By following these tips you have the ninja skills necessary to stop lag from impacting your show’s scripted movement.
1.0 First, Know your Lag Varieties
For MST movers there are two specific types of lag that cause the most trouble.
- Server-side script lag (typical).
You can identify this by opening up your viewer’s “Sim Statistics” window by pressing control-shift-1 and looking at the “Script Run %” results. Check out the image on the right.
In this example the “Scripts Run %” is 24.471%, which is not good. For optimal script performance, you should strive to get this number higher than 60%.What does this number mean? This means “Of all the scripts that attempted to process events in this server frame, we were only able to find time to run 24% of them. The rest were rescheduled for a later frame.” When this number falls below 50% there can be cascading effects that can make it difficult for a sim to recover. Anything that relies on scripts will be noticeably delayed. For Movers, low “Scripts Run %” will cause movers to load or reset very slowly, perform post-rez tasks slowly, and respond to requests to stop or start their movement with a delay.How do you avoid this situation? Try and reduce the number of scripts and busy scripts in your region. This is a large topic, I’ll attempt to write more in a followup article.
This type of lag is common in today’s SL, but was less prevalent five years ago.
- Server-side region lag (rarer).
If your region has a large number of moving objects or is otherwise strained, it may start to slow down as a whole. You can check this by opening up your viewer’s “Sim Statistics” window by pressing control-shift-1 and looking at the “Sim FPS” and “Physics FPS” lines as shown in the image on the right.
Healthy values are greater than 40 FPS (Frames per Second). The Second LIfe server maximum for a perfect region is 45 FPS.If your region is has a lower than 40 FPS, you may see sluggish, delayed, or erratic avatar moment. You may also see large movement inconsistencies when avatars enter or leave the region.For Movers, a low simulator FPS will result in movement that takes longer than it is supposed to. You may have specified that a movement segment shall take 5 seconds, but a low simulator FPS may cause it to take 7 or 8 seconds.
How do you handle this situation? In some cases you can avoid trouble by using “moveto” commands instead of a long-running long movement sequence. In other situations you may have inspect your region for sources of server-side lag such as– objects that move on their own, pathfinding objects or creatures, objects that change their shape, avatars or objects that are colliding with each other, or similar.
2.0 Reduce Back-To-Back SAY, SHOUT, or WHISPER Commands in your Eventlist
If you are operating in a region with significant script-lag, Try to avoid sending more than two chat (say, shout, whisper) messages out on any channel at the same exact split-second of time. Examples:
3.0|SHOUT:8:moveto dancer1 waypoint1 3.0|SAY:99:fadein 3.0|SAY:40:startParticles
The eventlist above will try to do 3 different things at the exact same time. It will work well on a unlagged sim but if there is script lag, it may not work well. Set up your choreography so that commands can be spaced out further apart in time. Suggestion: 0.5 seconds apart. The following will behave more consistently in script-lagged regions:
2.5|SAY:99 fadein 3.0|SHOUT:8:moveto dancer1 waypoint1 3.5|SAY:40:startparticles
3.0 Use groups instead of running each mover individually.
If your choreography calls for multiple movers to act at once, don’t send out the moveplay or moveto commands to each mover individually. For example, the following won’t work well in script-lagged regions:
3.0|SHOUT:8:moveto leaddancer1 waypoint1 3.0|SHOUT:8:moveto backup2 waypoint1 3.0|SHOUT:8:moveto backup3 waypoint1 3.0|MOVEPLAY:car1 3.0|MOVEPLAY:car2
The above eventlist creates 5 chat commands all at the same time. Instead you could use put the dancer movers into a “alldancers” group and the car movers into a “allcars” group and reduce it to just 2 chat commands like this:
3.0|SHOUT:8:moveto alldancers waypoint1 3.5|MOVEPLAY:allcars
4.0 Use the “moveto” style of moving when movements need tight synchronization.
There’s more information on this in the mover web documentation, but the short story is that the “moveto” method will help you avoid region FPS lag, because you can start movement at precise timed intervals instead of allowing it to drive with the sim’s FPS.
The downside to moveto is that if you have multiple movers active at the same time, you need to design ways to command them as a group to reduce overall chat messages, such as described in section 3.0 above.
5.0 When using the “moveto” mover style, Try to design “Catch up space” into your performance.
When facing both kinds of mover lag– script lag and full-sim FPS lag, you can mitigate their effects by building in movement pauses into your performance to allow the region to “catch up” with script and frame processing, if it has fallen behind.
What does this mean? You should not plan to keep a mover in constant motion for a long period of time, but instead design in places where it can rest. Below is an example of a movement sequence with no rests:
3.0|SHOUT:8:moveto dancer1 waypoint1 10.0 13.0|SHOUT:8:moveto dancer1 waypoint2 4.0 17.0|SHOUT:8:moveto dancer1 waypoint3 12.0
Instead it would make the performance more lag-resistant if the mover stopped for a bit, before proceeding to the next waypoint with moveto. For example:
3.0|SHOUT:8:moveto dancer1 waypoint1 10.0 13.0|SHOUT:8:moveto dancer1 waypoint2 4.0 20.0|SHOUT:8:moveto dancer1 waypoint3 12.0
In the above example the third line starts the movement to waypoint3, three seconds after the mover has arrived at waypoint2 instead of right away.
Note: This only applies to “moveto” style mover commands, if you use “MOVEPLAY” and wait time, it will not count as ‘catch up space’.
6.0 When using chat commands, try to use different and unpopular channels.
- The region has to do more work when multiple scripted objects (some of which might be worn by avatars in the audience) listen for commands on the same channel.
- To avoid this, do not use channels 0-10 if at all possible. If you have the option, you might try using channels with at least three digits like “959” or negative numbers such as “-301”.
- Note that at this time, many of the MST tools require use on channel 8. In the future additional channels may be allowed.
7.0 When using chat commands, use say, whisper, shout appropriately to the distance you need.
- “Whisper” chat commands will go up to 10m away
- “Say” chat commands will go up to 20m away
- “Shout” chat commands will go up to 100m away
Use just what you need and this will reduce the amount of work the region needs to do to process your message.
That’s all for now, look for more tips later!
-Arrehn
