Are scripts ever really disabled on parcels?

[ken Beyaz]

I am planning lag reduction measures for a forthcoming event and plan to turn off scripts on the parcel except for group members. This is supposed to work below 50m altitude and I am happy that turning this off in the parcel options does indeed prevent avatars using HUDS and attachments (when they click it no longer appears to work) BUT llGetObjectDetails() still reports non-zero running scripts and non-zero CPU time and memory through the OBJECT_RUNNING_SCRIPT_COUNT, OBJECT_SCRIPT_TIME and OBJECT_SCRIPT_MEMORY flags with the same values as if scripts WEREN'T disabled. So does firestorm through it's menus (which I guess must also be getting its info via the bridge using llGetObjectDetails() ) SO my question is: Are sim resources still being used to maintain the scripts or aren't they? Is this just a reporting issue with llGetObjectDetails()?

[Sassy Romano]

If a script calls llTakeControls or a script that does is in the same prim as other scripts, those scripts will continue to run and ignore your parcel flag.

 

If the object containing the above is instantiated in your parcel below 50m above land height, the script will not run. Simple solution, fly above about 75m, scripts start up, fly back down, scripts continue running.

 

Turn off flying? Simple solution, enable admin mode in the viewer and that ignore the parcel flag since it's a restriction that is checked at the client.

 

llGetObjectDetails is inaccurate when returning memory use against mono compiled scripts.

 

Loaded scripts still consume sim memory even when stopped.

 

Identical mono scripts share memory (see above about inaccurate results)

 

Mono scripts consume what they need up to 64k, llGetObjectDetails always returns 64k potentially erroneous.

 

Scripts are now hugely de-prioritised from what they were some years ago. I can't recall a recent time when scripts have been blamed as a major cause of lag.

 

For the above circumvents and erroneous reporting and priority changes, you're not really going to gain much.

 

You'd have better results requiring visitors to be using RLV and wearing a relay, at which point you could strip them off several billion polygons of dead weight mesh in onion skinned, over poly mesh avatars and their associated transparency rendering cost.

[Profaitchikenz Haiku]

What does the parcel info tab for script memory give? Ideally it will show you the location of and memory used by all scripted object within the parcel. If it does, it suggests that the scripts are still indeed loaded into the server, as one would expect. In order to check if they are actually running, you need to then try a couple of tests:

1) try attaching or rezzing an object in that parcel that does or says something, and see whatg happens

2) try entering the parcel wearing an object and see if it still operates

 

My expectation (which I can't try because there are too many things that would get upset if I turned off scripts in one of my parcels), is that all scripts for objects within the parcel will still be loaded into memory and show as such, but will not be running.

 

What I cannot predict but would like to know is for 2), does an avatar or object crossing into a no-script parcel nevertheless load the scripts into the memory for that parcel?

[Sayrah Parx]

My guess would be that it's because technically the scripts are still running, as in they haven't been turned off.  They're just simply not given any CPU time while they're considered disabled.  So I think you're correct that it's just a reporting issue with llGetObjectDetails, although it's technically not wrong.  People can bring as many scripts as they want onto a parcel, with the maximum script memory for each of them, and they are only prevented from getting CPU time.  The scripts are still loaded just as completely as they would be otherwise.  As far as OBJECT_SCRIPT_TIME goes, it's calculated by the region and not the parcel.  So my guess is that the scripts were already running on another parcel in the region before being disabled on your parcel.  In that case, it's likely that OBJECT_SCRIPT_TIME would only reach zero after 30 minutes.

[ken Beyaz]

Thank you so much to everyone for replying so promptly and with such useful information I will do some tests as suggested, but it would seem that getting avatars to take off attachments (which would include scripted attachments) in addition to reducing their render weight (clothes, footwear, jewelry, mesh clothes) would make a difference. Thank you for this learning experience

[Profaitchikenz Haiku]

Using the two information tools available to a land owner, the debug->top scripts tab of the region/estate option and the script-info button on the land info floater, I see the following:

 

If a script is running, it will be shown in the top-scripts with a value in milliseconds denoting how much time it requires. The amount of memory it requires is also shown in the script-info display.

 

If a script is stopped, it is not shown in either of the two displays. However, by toggling a script from running to stopped and back again, I am certain stopped scripts remain loaded in memory, since they start instantly.

 

Regarding lag due to scripted objects, trhis used to occur when avatars entered a region and was supposed to be a mono issue with loading the script. It was noticeable back in 2010, but has presumably been fixed since then, as I have not seen any sign of it lately.

I have only one experience of script-lag about two years ago, when there was a gallery event hosted on the island, and suddenly everything stopped. Coincidentally I had the debug-top-scripts floater open at the time, and doing a refresh on it, saw that somebody who had just arrived had a script count against them of more than 2 seconds. Given a typical avatar with a hetfy AO and hair/shoe resizers usially weighs in at 0.3 milliseconds, this one person was equivalent to seven people arriving at once. I bounced them, found we went back to normal in the island, and IMed them to explain that I had been compelled to take emergency measures. They said they didn't know what could be wrong, and I never did get to find out just what they were wearing that grabbed that much script time.

 

Your third tool is the View-Statistics floater, expand the time section of this, and you will see the total frame time the sim you are in broken down into various sub-sections, which may prove helpful.

[Sassy Romano]

---

Profaitchikenz Haiku wrote:

 

If a script is running, it will be shown in the top-scripts with a value in milliseconds denoting how much time it requires. The amount of memory it requires is also shown in the script-info display.

 

---

Just to be pedantic, top scripts time in milliseconds is the time that the script is using at the precise time that the top scripts function checks.  It is not dynamic, nor necessarily an accurate represenation of the time that a script requires!  I know it's one of the only tools that we have but this distinction is important for someone who may not be familiar with it to understand.

Example might be a script in an object on an avatar that has just TP'd into a region.  The script might perform several functions based upon the changed() event which triggered due to the teleport.

If that script performs scanning the region, off SL database calls and many more functions far more complex and time intensive, that scripts might well go to sleep for the rest of the duration of the avatar visit if it's ONLY triggered upon TP.

Thus by looking at top scripts and taking a snapshot in time result at the wrong time, would potentially bias an opinion based upon inaccurate data.  If the same snapshot were taken several seconds later, it's quite possible that the script will be the most inactive.

When looking at top scripts, it really needs to be bashed over and over and over before coming to any kind of reasoning, it should never be used as a static data point.

Similarly, 100 avatars who all happen to have the same set of 10 mono scripts may all be shown as using multiple 64KB memory scripts totalling 64MB  but the reality is that those mono scripts could be just a couple of KB only and if they are identical, they will share memory thus the load could be a handful of 20KB instead of the suggested 64MB that it would add up to.  This is why I loathe the plague of inaccurate script nazi scanners which are completely biased against the more efficient compiled scripts.  They're just brain dead!

Summary, the measuring tools are innaccurate.