Permission Quirk?

I have a table that shows as "no modify, no transfer". I rez it on the floor and since it is copyable, it creates a copy on the floor. Now instead of deleting the copy on the floor like I normally would, I clicked 'take' -- which of course puts a new copy in my inventory.

The part I'm questioning: The 'copy' that gets put in my inventory is marked "no copy, no modify, no transfer". I copied the copyable one to the floor and took it back a few more times and every new copy now has the "no copy" attribute. How does that happen when the first one doesn't show that?

~Twosteppin

Little oddities like this happen sometimes while objects are in inventory. If you drag those copied tables out of inventory onto the ground, you should see that they are indeed each copyable. I have no idea why inventory gives false information like this sometimes, but it does.

Nope - the ones marked "no copy" really are 'no copy'. When I take them from inventory and rez them, they do get removed from inventory -- all except the first one that didn't have that attribute. I suppose it is just another one of those SL things.

The one that isn't showing (no copy) hasn't been rezzed in-world since being set 'no copy.' Changes to the item's permissions were performed on it while it was in inventory. If you enabled Debug Permissions in the Client menu and checked out the Properties of the inventory item, you'd find an asterisk, representing that the "slam bit" is set on that item and its permissions will change upon rez. There may other things besides a rez that will cause the object's permissions to be reevaluated. To avoid this happening with your items, a creator can set the desired permissions on the object while it is rezzed, before taking the object into inventory.

Very interesting. I had no idea it worked that way. Thanks, Day.

It's not a quirk, it's so people who make things can resell them. Think about it. If I make something and set it to no transfer, then how would I vend it. So, it's setup such that the next owner cannot transfer. The original transferable one is always transferable, but copies rezzed from it are not transferable because of the "next owner can" setting. It's the system considering a copy a transfer of the item, hence it sets the "next owner" permissions. It's not a quick, it's the system performing as it was designed.

It could also be (instead of a quirk) a script that is in the object that is set as no copy. If the script hasn't run yet (as in the one in your inventory - the original) then the permissions don't show up in inventory. Once rezzed, the script runs and the permissions take affect. Therefore, once back in inventory, it'll show no mod/no copy/no transfer.

Is your item scripted in any way? (pose balls have scripts as well as ball-less furniture with a sit target imbedded)

A

Johan, I think you may be misunderstanding what Twosteppin was saying. He/she appears to understand next owner permissions just fine. That wasn't what was in question.

The issue was that copies of an object that was supposed to be copyable for the next owner, who in this case happens to be Twosteppin, turn uncopyable when taken into said new owner's inventory. This is odd because objects that are copyable for the next owner are supposed to be infinitely copyable by that owner, including copies of copies, and copies of copies of copies of copies.

Every copy is supposed to have the same permissions as the original, but in this case, they don't. Permissions are changing by the simple act of taking objects into inventory, which is not how it's supposed to work.

This behavior is not a function of next owner permissions as most people use them. It could be a quirk resulting from the creator having set permissions in inventory instead of in the world, which Day explained pretty well, or it could be a scripting issue like Abba described.




What you're describing is simply not how the copy permission works, not at all. I've got plenty of copy/no-transfer items in my own inventory. If I rez one and then copy it, I can make copies of the copy just fine, which is exactly how it's supposed to be.

Making a copy doesn't count as changing owners in any way. Why should it? The original and the copy are both owned by the same person.

If I simply right-click the copyable item and click copy and then paste, I get a new one that is still copyable. The item doesn't have any scripts. It isn't transferable so I can't give it to my alt and see what happens to the permissions in that case. When I 'edit' the item, even though it is 'no modify' I can still see that the "Next Owner Copy" box is checked.

However, if I then select 'edit linked parts' and click on the individual pieces, none of those have the "Next Owner Copy" checked. I checked the linked parts of another copyable item and every one of those pieces do show 'next owner copy' as checked.

Do the permissions of the linked pieces come in to play here? If so, definitely something for me to keep in mind because I think I have only been worrying about the permission of the final linked object for things I've been creating.

When you set the perms after linking, the child prims are supposed to inherit the perms of the parent. It sounds like maybe the creator of your object set the child prim perms to no-copy after linking. That's just a guess though. I'm curious so I'll try playing with that.

Ok Chosen, I re-read the post, and here's my take on it.

Original object is no mod/no xfer/copy

object is rezzed..

Original object still has no/mod/no xfer/copy perms

New object has no mod/no xfer/no copy perms. So, the difference being the rezzed copies of a copyable object turn no copy. Other than that, the permissions are the same.

Ok, here's why....

As Chosen stated, pointing out my mistake, a rezzed copy from inventory doesnt mean the new object rezzed is transfering ownership, but.. if an object is copyable, I can walk up to it, right click, and take a copy. Hence, if I set next owner permissions to no transfer, then when the copyable copy (the orginal) rezzes a new copy into the world, because Next Owner Can: permission are set to no transfer, the rezzed copy must be set to no copy (so others cannot right click and take a copy!). I stated it wrong... but I knew it had to do with next owner permissions. So, I'll state it one more time, it's not a quirk, it's the system working as designed. Trust me, even with all it's bugs and glitches, all of the possible copy/mod/xfer scenarios have been considered, and the system sets permissions accordingly. Hope that clears it all up

Sorry if it seems like I'm beating a dead horse, but I'm pursuing it because I'm still learning to build and so I'm try to also fully understand the 'permission' piece of it - and I love a puzzle.

This is the only item out of dozens that I've now tested that is doing this. I have a table and a chair, both received from the same person and that person is also the creator of both objects. Both objects show as 'copy/no mod/no xfer'. When I rez the chair and then take the copy that rezzed, the result is 'copy/no mod/no xfer' - just like the first/original one. But when I rez the table and take that copy is when I get what appears to be the anomaly. The only difference that I see between the two items is the permissions of the individual linked pieces.

I love to hop the lucky chairs, so I've got lots of 'no mod/copy/no xfer' items to play with and as of yet, I cannot find another that does this.

I think I'll go create something new and play with the permissions of the child pieces.

Think I might have found it, although if so I'm still a bit confused.

There is a pose ball as one of the linked pieces - I didn't notice it when I was first looking at the individual pieces -- and inside that pose ball is a 'no copy' animation.

If that is what is making the overall item 'no copy', how come the main/first item that I received didn't inherit that 'no copy' attribute? Not to mention the fact that I can apparently use copy/paste as much as I want to create more copyable copies.

Yes, that's why... it's working just as I explained above... and if one prim or content of a prim is set as no copy, it will do that.