Reduced return to inventory

Subconsiously I have been, I guess. When I saw the thread and the proposed idea is occured to me that I wanted it and had been wanting something like it. Though I did use the message from the system one time to gauge a grey-goo like script (it was ungodly slow though, one rez in 5 minutes and it wasn't supposed to goo, just keep a prim in existence for longer time period than the auto-return).
Due to the auto-retrurn message I was able to write the script properly, otherwise it would have looked right and it would have been gooing up unkowingly (silent kills on autoreturn).



Delete rezzed doesn't got to Trash, I've been wanting a bit, but I have needed to undo that on occation. For both reasons mentioned above.

Lag and performance problems are just as deserving of corrective action as bugs are.

If this change helps improve inventory download times, reduce demands on the asset server and cut in half the amount of processing required when cleaning up tens or hundreds {of thousand} of grey-goo objects, then I think it's well worth the few moments of consideration to make this policy change.

--
No one "cries out" for new tires until they get a flat.

I've actually been complaining about it recently.

I like your proposal Andrew. But why not go for the gold. Lets get rid of the trash permanently. It is not an insignificant problem. I have 10,000 items in inventory and have seen many times when I didn't stay on top of it where between trash and lost, there would be 5,000. That comes up to 1/3 of all items in my inventory that the server is having to keep track of.

If we low balled it to an average of 1/20 of inventory for everyone in SL then it is an enormous number. If I am not mistaken there is a confirmation that pops up asking on deleting no copy items???

Time stamp items in trash and then auto delete in say 72 hours???? Even autodelete in one week would help considerably. That way there would be a safety in place. Time stamping and perm delete is used by some other programs including some email.

Incremental improvements are sometimes the way to go as long as you think out where you want to go.

I'd start by making the system treat the returned objects as if they went off-world.

if (( STATUS_DIE_AT_EDGE == TRUE) &
(STATUS_RETURN_AT_EDGE == FALSE)) {
llDie();
}

If that is too harsh, put the objects into the trash instead of the normal inventory location and add a system that prompts the user to empty the trash when they log in if there are more than x items in the trash.

Ok, thanks for the input.

It appears that the work required to change the system and keep most people happy is more than I could do in a day or two, and I'm already full up on important work for the next month or more. That doesn't mean it will never get done, but the project just lost a bit of steam.

I'll document some of your suggestions on the internal item in the big list of things to do (BLOThTD) and see if I can round up some votes and get a couple of developers excited about working on it.

My Fireflies keep "falling off the edge of the world" and being returned either automaticaly or manualy when script lag lets the physics engine carry them beyond the script`s ability to recover. My latest breed has features to ameleoriate the situation, but I WOULD like to have the option of being notified that something happened without having my inventory clogged up by unneeded returns. In my case, I do not have a central rezzor to add a sensor to.That`s not the ONLY reason to want to keep the notices when something would have been returned the old way.Agreed.

Idea, Andrew: perhaps you could add an on_delete(integer Why) event that can be run before a delete is finalized, which could send out any required notifications, and the flag could be checked again aftwerwards, in case the object decided it would rather be returned after all? Such a handler would necessarily be limited in what it can do, as the delete would be finalized [one way or the other] as soon as the event concluded, without time for secondary events to trigger.

Where would that script run if the object went off world? =)

One problem that should be addressed..

Dropped attachments.

If I have an object.. for sake of argument, we'll call it "Object" (as most of my objects seem to have this name). Now I've spent a week on and off, carefully crafting my object as a very special addition to my avatar. Perhaps it's an AO.. or a multi gadget, a personal equipment rezzer, whatever. Now because it's so complex, I've been careful to delete outdated copies of the thing. Emptying my trash regularly to get it "just so".

Now I'm wearing it, and I go over to a freind's place.. and he gives me an animation to add to my AO.. I'm excited, and so I drop my precious device on the ground, straight off my avatar, and start searching my inventory for the animation he gave me.

Unfortunately, I've forgotten to set my group flag to his land's approved group, and in a woosh, the system autodeletes the alien object. Since it is copyable (I made it after all), and since I haven't yet modified it.. my precious cargo, and all it's contents, are gone. Not in my trash, not in lost and found... and even being copyable, because I was wearing the current version and dropped it.. there is now not a single instance of the object in my inventory.

The proposal seems to work fine in every instance but this one.. and the only way I can find a solution, is if "dropping" a copyable attachment would return it to inventory and THEN drop a copy of it (or drop the object on the ground and "auto take-a-copy" of it) But that's not how it works. Perhaps that should be changed as well to make this really sensible mod work?

I know I'd be thrilled to stop getting "[REZZER ITEM - DELETE ME] Chair" back 100 times over.

No problem Andrew. It was an idea that had some unthought of flaws that the resididents saw in ways they interact with the auto-return currently (and trash, etc.). I'm sure when we all agree on a system that works and it gets done it'll work BEUTIFULY and we can all join hands and dance and sing.

Ok, maybe not.

I like the STATUS_ flag, though it would be nice to be able to set that via the edit interface.

Agreed. Even if I have to go into some "advanced" tab, that's so much less of a hassle than muddling around and writing a script every time I want to turn one of these flags on.

At the off-world location in the sim it went off-world in, of course. If this means that some functions don`t work "as expected", so be it.

Kelly-

In the case where someone buys something from a vendomat...
and then does a wear->drop... the copy dropped is one that was
created by the vendomat, (obviously removing it from inventory.)

Does that count as script rezzed or not?

Well, that might work, but I'm still a little nervous. If it's ONLY autoreturns that are affected, that could be okay, but I'm kind of nervous about whether over-prim-limit returns might also fall into this category. If they did, think about this scenario:

1. I build a fancy convoluted structure using an automated building tool like PipeMaker (script rezzed prims), and link it.
2. Someone screws up parcel management and we go way over on our prims.
3. My structure returns because of prim limits (not autoreturn).

Especially if that happened on the mainland where a rollback isn't possible, having that returned copy of my structure could really save my butt. The thing is, you said that part of the stimulus for doing this is to help reduce load in grey-goo attacks. Aren't a lot of the returns in grey-goo attacks from parcels going over their prim limits, not just from autoreturn?

Anyway, here's another scenario:

1. I'm on my group's land. The autoreturn is set to 30 minutes or somesuch.
2. I accidentally have the wrong group title active.
3. I build that same fancy pipe structure and link it like before.
4. Autoreturn time comes, and my structure is deleted.

That pretty much sucks. I forgot to set my group title, and since I built something that was rezzed by a script and the prims involved are copyable, when the autoreturn I didn't expect to happen came, my structure was deleted, with no hope of recovery. I'd have to start over. At least if there was some tracking to see if the structure had been modified by an avatar, this might have been avoided.


These examples are a little contrived, but what makes me nervous about this whole business is what I can't think of off the top of my head. I get nervous when there's talk of deleting stuff completely, because if you're not totally prescient, someone could get stung. And what if there's a little bug? I know, it's not fair to ask that, but I'll do it anyway: if there's a tiny little bug in this, lots of content could get lost. At the very least, a feedback message saying my object was deleted is pretty crucial, so I can tell what happened and avoid it in the future.

Here's an idea... can you warn the avatar if they're in the sim, shortly before such an object gets deleted?

Lex, thanks for thinking about the various scenarios. I can identify with that feeling where you have nagging thoughts that you've neglected to think of some catastrophic corner case.

The over-prim-limit path has a distinct trigger from the autoreturn, so will be unaffected by the logic that Kelly proposed.

That said, I'm working on some experimental changes to how objects are returned when over the parcel prim limit. I'm adding over-the-limit returns to the grey-goo-throttle such that return events contribute to the grey-goo score and would therefore help bring the fence into effect if a lot of objects are being returned for parcel limits. Of course, a misstep in parcel ownership can cause a very large number of objects to be returned in a very short timeframe, however here are the rules for reducing any collateral damage in this case:

An over-prim-limit return of an object would contribute to the grey goo fence throttle if the object...

1) was rezzed from script
2) is copyable by its owner
3) was created recently (within the last few minutes)
4) belongs in the parcel's 'other' category (no matching group affiliation with parcel, nor owned by parcel owner)

Such an object would still show up in inventory lost and found... until it actually triggered the grey goo fence, at which point future returns would simply be deleted (incidentally this little hidden feature is already deployed to the grid).

The scenario of accidental wrong group on a group-owned parcel with autoreturn enabled would be true collateral damage, however two things:

(A) The logic could be changed to return to inventory those objects that had been manually manipulated after their rez, which would eliminate the scenario as you've described it since you included the manual link operation.

(B) The object was created using a automated build tool, which implies that it shouldn't be too hard to recreate it. Of course, someone could come up with an autogenerator that builds a truely unique and fantastic work or art every time, and it would be a shame to accidentally lose such an object, but I would expect the overlap between such objects and accidental parcel manipulations to be very small.

Okay, that sounds a little better, thanks for clarifying that a little. I think your A) is pretty necessary. The link operation was because otherwise, something would be returned in pieces and essentially useful, so there's definitely an implied manipulation for returning to be really useful. Kelly did specifically exclude the modification checks in the most recent proposal, but I think that's a pretty important safeguard, if it's feasible.

As to what kind of object created by an automated building tool would be actually useful, I'll send you both a copy of PipeMaker. In short, it helps you build "pipes" out of cylinders and torus-segments, doing some annoying math in the script to line each successive piece up nicely. You can specify torus radius, arc length, and rotation around the circular joining face. So one could conceivably spend a fair amount of time making a nice little pipe maze and doing some trig to make the start and end of the pipe series line up, and losing that to unexpected deletion would be annoying.

Builds created by "ringmaker" or using Rez-fu? Builds rezzed for sale in-place? Perhaps this could be reset when you "Buy..." something.
That would work, too... it's a more general version of the same idea. I thought Kelly had ruled that option out, though? Would it really be so hard to implement?

And I would still like to be able to explicitly set the flag... on vehicles, for example... through a script or in the object editor. And in the latter case it should be settable even if the object isn't modifiable.

From what I understand is that the act of LINKING those prims together counts as a "modified" event for the object and would not be deleted by the suggested rules set.

Kelly's proposed rule set is:

Nothing about "Modify" there.

Andrew's rule set for the grey goo fence considered that option (option A). We're just concerned that the two Lindens pull together here and *do* include the "modified" rule.

Try post #5

Go read Kelly's post again. It explicitly says that modification wouldn't be considered for auto-return, and it's more recent (and thus more current) than Don's.