No questions asked: Wear it!Simply touch food or beverage to instantly wear it and animate to "eat" or "drink" it, without it going to inventory nor asking permissions.
We're able to do that if the items are scripted with an Experience in which we're enrolled and that's permitted on the parcel. That's fine for grand-scale Experiences where our hunger or thirst might be part of a whole game or adventure.
But what about the casual nosh from a craft table or a quick coffee shop latte? Do we really want to approve a whole separate Experience for each one?
That's a problem for furniture makers, too, where it's just too much trouble for a sitter to temp-attach a quick prop when a pose changes. Fortunately, the same solution applies: a built-in pose engine Experience that works for touchers as well as sitters.
One common pose engine, AVsitter, includes just what's needed for both: a script interface to an Experience with a growing base of enrolled users who have already encountered AVsitter-scripted items. Furniture makers who license that pose engine already have instructions for using that Experience in their products. Here we lay out a simple recipe for using it to enable touch-to-add-attachment ability in your own items without needing to own the engine itself. (Of course, if you want to distribute the items that give the wearables, you need to own the engine, but not if you're just giving away the wearables themselves. This isn't an endorsement of a specific product; with some more scripting you can apply the same method to your own Experience.)
I've set out a little in-world sample here that you may want to dissect along with the description below. Please also use it any way it's helpful in your own content.
To start, we'll need a "giver" (e.g., a plate of donuts) and a "wearable" (e.g., a donut). The wearable usually has an animation to play while the item is worn, so it already needs to be scripted to run that animation. In addition, to temp-attach with the Experience it also needs the "[AV]object" script, which always needs Copy+Transfer permission (so you may already have props in your inventory containing that script with those permissions, but you'll want a recent version, so start with the one in the sample provided).
The giver must be stocked with that wearable to give out, and must also contain a copy of the "[AV]prop" script (Transfer only, which you also may already own inside some furniture item or another, but again use the current version in the sample). It also needs a tiny "AVpos" notecard and a tiny script to trigger [AV]prop's temp-attach process. For our donut example, these are as follows:
------ AVpos Script ------
Released to public domain by Qie Niangao, 2016 ◆
This "WARN 2" needed to allow non full-perm props ◆
PROP1 Donut|Donut (auto-attaching)|m0|<0.0, 0.0, 0.0>|<0.0, 0.0, 0.0>|right hand
where "Donut" is the label sent by script ◆
and "Donut (auto-attaching)" is the object in contents to attach as a prop ◆
------ Script: "dispense auto-attaching donuts" --------
// Released to public domain by Qie Niangao, 2016
llSetTouchText("Get Donut"); // shows in right-click menu
llMessageLinked(LINK_THIS, 90220, "Donut", llDetectedKey(0));
// "Donut" matches label of prop in AVpos notecard
Optionally set the stocked wearable Temporary (it's a good idea), take it into inventory, and put it into the giver. Then rez the giver on land that permits the AVsitter Experience, and touch it. If you've already approved the Experience, you'll wear the wearable as soon as the giver rezzes it; or, if you haven't already, you'll be prompted to permit the Experience.
Now, what about permissions for the wearable and its contents? This is often overlooked. Unless it's your own content and you don't care about limiting distribution, you'll need to be careful your item permissions comply with any licensing terms. Don't give away full-perm items or their contents as full-perm for the next owner unless that's allowed by the license (and it almost never is). Always test permissions with an alt or friend. (The sample is set as permissive as possible, generously permitted by the creators; yours will likely need more restrictive permissions.)
"Givers" as Products
The permissions question is much more complicated if you want to distribute products that are themselves givers -- that is, if you want to sell trays of donuts that the next owner can set out to supply donuts to third parties. (You can set next-owner permissions, but you really want more restrictive permissions on the NEXT-next-owner.) It's not really possible to fully protect the IP of those donuts and their contents, but it's possible to use the obscure "slam bit" function of SL permissions to somewhat help with this. You're still responsible to comply with any license terms, and you may demand tighter protection for your own content, too, so this is merely an idea to consider:
- In a rezzed copy of the wearable, set the next-owner permissions to transfer-only (no-Copy) on it and any contents you want to protect.
- Take that wearable into Inventory and from its Properties dialog change it to Transfer + Copy permission (which sets the "slam bit" on permissions because they changed while the item was in Inventory, not rezzed).
- Put that wearable from Inventory into a copy of the giver, set permissions on the giver to the desired product permissions (probably Copy+Modify, no-Transfer) and take it into Inventory.
- Pass it to an alt or friend for testing to make sure it's ready for your usual product distribution channels. (Note that for slam-bit testing, it's generally best to use another alt as the donut-eating third party.)
This way the product buyer rezzes out a copy of the giver, inside of which the wearable is still Copy+Transfer; then when a third party touches it, a copy of the wearable is rezzed -- but its "slam bit" was set so now the rezzed wearable gets set no-Copy, and transfers to the toucher to whom it temp-attaches.
(For more background on the "slam bit" see http://wiki.secondlife.com/wiki/Debug_Permissions .)
This does not totally protect content from intentional IP infringement by the *buyer* of the giver object (so it won't suffice for licensed content) but it does reduce risk of infringement by the *wearer*. It's at least possible to impose some EULA on the buyer, but it's hopeless to pass that down to the third-party wearer, so some mechanical constraint like this slam-bit approach may be the best we can do given the limitations of SL permissions and attachments. (There are ways to further protect content but they're beyond the scope here.)
- Plato Novo of %Percent for all the yummy donuts, inspiration, and patience
- Code Violet for giving AVsitter such a useful Experience and API
- Prokofy Neva for https://community.secondlife.com/t5/LSL-Scripting/A-script-that-disappears-objects/td-p/3088196
- Robin (Sojourner) Wood for everyone's favorite sipping anims (in the self-sipping donut attachments)