New Object Permissions Needed

For some time it has been recognized that object permissions need revamped. While I can't cover all the options in one message, at least this might open up some comments for such.

* SIZE MOD OPTION. Just because an object is nomod (in order to protect builder designs) doesn't mean it should not be resizable. There is need for a size-mod option for things such as hats, jewelry, swords and a plethora of other things. Why should an item not be able to be size modifiable? The builder should be able to indicate "nomod / size modifiable"

* TEXTURE / COLOR MOD OPTION. Same concept. Just because the builder wishes nomod does not indicate he wouldn't allow colors and textures to be altered to taste. So add a "color/tex modifiable" option.

* TEXTURE TRANSFERABLE. Right now texture vendors have two options: they can either make a texture full perm (thus immediately losing their hard-created texture author rights the moment they sell the first one) or they can make it copyable/no-transfer which means it cannot be used by builders to do builds for other people. A third function is needed across the board: IF a texture is copy/notrans, then IF that texture is used on a prim, that prim may be transferred. It's not like the texture itself is being transferred; it is simply adorning a prim that may then be transferred to the buyer of a build.
This option would be such a boon to the texture sales industry!

* BUG BUG BUG BUG. This bug has existed for as long as I have been a member of SL. LL has been notified of this bug time and time again, yet the problem still exists: the permissions shown on an item while it sits in inventory are often different than shown when the object is dragged to ground. How many objects have been lost to "public domain" because of this bug? Someone checks an item's perms in inventory and it says "nomod/nocopy/trans". Yet when it's dragged to ground, why, COPY is available! Had he given that item to someone, it would been all over SL before he could blink. Bottom line: perms should read the same in inventory as they do on the ground. No exceptions.


So, there are some first concepts. Any other permission ideas folks want to add?

There is a related bug in that if an object that is set to be "copy/no trans" and contains a script that is "no copy/no trans" (ignoring mod here, it doesn't matter), the object when you recieve it from the creator has cop/no trans. So, you copy it because you want a back up copy, then drag it to the ground and go about modifying it (you know you want to with your expesive avatar) and then link it back up again. "no copy/no trans." You now can't copy your modded version for backup because of the SCRIPTS that control it. Not only is this a pain (because it should be copyable), but if your above suggestion gets fixed, our "mod/copy/no trans" avatar parts become "no mod/no copy/no trans" overall, and while we can modify it (the prims are still set mod) we can't make a copy of it for backup DESPITE the prims being copyable.

Yup, exactly. I spoke with a Linden a while back regarding this very thing. If a primary object is marked COPYable but a script is marked NOCOPY, then here is how it should work:

The OBJECT entire may be copied. However, the script by itself cannot.

If an object is marked TRANSferrable but a script within is NO-TRANSFER, then the entire object should be transferrable, but the script should not be able to be removed from the object and transferred.

Instead, if I make an OBJECT marked MOD/COPY/TRANS but with a script that is marked MOD/COPY/NOTRANS, then when I give that item to someone, here is what it comes up with:

In inventory listing: NOMOD/ COPY / NOTRANS
When dragged to ground: MOD/COPY/partialTRANS

And when the receiver then tries to give the item to someone else, even though the main object is marked to allow transfer, it won't allow such because the script inside is marked NO TRANSFER. It is apparent in such a situation that the builder wants the object entire to be transferrable, but doesn't want the script by itself to be removed from the object and be transferred.

The fact that the "inventory perms" and the "ground perms" read differently indicates that the perm system is a bit messed up.

There is also the matter that when the properties are examined on some inventory items while in inventory, the "creator" shows up as "nobody". So how are we to know who made an item that we cannot drag to ground?

Seems odd that such bugs would have been around so long without someone fixing them. This isn't a minor thing, it is a major builders permissions bug. That's not back-burner that seldom causes problems; it's a hard core "@#$## I JUST ACCIDENTALLY MADE MY WORK PUBLIC DOMAIN/COPYABLE!" type bug. I nearly lost my entire merchant line last year due to such (thank goodness the bug only affected 4 items) and I let LL know about it both in emails and in the forums... yet the bug remains unfixed.

So you purchase a no-copy script from me that i want you to only EVER have one copy of because of some reason. You create a brand new prim of your own with full perms. Put my script inside. Grab your object into inventory

now because the containing object is copyable you just broke the protection i was supposed to have for my script. you rez out a lot of copies of your object and then pull the scripts out.

BAD IDEA(TM).

One important point: your script/content vs my script/content.

If I put my no-copy script in a copyable object and give it to someone, it's obvious I intend the script to be copyable so long as it remains part of that object, but not copyable if it is removed from that object.

Why? Well, I may want to create a vehicle that can be copied by the owner, but I don't want the vehicle script copied and applied to another vehicle.

If I put your no-copy script in a copyable object, then it shouldn't copy, because although I'm the creator of the object, I'm not the creator of the script.

So if the creator of the OBJECT is the same as the creator of the SCRIPT (or any other object CONTENT), then so long as the contents remains in the main object, they should follow main object parameters.

If you are the creator of the script, then whether I put it in a copyable/ transferrable prim or not, your perms override, because you are the CREATOR. That's part of the "not enough perm parameters" issue.

ok.. you purchase one of my no-copy scripts and pick up a full perms object of mine seperately. Put the no-copy into my full perms object. grab object. rez infinate copies (because the script is in an object also created by me) and take those script copies.


A no-copy script would need to be completely non removable by any means from a prim. But you would still be able to use a full perm objec tof mine to create script duplicates, unlinked the object and then use those prims with my script in one of your own creations.

Its still abusable and removes my ability to set restrictions.

EDIT:

btw i love most everything ELSE. we need a lot more permissions agreed and in general i SUPPORT this proposal. Just not supporting any aspect that under any conditions at all EVER lets you copy a no-copy item.

Good point. Yet there are solutions to that scenario: someone removes a no-copy script of yours and tries to put it in a full-copy object of yours. Since they are not the CREATOR of the content, they would be restricted from putting that nocopy content in a full copy object (or if they did, that fullcopy object would automatically switch to nocopy until the nocopy content was removed). You could still do so of course, since you are the creator of both object and content.

You are correct... there are issues that would have to be examined and heads put together so nothing was overlooked. They'd need someone to take the part of "if I were a thief, how would I hack this?" and figure out the problems just like we're doing here. Multiple heads would be good; I'm sure there are a lot of merchants that would be willing to present hack scenarios so they could all be addressed before a perms addition was released to the public. And of course, such could all be tested in Preview Grid before release.

But like you said, something needs to be done. Right now, there is no way at all for a texture merchant to sell textures as they need to be sold, ie, nomod except color/ copyable/ no transfer unless decorating an object. If they made that change alone, texture merchants and builders would become best buddies real fast.

IMO if i was selling textures to someone intended to be no-trans my personal intention would be for t hem to NOT be able to use that texture for profit at all or to just give it away on prims. So i -like- the fact that when a notrans texture is put onto an object, that the object becomes notrans. Just preference.

Example:

i have some really beautiful wall paper, floor tiling and other textures that make an absolutely beautiful home interior. My target market is people making their homes. I sell my texture to someone in Cordova that says they are designing their house on land they just bought. Next week i see 40 people with prefab homes all using my stuff. Thats 30 customers i was just cheated out of that bought my NO TRANS texture from the other guy instead of me.

BUT:

for people wanting to do your method and allow use some other perm would be great. personally on textures i think the 'no mod' flag should determine if the texture can be used in sellable items. I mean right now no-mod does nothing of any value for a texture. You have to have ALL perms to save it to disk. And you can always put it on a cube, set hires mode and take a snapshot to disk to save it. Well just an idea.

Well, the point is adding perms, not altering. For example, current perm list reads:
Modify
Copy
Transfer

And if you remove copy, it forces transfer.

Better list would be:

Modify
Modify Colors
Modify Textures
Modify Overall Size
Copy
Copy with Transfer
Transfer only
Transfer if part of an object // ie, textures and content intended only for original object.

That would pretty much take care of the whole 9 yards far as I can tell.