Black Dragon and Script Count screen ?

[BlakeStrong9786]

Hey folk.  I'm using Black Dragon version 6.4..13.47815 .   You know in Firestorm there was an option to read the number of scripts you were wearing and their memory usage?   Is there equivalent feature in Black Dragon ?

[Coffee Pancake]

There is no practical reason to look at script memory usage.

It's not even accurate and only indicates the maximum potential memory scripts in an object can use. Almost no scripts come even close to this maximum (getting an exact figure for memory usage of a running script is expensive and bad for performance, so LL don't do this).

This feature in the viewer was added years and years ago, back when for a brief period there was a server side issue with script memory. LL solved the problem back then eventually, probably by purchasing more memory. But, like everything LL do, this viewer feature to see script memory numbers was never removed or updated since.

SL's servers are now running in the AWS cloud, and have gobs of memory, so it's really not a problem anymore.

It never should have been a problem we as users should have been expected to deal with. If LL's servers don't have sufficient memory, that's on them, it's literally their one job.

 

Script memory became a snake oil issue in SL for a while. LL made it really easy for region owners to blame their visitors for poor region performance, and scripters (always happy to make a buck) starting selling script memory trackers to boot the bad memory users, fully aware that such scripts actually hammer the region and reduce performance way more than you having a few KILOBYTES of additional script memory.

 

tl;dr  unless you're a LL engineer wondering if you need to provision more memory for the servers (because that's LL's actual job), or you're a script developer working on a large and complex project (and there are way better tools for doing this), you don't and shouldn't need to care about script memory.

[NiranV Dean]

LL removed the script memory tab for yourself a year or so ago.

[Ansariel Hiller]

Yeah, they did?

Magic!!! 😂

[NiranV Dean]

Interesting, i specifically checked before i made that comment. I remember them removing something in this window (from the commit message) and opening the window reveals that the personal script info was removed, for whatever reason. I have never touched this window, the window is 100% stock so i would not know why the merge would have erroneously removed the wrong tab. I also vaguely remember an upcry about the removal of said personal memory info and other than a toolbar button (and the land info Script Info button) i don't even have an option to open this window.

In any case i can re-add it if it was not removed. Just another thing to add on my todo list.

EDIT: Going through LL's menu_viewer.xml confirms my suspicion that they "removed" it from the above window, they did not however remove it entirely, just made it its own window which got a new menu entry which was not added due to my Viewer having its own custom menu. You'll be able to find it in the next update in Dragon - Edit - My Scripts

Edited July 5, 2021 by NiranV Dean

[BlakeStrong9786]

9 hours ago, NiranV Dean said:

 

EDIT: Going through LL's menu_viewer.xml confirms my suspicion that they "removed" it from the above window, they did not however remove it entirely, just made it its own window which got a new menu entry which was not added due to my Viewer having its own custom menu. You'll be able to find it in the next update in Dragon - Edit - My Scripts

Thanks heaps Nirvan, I'll look forward to the next release.  I only ask as some avatar-intensive events , like dance recitals, ask all attendees to remove as many scripted attachments as possible.  One I attend has a ranking board of script memory.

[Coffee Pancake]

33 minutes ago, BlakeStrong9786 said:

Thanks heaps Nirvan, I'll look forward to the next release.  I only ask as some avatar-intensive events , like dance recitals, ask all attendees to remove as many scripted attachments as possible.  One I attend has a ranking board of script memory.

That ranking board is super bad. Scanning a list of all the avatars and then constantly asking the region how many scripts they have isn't free and consumes more actual resources than the idle scripts people have in their attachments.

It's also wrong - Each script is assumed to be the maximum 64 KILOBYTES in size. They aren't, they are the smallest they can be, right down to only a few KB. On a platform which uses GIGABYTES of memory.

It's also irrelevant - SL operates in a loop, that loop has a set target run time. The loop starts by doing all the important things, and then uses the remainder of the loop to run scripts. If there is a lot of important stuff going on the amount of time left in the loop isn't enough to run them all. Nothing bad happens, just not all the scripts get their chance to run in every loop. The loop can only go over it's allocated time if the other important things are overloaded. Scripts can't do that, they just loose out. 

It (can) also be the worst thing on a region - If the board is set to eject people (and it can be), that triggers the region to stop everything and do the most expensive thing it can do - package up an avatar and send them away. When this is happening, nothing else gets run, no important things, no scripts, nothing. The region literally freezes up while it waits for this action to finish.

 

This whole mess is made more fun by the region sharing time on a simhost with other regions (all regions share). LL pack as many regions onto a simhost as they can get away with. This can mean an entirely different region can make the one you're on run badly! (contacting LL support can get a struggling region moved to a new simhost)

It's also not your problem. Or the region owners problem (although their own build can create conditions where scripts don't have the time to run fully every loop - deleting the script checking board can help fix this!)

[Ardy Lay]

On 7/5/2021 at 6:22 AM, Coffee Pancake said:

That ranking board is super bad. Scanning a list of all the avatars and then constantly asking the region how many scripts they have isn't free and consumes more actual resources than the idle scripts people have in their attachments.

It's also wrong - Each script is assumed to be the maximum 64 KILOBYTES in size. They aren't, they are the smallest they can be, right down to only a few KB. On a platform which uses GIGABYTES of memory.

It's also irrelevant - SL operates in a loop, that loop has a set target run time. The loop starts by doing all the important things, and then uses the remainder of the loop to run scripts. If there is a lot of important stuff going on the amount of time left in the loop isn't enough to run them all. Nothing bad happens, just not all the scripts get their chance to run in every loop. The loop can only go over it's allocated time if the other important things are overloaded. Scripts can't do that, they just loose out. 

It (can) also be the worst thing on a region - If the board is set to eject people (and it can be), that triggers the region to stop everything and do the most expensive thing it can do - package up an avatar and send them away. When this is happening, nothing else gets run, no important things, no scripts, nothing. The region literally freezes up while it waits for this action to finish.

 

This whole mess is made more fun by the region sharing time on a simhost with other regions (all regions share). LL pack as many regions onto a simhost as they can get away with. This can mean an entirely different region can make the one you're on run badly! (contacting LL support can get a struggling region moved to a new simhost)

It's also not your problem. Or the region owners problem (although their own build can create conditions where scripts don't have the time to run fully every loop - deleting the script checking board can help fix this!)

Very helpful.

Now will you be kind enough to tackle explaining why avatars standing on large objects uses more simulator time than either sitting on large objects or standing on the ground?

[NiranV Dean]

54 minutes ago, Ardy Lay said:

Very helpful.

Now will you be kind enough to tackle explaining why avatars standing on large objects uses more simulator time than either sitting on large objects or standing on the ground?

Sitting is easy. When sitting you no longer count as physical object and thus no longer need to calculated physics for, you simply become a static object (or disturbance for other objects that bump into you), this saves a good chunk of resources. I don't remember what exactly was said but i think they said physics are currently the highest cost.

Standing on ground and standing on large objects should theoretically make no difference, whether you are standing on a surface, whatever that surface may be should not matter, you are simply calculated as physical and react as such, whatever that reaction may be (usually just standing still, sometimes sliding off on slopes). A possible reason why standing on ground might be faster is due to the collision for terrain being baked, so its a static cached thing that only ever changes when necessary, this saves time as it does not need to be processed before calculating your physics, objects on the other hand do need to be figured out first since they can change constantly (just like you do). Technically speaking something similar could be done with the navmesh baking but would require a rebake every time an object changes position and constantly moving objects would quickly destroy any hopes of that ever happening unless constantly moving objects are excluded and calculated separately.

[Coffee Pancake]

2 hours ago, Ardy Lay said:

Very helpful.

Now will you be kind enough to tackle explaining why avatars standing on large objects uses more simulator time than either sitting on large objects or standing on the ground?

Consider .. the numbers we get in the client about the status of the server could be wrong, mislabeled, wildly inaccurate or just plain old code that hasn't had any attention since they were first added. We don't know and have to just take them all on faith.

There are also differences in how the physics engine handles terrain, static and movable obstacles.

[BlakeStrong9786]

On 7/5/2021 at 9:22 PM, Coffee Pancake said:

The loop can only go over it's allocated time if the other important things are overloaded. Scripts can't do that, they just loose out. 

Id say your right, how often have you seen an object just plain not work.   I think with events the key  is to just jelly doll as many peeps as you can then watch the show.

[Henri Beauchamp]

Mindful scripters will limit the usable memory for their scripts to what those scripts do need: this will also prevent those scripts from appearing as always using the max allotment memory (64KB) when they actually only use a fraction of that allotment. But as noted in above posts, nowadays, and given the amount of equipped memory per server, I very much doubt memory usage is a problem any more...

Regarding the server-side load, the one and only relevant info for scripts is the amount of time they consume per frame (which is the OBJECT_SCRIPT_TIME figure as returned for each object by llGetObjectDetails()), i.e. how much time the server consumes to process events in the script at each server-side ”frame” (loop). And even then, you must account for the fact that this number is averaged over 30 minutes or so: it is maximal when you arrive in a region (because the script state de-serializing and resuming time is taken into account), and that's why you sometimes see a ”lag spike” when a heavily scripted avatar enters the region where your avatar is present). So, the micro-seconds per frame figure is only getting truly relevant 30 minutes or so after the avatar arrived in the region.

As a conclusion: that floater is of little to no use (a scripted load monitor can do the exact same job) and rather irrelevant most of the time anyway... That's why I never bothered implementing it in the Cool VL Viewer.

[Profaitchikenz Haiku]

On 7/5/2021 at 12:22 PM, Coffee Pancake said:

It's also irrelevant - SL operates in a loop, that loop has a set target run time. The loop starts by doing all the important things, and then uses the remainder of the loop to run scripts. If there is a lot of important stuff going on the amount of time left in the loop isn't enough to run them all. Nothing bad happens, just not all the scripts get their chance to run in every loop. The loop can only go over it's allocated time if the other important things are overloaded. Scripts can't do that, they just loose out. 

I really wish this was a mandatory  click-to-accept popup every time somebody deploys these nagging script-counter devices. (Even though they'll probably just click-through and carry on regardless.)

 

On 7/6/2021 at 6:48 PM, Ardy Lay said:

Now will you be kind enough to tackle explaining why avatars standing on large objects uses more simulator time than either sitting on large objects or standing on the ground?

Interesting, the less-time-sitting is easily explained because the region doesn't perform physics calculations for seated avatars, but I'm puzzled by the difference between standing on large objects and the ground. How do you measure this, and what defines "large" ?

[Ardy Lay]

6 hours ago, Profaitchikenz Haiku said:

Interesting, the less-time-sitting is easily explained because the region doesn't perform physics calculations for seated avatars, but I'm puzzled by the difference between standing on large objects and the ground. How do you measure this, and what defines "large" ?

Rez or construct a typical fancy dance floor that does NOT have the dancer scripts in it. Have the dancers either use their own animations, dance HUDs or a dance machine rezzed that is not the dance floor.  This works best with a "full house".  I had 44 on the floor, including myself.  I used one of the old "color regions" for the test.  I was watching simulator statistics and marveled at how much time was being used for physics.  As a lark, I deleted the dance floor (in my case it was a non-scripted object that looked like a wooden stage with lots of wooden adornments.  Construction was 43 prims.  None were sculpted but many were "tortured".  Only three 512x512 textures were used on this object, ripped wood grain, crosscut wood grain, and tree bark.  Overall diameter was about 14 meters.  When the group standing on the thing dropped about 1 meter to the ground, the simulator physics time dropped too.  The drop in time used for physics was to about 1/3 of the time being used before I deleted the dance floor AND time dilation changed from 0.78 to 0.98.

I should try to gather enough volunteers to reproduce this now SL is on AWS.  It's hard.  Took 3 weeks of planning and advertising it as a holiday dance party in the park with a well known club DJ providing music and games to get the turnout I needed.  I let them have their party, and, the DJ and I worked my removing the wooden floor into the show by rezzing a cornfield around the dancers!  (I thank the person that was known as Blue Linden for the corn.  It was a hit.)