[sldev] Static universal memory limits are operationally non-scalable
Stickman
stickman at gmail.com
Sat Dec 19 07:14:16 PST 2009
On Sat, Dec 19, 2009 at 6:36 AM, Robert Martin <robertltux at gmail.com> wrote:
> As a sidebar to this issue what if LL would identify scripting cases
> that can be replaced
> or minimized in memory useage/runtime and then work on doing so
Excellent idea. This is something Babbage specifically asked for, too.
> just in avatars you have several cases to work with
> 1 Tinies: have an avatar shape that is say 0.3 meters tall to 1.5
> meters tall (yes this will also allow for better child avatars)
> 2 Quadraped/Digitgrade: have a shape that is 4 footed
The "proper" solution is custom rigging and mesh support. I would
rather wait until LL gets around to doing that than receive a halfway
solution.
> 3 resize scripts: this can be solved by having a [halt script/done function]
You can delete a script after it's finished. The new
llSetLinkPrimitiveParamsFast() function, if paired with a tiny
llSetScriptState() script to shut it down when not needed, would be
just as effective.
Though I can't really recommend llSetScriptState() unless I know it
unloads the memory. I'm not sure how much of a not-running script is
stored in memory.
If the functions don't work as intended, and it's undesirable to
change them (eg, there's a noticeable lag time in reloading the script
into memory so it can execute again) then a new function like you're
suggesting is assuredly a good idea.
> 4 bling/particle emitters/type animations: these could be flagged for
> the first ones to be halted
> if the sim needs memory
Particles are a prim property and are clientside. After setting the
particles via script, you can delete the script and the particles will
continue to function just fine. Same with texture animation, and I
think llTargetOmega()? Or does omega reset on rez? llSetText() is also
a prim property -- set it via script and delete the script, and it
sticks with the prim.
Prim properties have little to no effect on the server, so there's no
reason to handle them in this case. But they are certainly a candidate
for cleaning up client-side visual lag issues. We've even got a slider
for number of simultaneous visible particles in our preferences.
> 5 translation huds/devices: could somebody please build this into the client
It's in Snowglobe. It and many other things really, really need to be
pushed back into the main viewer. I don't know how that's supposed to
happen, but some sort of magical process is hopefully in discussion.
> is if the sim starts getting "tight" then script halt and derez the
> highest NON parcel/sim owner avatar and all objects owned by this
> avatar.
If the choice is made to stop things, which has been argued against,
then stopping and removing things in the order that prims are returned
may be a compromise, though will still cause some problems, like the
actual prim return does.
I'm holding out on saying which method is best, because I don't
consider myself very learned on the topic. Until I can see what's
going on with these new script management tools we're going to get, I
don't want to hedge my brain down one path.
Lots of great ideas being said, with good points, and good counter-points.
-Stickman
More information about the SLDev
mailing list