No Copy / No Transfer Textures useless - Viewer 3 & Firestorm

[Lynna Yorcliffe]

Perhaps someone has some knowledge of whats going on but I have noticed that if I create a prim - and try to apply a sculpt map (no transfer) it will not apply to the prim - I get a red circle with the slash symblo (no symbol) and the same goes for any no transfer  textures. IN addition the Viewer 3 gives me a message I can not VIEW any no copy or no transfer texture I own in my inventory. WHAT IS up with that ? So now all the sculpt maps I purchased that are no transfer are useless ? And any no transfer textures are also useless?

WHY?

It appears I have been defrauded of even personal use - after paying for these items. Can someone tell me whats going on. If this is a bug, if a fix is in the works or have we actually had our use of our inventory stolen from us ?

[Alicia Sautereau]

This is painfull thing, but there is a "fix"

When you navigate to the texture in your inventory, you can drag it into the build window texture preview, same problem in the normal texturing window where "no transfer" textures will not show and need to be applied manually

[Drongle McMahon]

I tried this with a texture given to an alt. I don't see how that "fix" is supposed to help. You still can't put it in the sculpt map. There is something really wrong here. When you drag the no-transfer texture onto the object or into its surface texture box, it appears in the invenytory too, and it disappears from the object when you delete it. If you double click in inventory or in the texture panel of the edit dialog, it gives an error message saying it can't display a preview, but it does show the preview!

Surely there is a jira for this already ... I'm going to have a look.

 

[Drongle McMahon]

Yes. Here is the jira. It is expected behaviour!! :matte-motes-agape:

I don't understand why the no-transfer texture has to be in the object's contents to be applied. Can anyone explain that? When you drop the texture on the texture box, it automatically inserts a copy in the contents to satisfy that requirement. So why doesn't it do the same with the sculpt map box?

The jira says you can put the texture in the sculpt map using a script, which requires it to be in the contents first. That is the work-around. It's a bit much to expect ordinary users of purchased sculpt maps to know that they have to do that, and how to do it! I can't see any reason this action should not be done automatically when you drop the texture on the sculpt map box.

Might be worth a feature request.

ETA - also, the jira doesn't deal with the self-contradictory error messages!

ETA - tesed dropping map into contents and then script with

     llSetPrimitiveParameters([PRIM_TYPE,PRIM_TYPE_SCULPT,"texturename",1]);

That worked. Could then set stitching type etc in the edit dialog. Deleting the map from the contents reverted to the default sculpty.

[Kwakkelde Kwak]

---

Drongle McMahon wrote:

I don't understand why the no-transfer texture has to be in the object's contents to be applied. Can anyone explain that?

---

 

I think that's because the way permissions are seen by SL. If you apply a texture to an object, it doesn't change the permissions. So if you were to apply a no transfer texture to a full perm object, the textured object would be transferrable. If you have to put the texture into the object however, the permissions of the texture apply to the entire thing.

[Drongle McMahon]

Maybe. But why can't the texture permissions apply anyway, without it being in the contents? Maybe a matter of programming convenience or performance. Also, I deliberately tested it on a no-transfer object to get around that requirement, and it still couldn't be applied. Whatever, ther's stioll no reason dropping on the sculpt map shouldn't function the same way as dropping on the texture and add it to the contents if that's needed.

[Alicia Sautereau]

Expected behavior, well, that`s just, crap ...

[Lynna Yorcliffe]

So you have to drop the texture into the contents of the object first ? ohh what a mess.

[Lynna Yorcliffe]

Really - I wonder who thought this change up and why they messed with it when it worked just fine before (?)

[Cerise Sorbet]

---

Drongle McMahon wrote:

Maybe. But why can't the texture permissions apply anyway, without it being in the contents? Maybe a matter of programming convenience or performance. Also, I deliberately tested it on a no-transfer object to get around that requirement, and it still couldn't be applied. Whatever, ther's stioll no reason dropping on the sculpt map shouldn't function the same way as dropping on the texture and add it to the contents if that's needed.

---

This is one of those ugly legacy problems. Very very early on, it was decided that permissions for textures would be stored in the inventory entry. The texture assets themselves have no permissions information on them. So, the inventory entry in an object is how the server can learn what the permissions are. This is the case for most asset types that aren't objects. That horse is lightyears out of the barn now, so we get to put up with the quirks.

This same problem led to how user-uploaded animations got their unique behavior, where scripts can only run them by inventory name and not by UUID. User animations were added after the trouble with sounds and textures was fully grasped. And of course, this was one of the considerations (along with the performance worries) that kept mesh assets inaccessible by UUID.

[Kwakkelde Kwak]

---

Drongle McMahon wrote:

Maybe. But why can't the texture permissions apply anyway, without it being in the contents?

---

 

Because the object can only store one set of permissions. As soon as a texture is applied it no longer has properties, the texture becomes one of the properties. All that is stored in the object is the UUID. That's just how it works. If the texture permissions would apply to the object, those permissions would stick when the texture is removed. That would be fun.

Doesn't sound like a lot of work to add 8 extra "permissions slots" to objects for the textures, but I could be very very wrong. Ofcourse these slots would also have to show somewhere in the texture tab or one wouldn't know why something can't be copied for example. That might be confusing, what should the permissions say for a texture that is applied to an object and then sold? The texture isn't copyable or transferrable or modifyable, it's simply applied and can't be taken from the object. So even if the object is full perm, the texture can't be considered to be that. Should the menu say "the texture on this face makes it impossible to copy the object, even though the object itself has full permissions and oh by the way you CAN transfer the object, this texture doesn't prevent that"? Ofcourse I'm being silly, but simply allowing textures inside an object to have permissions of their own won't work.