Chris8888 Posted April 27, 2016 Share Posted April 27, 2016 I wear an object (main) which contains an object (child). Is is possible to click on the main object and attach the child object on my avatar (on a different attachment point and not necessarily creating an inventory copy- attach temp is just fine). Link to comment Share on other sites More sharing options...
Rolig Loon Posted April 27, 2016 Share Posted April 27, 2016 You'd have to rez it first, at least temporarily, because you can't attach an object that's in another object's inventory directly. As long as you have perms to rez objects wherever you are planning to do this, you should be fine. Rez the new object and then llAttachToAvatarTemp. 1 Link to comment Share on other sites More sharing options...
Chris8888 Posted April 27, 2016 Author Share Posted April 27, 2016 Not a good solution to rez it first, since not all sims allow that. The solution of copying it in the inventory first and then attach it is also something that is not working and it is a little awkward. *First, the owner is required to accept their own child object. I believe that, since I trust the Main object which I have attached, then I should trust the content too. The following works but is awkward: default { touch_start(integer total_number) { //if Child object name is BALLinBOX exist, then (1)copy in inventory //get the UUID of the person wearing the MAIN object. if (llGetOwner()!=llDetectedKey(0)) return; //allow only owner. integer i; integer found=FALSE; for(i=0;i<llGetInventoryNumber(INVENTORY_OBJECT);i++) { if(llGetInventoryName(INVENTORY_OBJECT,i)=="BALLinBOX") { //Child object name is BALLinBOX exist. (1)copy in inventory. llGiveInventory(llGetOwner(),"BALLinBOX"); //Found. Exit the for-loop. found=TRUE; i=llGetInventoryNumber(INVENTORY_OBJECT); } } if(!found) llOwnerSay("Child object with name BALLinBOX not found."); } * Second, you can not automate the AttachToAvatarTemp when the chlid object is copied in the inventory, because the CHANGED_INVENTORY will not be triggered if it was caused by a script function or a user taking advantage of llAllowInventoryDrop. The following does NOT work: default { changed(integer change) { if (change & CHANGED_INVENTORY) { //Request permision to (2) attach on the avatar. llRequestPermissions(llGetOwner(),PERMISSION_ATTACH); } } run_time_permissions(integer vBitPermissions) { if(vBitPermissions & PERMISSION_ATTACH) { llOwnerSay("Permission to attach accepted."); //(2) attach the Child object with name BALLinBOX on the avatar. llAttachToAvatarTemp(ATTACH_LHAND); } else { llOwnerSay( "Permission to attach denied." ); } } } Link to comment Share on other sites More sharing options...
Rolig Loon Posted April 27, 2016 Share Posted April 27, 2016 Yup. You're stuck. The typical solution for this sort of problem has always been to wear the "child" attachment all the time but make it transparent when you don't want it visible. That's how many weapons are carried, for example, and also many um... "personal" attachments. Link to comment Share on other sites More sharing options...
Innula Zenovka Posted April 27, 2016 Share Posted April 27, 2016 You could do it with RLV and shared folders, though it's a bit of a fiddly job to do, and if you're giving the items only to yourself it would be far simpler just to create a subfolder in your main #RLV folder manually, put the "child" item in that, and have the "main" attachment simply use @attach and @detach to attach and detach it. If you are interested in that solution and still need help after consulting the RLV API in the Wiki, I'll give what help I can. It's all reasonably straightforward but the process of giving the folder by script, and then checking that it's been accepted and aslo ended up in the right place before you try to attach the contents, has to be done correctly, with the script checking at each stage and handling errors gracefully. 1 Link to comment Share on other sites More sharing options...
Chris8888 Posted April 28, 2016 Author Share Posted April 28, 2016 Thank Rolig and Innula for the help. Please note, however, that before I posted the original question I tried the hide/show method and soon realized that it is not practical when you have a list of 15 or more child objects that the users can choose from to add just 1 or 2 today and probably different ones tomorrow (ie. you can never detach and soon the user runs out of attachment points). I have also started coding an RLV-based solution. However, I stopped because I haven't done any serious coding on RLV and I do not want to end up with another working, yet unsatisfactory solution. My primary concerns are: 1) What happens when the owner has RLV off or a viewer that does not support RLV? 2) What happens if the user does not have an #RLV folder yet? Can I create it though script? 3) Do the @attachover and @attachthis create copies like the llAttachToAvatar.? 4) I identified the following steps in achieving what I want with RLV and it looks that I will have to rely heavily on arbitrary(?) timeouts since most will be happening in Asynchronous mode. (a) Check if already the child object is attached on the avatar (@getattach[:attachpt] top/down or @getinvworn for bottom/up approach) -- Async (b) If not, Check if #RLV already contains the child object -- Async © If not, issue an @acceptpermission=add and send the child object in an #RLV subfolder (@??? ) -- Async (d) Wait for successful completion of the above (I gathered that RLV will not return a success/fail for a command and I will depend on timeouts) (e) Issue an @attachover or @attachthis to force attach the child object - Async (f) Verify if attached ( llGetAttachedList) before using the child object -- Synch I just hope you have in mind a more robust solution that the above. Link to comment Share on other sites More sharing options...
Qie Niangao Posted April 28, 2016 Share Posted April 28, 2016 Chris8888 wrote: [...] 1) What happens when the owner has RLV off or a viewer that does not support RLV? [...] I just hope you have in mind a more robust solution that the above. Right, that's the problem, and that's why you never see the full functionality you're trying to build: The RLV approach only works for users set up for RLV (viewer is RLV-capable and -enabled), The temp-attach approach only works on land where rezzing is enabled, Giving and attaching from recipient avatar inventory is as you say "awkward" -- requiring multiple end-user interactions, and there's no way to attach directly from an object's inventory. That's not just cussedness; attachments inherit implicit permissions, so the act of attaching kinda needs to be explicit. I'd hoped that maybe attaching from an Experience-enabled object's inventory might become possible someday, but it doesn't seem to be happening any time soon. Of course that would only work for users who enable the Experience on land where the Experience is enabled (or, at least, not disabled, come grid-scope Experiences). But that's why it may be okay: by being limited to Experiences, there's that extra level of permissions control. (Another limitation, by the way, is that nothing can dynamically link to a worn attachment, but that's minor compared to the roadblocks above.) Link to comment Share on other sites More sharing options...
Recommended Posts
Please take a moment to consider if this thread is worth bumping.
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now