Jump to content

Object attaching child object


Chris8888
 Share

You are about to reply to a thread that has been inactive for 2892 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

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

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.

  • Like 1
Link to comment
Share on other sites

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

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

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.

 

  • Like 1
Link to comment
Share on other sites

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


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

You are about to reply to a thread that has been inactive for 2892 days.

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
 Share

×
×
  • Create New...