I am fine with competition reverse-engineering my designs the hard way, taking a few hours to remodel it from the ground up, but I am not alright with the easy of adding a parameter stealing script that can rebuild an identical match of my design in a matter of seconds. This problem has caused me to mostly design for myself and close friends only and forego marketting much of my work. I am sure I am not alone on this, this feature should of been a part of the Second Life interface from day one rather than requiring a community supported vote several years later.

I think resize-only is a good start, but I wouldn't mind seeing no-content mod or resize/color-texture change only.

Personally, I think it's an all-around poor approach to things, since many people need to adjust individual prims (say, in a hair) to get the right fit. Also, as far as I know, a relatively basic client-side hack would make this permission rather meaningless when it comes to preventing theft.

Better would be to allow an option to prevent the object from accepting content into its inventory (such as the common copying scripts), which should deal with most casual thieves (who tend to use such scripts) without causing undo problems for legitimate users.

Ran, I don't think preventing modify-enabled prims from accepting scripts is a viable solution. Modify permission assumes the prims its contents can be modified, so it'd be incompatible with a new "no modify contents" flag unless the meaning of modify were to change (something I doubt). This is an SVC issue, too; the change wouldn't be client-side.

I have a charm I want to add to a necklace but, I can only shrink/grow it. Maybe I want to combine a tail with a belt that I have cause theres not enough attachment points? Maybe I got this crappy tiara, that could use a little of this and a little of that and now I have something I actually want to wear. This is a temporary solution to a problem that haunts content creators, there has to be better ways where the consumer can actually get what they pay for.

No one wants to buy a red car and have to keep it red, no one wants to buy a house without being able to add to it or change a wall. I am one to customize things and change them into something totally spectacular or what I envision... im getting bored lately at the lack of innovative content, maybe this is the only solution for now. But is protecting creators content going to satisfy? What value do you put to someones work so that it is reasonably priced?

Voted, but it was a very tough decision to a problem that isn't easily solved, and still won't be with this option.

While I won't go into it too much, with hair especially, full modify rights are a necessity - I frequently need to move prims around, in addition to resizing, in order to fit my avatar's shape, and accommodate my glasses. Also, deleting prims that I find unnecessary, like the tangle of bangs/tendrils that many hair makers put around the face of otherwise beautiful styles (or adding new prims, if a style is sparse). Finally, I re-texture almost all the hair a buy to a texture I made and uploaded to match my RL hair, for continuity. This change would remove all of these abilities, that I think are vital to the vibrancy of avatar customization that makes this metaverse so appealing.

If a creator chose to make their product resize only, and you don't like not being able to make more mods than that permission allows, you can always vote with your wallet and buy from someone else who does allow it.

Voting for this doesn't mean voting against full-mod perms. It's just another option that could help cut down on content theft.

You say that people can vote with their wallets and it's an optional tag, you're right there but considering the panicky comments that I keep seeing from content creators who are quite frankly paranoid at this point, rightly or wrongly, about the scourge of content theft that they'd probably vote to get rid of the mod and transfer tags all together if it was up on the JIRA. I can't blame them for being concerned but I have serious doubts in this as being a proper solution.

sonnet Trilling

Certainly content creators are concerned about lost revenues from ripped merchandise. If that's their only concern, I don't really blame them. I'd say it's definitely cause for concern. Apart from that I'd also say that many are concerned because they feel violated that someone has come in, and, with little effort, taken something that required a great deal of effort, time talent and skill on the part of the content creator to bring to market in the first place.

Part of the reason the vast majority of content creators produce goods in SL is the satisfaction of doing so. Sure, they want to be compensated for their efforts. That's part of the incentive, but there's a certain joy that comes from knowing someone liked something they created enough to sacrifice a few $L for the privilege of owning a copy. Don't you think content creators want their customers to be satisfied with their product and feel that they're getting the most they can out of it?

What I'm getting at is that simply because the option for resize-only perms exist, doesn't mean that suddenly everything will be made resize only. Full-mod perms will still exist, and as I said in my comment above, I believe the market (ie customers) will determine what perms creators ultimately set for their products.

Are there panicked creators out their who want to lock their content in a vault so no one can get at it? I'm sure there are, just as I'm sure there are those at the other extreme end of the spectrum who think everything that gets produced should be free for the taking to all comers.

But guess what? Neither of those things work in the marketplace for very long, and if they do they hold a VERY small portion of said market. The vast majority fall in the middle just like everything else in life, and those are the people who set the tone for the market.

Is a resize-only perm the last piece of the puzzle that will prevent content theft? Of course not, but that doesn't mean it's not a piece of the puzzle and doesn't have merit.

The fact of the matter is is that not everything in SL needs full-mod perms. There is no reason why something that doesn't need full-mod perms should get full-mod perms if another option is available. If someone tries to sell items without full-mod perms when those items need full-mod perms they'll have to provide a service where the creator makes the item work for the individual, moving and modifying prims to suit the customer's needs after purchase. Otherwise they'll risk losing customers to creators who recognize the fact that full-mod perms are necessary for a similar product and sell that product will full-mod perms.

I am absolutely all for satisfying my customers, as I think the vast majority of creators are, but the fact is not everything needs full-mod perms, and there's no reason another option like this shouldn't be made available. It's not the end-all-be-all-perfect solution, but many things aren't. If LL would change the TOS to outlaw prim replicators maybe something like this wouldn't be on the table.

And to make a final point, if so many of content creators are "panicky" and "paranoid" as you say, why hasn't one of them put up a JIRA request asking for mod/trans rights to be revoked as you suggest they would?

Basically the market will sort itself out if this ever comes to fruition, and the extremists on either side of the issue will end up being marginalized.

Secondly, the whole point of security is not to lock things down so even the best hacker out there can't get in. The point of increasing security is to decrease the amount of people who ARE capable of getting in. This goes the same with SL. It's impossible to lock things down completely, nor should we try. But it is possible to make security better so that we don't have a hypothetical Joe Bob who can barely open a word document stealing our creations because he found this cool neato script that does it for him.

Security goes two ways. Any time you increase the security of software you risk reducing the usability of the software. So you want to try and get to the point where you have the most security you can without sacrificing the ease of use and functionality of your software. Ultimately what I think would be best is to have a full range of "locks" across the entire object. Putting checkboxes next to each modifiable setting in the object details that allows us to set if this particular setting can be changed or viewed. These settings likewise would only get transferred upon object focus so wouldn't get transferred during normal server-client object sending for rendering. Meaning, it wouldn't create any additional lag in that regard.

Either way, I believe that the solution for IP issues in SL is for LL to put the proper tools in our hands to combat it, and that starts with better control over the permission system which hasn't really been looked at or modified since it's inception.

Edit- Yeah I really do mean trivially. I could create and distribute a client that can do it with very little effort. It doesn't take any obscure knowledge, it's extremely basic.

In fact, its more annoying that this, since some of us are very particular about how we set up icons and other things on our desktops, and changing resolution to some different mode, just to use SL, could potentially mess other things up, not including pushing the graphics card even harder.

So, yeah, I vote for this issue too, just from a usability standpoint.

This additional permission would provide a function that's very important to residents while reducing the exposure of the creators. Voted.

I absolutely hate No-Modify objects, especially clothing attachments, so I refuse to buy them, which is a shame because I see great content sold as no modify, which is utterly useless to me since i can't fit it to myself. This Jira if done correctly (Resize only is still a bit restrictive, there's no reason to not allow the rotation of and offset of a few child prims, but still have them hidden from script access), this would go a long way to improve people's content.

Delerium, although I can't find a citation just now, I recall a Linden acknowledging that they are aware that the whole permissions scheme needs a serious overhaul. The permissions change that actually seems to be making progress is VWR-5082 which advanced when a volunteer wrote a code patch without making major changes to the existing system. It would be nice to have a Linden at least say, "Yes, we see this and will keep it in mind as a possible addition when we get around to fixing the whole thing." Or even just, "Forget it. Ain't gonna happen."

modify did the job for 5 years now and the SL sky didn't fall so it doesn't seems to need an URGENT fix.

Seriously why do you think it qualify as a MAJOR issue when it has been like this since more than five years?

It's a feature request for a new permission bit, it won't patch all the content theft problems and not having it won't be the end of SL either, so at best NORMAL priority.

As has been mentioned, those who do not like no-mod items need not buy them. This JIRA request is not about bending the whole grid to meet the needs of a single shopper. It is about improving the permissions system to meet the needs of many producers and shoppers. Now, where are those Lindens?

I don't care if you customize your objects, but because YOU like to customize something you bought doesn't mean that EVERYONE must make their items modifiable. If I choose to make something no mod (or if the option were available) resize only, that's my choice. Just as it is your choice to not buy resize only or no mod objects.

See how freedom of choice and capitalism works now?

The point is that your attitude seems to be that if you don't like it or it doesn't suit your needs, then the idea isn't worth doing. It's an attitude you've exhibited in your comments on this JIRA item as well as at least one other today. You seem to be infatuated with the word "ridiculous" as you've thrown that around a lot in your comments here and elsewhere. Try to be a little more constructive next time.

As I pointed out in a comment above...

"...simply because the option for resize-only perms exist, doesn't mean that suddenly everything will be made resize only. Full-mod perms will still exist, and as I said in my comment above, I believe the market (ie customers) will determine what perms creators ultimately set for their products."

If you don't like how the perms are set on something....THEN DON'T BUY IT. Content creators want to sell the products they make, and they will ultimately set their perms in such a way that will allow them to sell the most product. If they don't, someone else will come along and make a competing product with perms people want. I'd imagine that there are plenty of products that a resize only option would work great for, others not so much. Doesn't mean it's not a good idea.

Because that is one BIG hog. What will the user interface look like on the dialog that lets you set permissions so that the next owner can or cannot change rotation x, rotation y, rotation z, size x, size y, size z, phyical, phantom, temporary, block type, path cut begin, path cut end end, hollow, skew, twist begin, twist end, hole size x, hole size y, profile cut begin, profile cut end, taper x, taper y, radius, revolutions, shear x, shear y, dimple begin, dimple end, sculpt texture, mirror, inside-out, stitching type, material, flexible, softness, gravity, drag, wind, tension, force x, force y, force z, light, light color, intensity, radius, falloff, texture, color, transparency, glow, full bright, mapping, shininess, bumpiness, repeats horizontal, horizontal flip, repeats vertical, vertical flip, texture rotation, repeats per meter, horizontal offset, vertical offset, scripts, name, description, share with group, allow movement, anyone copy, show in search, for sale, for sale original or copy or contents, price, owner copy and left clicked behavior? And for each child prim, including limits on position x, y and z in relation to the parent? Maybe I want the customer to change everything except I hate excessive glow and overly active flexiness and I am willing to let them sell these themselves, but not for too much money.

We asked the Lindens to change one bristle on that hog and they have avoided the issue for over a year. Linden Lab would have to buy a new server farm to accommodate the size of the hogs in the database if we could set "precisely" what you can do. There seems to be a lot of interest in the resize option. Let's see if we can find a way to get that one done.

Oh, and I am always bad at reading tone of voice, so I am not sure if I am disagreeing with Kagehi or reinforcing Kagehi's point. But, even if we get a little frustrated at the long wait for response on this request, I shall try to keep my discourse civil. If anything I say seems to insult anyone else, that was not my intention, and please accept my apology.

The point is, as nice as this one feature is, it solves one problem while ignoring a host of other similar issues. Useful, yes, as useful as it could be, probably not. So, lets put it another way. Lets say they add one byte:

&h01 = resize X
&h02 = resize Y
&h04 = resize Z
&h07 = resize All
etc.

That still leaves &h08, &h10, &h20, etc. for like.. 5 more attributes you could flag. If you add rotation, you get 2 left. So.. What, "let them change textures on/off" and.. what else?

Point being, if your are going to add one flag, its probably a good idea to use up the rest of the byte too, filling it with more flags for other attributes. Otherwise, you really "are" wasting space on the servers.

The user interface must also be considered. Putting nine more checkboxes at the bottom of the first pane of the edit window might get a little unwieldy. Should a new tabbed pane be added? Is there room for another tab? Or should the first pane have a button to bring up a pop-up permissions setting window?

Also, at the moment, when I look at an item in inventory I am told if it is no copy, no modify, no transfer. Clearly expanding this to a list of twelve items could be a problem. A set of single character indicators would be as ugly and unreadable in SL as it is in Unix directory listings. But allowing the modify item to also include "some modify" in addition to "no modify" would, I think, provide the user with enough information at that level.

First off, I was being conservative, and you miss counted. On an old 8 bit computer like the Apple IIs, integers only stored 8 bits of data, so only 8 flags where possible. Odds are, they store flags in a 32 bit integer, which means 32 flags *per* stored number. Right now, likely, their storage is either using a few bits of that data to designate the flags, or they are using individual integers for them, which actually wastes more space, but if you only have 1-2 flags, someone might consider it worth it. Its one of the things that bug me about languages like LSL. Even under VB you could at least break things down to real bytes, via something like:

type mybytes
byte1 as string * 1
byte2 as string * 1
byte3 as string * 1
byte4 as string * 1
end type

This is functionally equivalent of a 32 bit integer. In that you could directly tell the system something like:

mybytes t;
t = 3124554636;

But, VB also had true boolean, not an integer.

This would mean that "each" of the above "bytes" would also break into something like:

type mybool
bool1 as boolean
bool2 as boolean
bool3 as boolean
bool4 as boolean
bool5 as boolean
bool6 as boolean
bool7 as boolean
bool8 as boolean
end type

4 bytes * 8 bits (boolean switches) = 32 bits (switches)

I.e., the only values such a variable could contain was TRUE and FALSE, where as in LSL you could make something that says:

integer mybool = FALSE;

and later on go

mybool = 411;

and all the system is going to do is go, "Oh, its not zero, so it counts as true."

Well, yeah, by definition "Any value that isn't 0 when compared to 0, is not zero, so is TRUE.", it doesn't mean its a real boolean value. Its also why languages can't seem to make up their minds whether -1 or 1 should be used as "TRUE" in them, with half of them picking one or the other (and making a mess of math that combines boolean values with things like multiplication. VB opted for -1, while LSL uses 1).

Anyway. Point is, if you have an integer, as used in LSL, "in theory", that integer has 32 slots that can be filled with 0 or 1, in its binary representation. Functions like & and | do direct binary comparisons, they don't add, subtract, multiply, divide, etc. All they do is go:

1|0|1 <- first number &
1|1|1 <- second number
y|n|y = 101 <- answer.

1|0|1 <- first number |
1|1|0 <- second number
y|y|y = 111 < answer, since a 1 existed in at least "one" of the two numbers in all positions.

This means, if you use 8-bit, you get 8 slots, if you use 16-bits, you get 16 slots, 32-bits, you get 32 slots. Just like a bank of switches.

And, yeah. I would think that you would need a new tab, like "Advanced permissions" to handle what ever settings you allowed to be adjusted this way.

edit: that's what i get for deleting part of a comment and rewriting it sigh
There is already a 8 byte, not just 32 bit number reserved for permissions that a resize option would be tied in with. no extra space needed as it already exists and is reserved for future permissions.

pulled from lslwiki

Permissions Value (in hex notation) Value (integer) Description
PERM_ALL 0x7FFFFFFF 2147483647 Move/Modify/Copy/Transfer permissions
PERM_COPY 0x00008000 32768 Copy permission
PERM_MODIFY 0x00004000 16384 Modify permission
PERM_MOVE 0x00080000 524288 Move permission
PERM_TRANSFER 0x00002000 8192 Transfer permission

Note: ((PERM_COPY | PERM_MODIFY | PERM_MOVE | PERM_TRANSFER) != PERM_ALL). This is because there may (read as: will) be more permissions in the future.

Note, a "byte" is two hex numbers, not one. I.e., 0xFF = Byte, 0xF = Nibble. And yes, that is a term, its just never used, since no processor in existence ever worked, as far as I know, on "Nibbles", instead of full bytes. So, my explanation is still correct, in terms of how many switches/flags you have to work with.

yes directed at myself LOL

point is they can add the resize easily, and it would be very useful. as for the rotate comment, you can rotate whether it's mod or no mod. If only referring to child prims, that's modifying the whole thing, just just resizing. so kind of pointless. They could always add a new option as was previously suggested, 'no mod contents'. That would be useful in some ways. and would eliminate the need to choose very specific options (aka rotating child prims, moving them etc.) the resize only would not be the best fix for hair, but it would be better than relying on a script to do the resizing as some are.

Changes to permissions are only going to be 1 or 2 at a time. They are not going to do a bunch of different options all at once. If they did, imagine the bugs we would likely have and how chaotic content creation would be for a while. Not practical nor desirable.