llSetLinkPrimitiveParamsFast, SetLinkTexture, "Texture not transferable...Could not find texture"

[Asimos]

An object ends at the customers with No Mod, Yes Copy, No Transfer. This Object conatins scripts and a texture with the name "texture-A" that end at the cutomers with No Mod, Yes Copy, No Transfer too.

The following line gives them an error "Texture not transferable." "Could not find texture 'texture-A'." 

* llSetLinkTexture(3, "texture-A", 1);

I even changed to the following and they still get the same errors.

* llSetLinkPrimitiveParamsFast(3,[PRIM_TEXTURE,1,"texture-A",<1.0, 1.0, 0.0>, ZERO_VECTOR, 0.0]); 

I even uploaded a new texture-A just incase. I still get the same errors (Actuaty is is worst now. They get --Texture not transferable..... Too many errors... dropping further messages until the flood stops.)

 

[Ruthven Ravenhurst]

If I remember correctly, you must have transfer perms of a texture to assign it with llSetLink.....

Why not hard code the uuid of the texture, and not put the the texture into the contents?

[Vulpinus]

Exactly as Ruthven said - and I know because I recently discovered the same issue. Apparently it's some legacy problem with permissions that won't be changed and is a real pain in the assets.

To set an embeded texture onto a child prim by script, the texture must be transferable. It's stupid but that's the case.

My solution was to grab the UUIDs and hard code them in a list. Alternatively put them in a (no trans, no mod) notecard and read them into the list at script start.

[Qie Niangao]

---

Vulpinus wrote:

a (no trans, no mod) notecard

---

No setting of permissions is sufficient to protect a notecard's contents. Dropping a full-perm asset inside the notecard will help.

Also, no-transfer textures should be avoided for almost any purpose. Their implementation included a dreadful category error about what that particular DRM should mean, such that it now applies (kludgily) to both the asset and its application. I for one can't even imagine the confusion if scripts too were able to manipulate that mess.

[Vulpinus]

---

Qie Niangao wrote:

---

Vulpinus wrote:

a (no trans, no mod) notecard

---

No setting of permissions is sufficient to protect a notecard's contents. Dropping a full-perm asset inside the notecard will help.

---

I think I might have caused a misunderstanding there.I meant copy the UUIDs of the textures into the notecard, so they could be read by the script.

Not to drop the texture itself into the notecard - I had no idea that could even be done, but I do now.

Or do you mean that even copying the UUIDs (or any text) into a no-mod notecard isn't secure from someone else viewing it?

---

I've no idea of the complexities behind the transfer-perms being required in this instance. It seems daft to me the way it works though. I do know it's simply not possible to prevent copying of a texture file, the way things are, so any 'protection' in the system is really worthless if someone wants the file.

I was using some textures (a lot of variations) I had bought with a full perm object, with the usual distribution rights of no-copy or no-trans on the main object. The finished product occasionally needed a texture switch during an animation. Dropping the textures needed into the finished item was the simplest method. There were a lot of similar objects but with different versions of the texture, so coding all the UUIDs into each item's (otherwise identical) script would have been a pain. Making the texture no-trans seemed the simple answer. Clearly not

 

[Qie Niangao]

---

Vulpinus wrote:

Or do you mean that even copying the UUIDs (or any text) into a no-mod notecard isn't secure from someone else viewing it? 

---

Right. Well, it may discourage someone else, but not someone else's script. The trick here is that scripts won't read notecards containing stuff other than text. As the wiki says:

• If notecard contains embedded inventory items (such as textures and landmarks), EOF will be returned, regardless of the line requested.

I'm not 100% sure this limitation was intentional, but the likelihood of it changing now seems pretty remote.

[ChinRey]

---

Vulpinus wrote:

Or do you mean that even copying the UUIDs (or any text) into a no-mod notecard isn't secure from someone else viewing it?

---

It is not possible to create a notecard that can be read by some scripts but not others.

There are two possible solutions, either use a feeder script instead of a notecard or encrpt the UUIDs in the notecard.

Then again, there is no copy protection for textures in SL anyway. Just look in your cache folder and you'll find a nice list of the UUIDs of all textures your avatar has been anywhere near recently.

[Vulpinus]

Thank you both for that clarification. I had never realised that; I always assumed (and we all know what that does) that it worked the same way as the user trying to view it.

It's something to bear in mind. I was more concerned in my case with simply not breeching the terms of use of the textures.

But yeah, no texture is safe from the cache browser. Mine always seems mostly full of people's thumbnail pictures from groups though.

Hmm... now I know how to get all those animation settings from some furniture that I wanted to reconfigure, but it had a locked config nc which made it more work that it was worth.

[ChinRey]

---

Vulpinus wrote:

Thank you both for that clarification. I had never realised that; I always assumed (and we all know what that does) that it worked the same way as the user trying to view it.

---

Nah, that would have been too easy. A notecard's permission settings does not affect it's readbility to scripts. The only way to make a notecard script-unreadable is the method Qie mentioned but then it would be unreadable to all scripts, including the one that's supposed to read it.

---

Vulpinus wrote:

But yeah, no texture is safe from the cache browser.

---

You don't even need a cache browser really, that's just a convenience. The UUIDs are used as the names for the cache files so they are all listed in the folder.

---

Vulpinus wrote:

Mine always seems mostly full of people's thumbnail pictures from groups though.

---

Your texture cache contains the profile pics of all your friends, the profile pics of all groups you are a member of, the profile pics of all parcels in the sim you're in and in the neighbor sims, the profile pics of all avatars in your sim and the neghbor sims, the profile pics of every avatar logged on to a group chat you are also logged on to, all the graphics used by the viewer interface, every texture worn by an avatar in your sim and in the neghbor sims, some mysterious graphics nobody knows what is for and a complete set of high resolution scans of the pages from the 1986 edition of Encyclopedia Britannica. If there's room left, it'll also contain the textures you see around you in SL.