llTransferOwnership() returns 0 instead of -6 when flag 0x4 is used and no-transfer content is present in object's inventory.
complete
Lucia Nightfire
llTransferOwnership() returns 0 instead of -6 when flag 0x4 is used and no-transfer content is present in object's inventory.
Does not repro with flags 0x0 nor 0x2.
Those flags return -6.
Log In
This post was marked as
complete
Maestro Linden
tracked
Maestro Linden
under review
Maestro Linden
These are the results I see with Apple Cobbler 2024-11-26.12040480539:
- UserA: rez a new box
- UserA: create a script in the box, containing the source shown in my comment in https://feedback.secondlife.com/admin/feedback/scripting-bugs/p/lltransferownership-with-flag-0x4-still-allows-no-copy-inventory-duplication?boards=feature-requests_scripting-features&status=open
- UserA: add a copy/modify/no-transfer item to the box (appears as 'O:VMC' in 'debug permissions')
- UserB: touch UserA's box to trigger llTransferOwnership() in 'copy' mode
5: UserB: rez your copy of the box and inspect the contents
Actual results:
- in step (4), llTransferOwnership() returns 0 (TRANSFER_OK) and UserB gets a copy of the object
- in step (5), UserB's copy of the box does not include UserA's no-transfer item
I spoke with Rider about this behavior, and confirmed that llTransferOwnership() is following similar behavior as llGiveInventoryList() - rather than triggering an outright failure result if the contents can't be copied 100%, it is simply skipping over the items which can't be transferred due to perms.
As a solution, we're thinking about adding a flag parameter to llTransferOwnership() to control what happens when only some of the contents can be transferred, i.e. fail with TRANSFER_NO_PERMS vs only transferring contents which can be transferred. If the object itself can't be transferred due to perms, the transfer should always fail with TRANSFER_NO_PERMS as there's no container for the inventory items.