[sldev] Script/Parcel/Memory Limits - Memory Limit Configuration

Tigro Spottystripes tigrospottystripes at gmail.com
Mon Dec 28 21:46:15 PST 2009


how about : http://jira.secondlife.com/browse/SVC-5199  "event before
somthing is done to a script that is using more memory than it should"

put an llEmail or llInstantMessage or even llSetText or somthing else
that changes the appearance of the prim, in the event and you will know
if the script is not runing anymore/got downgraded into sporadicly
running when there is iddle time on the sim or whatever happens to
scripts in such situation,


Darrius Gothly escreveu:
> Another issue came to mind as I was reading this ...
>
> How does anyone know the script has been disabled? I mean, what's to 
> indicate it's a system-imposed "malfunction" vs. one that just happened 
> because the script hit a bug? And "screaming on the DEBUG CHANNEL" just 
> isn't sufficient because the owner may not even be logged in when the system 
> disables the script. There has to be something plainly evident (at least to 
> the owner if not everyone else) indicating the object has been disabled by 
> the Sim/System. Perhaps one of those little floating icons like is seen when 
> there is a script error, but that stays around until the object is deleted, 
> taken or returned ... or restarted. And of course that will require an 
> additional attribute per Prim.
>
> ----- Original Message ----- 
> From: "Kitty" <sldev at catznip.com>
> To: "'SLDEV'" <sldev at lists.secondlife.com>
> Sent: Tuesday, December 22, 2009 10:41 AM
> Subject: Re: [sldev] Script/Parcel/Memory Limits - Memory Limit 
> Configuration
>
>
>   
>>>       [3:42]  Babbage Linden:  that will include functionality for
>>> finding and returning scripted objects
>>>
>>>       [3:42]  Babbage Linden:  so everyone will be able to find and
>>> clean up the scripts they don't need
>>>
>>>       [3:43]  Babbage Linden:  before we start enforcing limits
>>>
>>>       
>> I would hope that simply refers to what you can do today with the "Top
>> Scripts" floater (highlight a scripted object + click return).
>>
>> Otherwise you'll get chaos where someone checks their sim the day before 
>> the
>> roll-out, finds that they're within the limit, goes to bed and wakes up to
>> dozens of auto-returns because some other group member decided to rez some
>> new script-heavy toy they just bought which pushed it over the limit.
>>
>> Expecting every land or group owner all over SL to turn off build for
>> everyone for a few days is simply not realistic, particularly given the 
>> fact
>> that only a small portion of residents reads the blog which is only in
>> English.
>>
>> Given the high failure rate of return in general if sims all over the grid
>> start auto-returning prims then a good portion of those will go *poof* and
>> never return to anyone's inventory. That alone should be enough to not 
>> even
>> consider auto-returning anything.
>>
>> Objects should simply get their scripts disabled and then the owner can
>> decide to leave them around "script-less" or take them back into their
>> inventory or do something else to get them working again.
>>
>> Similarly rezzing should never fail because of script limits because that
>> would make it rather impossible to fix objects after the script limits are
>> in place. Or someone will be working on something, drop in a new script, 
>> the
>> parcel hits its script limit, the prim gets auto-returned and then can't 
>> be
>> rerezzed.
>>
>> It would also be very fun for updaters: rez the updater, updater drops new
>> scripts into the older version, which then subsequently gets auto-returned
>> because the limit is reached and ends up broken because it's half-old and
>> half-new. Things won't improve if the updater gets auto-returned since 
>> it's
>> the last to have been rezzed, or if it gets its scripts disabled halfway
>> through.
>>
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/SLDev
>> Please read the policies before posting to keep unmoderated posting 
>> privileges
>>
>>     
>
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
>
>   



More information about the SLDev mailing list