Jump to content

Inconsistant script error: Unable to give inventory: 'Blocked by permissions'


Guest
 Share

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

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

Recommended Posts

avatar A & avatar B both have permission to modify each others objects.
They both have a scripted object that allows each other access to its menus and actions.
Each object can "give" transferable items from its contents to other avatars or objects (if the owner has permission to modify those objects).
So... avatar A's object can give items to its owner (avatar A) or to avatar B or to an object owned by either avatar
avatar B's object can do the same.

you with me so far?

then this test worked several times whilst testing various other gives from the objects....
avatar A gave a NOcopy item from avatar A's object to avatar B's object - worked
avatar A returned that NOcopy item from avatar B's object to avatar A's object - worked

but then we hit the problem when repeating that earlier working test....
avatar A gave a NOcopy item from avatar A's object to avatar B's object - worked
avatar A returned that NOcopy item from avatar B's object to avatar A's object - failed with a script error... Unable to give inventory: 'Blocked by permissions'
however avatar B could succesfully give that NOcopy item from avatar B's object to avatar A's object
further tries continued to give script errors to avatar A, but not the object owner, avatar B

why did it suddenly start giving 'Blocked by permissions' script errors to avatar A, when it worked before and why would the permissions be ok for avatar B

Apologies for the long post :)

Link to comment
Share on other sites

I don't know of any scripter or builder that hasn't had a frustrating tangle with the permission system.  It's not easy to figure out.  The situation you describe is odd, but I suspect that there's something going on that you haven't looked at yet.  For example, the LSL wiki notes these two potential issues with llGiveInventory:

 

  • If destination is locked then inventory is not transferred and a Blocked by permissions error is shouted on the DEBUG_CHANNEL.
  • If destination object is not modifiable then inventory is not transferred and a Blocked by permissions error is shouted on the DEBUG_CHANNEL.

I'm mildly confused about which object (A or B) is the one having trouble receiving things, but you might check both objects to be sure that they are unlocked and modifiable.  Also, if you have changed permissions on any of the items that you are trading back and forth, be sure that you have changed them on rezzed copies, not on copies in your inventory.  Perms are not set until an object has been rezzed, so if you change perms in your inventory and then load the item directly into one of your "givers", the actual perms may not be what you think they are.  See the discussion of the "slam bit" here >>> http://wiki.secondlife.com/wiki/Debug_Permissions

 

 

Link to comment
Share on other sites

Thanks for your reponse Rolig. Its late for me in the UK, so I'll try to take in all the info you have given tomorrow.

However, neither object is locked, both modifiable and we have permission to modify each others objects.

The problem occurs when the NON owner of the object tries to transfer a NOcopy item to their own object.

If the script is reset, it works ok again for a while

Goes to bed pulling my hair out, Night night :)

 

Link to comment
Share on other sites

I cannot reproduce your result.  My alt and I have been transferring two NOcopy objects between us, each using a scripter giver as the transfer agent, for a half hour. Neither of us has failed to be able to drop either object into our giver.

The specifics:

We each have a "giver" prim with this script in it...

default{    touch_start(integer total_number)    {        llGiveInventory(llDetectedKey(0),llGetInventoryName(INVENTORY_OBJECT,0));    }}

We each have permission to modify the other's giver.

We have each created a NOcopy NOmod Transfer object -- a simple colored sphere -- and placed it in our own giver.

We verify that either one of us can click on either giver to receive its contents.

We can each load either test object (our own or the one created by the other person) into our own giver.

We verify that no matter who loaded either of the test objects into her own giver, she and the other person can still click to retrieve it.

As I say, we have passed both test objects through both givers repeatedly, each loading whichever test object we happen to have at the time into our own giver.  In a half hour of testing, we have never failed to load either test object into either giver or to get it back out again.

Link to comment
Share on other sites

Thank you again Rolig, I greatly appreciate your time

I read the Debug_Permissions with interest including the "slam bit" and did learn from it, but I dont believe that is the problem.
The items we're using were created by my alt with the next owner perms set while they were rezzed. They show as I would expect in my inventory with (no copy), in blue text, following the object names and they leave my inventory when adding them to our giver objects.

ok, recapping. the failure occured when my friend tried to send a NOcopy item from my giver object to her own giver object (Unable to give inventory: 'Blocked by permissions'). This started to fail despite several similar successful transfers previously
we have permission to modify each others objects
She can still send NOcopy (& copy) items to her avatar.
She can still send copiable items to her giver object.
All other attempts by her to give any NOcopy item from my giver object to hers fail
I can still send NOcopy items from my own giver object to hers
Both giver objects are rezzed inworld, not worn.
llGiveInventory is used to give the items.

Today, without resettting my giver object, I did a test with my alt
she has permission to modify my objects but not my friends
I gave her access to the menus in my giver object by adding her to the allowed admin list
She successfully transfered NOcopy items from my giver box to my friends giver box
I concluded from this that my giver object must have permission to give items to my friends giver object because my alt doesnt.

I remain baffled why my friend lost permissions to give NOcopy items from my giver object to her own. Its as if the permission on my object changed, but only for her. I must have an error in my quite lenghty script somewhere, but what could cause permissions to change for only one avatar, only for NOcopy items and only to her own object?

I'll do more tests with my friend later.

 

Link to comment
Share on other sites

I notice these transfers rely on the fact that these accounts have been granted the ability to modify each other's objects. I wonder, might success depend on the script's owner being logged-in and in the same sim at the time the transfer takes place?

(I have no idea if that's even a requirement for this ability, but I was reminded of similar well-known blocking of script permissions for group-dependent abilities when the owning avatar isn't present on the sim.)

  • Like 1
Link to comment
Share on other sites

Thank you Qie, you hit it on the head!
I hadn't previously related my online status to the failure or success of the various gives from my scripted object.
Further testing today confirms your suspicions:
when I'm online, in the same sim - my scripted object always works.
when I'm offline - it fails giving to my friend's object but works giving to other avatars.

 

Link to comment
Share on other sites

Aha!  So the answer is that the owner of the "giver" must also be the owner of the land that it's on.  The normal solution to that issue is to deed the giver to the group that owns the land.  Be sure that you set its perms to Mod and share with the group before you deed it, so that you can still edit the script and other Contents afterwards.

Link to comment
Share on other sites

No, there isn't.  But I don't understand what you are trying to do.  I get confused each time I read back over your comments, so I'm clearly missing something.  Why do you want the objects to modify anything?  I thought the whole idea was to be able to pass NoCopy objects back and forth among the various owners and their "giver" objects.

Link to comment
Share on other sites

OK, so I am still clearly missing some part of your puzzle.  I have just written the following "giver" script:

default{    touch_start(integer total_number)    {        llSensor("Test Giver B","",ACTIVE|PASSIVE, 10.0, PI);    }        sensor(integer num)    {        llOwnerSay("Detected Test Giver B");        llGiveInventory(llDetectedKey(0),llGetInventoryName(INVENTORY_OBJECT,0));    }}

I put that script into a prim labeled "Test Giver A", along with a NoCopy object.  My alt has done exactly the same thing, except that her script has the sensor looking for my test giver, "Test Giver A".  My giver and her giver are both full perm and shared. 

We test.  Either one of us can touch either giver to make its NoCopy object transfer to the other person's giver.  Each of us then removes the original object from her giver, so that the givers now contain received NoCopy objects. Eaither of us can then click either giver to send the received NoCopy object back to its original home.  We can keep doing this transfer of the objects back and forth between the two givers as many times as we like, and either of us can do it.

NOW, we start the experiment again, with our original objects back in their starting givers.  My alt then logs out of SL.  I click her giver and her object appears in my giver.  I click my giver and my object appears in hers.  I remove both original objects, so there are now received NoCopy objects in both givers.  I can click either one and transfer its object to the other giver, the same as in the original experiment.  I can keep sending either object back and forth between the givers as many times as I like, despite the fact that my alt is not in world. 

Once again, therefore, I cannot reproduce your failed test.  My alt does not need to be in world for her giver to work.  It sends things to mine and receives things from mine with no problem.

 

Link to comment
Share on other sites

I might see a difference in the permissions between our tests
My friend / alt and I have given each other permission to "Edit, delete or take my objects" using The friend method from our friends list, so it applies to all of our objects
Are your objects shared in the same way or are you using The group method and just sharing the specific objects?
Ref: https://community.secondlife.com/t5/English-Knowledge-Base/Friends-and-partnering/ta-p/700067#Section_.4

 

Link to comment
Share on other sites

Select each object with your editor.  Open to the General page and check all three permissions boxes (Modify, Copy, Transfer) plus the box to Share with other group members.  When  you are doing collaborative projects, that is the only method that guarantees that collaborators will have full access.  Sharing by giving another individual access to all of your objects does not do the same thing consistently. The difference, I think, is that giving another person the ability to work with your objects does not give their objects the ability to do it.  You need to set permissions and sharing on the objects individually if you want to enable full collaboration between you.

Link to comment
Share on other sites

Thanks for your advice Rolig. I am aware how to share objects with a group, but that wasn't appropriate for my current project. I only want a couple of close friends and my alt to be able to access or change the contents of my object not the whole group. Yes I could set up a new group but thats not necessary as the script will do what I originally intended, although my friends will have more limited powers than I

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3048 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...