[BUG-20036] Temp attachment without transfer #2738
Description
How would you like the feature to work?
Using an analog of llAttachToAvatarTemp, given the correct script permissions, a scripted object should be able to attach itself to an avatar while retaining its current ownership. That is, it should not automatically be transferred to the wearer, even temporarily. (It's fine if these "correct script permissions" can only be established in an Experience.)
Why is this feature important to you? How would it benefit the community?
A scripted object can use llAttachToAvatarTemp to attach to an avatar other than its current owner, but is then temporarily transferred to that avatar while it is worn. That's consistent with the longstanding assumption that anything worn is owned by its wearer, but it imposes major limits on the utility of temp attachments and (especially) Experiences.
An example of this problem: At least one popular multi-animation engine (AVsitter) has a built-in Experience that provides seamless attachment of props to those sitting on scene objects ("furniture") scripted with the engine, once they've granted permissions to that Experience on that or any other such furniture. The problem is that this engine is written to support furniture creators who will then sell the furniture to a second party, and the attachments will be made to a third party, which means these prop attachments must be given both Copy and Transfer next-owner permission by the furniture creator, in order for them to work as current temp attachments.
It's not merely that the furniture maker may not want to supply such permissions, but that they themselves should not need a license to distribute those props with such permissions. This fully severs a value chain: externally-sourced props simply cannot be used. (This can't really be solved by an IP legal mechanism; it's way beyond any normal EULA to try to impose compliance by someone not even a party to the agreement.)
(I've been told this is somehow related to BUG-11356, so I'll link it, although I don't exactly recognize it there. I'll also link the venerable SVC-2622 "Add permissions for owner-after-next" which would also address the general value-chain problem by revising the permissions system; it may be much easier to contemplate extending Experience permissions only for temp attachments in the very specific way proposed here.)
Links
Related
Original Jira Fields
| Field | Value |
|---|---|
| Issue | BUG-20036 |
| Summary | Temp attachment without transfer |
| Type | New Feature Request |
| Priority | Unset |
| Status | Closed |
| Resolution | Unactionable |
| Reporter | Qie Niangao (qie.niangao) |
| Created at | 2016-06-17T09:55:21Z |
| Updated at | 2016-07-06T18:41:30Z |
{
'Business Unit': ['Platform'],
'Date of First Response': '2016-06-17T15:44:48.846-0500',
'How would you like the feature to work?': 'Using an analog of llAttachToAvatarTemp, given the correct script permissions, a scripted object should be able to attach itself to an avatar while retaining its current ownership. That is, it should not automatically be transferred to the wearer, even temporarily. (It\'s fine if these "correct script permissions" can only be established in an Experience.)',
'ReOpened Count': 0.0,
'Severity': 'Unset',
'Target Viewer Version': 'viewer-development',
'Why is this feature important to you? How would it benefit the community?': 'A scripted object can use llAttachToAvatarTemp to attach to an avatar other than its current owner, but is then temporarily transferred to that avatar while it is worn. That\'s consistent with the longstanding assumption that anything worn is owned by its wearer, but it imposes major limits on the utility of temp attachments and (especially) Experiences.\r\n\r\nAn example of this problem: At least one popular multi-animation engine (AVsitter) has a built-in Experience that provides seamless attachment of props to those sitting on scene objects ("furniture") scripted with the engine, once they\'ve granted permissions to that Experience on that or any other such furniture. The problem is that this engine is written to support furniture _creators_ who will then sell the furniture to a second party, and the attachments will be made to a third party, which means these prop attachments must be given both Copy and Transfer next-owner permission by the furniture creator, in order for them to work as current temp attachments.\r\n\r\nIt\'s not merely that the furniture maker may not _want_ to supply such permissions, but that they themselves should not need a license to distribute those props with such permissions. This fully severs a value chain: externally-sourced props simply cannot be used. (This can\'t really be solved by an IP legal mechanism; it\'s way beyond any normal EULA to try to impose compliance by someone not even a party to the agreement.)\r\n\r\n(I\'ve been told this is somehow related to BUG-11356, so I\'ll link it, although I don\'t exactly recognize it there. I\'ll also link the venerable SVC-2622 "Add permissions for owner-after-next" which would also address the general value-chain problem by revising the permissions system; it may be much easier to contemplate extending Experience permissions only for temp attachments in the very specific way proposed here.)',
}
Activity
sl-service-account commentedon Jun 17, 2016
Qie Niangao commented at 2016-06-17T10:02:35Z, updated at 2016-06-17T10:04:24Z
Also linking BUG-7702, another problem with the automatic transfer of temp attachments to the wearer. It's an assigned Severe-ranked bug so presumably it will be fixed, but included anyway as another demonstration of the high stakes of requiring that transfer.
sl-service-account commentedon Jun 17, 2016
Lucia Nightfire commented at 2016-06-17T20:44:49Z, updated at 2016-06-17T20:54:45Z
If I'm reading the summary correctly, it sounds like the implementation of https://jira.secondlife.com/browse/BUG-11693 would help in third party use cases.
Also see https://jira.secondlife.com/browse/BUG-9933 which is basically temp attaching from object inventory instead of the redundant rez-then-attach method.
sl-service-account commentedon Jun 17, 2016
Whirly Fizzle commented at 2016-06-17T21:29:38Z
Strife brings up a good point about this proposal on issue BUG-11839.
sl-service-account commentedon Jun 18, 2016
Qie Niangao commented at 2016-06-18T02:30:10Z
If I understand Strife's comment, it doesn't apply because the intent here is to specifically defeat that third step (attachment) leading to any change of ownership. That's kinda the whole point. The proposal here is for an analog of llAttachToAvatarTemp rather than a change to the existing function's behavior.
The jira on which Strife commented, in contrast, was to allow no-transfer items to be temp-attached and still become owned by the avatar to which they attach, which effectively would transfer no-transfer objects. (I admit, however, that I don't quite understand why Strife included the giver script in that objection; an object's contents are very much available to its wearer under the current conflation of attachment and ownership, no script required.)
sl-service-account commentedon Jun 22, 2016
Kyle Linden commented at 2016-06-22T19:03:25Z
Leaving open for further opinion and discussion.
sl-service-account commentedon Jun 22, 2016
Simon Linden commented at 2016-06-22T19:07:16Z
We'd love to hear of more specific examples where this would be a really useful new feature. This would be a fundamental change to some of SL's permissions and usage, so it needs to be balanced with the complexity and risk.
sl-service-account commentedon Jun 22, 2016
Lucia Nightfire commented at 2016-06-22T23:06:45Z, updated at 2016-06-22T23:46:19Z
I now better understand the premise of this request. Without a change in owner, this request yields most of the same benefits as in https://jira.secondlife.com/browse/BUG-11356 where the wearer can not manipulate the attached object or anything it rezzes.
I do believe that an experience-only function should be used to achieve this because a run-time equivalent would allow uncontrollable group member use with all member roles whether desired or not by officers or group owners. It should only be achievable by land owners, group owners or group members in roles that limit their abilities, such as with the experience contributor ability. I welcome any arguement against this idea though.
Additionally I would ask that while a different owner object is attached that under no circumstance would the object, its contents or anything rezzed by it be able to be modded even if the wearer has mod rights on the original owner's objects. This also includes repositioning and rotating. Detaching, of course, would still be allowed.
sl-service-account commentedon Jun 22, 2016
Takara Pikajuna commented at 2016-06-22T23:08:31Z
Hello Simon! Regarding your request for more specific examples, I have one (submitted in https://jira.secondlife.com/browse/BUG-20076 ). I created an environment for the SL13B and offered a temp-attach snorkel so that visitors could enjoy the exhibit with a swimming AO. Because the snorkel seems to transfer to the wearer, the scripts break (the parcel has scripts turned off to anyone but group members). By retaining my ownership over temp-attach items, my visitors can enjoy my objects without cluttering their inventory, and I can rest assured that my objects will not be abused.
sl-service-account commentedon Jun 23, 2016
Code Violet commented at 2016-06-23T01:37:38Z
Hi. Please also read and link the issue BUG-6629. Similar to Takara's example, BUG-6629 explains a problem with scripts inside temp attachments, as they will not run after they are transferred with llAttachToAvatarTemp() on land where the recipient of the attachment does not have permission to run scripts. Specifically, the script will not even have the ability to llDetachFromAvatar() when needed. This causes unexpected behavior. If attachments remained owned by the avatar giving the attachments then it would likely solve this issue too.
sl-service-account commentedon Jun 26, 2016
Lucia Nightfire commented at 2016-06-26T05:47:35Z, updated at 2016-07-06T01:32:31Z
In my previous comment I mentioned that the wearer should not be able to reposition or rotate attachments. I am changing my view on that and think it should be allowed since it is not uncommon for adjustments to be needed. If an application absolutely needs to maintain its attached pos/rot, it can be monitored and maintained by a script in said attachment. The owner of the attachment, though, should not be allowed to manipulate the attachment while it is attached to someone else and the wearer should not be able to modify the attachment if they have mod rights for the original owner. I'm also changing my view that the owner should not be able to manipulate objects rezzed by the attachment. This new function should be Experience based only and thus, have a higher expected level of trust and a limited area of use in-turn making abuse far less likely than if it was in a sole run-time environment that could be used anywhere.
A new function such as llTempAttachNoTransfer() or llTempAttachKeepOwner() would be a major evolutionary change for Secondlife as it would allow immense flexibility and opportunity for land owners, whom most are not skilled in scripting, 3D modeling or art design, to create in-depth Experiences using third party content they've purchased while still honoring the permissions system.
I now have to play Devil's Advocate because as much as I'd love to be able to use all the mod/copy avatars, weapons, combat gear, HUDs & maybe furniture I've purchased over the years in a full region Experience setup and involve temp attaching them to participants, we all know LL is not going to allow no transfer content to be attached to different owners because most content creators have not set up their content for the introduction of such a feature and some of them may not wish to have their products worn by users other than the ones that originally purchased them for ethical reasons or principal, not to mention it could cause issues with scripted user database checks, scripted piracy deterrents or EULA conflicts.
Many, though, would overwhelmingly want to allow their no transfer products to be used in a buyer's Experience with this new function that maintains the buyer's ownership. In order to give creators this ability, we ultimately are going to need a new permission flag that owners of full perm objects can enable for next owners to explicitly use this feature. I know LL is reluctant to bother with adding/changing permissions, but we're talking about a major feature that will allow the platform to evolve. Such a feature is inevitably going to be needed with Sansar and in Secondlife with the introduction of Created Agents(BUG-11368) if their owners want to equip/accessorize their NPC's or pets with mod/copy attachments.
This "Special Transfer" flag can only be enabled if the current owner has full permissions over the object and its inventory items and the next owner Transfer permission is disabled. This would not be hard to implement. Like any extensive feature, documentation just needs to be available explaining its use.
This "Special Transfer" flag is needed to protect existing content from being used against the intentions of the creators and to bridge the road to the introduction of new abilities.
The constant, OBJECT_WEARER will also be needed for llGetObjectDetails() remotely and internally since the only time an object can directly check if a different owner is wearing an attachment is in the attach() event.
llOwnerSay()'s behavior may need to be changed with scripts worn by different owners since llRegionSayTo()use counts toward a region throttle.
This function, combined with BUG-11693, solves a long standing problem I've had with not being able to demo/sell complete experience based games and security systems that use HUDs.
sl-service-account commentedon Jul 6, 2016
Dan Linden commented at 2016-07-06T18:41:31Z
Thank you for your suggestion. We've reviewed your request and determined that it is not something we can tackle at this time.
Please be assured that we truly appreciate the time you invested in creating this feature request, and have given it thoughtful consideration among our review team. This wiki outlines some of the reasoning we use to determine which requests we can, or can't, take on: http://wiki.secondlife.com/wiki/Feature_Requests
Thanks again for your interest in improving Second Life.
1 remaining item