Reduced return to inventory

I was brainstorming with one of the other developers and he made the following simple suggestion:



There are a few advantages of such a rule, the primary being a reduction of cruft in many people's "Lost and Found" folder. We tried to come up with some serious disadvantages but couldn't come up with much.

I figured I would throw it out to these forums to see what you all think. If no one can come up with a compelling reason to return copyable script-rezzed content to inventory then I could roll this change in with some other stuff I'm currently working on today.

I would agree with this Andrew and go one further. Why return ANY copiable item to inventory at all ? It seems really redundant as when you manually rez a copiable item as well, one generally stays in the inventory also, no?

If that was done, implement a FLAG_CHANGED, so that if the rezzed object was changed at any point by the owner (or anyone who has change permission on it) then it DOES NOT count as a copyable object rezzed from inventory as it is now a unique item (say the owner rezzes it on a 10 minute auto-return to do a bit of script fiddling and figures it'll take 1 minute to change, 5 to test and it ends up taking all 10--he'd be pretty upset if the auto-return kicked in and DIDN'T return it to lost and found).

For some of my stuff is rezzed via script, because it's easier to have a script rez it, rather than to place all objects by hand.

Everything is structured so that you shouldn't ever have it auto-returned to you. That is to say, if it's autoreturned to you, something is wrong with how you've set up your parcel. (ie. too close to an edge, something disasterous happened with parcel prim quotas, etc.)

The autoreturn notification lets me know that something went wrong. I'd rather not go back and discover that parts of my build are missing or anything.

What about creating another rezobject call?

ie.

llRezObject(string inventory, vector pos, vector vel, rotation rot, integer param, integer allowAutoReturn)

That way people who know they want the autoreturn can keep it.

What about only returning an object to inventory if:

1) It was rezzed directory from a resident's inventory
2) It was manipulated by a resident since it was rezzed.
3) It is not copyable

Creating yet another rez object call to mark it as allowing autoreturn would probably defeat a lot of the benefits to this change. For example, victims of certain grid attacks may find their inventory unusable because of the number of returned items in their lost and found.

What about just an llSetStatus flag, like STATUS_DIE_AT_EDGE... STATUS_LOST_AND_FOUND? I constantly get bothered by trams being returned to me whenever there are issues in Caledon, and I would really love to be able to stop that happening and be able to actually use IM-to-email. On the other hand, sometimes you do want to be able to access an object which was killed by a return, and see what state it was in at that point. I think a settable flag would be ideal.

A copyable item can have state, it can be edited. I have had vehicles I was working on returned to my inventory and been glad of it.

For copyable script-rezzed items, though, you are less likely to be editing them. Just as long as editing it, or taking a script-rezzed object into my inventory and rezzing it again removes the flag.

Alternatively, make this a flag on the prim that you can set in the editing box (not just from a script), and that defaults to "off" for manually-rezzed objects and "on" for script-rezzed objects. Just add a checkbox for this and "die at edge" below "locked" and above "temporary", and have it set by script calls or rezzing type... that way you can change it for special cases and see what it's set for now...

From my perspective, no return of copy items rezzed from inventory, would be a very useful feature.

This is true, hadn't thought of that.

Ok, how about the following proposal:

1) Add a per-object setting STATUS_RETURN_TO_INVENTORY. When TRUE the object is returned to inventory whenever it is returned or deleted by a parcel autoreturn, by some randome parcel-owner, of by any other automated system return. When FALSE the object is just deleted whenever it is removed from the world.

2) STATUS_RETURN_TO_INVENTORY = FALSE by default for non-modified copyable stuff either rezzed from inventory or script. STATUS_RETURN_TO_INVENTORY = TRUE always for non-copyable objects and set to TRUE for manually created or modifed objects.

3) STATUS_RETURN_TO_INVENTORY can be changed (when not disallowed) by the llSetStatus() LSL call

4) Add a per-inventory item setting "return to inventory" (defaults to FALSE) that when set TRUE can override the default FALSE value when the corresponding item is either rezzed from inventory or script.


Does that work for everyone? If not, how does it need to be changed?

That sounds to me like a good way to try out the feature. I like the compromize.

How are you defining non-modified in relation to scripts in the object? If the script does something will that count as the object being modified?

No. Non-modified means that the object has not been manually modified using the SL client's UI tools. Any script that wanted to be returned would have to set the STATUS_RETURN_TO_INVENTORY bit.

That works for me, can't see anything wrong there.

I was bouncing these ideas off of some of the other developers in the lab and Ian pointed out one of the reducible loads on our asset system (and garbage collection therein) is that every time someone deletes an object it shows up in their inventory's trash as a new asset. He suggested that deleting an object should just delete it (unless it is uncopyable, I suppose) and only add to inventory objects that were taken (or taken as a copy).

So now I'm wondering about how much that would change the system and how much work it would be to implement that. I suppose if we were to make that change then we would also have to add an undelete feature. If you have comments on that idea please add them to this thread.

I think thats a good idea BUT heres the deal

You will have alot of work to make this a reality and Im sure that there will be times when someone DOES want a copy item returned. For example a copy item that has been modified. I believe that this functionality will result in alot of lost items esp if a NO COPY item gets purged ( stupid bug)

If I understand the previous post----
What I feel might be a better solution is the ability to put on any object or linked set a checkbox named return to inventory, If the object is to be returned do it
otherwise send it to never never land.
If you do this instead, then the user can decide what to do and it won't be on your heads if something gets "accidently" purged. I am not familiar with your database but i think this would also result in less coding and you wouldnt have to consider so many variables.

Simple. Just make it follow the same rules as the new autoreturn, new flags and all. Delete any unmodified? Gone. Delete any modified? Trash. Want to decide for yourself where it goes? Manually toggle the flag. Works for me. I don`t see as this requires any significant changes to the system, and it uses an Undo that we ALREADY have. Oh, and make this flag settable from Properties in Inventory, too.

P.S., I`ve been wanting some way to do this delete-without-trash for weeks now. [I`m only ninteen weeks old, as I type this. ] I`ve even gone so far as to write my own Instant-Permanent-Delete SCRIPT for deleting things. I drop it onto things instead of using the Pie menu Delete. Only thing is, I cannot use it on Copy/NoMod items. I`d hope that the new system would allow me to set the NoTrash/NoReturn flag on NoMod items.

Which makes me think, if an item is SOLD with the NoTrash/NoReturn feature enabled, should we be alowed to clear that? Hmm.

I was going to say that it might be nice to have the option to be notified if a "don't-return-to-inventory item" vanished... (Because I seem to be having problems with my own "copy-rezzed-from-object" items being returned to me by my own land)... but there are simple work-arounds. (I could always just add a sensor in the rezzor to see if it needs to summon another.)

Some might miss finding out where someone else's weapon's mal-formed projectiles finally end up going off world... but that's hardly a reason to keep the old behavior.

Sounds like a very helpful mod.

I can't count how many times I've accidentally deleted something in-world, and pulling it out of my trash folder saved the day. I also have had many occasions where I modified something irrevocably in-world (sometimes due to a bug) and the only way I saved it without entirely rebuilding it was to start pulling copies from my trash until I found a recent copy. Usually the recent copy came from me shift-dragging the structure and then having second thoughts and deleting it. Sometimes the deleted copy I pull out of my trash wasn't even deleted in the same SL session (think about crashes), so undelete wouldn't necessarily save the day.

Maybe reduce drastically the lifetime of trash items? I think maybe the answer to that is "that won't help the fact that an asset has already been created and stays around even when the inventory is purged"... but think about this: the trash folder probably holds unique references to assets. Any time you rez a trash item, the inventory item itself either disappears (for no-copy items) or moves out of your trash, right? So, with some extreme caution, it might be possible to instantly garbage-collect purged trash.

I can think of one big reason why returning copyable items rezzed by a script would be desirable, and just blowing them away wouldn't be: building tools. Think about the ShapeMaker, or my PipeMaker. They both rez items from their inventory and align them into nice little structures specified by user commands. If I just spew out a dome with ShapeMaker and link it together and wander off, and hten suddenly my sim goes nuts and returns everything, I'd really want to be able to dig through and find that thing I just made. It'd be gone after a rollback, so the returned copy would be all I had to work with.

I think your rules for always returning anything that's been modified by a human should handle that, Andrew, but I'm a little nervous. Presumably the step of linking the pieces of the structure together would make it so it returned, and if I didn't bother linking the structure together, it'd just return as a useless heap of prims in my inventory, making returning them pointless... so it seems like a good plan on the outset.

I think what I'm going to do is keep track of every time something gets returned and that saves my butt, and see if it would still have gotten returned based on these new rules you're proposing.


One thing only briefly touched on by Francis Chung here is the concept of user feedback. Sometimes I like that I can return the 100 prims left by some jerk in my sim, and they'll get spammed with return messages, and that'll teach the bastard not to leave things in my sim, bwahahaha ;) I know that when I was a newbie, getting stuff returned to me taught me that I needed to clean up my toys better. Perhaps a message letting me know that something of mine has been deleted from some land somewhere would be very much in order. Along with providing feedback, it would help flag quickly whether something has gone drastically wrong, and perhaps if something's critically important, a temporary rollback can be done to retrieve the lost item, or something.

I prefer the extended rezobject call myself:
ie. llRezObject(string inventory, vector pos, vector vel, rotation rot, integer param, integer returnToInventory)

The reasoning being:
1) Things that are rezzed are not necessarily scripted.
2) This requires you only modify the rezzer, as opposed to every single thing you might want to rez.

edit: Forgot to say, I am very much against "things that you delete not showing up in your trash".

I can't count the number of times that I've accidentally deleted something and restored it from trash.

This is especially helpful, because SL's UI is somewhat ambiguous at times. "Did you mean to delete an item in the object's inventory or the object itself? Oh well, I'll just delete everything. You lose."

Checkbox on the editor so you can set it manually for unscripted objects.

As for an extended llRezObject call, I don't like changing the API for the existing code, and I don't really think that's possible without breaking all KINDS of code. You'd be better off adding "llRezTemporaryObject()" with a bitmap option to let you specify what "temporary" meant for that object: Temp On Rez, Die At Edge, or No Return To Inventory (or a combination of them).

Whatever you do, don't let it hold up llTeleportAgent().

Or better yet, "Did you mean to delete the text in the chat bar, or the object you're editing? Well, I'll just delete the object you're editing."

While it's extremely nice to see Linden/resident interaction on this - was anyone crying out for this new feature to be developed?

Thought not.

How about addressing the numerous bug in the game instead?

Think about it please...