Nah, I didn't confuse other people returning objects with the system
returning them. But you do raise a good point, and one that I think needs
"official" clarification.
If, as you read it (and you make a good point too), the "Item Return"
procedure is limited only to the day they switch limits on, then that's a
reasonable one-time hit that people will just have to live with. On that, I
totally agree. However, the whole issue of returning objects has been tossed
around from so many angles that there is no clear definitive statement as to
exactly what they intend to do.
I also have issues with "stopping scripts" when memory limits are exceeded.
I have several devices that perform a sequence of database updates depending
on options chosen and other conditions. I have done as much as
programmatically possible to "batch" these transactions so they cannot be
interrupted mid-update, but with LSL and its external access capabilities,
that isn't always possible. Some of those situations could result in massive
failure, perhaps even loss of money, if the updates are only partially
completed. (Yes, I'm being a bit extreme, and yes, I've made double sure my
devices cannot fail that horribly, but not everyone that scripts is skilled
or experienced in DB/transaction philosophy.)
LL really should consider an option on an Object called "Do Not Suspend",
perhaps limiting that to 1 Object per 100sqm or some such, so critical items
such as remote deposit boxes, ATMs, and other money handling devices cannot
be suspended at all. Maybe the presence of a money() event and the
http_response()/http_request() events in a State would exclude that script
from suspension eligibility, although that would open it up to abuse as
folks would just put those events in every script state to prevent
suspension no matter what.
----- Original Message -----
From: "Carlo Wood" <ca...@alinoe.com>
> On Tue, Dec 22, 2009 at 07:08:38AM -0500, Darrius Gothly wrote:
>> llEndScript(integer die=FALSE); ? Or maybe a parameter with constants:
>> ENDSCRIPT_END, ENDSCRIPT_RETURN, ENDSCRIPT_DIE
>>
>>
>> The comment about "returning objects" comes from Babbage's office hours
>> on
>> the 9th of this month where he makes a comment about it.
>
> Haha, if that is true - then the average IQ on this list
> is a lot lower than I had expected. So, Babbage says:
>
>> [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
>
> which means that IF they would implement a new LSL function
> called llEndScript that allows one to pass a parameter "ENDSCRIPT_RETURN"
> THEN (after adding that to all scripts) one could have a script return
> the object it is in (as function of detected circumstance, like not
> needing the script to run or exist).
>
> And then people think that if I mention "dynamic limits" that that means
> that if a script that is running and then can't run anymore because it's
> memory is needed by a script with a higher priority, then the first
> script is automatically returned by the server...
>
> Those those two have so little to do with eachother I don't know where
> to begin to draw a parallel that shows how little.
>
> So, to be clear: No those are TOTALLY different subjects. And I never
> said that objects had to be returned. On the contrary, that would be
> a poor implementation as well. The simplest implementation that is
> reasonable is to stop scripts that lose their memory (so they would
> have to be manually restarted), and refuse to start scripts that don't
> have memory at that moment, and probably to refuse to rez objects
> with scripts that wouldn't have memory. However(!) that is a rather
> poor implementation as well. A lot better would be to stop scripts,
> but swap them out to harddisk to preserve their state and automatically
> resume where they were once there is memory again. Even better
> would be to tell the scripts that they are swapped out and let them
> deal with that fact at a very low pace (where one could then do:
>
> state_stasis {
> llEndScript(ENDSCRIPT_RETURN);
> }
>
> in the chickens of my chicken-shoot example ;)... cause I'd have
> no problem with the excess chickens to disappear.
> Hopefully that isn't going to confuse people.
>
>> However he does add just after that ...
>>
>> [3:44] Babbage Linden: no one else can see or return your
>> attachments
>
> They are not asking people for input... they're just telling you
> what is already decided. Nevertheless, I fail to see what this has
> to do with our subject, unless you belong to the confused and think
> now that someone else would return the objects of others when
> they enter the sim and need memory HAHAHAHA.
>
>> And then goes the other way 10 minutes later ...
>>
>> [3:53] Babbage Linden: Jack is going to be communicating this to
>> people
>>
>> [3:53] Babbage Linden: when the limits are enforced, you will end
>> up
>> with objects being returned
>
> Sorry, but that is not "the other way". Objects being returned by the
> system is not the same as objects being returned by others.
>
> Also, this refers to a one-time moment: the moment the limits are switched
> on, objects will be returned to force you within your limit. From that
> moment
> on you will never be able to rez the same amount of objects (with scripts)
> again, you will not be able to use more than your tiny share, even if the
> server is totally unloaded; so after that is not needed to ever return
> objects.
>
>> [3:54] Babbage Linden: but hopefully everyone will have enough
>> time
>> to manage their attachments before that happens
>
> Semantic translation:
>
> no reason to shout that returning random objects is unfair, because then
> you should have decided what jewels and/or other attachments you are
> wearing
> now to delete yourself, before we enforce the limits.
>
>> So, yeah, I can understand why people are concerned.
>
> Well, you confuse the "fixed limit" approach that LL is going to force
> down our throats with no means to chance anything about that, which will
> only return most of your objects once,... with the "dynamic limit"
> approach
> that was proposed, where objects are never returned and only stop
> running temporarily at those moments that the sim is REALLY loaded too
> heavily.
>
> --
> Carlo Wood <ca...@alinoe.com>
>
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges
