Add llTakeObject
tracked
Logan Elf
Add a new function to allow objects to take back into their inventory a rezzed object.
Something like:
void llTakeObject(key id, string name)
or (if dataserver event is to be used):
key llTakeObject(key id, string name)
Where id is the UUID of the object to take and name is the proposed inventory name.
The empty string "" for the name can be used to signify the taken object's name should be used.
In either case, the renaming of a duplicate would still apply.
This function would be restricted to only taking objects that:
a) were created by llRezObject, llRezAtRoot or llRezObjectWithParams
b) hasn't changed owner
Taking an object will take some time, so a script would use the change event's CHANGED_INVENTORY to know when the item was in the inventory.
Alternatively a dataserver event could also be raised.
This function would be useful for enabling rezzers to support rezzing out no-copy objects. The rezzer would be able to take back the no-copy object when asked to derez.
It could also be used to rez out a no-transfer object that can be interacted with by a user and then taken back, obviating the need to have a transfer object that the user has to take to their inventory and then drag onto the original object (I've seen cases where people drag the wrong thing into objects, and worse where multiple items got accidently included in the drag).
Log In
rhet0rica Resident
I'm fairly sure this is safe from a gray goo perspective, but it should perhaps be noted for posterity that if the recursive rez limit is ever removed or substantially raised, llTakeObject() would be a key part of any infinitely self-copying forkbomb, and essentially provide a way to bypass the immutability of object inventories (which currently prevents an object from containing itself).
That being said, I would personally have a use for this as a way to automate repacking software add-ons, and I think it's just generally neat in principle.
Spidey Linden
tracked
Issue tracked. We have no estimate when it may be implemented. Please see future updates here.
Crush Cutie
How would the script or object calling this function know how the target object came into existence. Do objects themselves even have that information.
Why limit it at all.
If same owner, allow take. Job done.
Logan Elf
Crush Cutie: The llRez* functions cause an
object_rez
event in the script that called the llRez* functiions. That event gives the UUID of the newly rezzed object.llGetObjectDetails
of an object can give the OBJECT_REZZER_KEY
-- which is the UUID of what (object or avatar) rezzed that object -- so that information is known to the simulator and thus the simulator can enforce the restriction i proposed.Vincent Nacon
I was just about to make the same suggestion, but this function does need a Pin. Because people could troll others by gifting them something to rez or wear, could be scripted in a way that it could yank their entire house or whatever they have rezzed on their parcel.
llTakeObject(key id, string name, integer pin);
It should fail silently if the target id is an avatar/attachment or anything that isn't a prim. I'm not sure if it should be allowed to take an object that is set to no-copy, will leave that up to LL's decision.
Crush Cutie
Vincent Nacon: I would prefer a permissions check .. "This object wants to take other objects you own"
Vincent Nacon
Crush Cutie: That's annoying for dealing with things that you're not sitting on, it still can be used to trick you into thinking it's just gonna take one thing, but ends up taking a lot more. Pin is safer.
Logan Elf
Vincent Nacon: That's why I proposed the restrictions on the function caller of having to have been the rezzer. As i replied to Coffee, the object to be taken has what rezzed it, so the simulator can enforce the restriction that only the rezzer can take it.
Though the Pin version could be useful for use in attachments, as they get a new UUID on re-attach (I was originally thinking this function would be used by rezzed objects).
Crush Cutie
Logan Elf:
If the only use-case under consideration is "allow mainland rentals to pack more skyboxes onto a single under provisioned parcel", then this is pointless.
* for those who don't know .. there is a practice on mainland to place on-demand sky-boxes up for rent. These spawn the rented location when the renter is nearby. This allows the landlord to rent the same parcel multiple times, counting on not everyone being around to use their rented home at the same time. No copy furniture items present a limit on how many times a location can be re-rented, in that they must remain out all the time and consume a fixed amount of Li.
Logan Elf
Crush Cutie: I don't rent out parcels or skyboxes and never have done. I find your insinuation that I'm some low-life quite insulting.
FWIW I was asked to come up with a postcard system which could still be used by visitors who didn't have rez rights. The system could give their choice of postcard, but a no-mod script means they can't rename the postcard (and you can't rename an object that is attached either). Using llAllowInventoryDrop (so they can give the modified postcard back) has a number of problems: it allows anyone to drop items; scripts don't know who dropped in an item; scripts don't know which item was dropped without clogging up memory by maintaining a list of all existing items. Also, it's easy for a user to drop the wrong item in or i've seen people accidently drop in multiple items.
With this proposed function, the script is in total control of the process.
Crush Cutie
Logan Elf: what .. why are you wanting to pass actual items back and forth? Presumably the data is what matters not the prims.
Anyway, I didn't suggest you were a landlord, I was responding to this
"This function would be useful for enabling rezzers to support rezzing out no-copy objects. The rezzer would be able to take back the no-copy object when asked to derez."
Vincent Nacon
Crush Cutie: Even if it's the data he wanted, I still need this function to actually take the prim, even if it's no-copy.