Right now i can not get any textures to come up int he picker at all. It is total broken.

Bottom line, if a texture is in my inventory, it must show in the texture picker. Permisions are irralavant, if i own a texture i should be able to use it.

Darling Brody

ps. i would vote twice for fixing all texture picker problems!

To apply a No Transfer texture to a prim, just drag the texture from your inventory onto the actual face of the prim you want to apply the image to.

Your prim will complain with: "Object shouts: Unable to add item!"
Presumably because you're not adding stuff ot the object's inventory but rather applying a texture.

After the texture has been rezed on an object you can use the eye-dropper tool to select the texture for other faces of the prim, just like you would with any other texture.

Hope this helps someone as much as it helped me.

The issue I'm having is that I am holding up products for sale as I would have to educate every buyer on how to use this workaround.

I created the product when this was working properly and customers don't want to hear it's an SL bug, not a texture problem. This is a problem, I would think, for any builder who doesn't want to give out their textures full perm or include a couple hundred variations of the product depending on which 'color' the person would want to have it in.

I guess I have to go back to the drawing board and just maybe make a scripted way for changing the texture. I was really hoping for a solution by now.

it's as easy as print screen and reupload, to get full perms on a texture

Setting no copy, or no transfer, is IRRELEVANT. If you want texture setting, use scripts and set by UUID. Or make the textures full perms.

Looks as if this was implemented on purpose. Is there a good reason for that?

Ok, I have to say that I'm strongly against this fix as there is a reason for a texture to be no transfer, as in, IT'S FOR YOUR EYES ONLY!

Looking at the comments I counted 5, FIVE,

F _ I _ V _ E

people who wanted to circumvent the no transfer setting on textures, and a few who actually wanted to redistribute them in or on items they were intending to place for sale, can we say possible DMCA....

C'mon peeps, you can't cry foul in one topic and then try and do the same thing later that you were crying foul about earlier.

And the reason they SHOULDN'T show up in the texture picker is so they can NOT be placed on a prim for others to see, (remember, for your eyes only), which would technicaly be considered transferring the texture in question.

So, anyone out there wanna give me a yes copy/NO transfer item so I can turn around and try and get Linden Lab to make it so I can give/sell it to lots of someone elses?

Votes a really big NO for this being broken into allowing the transfer of no transfer textures.

Whichever the case, it certainly makes no sense that the behaviour is inconsistent between the texture picker widget and the inventory drag&drop. But since it still works, imho this is a minor flaw, not a critical bug. If the above is all it takes to fix it then this is trivial (I have not tried compiling with the filter disabled).

The only way I have found to get around the problem of not being able to choose these textures from the Picker is to drag the texture onto a prim, which then puts a copy of the texture inside the prim. This isn't a big deal to me, but it's an annoying way to have to do it.

Couldn't we see a transfer of properties, where if a builder uses "no transfer" textures, the prim itself becomes "no transfer" because of the texture? This would be similar to cases where a prim is holding a collection of items and one (or more) of its contents have restrictions on its permissions...

Oh-- I have seen this in 1.19.1 and 1.20RC0, as well.

"And the reason they SHOULDN'T show up in the texture picker is so they can NOT be placed on a prim for others to see, (remember, for your eyes only), which would technicaly be considered transferring the texture in question.

So, anyone out there wanna give me a yes copy/NO transfer item so I can turn around and try and get Linden Lab to make it so I can give/sell it to lots of someone elses? "

With all due respect, that's just stupid! Placing them on MY prim, in MY build, on MY land is certainly not "technically transferring them" whether others can "see" them or not. There's a HUGE difference between "seeing" something and "owning" something. Your analogy above would be better stated by saying that if the item you own is NO transfer, then you won't be allowed to rez it for your own use, because after all, someone else will SEE the item, and we can't have that, right? RIDICULOUS!

I have a large NO transfer home which I purchased, which came with a set of NO transfer textures to allow me to do matching textures on my NO transfer home should I make modifications to it. I in no way will be circumventing DMCA if I apply those textures to mods on my home - after all, they're already covering my home in the first place!

"there is a reason for a texture to be no transfer, as in, IT'S FOR YOUR EYES ONLY!"

Once again, NO Keisha, its not for my eyes only, its for my ownership only.

We don't have a mechanism to preview a texture on an object, so the live preview ("Apply immediately") functionality actually applies the texture via the normal mechanism. This also supports live collaboration, or WYSIWEG (what you see is what everyone gets) since anything you preview becomes visible to others around you. This is usually not important, so I think we can live with it turned off by default to fix this bug.

Anyway, if you do this with a no transfer texture, then the texture is removed from your inventory and appears in the object's inventory. We would then have to ensure that you get that texture back if you ever change your mind. And there are too many edge cases (object being deleted, moving out of range, your client crashing, etc) for us to guarantee that we give you the texture back. So we purposefully filter out no transfer textures when that checkbox is checked.

I think you're thinking of no copy/no transfer textures, too. With no trans textures, the texture is still in your inv, but since it's copy you'll still have it even if the prim is lost forever.

The workaround I use is simply dragging no transfer textures onto prims, but it's hard to remember what I have when I do most of my texturing via the texture picker. Is this something an OS developer could work on, do you think?

What does that mean ? In sandboxes right now, beginners are taught how to take snapshots of textures they bought so that they can enter the builders world...

Given this, they should appear in the texture picker as well. There is no reason for them not to.

what should you use them on? There is nothing left.
Anyways, in llpanelFace.cpp, around line 98:

// Don't allow (no copy) or (no transfer) textures to be selected during immediate mode
mTextureCtrl->setImmediateFilterPermMask(PERM_COPY | PERM_TRANSFER);
// Allow any texture to be used during non-immediate mode.
mTextureCtrl->setNonImmediateFilterPermMask(PERM_NONE);

For this fix, setImmediateFilterPermMask simply needs to be set to

mTextureCtrl->setImmediateFilterPermMask(PERM_COPY);

Then, no-transfer textures should show again, even with 'apply immediately' turned on.

This also affects llPanelLandMedia.cpp for media textures, llPanelObject.cpp for sculpts, llFloaterLand.cpp for parcel images. In those three cases, setNonImmediateFilterPermMask is also set to PERM_COPY |PERM_TRANSFER. I presume this should be simply PERM_COPY to only prevent selecting no-copy textures here, as well.

On a note, the appearance editor lists all kinds of textures, even no-copy, in the texture picker for new outfits.

But this limitation impacts the way the texture is applied in classes.