llTransferOwnership locks the given No-Copy Object
tracked
Vala Avro
Hello,
I wanted to find a way to give an object to a new owner from a script, the object being no-copy I used the flag "TRANSFER_FLAG_TAKE" but after receiving said object, the new owner has a "Locked" version of the object. It wasn't locked before. So if they rez it, they are unable to take it back as it's also no-mod.
Log In
Lucia Nightfire
The locked flag was a stopgap added in between my filings of bug reports on no-copy object duplication vectors via llTransferOwnership() and the TRANSFER_FLAG_COPY flag. Looks like it had broader coverage, heh.
Vala Avro
Hello again,
I've tried on a server Second Life Server 2025-03-03.13640255822
Same steps as before, making sure the object (just made prim cube on the spot) but with your script and clicking it myself. Reproduction of the issue doesnt need third-party avatar.
Problem is also happening.
Maestro Linden
tracked
Maestro Linden
needs info
Maestro Linden
Hi Vala, is it possible that the object was locked prior to ownership being transferred via llTransferOwnership? While any ownership change will apply 'next owner' permissions (which may include disabling 'Modify') the actual "Locked" flag on the object shouldn't be affected by llTransferOwnership.
I can't reproduce this issue when doing the following:
- UserA: Rez a new box
- UserA: Select the box, and verify in the build tool that it is notlocked ("Object" -> "Locked" is unchecked)
- UserA: Create the script below in the box
default
{
touch_start(integer total_number)
{
llSay(0, "llTransferOwnership() returned " + (string)llTransferOwnership(llDetectedKey(0), TRANSFER_FLAG_TAKE, []));
}
}
- UserB: Touch the box, and select "Keep" when the object transfers itself to you
- UserB: Rez the box
- UserB: Observe that while not modifiable, the box is not locked - it is movable
Maestro Linden
Digging into this issue a bit more deeply, I do see something that looks like a bug. There's an undocumented feature for llTransferOwnership() that it temporarily locks the object before the recipient clicks "Keep" or "Discard". If the target agent ignores or closes the prompt, the object remains locked indefinitely.
- UserA: Rez a new box
- UserA: Select the box, and verify in the build tool that it is not locked ("Object" -> "Locked" is unchecked)
- UserA: Create the llTransferOwnership script (from my other comment) in the box
- UserB: Touch the box
- UserA: Reselect the box. Observe that "Locked" is enabled (this is the "expected" temporary locking)
- UserB: Click "X" to close the ".. has given you this object" prompt without making a decision about keeping or discarding the offer. Alternatively, exit the viewer and reconnect to the sim.
- UserA: Reselect the box. Observe that "Locked" is still enabled
- UserB: Touch the box again. Select "Keep" when prompted to accept it
- UserB: Rez the object from inventory, and observe it if it is locked
Expected results:
- The 'locked' state invoked by llTransferOwnership should be temporary and be reset at some point if UserB does not respond to the dialog.
- The object should not be locked for UserB in step (9) after llTransferOwnership completes successfully
Actual results:
The 'temporary' lock from the ignored llTransferOwnership attempt becomes permanent, and remains enabled after UserB accepts the object in step (9).
Vala Avro
FYI It also does the same on Firestorm than SL viewer
Vala Avro
The receiving new Owner is able to remove the lock manually after when editing the object.