Jump to content
Zunx

Permissions for llGiveInventoryList()

Recommended Posts

Hello

I'm doing an installer, an object rezzed from a worn attachment, to be able to drop content inthe installer, which then can copy it's content into the initial attachment.

  • The installer to rez is in the root prim of the attachment, as well as the script used to rez it.
  • All is for the same owner (the avatar on which it's attached)
  • The content is copied to a child link of the attachment (key sent to the installer via after-rez handshake)
  • Content to copy are textures.

Although all belong to the same owner, I have issues with textures not having the transfer perm. I get a Debug window error listing items that couldn't be copied.

Here is the piece of code doing the copy:

count = llGetInventoryNumber(INVENTORY_TEXTURE);
if (count) {
    list copy;
    for (i = 0; i < count; ++i) {
        name = llGetInventoryName(INVENTORY_TEXTURE, i);
        if (PERM_COPY & llGetInventoryPermMask(name, MASK_OWNER)) {
            copy += name;
        }
    }
    if ([] == copy) {
        llOwnerSay("No copiable item found.");
    }
    else {
        llGiveInventoryList(sendTo, llGetObjectName(), copy);
    }
}

So as the owner does not change, why I get this issue, and how to fix it?

Cheers

Share this post


Link to post
Share on other sites

I am not sure about the test you're using.   Someone who understands bitmasks better than I do (which isn't a high bar, admittedly) will be better placed to comment, but I think the bracketing is wrong.   Certainly if you try this experiment, 

		integer PERM = PERM_COPY |PERM_MODIFY ;
		if((PERM & PERM_COPY) == PERM_COPY){
			llOwnerSay("true");
		}
		else{
			llOwnerSay("false");
		}

 

the object says "true" but if you change it to if(PERM & PERM_COPY == PERM_COPY) -- that is, you don't bracket (PERM & PERM_COPY) it says "false".    So I would try again using something like

		integer PERM = llGetInventoryPermMask(name,MASK_OWNER) ;
		if((PERM & PERM_COPY) == PERM_COPY){
				copy += [name];
		}

and see what happens.  

However, I don't quite understand why you are using llGiveInventoryList, which works only if you want to give items to an avatar's inventory.   Your description sounds as if you're copying the textures to a child link in the attachment (though I don't quite understand why you need to do that).   If that's the case, then after you've populated your list with copyable textures, then you need to loop through it again, using llGiveInventory(llGetLinkKey(childPrim),llList2String(copy,n)) and give the textures one at a time.

You know how your application works and I don't, but I'd be concentrating on reading the textures' uuids and storing/transmitting those rather than on copying the actual textures from one prim to another.

Share this post


Link to post
Share on other sites

I don't understand why you even need this bit of code.  It's just asking whether you have copy perms on the item.  Since all you want to do is move the items from one prim to another, why do you care?  Just move them.

Share this post


Link to post
Share on other sites
5 minutes ago, Innula Zenovka said:

Hello Innula, and thank you for your reply.

I checked permissions, and it works well. A bitmask generates an integer value, that does not need to == tested (as the result is 0 if the value does not contain the masked part), so my test is like


if ((PERM_COPY & llGetInventoryPermMask(name, MASK_OWNER)) == PERM_COPY)

Now for what I want to do. Things can't be copied directly from avatar inventory to a hud attached object, so to avoid rezzing the hud (it's a texture organizer hud), I found this solution better, as it's more user friendly. The fact I don't want to message UUIDs, is that I actually want to store the textures in the hud (and thus, need to copy them from my rezzed installer).

I have already seen a long time ago such a system, but I surely lost it during an inventory cleanup. What I'm not sure of, is the reason of the failure. For example, if I have that set:

  • texture1 (mod/copy/trans)
  • texture2 (mod/copy/notrans)

Then llGetInventoryList() will copy correctly texture1, but not texture2. I haven't tried with llGiveInventory(), but I don't see why it would change anything. At least, nothing I can see in the documentation.

 

Share this post


Link to post
Share on other sites
4 minutes ago, Rolig Loon said:

I don't understand why you even need this bit of code.  It's just asking whether you have copy perms on the item.  Since all you want to do is move the items from one prim to another, why do you care?  Just move them.

I thought nocopy items couldn't be transferred by llGiveInventoryList()... I managed to give a warning to the user when the inventory contains non copiable items, to be sure they wont be lost. I haven't even tried it. If it works, of course I wont test the permissions. But the main point is not the permission checking, as what I thought working, just does not work :)

Share this post


Link to post
Share on other sites

I am confused.   You write "Things can't be copied directly from avatar inventory to a HUD attached object".  But you can't access the avatar's inventory by script at all (other than to give items to it),    But the rest of your explanation suggests you are trying to copy items from an installer object to a HUD that you're wearing.  

If you want to copy the items from the installer to the HUD's inventory you have to use llGiveInventory.   llGiveInventoryList will work to give items to your inventory but not to your HUD's inventory.   And llGiveInventory doesn't mind whether the items it is giving are copyable or not.

Share this post


Link to post
Share on other sites

It's true that you can't send NoCopy items with llGiveInventoryList, but why do it that way?  You don't want to create a folder in the receiving object (you can't do that anyway), so just use llGiveInventory and transfer the items individually.

Share this post


Link to post
Share on other sites

You can use llGiveInventoryList to send a collection of items from one object to another.  The only differences between sending to an object and sending to an avatar are that

Prim / Object

  • The prim must be in the same region.
  • Does not create a folder.

and, as you have noted,

If inventory permissions do not allow copy, the transfer fails and an error is shouted on DEBUG_CHANNEL.

But those restrictions to not apply to llGiveInventory. (except for the one about being in the same region).

  • Like 1

Share this post


Link to post
Share on other sites

Thanks, Rolig.  I never realised that you can use llGiveInventoryList to give stuff to prims.   I don't really see why I'd want to use it in preference to llGiveInventory, but it seems you can use it.  Good to know.   

Share this post


Link to post
Share on other sites

Thank you Rolig, I will try with llGiveInventory() then, it just seemed simplier to make one copy call than looping on the list to send one by one (as the folder argument is not used).

And yes Innula, that's what I want to do:

Quote

The rest of your explanation suggests you are trying to copy items from an installer object to a HUD that you're wearing.

 

Share this post


Link to post
Share on other sites

Not to pooh-pooh the whole project, and I'm sure I'm completely ignorant of some key thing that explains it all, but why do you need a script for this?

If you're doing it just to do it, nuff said, no excuse necessary with me, cos I do that too for the sake of learning (and being stubborn), but it does seem a rather complicated way to do something you could do with a couple clicks and a drag...

I use objects to rezz other objects all the time, but I've never really had to "install" anything to do it... I just add the items to the rezzing object's invy.

What am I missing here? I realize this is probably an annoying question, and the answer is probably obvious to everyone but me, but yeah, just wondering... ^-^;

Edited by Berksey

Share this post


Link to post
Share on other sites

Hello Berksey

What I'm building is a texture organizer hud (aka worn attached to the hud). The goal is to put all my textures in central places instead of my inventory. There is the solution of rezzed organizer, but it consume prims, and I prefer the hud way. This said, as items can't be dropped in a hud attached obect, I don't want to rez my hud, drop images in it, and grab it back in my inventory each time I want to put textures in it

The installer is a quick an easy solution. You click on a button in the hud, it rezzes that installer prim in front of the avatar, just drop textures in it, and then click on the prim to get teh textures back in the hud, directly. The installer auto-dies.

Share this post


Link to post
Share on other sites

I just tried with a loop on llGiveInventory, and got the same result: no transfer items are not copied, despite the copy is made to the same owner (me) of the two objects involved.

Share this post


Link to post
Share on other sites

I'm mildly confused.  If items are No Copy, they shouldn't be copied.  If they are Transferable, they should transfer.  It sounds as if you are using the words "copy" and "transfer" as if they mean the same thing.  If you have a No Copy texture, it can only be in one place: either in your own inventory or in your installer or in the HUD or on something that you have applied the texture to.  You can't make multiple copies of a No Copy item.

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, Zunx said:

I just tried with a loop on llGiveInventory, and got the same result: no transfer items are not copied, despite the copy is made to the same owner (me) of the two objects involved.

I just made some textures copy, no transfer, and gave them to my alt.   My alt then successfully used this script to copy them from the root prim of a linkset to a child prim.  I think you should examine your permissions check for typos.  You need if((llGetInventoryPermMask(strName, MASK_OWNER) & PERM_COPY) == PERM_COPY).  

integer iCounter;
integer iMax;

key k;
string strName;
default {
	state_entry() {
		
	}

	touch_start(integer num_detected) {
		k = llGetLinkKey(2);
		iMax = llGetInventoryNumber(INVENTORY_TEXTURE);
		iCounter = 0;	
		do{
			strName = llGetInventoryName(INVENTORY_TEXTURE, iCounter);
	
			if((llGetInventoryPermMask(strName, MASK_OWNER) & PERM_COPY) == PERM_COPY){
				llOwnerSay(strName + " is copyable.");
				llGiveInventory(k, strName);
			}
			
		}
		while(++iCounter < iMax);
	}
}

 

  • Like 1

Share this post


Link to post
Share on other sites

I undrestand well the copy/mod/transfer permissions. I don't try to copy transferable no-copy items. The textures I try to copy from one prim (rezzed by my hud) to a child link of my hud are either copy/mod/trans (fullperm) or copy/mod. That means I can't transfer them to another owner, which is irrevelant to me as I don't want to transfer them anyway (all under the same owner).

But the fact is in this schema, if I try to copy a copy/mod (no transfer) from my rezzed object to the hud, I can't.

Share this post


Link to post
Share on other sites

Seems a convoluted process, but.... My alt has  just tried rezzing a box containing the no-copy textures I game him from a HUD and having the box, on rez, give the no transfer textures it contains back to the root prim of the HUD that rezzed it.   You may be running into some LL restrictions on altering the inventory of a worn item that you didn't make yourself (including all the contents).   I can never remember what they are, but I remember they were introduced years ago to prevent an exploit that allowed people to copy no-copy items, which is why updaters for attachments (e.g. collars) normally require you to rez the item on the ground before using the updater prim.   Anyway, my alt made the simple 2 prim HUD and the box containing the textures.   These are the scripts my alt used.

For the HUD:

Quote

integer iChan = -21543809;

string strObject;

default {
    state_entry() {
        strObject = llGetInventoryName(INVENTORY_OBJECT, 0);
    }

    touch_start(integer num_detected) {
        llRezAtRoot(strObject, llGetPos()+<2.0,0.0,0.0>,ZERO_VECTOR,llGetRot(),iChan);
    }

    object_rez(key id) {
        llSleep(0.2);
        llRegionSayTo(id, iChan, (string)llGetLinkKey(2));
    }
}

For the box: 

Quote

integer iCounter;
integer iMax;

key k;
string strName;
default {
    state_entry() {
        
    }

    on_rez(integer start_param) {
        if(start_param){
            llListen(start_param, "","","");
        }
    }

    listen(integer channel, string name, key id, string message) {

        k = (key)message;
        iMax = llGetInventoryNumber(INVENTORY_TEXTURE);
        iCounter = 0;    
        do{
            strName = llGetInventoryName(INVENTORY_TEXTURE, iCounter);
    
            if((llGetInventoryPermMask(strName, MASK_OWNER) & PERM_COPY) == PERM_COPY){
                llOwnerSay(strName + " is copyable.");
                llGiveInventory(k, strName);
            }
            
        }
        while(++iCounter < iMax);
    }
}

 

Share this post


Link to post
Share on other sites

I made a stripped down fullperm version of the system, that I can give away to anyone willing to help me :)

Share this post


Link to post
Share on other sites

Mkay I totally get it now, why you're doing this. I just hadn't any knowledge of your reasons for it, but it makes sense now. It's kinda similar to making texture packs to install with certain items. I've done this myself, sort of, but the installer I made the textures for used the UUIDs, rather than the actual textures, and they all had to be entered one by one into a dialog box. Then the installer could be rezzed or added/worn, and the item responded by updating and adding the new texture pack to the menu.

So yeah, not at all what you're doing, but close enough to understand the reasoning.

I'm sorry I'm of no real help with any of this, but thanks for de-confusing me, at least!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×