I just had a talk with someone wondering if Meeroos set on Insane were causing lag. (My opinion: possible, but not likely.) So I thought I'd put together a note about what Time Dilation is and what Players, Creators, Area Designers, Script Authors, and Estate Owners and Managers can do to find it and fight it.

So, what is Time Dilation?

To understand Time Dilation, we need to understand a bit about how the Simulator program works.

There are three main activities for the Simulator: determining which objects and textures need to be sent to the viewers, updating the physics (avatar movement, physical object movement, and collisions between these), and executing scripts.

The Simulator uses a scheduling technique called "time division multiplexing" to perform each of these three activities, as well as fourth, Idle activity for those times when it actually has nothing to do. That means it runs each and, if it's taking too long, leaves off and moves on to the next phase.

The Simulator schedules using a "heartbeat". This is an event which occurs regularly. For this discussion, we'll state it's a one-second beat. Basically, all the heartbeat does is set a status meaning "start another cycle" and, if the Simulator is in the Idle state, kicks into the Objects and Textures state. For tracking Time Dilation, the time-stamp of the heartbeat is recorded.

Time Dilation is a measure of Simulator Lag.

So, what is Simulator lag? Stated more precisely, what causes the Simulator to be unable to finish one complete cycle through all three activities before it's time to begin another?

---

For the Objects and Textures phase, Avatars on (or close to) the Region cause lag. The effect is complex, but the basic factors can be described. One main factor is Draw Distance. This controls how many objects and textures you'd like sent to your viewer. Another factor is the camera angles and positions. This allows the Simulator to know some objects and textures are not being seen and don't need to be sent. And a final factor is "blocking prims" .. that is normal (not mega) prims which have no holes, transparency or alpha textures. Of course, through all this, there are the prims and textures the viewers need to draw our pretty images! This phase is all about figuring out which prims and textures we need to know about, and sending that information to our viewers.

So, to combat Simulator lag, as a visiting avatar: shorten your Draw Distance to the minimum usable for the area. If you have a lot of attachments on, remove them to reduce the number of objects and textures. Don't worry about your Skin, Clothing and Tattoo layers: those are 'baked' into a single set of three textures by your viewer before being sent to the Simulator for forwarding to others' viewers, and so are pretty constant from one avatar to another.

And, to combat Simulator lag, as an area designer: install blocking prims. For example, walls which segment the space so avatars in one area cannot see prims or avatars in another. Of course, saving prims and textures should go without saying! Objects which change textures cause a lot of lag (for the Texture phase as well as the Scripts phase) and should be curtailed when possible.

There are some minor improvements Meeroos could make to further reduce Object and Texture lag, but these are so minor, that the savings in Simulator lag over the lifetime of the product line will probably not exceed the time spent making the changes. There are far better things to be done.

---

For the Physics phase, Avatars and Physical objects cause lag. Again, this is complex but the factors can be described. All avatars are Physical objects. Other objects can be set Physical by the creator and/or script author. When physical objects move, the Simulator calculates their paths. Also part of this phase is determining when Physical objects collide (touch or penetrate) other objects. All this is HIGHLY computationally intense involving a good deal of higher mathematics.

Flexible prims move and, so, add lag during the Physics phase.

Note that collision-detection is a long, complex problem all by itself. But creators and script authors can reduce this problem by marking objects Phantom. Phantom objects cannot collide with other objects and, so, are eliminated from the Physics phase for collision detection; but they still participate for movement.

Meeroos are marked Phantom to eliminate their contribution to the collision-detection part of this phase. Setting Meeroos to Insane activity does increase the work for the movement phase. But movement calculations are far simpler than collision detection. So, I doubt anyone would be able to actually measure any significant change in Physics-phase lag due to Insane Meeroos.

As a visitor to the Region, to reduce lag during the Physics phase, remove all flexible attachments (mainly hair, and some accessories like belts and necklaces). Other than that, there is little you can do other than leave (which is probably not an acceptable solution).

As an area designer, creator or script author, you can take care to reduce the number of Physical objects and, whenever appropriate, mark objects Phantom. (A phantom floor looks fine, but avatars will fall through it, so Phantom may not always be a wise choice!)

Estate Owners and Managers can use the Region/Estate tool, Debug tab, to check on, and locate, objects which are causing a lot of Physics lag during the collision detection phase.

---

For the Scripts phase, the number of scripts is the main component. Yes, a script author can do things which makes scripts run longer. But the MAIN component of Scripts lag is the simple fact a script exists!

As an avatar visiting a region, you can reduce script lag by removing attachments which contain scripts; or removing the scripts from your attachments: this includes many appearance attachments (shoes and hair being the principal ones to look for), as well as invisible ones (face lights), and virtually all HUD attachments.

As the designer, creator or script author you can reduce Script-phase lag by searching for and removing either the objects, or the scripts from those objects.

Of particular note here are certain "sit" animation builds. There are some systems, commonly in use, which require one script per animation, per "sit" location. I have seen a complex 30+ prim tree built with over a dozen "sit" locations and over eight animations per location. Needless to say, removing that single tree from my region produced a MARKED improvement in script-phase lag.

In another example: one breedable mall area I know of uses pre-fab buildings. While lag is generally not an issue there, each building actually contains a couple scripts for "sitting on the steps". If lag should become an issue, the area owner/designer could go through and remove those scripts to good effect since there are over a hundred of those buildings in the region!

Script authors, of course, can fight script-lag by not creating more scripts than necessary. Of course, they should also test their scripts to ensure they are not taking overly-long to complete (particularly: no long or infinite loops).

Meeroos use a minimum number of scripts and do not seem to waste time in those scripts; so they are not likely, individually, to be the culprits for Script-phase lag. (Of course, in the extreme, a Full Region containing nothing but 1,500 Meeroos would probably be a bit laggy.)

Estate Owners and Managers can use the Debug tab of the Region/Estate tool to find objects using a lot of script time. This tool, in fact, was how I found the tree mentioned above (and then looked inside to see why, even when unused, it was using such a vast amount of script time).

---

So, what is this number "Time Dilation"?

All the work for each cycle runs until complete, or until it reaches some (rather large) internal limit and is set aside until the next cycle.

When the cycle finished, if the heartbeat has not ticked, the Simulator enters an Idle state. The Time Dilation in this case is always 1.00.

But, most often, the cycle does not finish. In this case, the time the cycle took (seconds) is compared to the heartbeat frequency (one second). The ratio between these numbers is the Time Dilation.

Thus, a Time Dilation of 1.00 means that a "heartbeat" took 100% of the actual cycle duration. And a Time Dilation of 0.16 means that a "heartbeat" interval was only 16% of the actual cycle time (or, converting to seconds: the cycle took about 6.25 seconds to complete its work but it SHOULD only have been only one second before the next cycle SHOULD have started).

We call it Time Dilation because, as script authors, there are things we can do which "tick off time" inside our scripts and, when the Simulator is lagging, time (using those methods) will seem to slow down.