Now that Melanie has started work on the temp attachments on the master branch, I've changed how osForceAttachToOtherAvatar works, so it's always temporary.

~ Marv.

On 11/08/2012 12:12, SignpostMarv Martin wrote:

On 10/08/2012 22:34, dz wrote:
I'll bite...

Lets focus on one of the patches.... new feature: attaching objects to non-owner http://opensimulator.org/mantis/view.php?id=6133 ...

First problem with this patch... It replicates the *osForceAttachToOtherAvatarFromInventory* function documented here -> http://opensimulator.org/wiki/OsForceAttachToOtherAvatarFromInventory .. as you can see from the history of that page it was created almost a month before your patch was submitted...
It doesn't replicate osForceAttachToOtherAvatarFromInventory(), it "replicates" llAttachToAvatar() http://wiki.secondlife.com/wiki/LlAttachToAvatar

osForceAttachToOtherAvatarFromInventory() is for adding an attachment from the object's inventory to a specified avatar, llAttachToAvatar() is for adding the rezzed host object to the object owner. The patch I've attached is for attaching the host object to the specified avatar, the sole difference to llAttachToAvatar() being the specification of the avatar.


Second problem with this function... and one i added to the talk page on the wiki... Unless that object is unscripted OR is removed when the avatar exits the region or disconnects,
this sounds like a heap of griefer trouble...

What happens when I visit a region where an object scans me, attach a malicious package to me, and then take advantage of the fact that attached objects don't require permissions to teleport me to a random region and have the object spew 200,000 prims into someones else space??? Is MY fault I didnt check all of my attachments before and after i TP'd???

There are so many reasons why asking for permissions works, and owning the objects that are attached to you makes sense.. The ONLY valid reason I have ever come across for someone wanting to attach something to me without me owning it is DEMO prim/mesh clothing/accessories That functionality IS supported in SL via lAttachToAvatarTemp <http://wiki.secondlife.com/wiki/LlAttachToAvatarTemp>... and ASKS.
There are two functions in the patch. One asks, one doesn't. Your sole concern seems to be the potential for griefing with the osForceAttachToOtherAvatar() function and not osAttachToOtherAvatar(), a concern that would seem to be addressed by either raising the threat level of osForceAttachToOtherAvatar(), or just not including it.



Like I said above.. making this functionality accessable to NPC bots who cannot leave the region, and currently cannot grant permissions, MIGHT be a use case.. But since you make no distinctions...
I could implement another pair of functions designed for NPCs if you'd like, that's fairly trivial.


...

I guess the bottom line is... there's some code there, yes... but even if it is functional, it is going to take more than filing a mantis to get it worked on and reviewed... Part of that work is defining and communicating the NEED for the function so it can be balanced against the implications of implementing it.
At work I needed to attach a wheelbarrow (and in future, other tools & equipment) to the user without
a) transferring ownership
b) constantly interrupting them with permissions dialogs- as is required by llAttachToAvatar() c) performing the ungraceful hack that one would do in Second Life with many attachments that remain attached to the avatar but are invisible until needed, or one that is invisible and changes appearance as needed.

This scenario is accompanied by a function that permits script-triggered dropping of attachments (in both perms and non-perms flavours) http://opensimulator.org/mantis/view.php?id=6118


~ Marv.


_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev

Reply via email to