Owner/new owner permission problems

Has anyone else noticed a problem with owner/new owner permissions?

I have an object, which I set copy. It's automatically set no-mod because of a script inside of that I do not own. But if I give the item to my friend, he receives it as nomod/nocopy/notrans.

I've tried setting the copy permission both from inventory, or from rezzing the object and then taking it. The copy permission transfers okay for me. (ie: it rezzes as copy.) It just won't copy over to the new owner....

This is expected behavior. In inventory it will show a composite of the permissions within the object. However this evaluation only takes place when you rez the object on the ground. So when you initially transfer the object, it only evaluates the permissions on the object itself. When you rez the object it will perform the evaluation on the contents of the object and generate a composite.

It is interesting to note that attaching the object does not perform this evaluation, only dropping it on the ground. So you can maintain the top-level permissions and edit the attachment (adding full perms items for instance).

I assume that full perms items are allowed to be added to attachments because they won't change the composite permissions. This seems to also be the reason why you can't rez no copy items from attachments. It would require a reevaluation of the permissions.

Another important thing to note is that if you edit the next owner permissions from inventory you will only be able to select the least common denominator permissions-wise. So it is highly advised that you do not set the permissions in inventory. I recommend that you always set the permissions on objects rezzed on the ground so that you can be sure to maintain modify permissions after transfer.

Hope this helps.

Amethyst

Thanks for the reply, Amethyst.



However, that is exactly what I did:

"I've tried setting the copy permission both from inventory, or from rezzing the object and then taking it. The copy permission transfers okay for me."

I did figure out the issue. Appearently, the nocopy/trans logic has been changed recently. My item is composed of several sub-items that are rezzed by scripts. One of the items was accidently set to no-copy. Previously, this will result in the container item remaining copy/notrans and then generating a "cannot rez no-copy object" error when it attempted to rez that no-copy item.

But now it seems that SL bubbles up the no-copy to the container object itself now.

Okay, not a "bug" per say, just changed behavior I never noticed.

Well don't think that is a "recent change" it has been doing that for me for quite some time.

Yes, that sounds standard to me too.. the way to think of it is that when you see the object in inventory, you're seeing what you could do to the entire object.

So the object has a no copy object within it, you can't copy it because that would involve copying the no-copy object which you aren't allowed to do. It used to be the case that if you dragged a copy in world, you would get a copy with the no copy part missing, but that might have changed..

Further update: I have to set the ENTIRE CONTENTS of the object to copy in order to get the object to be copyable. All objects, all animations, all scripts must be copy.

This -- is not cool. This means that all of my scripts are now copyable and can be removed from my object if I give it to someone else.

Holy crap, why was this changed?

Are you saying that they are actually uncopyable when rezzed in world, or just listed as "no copy)" in inventory?

I have to make all the scripts in my network vendors copy and no transfer to get the vendors to be copyable. Have had to do that since about version 1.9 or so. Nothing new.

Yes, Yumi. The item shows up in the new owner as nomod/nocopy/notrans, and is rezzed inside the world with the same permissions.

I have talked to a Linden about this and this is appearently expected behavior. When did it change? I don't know.

This REALLY SUCKS because it means if I have, say, a security script or some other kind of authentication script, if I want the item to be copyable I also have set this security script as copyable. Which means someone can easily take it out, put it in another prim and have all kinds of fun.

Why was this changed?

Hmmm. I bought an object a few weeks ago with copy/mod perms, that contained no copy/no mod scripts, and I have no problem copying that object in inventory.
Can NOT copy the object when rezzed in world, as described above for expected behaviour.

So I hope what you are describing is a localized bug, because I was looking forward to selling my "copy" permed objects containing my no copy/no modify scripts.

But if this is another recent Linden messup, many store owners will be encountering some pretty unhappy customers. And I will be very unhappy that I won't be able to sell copyable objects.

That's because the vendors are no use without their scripts.

But if what Fenrir is saying is true - permissions propagation is now occuring in-world as well as in inventory - then that's much worse. In this case, for example, you'd have to make the scripts in your collars modify-ok because otherwise the prim model would inherit no-modify and couldn't be sized to the avatar. Scripted texture organisers, where the prim model might be full perms so that the user can grab the textures with the pipette tool, would become impossible - the scripts would have to be full perms too.

I'm definately going to need to check on this..

Same here. The ability to extract my scripts sort of renders my ability to sell a vehicle with custom physics a lot less useful. (And yes, I tested, even if the item is no-mod, people can take the scripts out.)

Random Person: Heck, I like his flight script, let's take it out and drop it into a vehicle of my own making!

Sure, this Random Person cannot give the item away, as the script is still no-transfer, but this does suck for other cases I have outlined earlier. (Such as the updater I use in one of my items I sell, which relies partially upon the fact it cannot be copied out of the item even though the item itself is copy...)

This behavior seems to be limited to just newly-minted items. I have an older vehicle I have created with is nomod/copy/notrans, with scripts and items within which are nocopy, and when I give it to my friends it still shows up as copy/notrans.

This change is recent; That vehicle I mention which has nocopy scripts, for example, I made in version 1.10-ish. HOW recent I don't know, because I haven't been building in SL for a little while.

Yumi, I haven't verified yet if nomod is treated the same way but -- that's a really good point. This is a big problem for a lot of items that people might choose to sell!

Another problem: My older vehicle gives you a full-permissions HUD when you get on it, so that you can read the battle damage display. Does my vehicle now have to be rezzed full permissions? :/

It wasn't. That's explicitly how the system works. You can't copy an object unless you can copy everything in the object. It's documented that way everywhere, and it's been that way as long as I've been in-world (since 1.6).

This is not the case for container items with copy permissions set for next-owner. ie: Next-owner says copy, so new owner can rez from inventory as they wish, but THEN do not have the ability to copy the item once it is inworld and next-owner perms have been enacted.

THAT has changed.

NOW it appears that no-copy child items are being applied to the container immediately, upon transfer to another person. Instead of when the item is in-world rezzed.

If this is "how the system works" or supposed to work then why was it changed? Prior behavior was very useful, in that it let you give out containers that had different permissions than their children. (Like my copy/trans Daleks, which contain nocopy/nomod/notran scripts that I do not wish people to edit or remove for fear of them being turned into griefing weapons.)

So what? They bought your vehicle. You've got your money. If they believe value in the vehicle is in the script, and the script is why they bought it... then the script is what they bought. To them, the script is the vehicle, and all they're doing is customizing the appearance.

Seriously, if they make the vehicle look different, what have you lost? You haven't lost any sales, because they can't resell it, so where's the problem?

Ah, the "Tringo hack".

I've had a couple of items trashed by that, because I didn't know that wearing them would turn them no-copy so I needed to make a copy in inventory before doing the "wear then drop" hack to rez them at high altitude. I've also got a plane I'm trying to fix... a modifiable one using an open source script, by the way... that has a "tringo hacked" prim somewhere inside it that's turning it no-copy when I rez it... which makes it hard to debug given how easy it is to lose and trash planes these days. I'm going to have to take the whole thing apart and examine it prim-by-prim.

And the reason this was changed was that people were accidentally selling objects "full perm in inventory" and getting them pirated as a result.

I have no idea what the "Tringo hack" is. This is a very annoying change for a safety net.

As for having items that contained other items which effected-inworld rezzing; Well, that to me is the responsibility of the original creator. If they had a prim inside of it that ruined the item upon rez when it was supposed to be mod/copy, that's something I would take up with the original creator. If they have no clue, or do not want to fix it, then well, my time is likely better spent elsewhere.

Other reasons this was useful; Self-limiting items. You rez it, it had copy permission so you could keep rezzing it from inventory, but no longer has copy when in-world and now cannot be duplicated. Or it contained a no-copy prim that it rezzes and then is intentionally no longer useful. My copy/notrans vehicle that could give out a full-permission HUD. Or the Dalek example.

As for the assertment that I shouldn't care, because I have that person's money -- My items are more than just scripts. It's a holistic experience, a combination of art and science. I don't necessarily want people taking my items apart and using pieces from them in their own creations. I mean, that's why it's no-mod! But under the new system, all of my child items have to be copy if I want to give the new owner the ability to make copies -- not just scripts, but prims, sounds, animations...

This new system is much more restrictive. :/

I am still able to give out my copyable collars with the contents being non-copyable. How are you testing this?

[Edit]
Meaning I pass out the collar itself as copyable (but keyed to a particular individual). They rez it and it becomes no copy because of the no copy status of the contents. But they can hand them out from inventory as much as they want.

That's the behavior I am seeing for my vehicle I made a while ago. But my latest one sets itself no/copy. I've given it to several of my friends and they all see the same results.

I've tried both FirstLook and the original client, it doesn't seem to be related.

I figured exactly what was going on by removing every last script and child prim in my vehicle until it became copy/notrans when I gave it to my friend. I found out it was the scripts, so on the second pass I set all scripts to copy and gave it to him. If any one of the scripts or other items (such as animations) wer not set copy, it would show up in his inventory as nocopy.

(Also, when I say "child prim/obj" I am meaning a prim/obj that's contained inside another.)

Well I am not sure I've done testing about an hour ago and I do not see the behavior you are describing. Must be something else we are missing.

Now I am REALLY confused.

I have a script in my vehicle (Callahan's Combat System, FYI) that is set to copy/trans/nomod, and it's causing my vehicle to appear nocopy, even though under Debug Permissions I see "N: V C". But when I give it to a friend, it shows up in the inventory as (no copy), but when he rezzes it, it shows up as "O: V C". (Yet he can't actually make a copy by, say, shift-dragging.)

But if I remove the CCS script it causes my vehicle to behave the expected way. (ie: It remains copy, even though the scripts within are no copy.)

I've tested this extensively with my friend, and I was barking up the wrong tree intially; Making everything copy in my object does allow it to become copy for him (with the CCS script inside), but if I have just one item that isn't copy along with the CCS script, it makes the vehicle no-copy.

This is just...weird. I'm filing a bug.

I tested this last night with Amethyst's help, with a newly created object and script, and it's behaving pretty much as it always has.

If you put a no-copy script inside a full perms item, the object shows in inventory as being no-copy. When rezzed, you can't copy or transfer it, because the script would have to go with it. You can modify it, because that doesn't effect the script. If you take the script out, you can copy and transfer it.

On the other hand.. if you put a no-copy script inside an object, pick it up, and then set it to full perms, then you get an object that's full perms until it is rezzed, and then becomes no-copy (unless the script is removed). This is because SL doesn't check the permissions on internal parts of an object until it's rezzed.

It occured to me that if we want that feature that allows us to open up objects that are in our inventory to more easily and and remove items, this particular "functionality" would break. The inventory would now know if an inventory item had a no-copy object inside it.

That's what's so weird about this, I received the script with these permissions: nomod, copy, trans. So I have copy permissions for this script.

But yet, when I place it in JUST this one object, it makes it go no-copy when I give it to someone else, regardless of how I set the offending script. If I create a new object, drop the same script in it, the object is allowed to remain copy when I give it to someone else.

I've filed a bug about this.

I'm not going to argue that you're wrong, you have to get with Linden Labs on that. They seem to think it matters.
Yeh, like I said, I've got some products like this and they're a royal pain. For example, I've got over 100 avatars, I want to customize an item ONCE and put it in each folder for further customization. For items like this I have to do the same initial configuration for every single avatar, instead of just making minor changes for a few avs. Or a vehicle, where you *have* to be able to save a copiable version in your inventory because of the likelihood that you're going to lose it. Doesn't matter whether the configuration is because the item is mod or because the item's got scripts in it that let you change colors or textures or preferred animations or whatever.

I don't understand this... it doesn't work the other way: rezzing a notrans object doesn't remove trans permissions from objects inside it.

You and Steve Jobs both. Luckily for Mac buyers, the law says that you're allowed to modify your mac and even make it ugly, and for good reasons.

Yep, the new system is much less restrictive.