llReturnObjectsByID and llReturnObjectByOwner

[Alpha Steamer]

 

Would be nice if more was known on these two functions, even a simple 1 line idea to how they could work would be great.  Been hunting for ways to use since they came out and most likely I'm getting closer just no examples to inspire from.

 

[Alpha Steamer]

 

Would be nice if more was known on these two functions, even a simple 1 line idea to how they could work would be great.  Been hunting for ways to use since they came out and most likely I'm getting closer just no examples to inspire from.

 

[steph Arnott]

I have only just read these functions, I can only guess that if it a RP type sim then rather having auto return or some one manually searching, A ranked group member or land owner can just return a specific owners objects. That's how I read it. But you have to read the caveats as the is a slight difference with the return.

ADDED: Ifa group is closed then could be used for that too. Seems to be a specialized function.

[Rolig Loon]

They're both pretty straightforward tools for land management.  Essentially, they allow you to write a script that lets a landowner automate the Return to Owner functions that are in About Land and the Region/Estate tools in the viewer.   Landowners can return objects that do not belong on their land either by saying "return all items owned by this specific person" or by saying "return the specific item with this UUID."  With these two LSL functions, a landowner can write a script to perform those functions for him/her.  We have several other LSL land management functions (for banning or ejecting avatars, controlling media streams, etc.).  These just add two more.

[Qie Niangao]

I'd guess that the wiki is clear enough on the mechanics of how to use the functions, but if not, we can surely discuss any problems with that.

The question may be more about why one would use them. They're specifically not intended to deal with griefing in real time. (Think about what would happen if griefers and llReturn* scripts battled it out for a while.)

One example (possibly similar to Steph's?) that comes to mind is to address a common problem of land deeded to an open group (e.g., a store group). This sounds like a good idea at first, but if the land is set to allow group rez, then auto-return can't clean up after casual group members. A script can now automate that clean-up using llGetParcelPrimOwners() and llReturnObjectsByOwner(), excluding from return just those owners who should be allowed to keep items rezzed on the parcel.

That combination of functions can also address occasional stray prims on no-auto-return parcels set no-rez and no-object-entry. (Yeah, stray prims are still possible with those settings -- don't ask.) Auto-return is surely preferable (less lag), but some parcels want to retain specific "legacy" objects set to other groups.

I have no idea if this is anything like an intended use case for llReturnObjectsByID(), but the place I can see using that one myself would be to make a holo-rezzer of unscripted objects. It's actually expensive to start up a script in such objects, just to make them llDie() at the right time. Instead, for rezzing otherwise unscripted objects, the rezzer script can keep track of object_rez events and tidy-up after itself.

Otherwise, the -ByID() variant needs to get the object UUIDs from somewhere -- perhaps sensor() events, llCastRay(), or maybe objects that self-report.