Transfer Inventory between prims llGiveInventoryList

[HighlanderXVI]

Hi every one been battling with this and cant get it to work, want to transfer mod/copy/no transfer between a pose server, and a hud.

integer MALE=101;
SUB_TRANSFER(key LK1, key LK2)
{
    integer ANIMECOUNT=llGetInventoryNumber(INVENTORY_ALL);
    integer IDX;
    string SCRIPTNAME=llGetScriptName();
    list ITEMS =[];
    for (IDX=0;IDX<ANIMECOUNT;++IDX)
    {
        string ITEMNAME=llGetInventoryName(INVENTORY_ALL,IDX);
        if(ITEMNAME!=SCRIPTNAME)
        {
            if (llGetInventoryPermMask(ITEMNAME,MASK_OWNER) & PERM_COPY)
            {
                ITEMS+=[ITEMNAME];
            }
        }
    }
    llGiveInventoryList(LK1,"", ITEMS);
}

default
{
    state_entry()
    {
            
    }

    changed(integer change)
    {
        if (change & CHANGED_OWNER)
        {
            llResetScript();
        }
    }

    link_message(integer SOURCE, integer CMD_FILTER, string MSG, key KEY)
    {
        if(CMD_FILTER==MALE)
        {
            SUB_TRANSFER((key)MSG,KEY);
        }
    }

}

If i rez the hud in  world, it works fine, if i attach the hud it fails to transfer the animations.

I have copy/mod perms over the animes, the prims that are transfering inventorie are bouth mine(im the creator).

Any ideia why it would fail while attached and work when rezzed?

[Phate Shepherd]

I assume there is another script that is listening for something from the HUD to get its key? It sends a link message with CMD_FILTER of 101, and the destination HUD key is the MSG string?

What is LK2 used for?

[HighlanderXVI]

The server where this script is has a listener in the root prim, depending on what poses i select MALE/FEMALE/UNISEX from a dialog it sends the linkset a message, CMD_FILTER decides what poses to send to the hud, LK2 is a second prim where the poses are backedup.

And yes, it receives the keys from the hud.

It works fine when rezzed, it fails when attached as a hud.

Edited October 8, 2020 by HighlanderXVI

[Mollymews]

as wrote there is no reason why this script would not work in both situations

the issue most likely is with the other script.  The link message parameters being sent to this script from the other are not what this script expects

[HighlanderXVI]

This is the error i get in the debug channel:

Unable to give inventory list: Unable to add 'CWS - male1', 'CWS - male2', 'CWS - male3', 'CWS - male4', 'CWS - male5', 'CWS - male6', 'CWS - male7', 'CWS - male8', 'CWS - male9', 'CWS - male10', 'CWS - male11', 'CWS - male12', 'CWS - male13', 'CWS - male14', 'CWS - male15', 'CWS - male16', 'CWS - male17', 'CWS - male18', 'CWS - male19', 'CWS - male20', 'CWS - male21', 'CWS - male22', 'CWS - male23', 'CWS - male24', 'CWS - male25'

The poses are no transfer, but since bouth objects and the poses belong to me, i should be able to add them via llGiveInventoryList.

Also checked the prims UUIDs receiving the poses they are correct.

[HighlanderXVI]

After some more research found this: https://jira.secondlife.com/browse/SVC-7306

So tested by attaching a no transfer prim as a HUD and used llGiveInventoryList, it worked fine, so seems this bug was never corrected and since the hud was created by me, i have full perms, i can't give to inventory no transfer items while attached.

Edited October 8, 2020 by HighlanderXVI

[Mollymews]

16 minutes ago, HighlanderXVI said:

After some more research found this: https://jira.secondlife.com/browse/SVC-7306

So tested by attaching a no transfer prim as a HUD and used llGiveInventoryList, it worked fine, so seems this bug was never corrected and since the hud was created by me, i have full perms, i can't give to inventory no transfer items while attached.

ah! ok

i would never have thought of a use case where a linked prim in an attachment would give content assets to another prim in the linkset

[HighlanderXVI]

The prim that gives the contents is not part of the HUD link set.

The contents giver is where i store all mi poses, self made or bought, and its a 4 prims link set, where poses are devided by gender or unisex.

I wanted to import them in to the hud, not having to rezz it on the ground. That will alow me to at  any moment attach the giver link set and transfer what ever i need in to the hud even if im in a no rez sim, solution was to add a no transfer item to the hud inventory.

[Mollymews]

7 minutes ago, HighlanderXVI said:

The prim that gives the contents is not part of the HUD link set.

The contents giver is where i store all mi poses, self made or bought, and its a 4 prims link set, where poses are devided by gender or unisex.

I wanted to import them in to the hud, not having to rezz it on the ground. That will alow me to at  any moment attach the giver link set and transfer what ever i need in to the hud even if im in a no rez sim, solution was to add a no transfer item to the hud inventory.

just so I am clear on what is happening

there is a HUD.  There is a Animation Server.  Attach the HUD. Attach the Animation Server.  The attached Animation Server gives the attached HUD the animations

the issue was that the HUD doesn't receive the animations because it is attached

you are suggesting that you found that a solution is to add a no transfer item to the hud inventory.

a question I wouldn't mind an answer to is: When you say add, does this mean the no-transfer item is in the llGiveInventoryList which enables the assets to be transferred for the animation server to the HUD ?

 

[Qie Niangao]

2 hours ago, HighlanderXVI said:

I wanted to import them in to the hud, not having to rezz it on the ground. That will alow me to at  any moment attach the giver link set and transfer what ever i need in to the hud even if im in a no rez sim, solution was to add a no transfer item to the hud inventory.

The already-linked jira includes a comment by Maestro that might explain why there's a problem at all:

Quote

It's expected behavior that you can't add a no-transfer item to a transferable HUD or add a no-copy item to a copyable HUD - otherwise, there would be a permissions exploit.

So I guess the potential "permissions exploit" is that an attached transferable object would remain transferable if no-transfer content could be added to its inventory, making it possible to transfer no-transfer content. In contrast, adding no-transfer content to an unattached transferable object makes it rightly impossible to transfer that object (despite the object's own permissions remaining unchanged).

What seems new here is that one way to make a transferable attachment eligible for receiving no-transfer content while attached is by having it already contain some no-transfer content, rather than needing it to have no-transfer object permissions itself. (In cursory testing, however, that does not seem to enable viewer drag-and-drop of permissions-restricted content into an attachment.)

I'm interested in this because I've long been annoyed by being unable to drag copyable, no-transfer anims to a HUD-attached animation overrider: it works fine if the AO is rezzed unattached, but that's a pain because the rezzed copy is a new object, so when taken back into inventory it must be re-linked into all outfits (thank heavens for some TPVs' "Replace all links"). But in this case I can use llGiveInventory to copy anims from a scripted object to populate the attached AO. In fact, I'd been thinking of writing about that as a little hack others might find useful.

Now I realize there could be a bunch of special cases: basically every permutation of permissions for the attachment, the items already in its inventory, and the item(s) with which it is to be populated. In the broader sense, I realize I don't really understand what the permission system is doing here, and I wish I did.

[Mollymews]

19 minutes ago, Qie Niangao said:

What seems new here is that one way to make a transferable attachment eligible for receiving no-transfer content while attached is by having it already contain some no-transfer content, rather than needing it to have no-transfer object permissions itself. (In cursory testing, however, that does not seem to enable viewer drag-and-drop of permissions-restricted content into an attachment.)

I'm interested in this because I've long been annoyed by being unable to drag copyable, no-transfer anims to a HUD-attached animation overrider: it works fine if the AO is rezzed unattached, but that's a pain because the rezzed copy is a new object, so when taken back into inventory it must be re-linked into all outfits (thank heavens for some TPVs' "Replace all links"). But in this case I can use llGiveInventory to copy anims from a scripted object to populate the attached AO. In fact, I'd been thinking of writing about that as a little hack others might find useful.

Highlander PM'd me about this. Highlander said yes that they found this to be the solution. When an attachment already has a non-transfer item (given by another account) in its contents then it will accept assets from another attachment

i haven't played with it yet myself but what Highlander said and what you Qie have also said, suggests to me that this is possible

i have had the same issue myself, wanting to transfer animations into a HUD while it is attached. This solution is not as good as being able to drag drop direct from Inventory as you say, but still useful I think

[HighlanderXVI]

Sorry for the 24h delay on reporting back but the forum limits to 5 messages a day, guess couse i just join it, never the less seems a bit short.

I run some more tests on this and the only way i could find to make llGiveInventoryList or llGiveInventory work was to get another resident to send me a no transfer object and add that object to the HUD inventory, with that the Animation server either also attached or rezzed in world will transfer the non full perms items to the HUD inventory.

What i dont get is since if i rezz the HUD in world i can drag the non transfer assents to it or transfer via llGiveInventoryList/llGiveInventory in to it, even that the HUD it self is transfer, it becomes NON TRANSFER, why isn't this behaviour implemented when attached. Wiki also doesn't has on info on this case, but since on the JIRAs i readed this is sayd to be expected behaviour no point report it as a bug again.

Thank you guys...

[Kyrah Abattoir]

Attachments are interesting in the sense that some of their properties don't always persist, so not entirely surprised.

[Wulfie Reanimator]

2 hours ago, HighlanderXVI said:

Sorry for the 24h delay on reporting back but the forum limits to 5 messages a day, guess couse i just join it, never the less seems a bit short.

We've recently had some... very persistent spammers here, making new accounts and filling the forum with terrible content. I imagine that's one reason the whole forum got an update, along with the limits to new users.