making the case for llReturnObject(key id)

Currently, there is no way to return all objects in a sim owned by a particular person or return a single item via script, except by screwy hacks.

The reason given for this is that a script function doing this is a drain on the server.

In fact, this would lighten the load of a server. Right now, instead of doing this with a function, land owners have to use the land tab or right click an item. They do it anyway, so there's no less of a drain on the server by forcing them to open the land tab.

In fact, the land tab grabs more server data than merely objects, which means a land owner that is regularly returning objects (such as in a sandbox) will be running that land tab regularly.

Perhaps the dev group believes it would add more work to the server because more people would be using the function if they didn't have to open the land tab?

Maybe, but at the same time, doesn't it also mean those servers would have that many fewer prims sitting around as trash? Weren't we told it is desirable not to have lots of extra prims sitting around, since the server has to process for each one?

I never understood why either. We have llRezObject which creates NEW objects, that's a heavier load than llRemoveObject could ever really give. Unless an object tried to rez things and then remove them to try and cause a crash/failure; but that's easily remedied by making it usable on your own land only (since there's little demand for removing your own items from someone else's land anyway).

You can read through http://blog.secondlife.com/2006/11/06/getting-technical-auto-return-time-increase/ for some insight on why returns are "expensive".

In the comments (partial quoting):

Can't you just bring up the objects tab on About Land, and select Joe Blow and return all his objects? Why do you need a script to do this? And if you are trying to return objects on land that's not yours, I don't think that should ever be possible.

Though I think landlords who care about security could at least hire someone to take care of the place, I wonder if something like llBanAgentAndReturnObjects would be okay?

Ooh, good links, Kitty. I was getting all geared up to explain why LL is avoiding implementing this.

Just to play devil's advocate...



I can actually think of a very good reason for this kind of thing. It has to do with how the autoreturn and group-sharing system currently works.

I have a sim that my group and I built. All of the structures in the sim were built by us, and we share everything with our group so that we can all modify the buildings. The main plots in the sim are set to autoreturn, and the land is owned by the group, so our build doesn't get returned.

We have a building set aside for vendors, and it's on its own plot. The plot has our building on it and the vendor objects owned by our vendors.

We'd really like to have autoreturn, but we can't. We can't invite the vendors to the same group that our buildings are set to, because we don't want them to be able to edit our buildings. We can't set our buildings to the Vendor Group, because, again, we wouldn't be able to share them with each other. Since there are objects on the land that are set to two different groups, we can't set autoreturn, because one of the sets of objects (our building or the vendor objects) would get returned. So we're stuck, no autoreturn.

Having a function like llReturnObject might let us hack together a script that returns stuff that doesn't belong there. It wouldn't be a perfect solution, though.

Thanks for the explanation, Lex. In a situation like that, you're right.

There is an alternative actually, and in your case (Lex) would be exactly what you wanted. I posted it to the JIRA a while ago but is one of those things that just doesn't seem to get much attention for whatever reason:
http://jira.secondlife.com/browse/VWR-174

Basically the proposal is to have the allowed list for a plot of land exempt from auto-return. So if you're on the allowed list, then your items won't get returned (if the option is set). This idea basically requires then an extra check on auto-return, or on object rez (depending when it performs the check), which does a look-up against the allowed-list, making sure the list is a hash-map or something else that can be looked up really quickly would help a lot there.

This is good because we already have LSL functions to add/remove people from the allowed list, allowing a fully scripted solution to be implemented.

As I said, if one can do it by the menu, why can't one do it by script? What is your problem that we shouldn't be able to do it by script?

and no, I'm not trying to do it on land I'm not authorized to do it.

Why do we need a script to do it? why do we need scripts to do anything?

If you'd actually bothered to read the blog post by Kelly, you'd know since the infrastructure hasn't really changed since then yet.

I would like to see a way to FIND objects on the parcel.

My biggest issue is not returning objects, but finding those tiny ones that won't appear unless I am within 10m of them. I can't just return all of there objects just because he/she/it dropped a small prim someplace.

llGetParcelPrimOwners() only tells me that there are prims, but I want a way to cycle threw
all the prims on the parcel and then return the ones in set areas.

For example:
On my property there should not be any prims between z=260m and z=600m

I wonder if it was possible to have a LSL function to flip someone else's prim to "temporary on rez"? It would then be returned when the sim cleans up temp prims.

It would of course have to have the same checks in that the script would have to be deeded to the group land and the object being changed would have to be over the same land.

Edit:
Or the sim could have a bit that says that that object should be returned when there is time.

It is annoying, but a good solution (user interface-wise) would be very costly to implement for relatively small gain. What I envision would be a sort of 3d map of a parcel, highlighting all objects as dots and (if you wish it) rendering the objects they represent. You could then move around this view and filter it by owner to quickly find objects. Once you have them in this view (which would scale all the way out to the limits so you can see all objects at once) you could quickly single out objects that shouldn't be there.

Being able to do an llGetObjectKeyByUser(key user, int index) would be nice to cycle through all objects a user has on your land. This would simply return the object key from the index specified in whatever internal structure LL uses. It would only work on land owned by the owner of the object, and returns NULL_KEY if you try to use it without permission (in addition to an error) or if you attempt to access an index that does not exist, or a user who has nothing on your parcel.