Protecting Texture UUIDs

[Pedlar Decosta]

Hi, I was under the impression that if you used a texture on an object and that texture was no mod and no copy, and you gave that object to someone else, that they couldn't get the UUID of that texture, even though the object used it. And this seemed to be the case because if you went to the texture TAB it would show a Null Key. But a friend showed me that if she put a script in the object with a simple llGetTexture() function, it would still retrieve the UUID. I own textures that, because of user conditions I'm supposed to protect from other people, but if they can get the UUID, they can just use the texture wherever they like. (Can't they?) On the other hand I have seen scripts on marketplace that claimed to 'encode' or 'hide' the UUIDs. I always thought it was a disingenuous claim as I believed SL already protected them as I just explained.

So, my question/s are, what is the actual situation? Do I need to take further steps to hide the UUID's ? If so, how ? I have looked for an answer, but even the UUID lslwiki page doesn't mention protections for textures.

Thanks in advance.

[Wulfie Reanimator]

1. If you have the UUID, you can apply it without restrictions.
2. Products on MP that "encode/encrypt/protect/hide" UUIDs only do so while they are being communicated between scripts.
   • Basically, the UUID gets turned into some other text, sent to the other object, which then reverses the encryption to apply the real UUID. This is almost always insecure and completely unnecessary, because textures are incredibly easy to get to from outside the viewer. There is no script solution to protect textures. No protection, really.
3. llGetTexture's wiki says:
   • If the texture is in the prim's inventory, the return value is the inventory name, otherwise the returned value is the texture UUID.
   • NULL_KEY is returned when the owner does not have full permissions to the object and the texture is not in the prim's inventory.

Having tested it for myself, I'm not able to get the texture UUID even when I have copy/modify permissions. (I've sent a no-transfer object to my own alt, the texture is full-perm.)

[Pedlar Decosta]

You are a legend Wulfie

I did the same tests with the object not having full perms and in every case it returns a null key. So essentially, as long as the object is not full permissions, you can rest safe that you aren't breaking the user applied conditions.

But if it is a full permission object, they can retrieve the texture UUID. And here I was thinking the texture permissions were what mattered and it was the object itself's permissions.

Thank you so much. That makes me rest easier.

[VirtualKitten]

Pedlar . Its important to note perms of objects have changed you cannot give full perms to an object unless you take it into your inventory first and set perms there. This is a form of protection . You can also while the object is in world go to perms  in  content properties and adjust all content permissions  even texture perms for textures or anything else in the object . Hope this helps .

[Qie Niangao]

1 hour ago, VirtualKitten said:

Its important to note perms of objects have changed you cannot give full perms to an object unless you take it into your inventory first and set perms there.

This is either mistaken or very confusingly stated. Nothing has changed about SL object permissions and it's certainly possible to give full perms to normal rezzed-in-world objects (as long as these next-owner perms don't exceed the editing user's own perms on the object).

As to manipulating permissions while the object is in agent Inventory, this is the way the permissions "slam bit" is set, which affects when different next-owner permissions apply after transfer.

[Pedlar Decosta]

Hi VirtualKitten. I had realized things had changed simply because after setting permissions on item and then checking them again in my inventory only to find they had changed. I remember a time when whatever permissions you changed on a rezzed item, remained the same once in your inventory. I figured it was extra  protection, but man it has caused me some grief, especially causing concern over whether items in an objects inventory had also had their permissions changed as well. I did prefer it when you could set the permissions , take the item and then give or sell it, and have confidence the perms were right. I admit to cursing a lot over this, when for eg a friend says "I can't mod or copy this...". So thanks for your comment. because I felt a bit like Neo in the Matrix and would think "..wait...  my reality has just changed.... it didn't used to have that brick wall there...." lol

Hi Qie Niangao. thank you so much for that link about the permissions 'slam bit'. I can certainly learn and utilize that information. But I do believe that if I set an object perms to FP and then take it into my inventory, it is inevitably not FP when I check it and have to do the perms again before giving it away or selling it. Which is different from my workflow a decade ago.

[Pedlar Decosta]

Although I feel confident now that texture permissions are secure on a non full perm object, I belatedly realized that I was storing the texture UUID's in notecards for all the next owners and possibly others to see. So although Wulfie explained for some people it isn't difficult to grab UUIDs from outside the viewer, I'm doing a crash course in encryption (in my own fashion) to at least keep the UUID's out of people's faces, most of who wouldn't know how to grab textures from 'outside of the viewer'. Because in my mind, any level of security is better than none in my opinion, and it certainly does lower the number of people that would have the ability to abuse the UUIDs.

[VirtualKitten]

Lol Peldlar yes it was a headache for me too until i realized why my perms for next owner was not changing unless i made this change in inventory. It is better i think like this now and more usable. For textures even if i bought something from MP full perm it doesn't always come with texture and I cant always obtain it . Its all very good using keys but if its in an avatar account that gives up LSL it then i believe is lost  to the system and no longer able to be found.

[Qie Niangao]

11 hours ago, Pedlar Decosta said:

But I do believe that if I set an object perms to FP and then take it into my inventory, it is inevitably not FP when I check it and have to do the perms again before giving it away or selling it. Which is different from my workflow a decade ago.

I've never seen this happen, except when there's been some object contents somewhere that were not set full perm -- and needing to set those permissions in Inventory is always an indication that I've done something wrong. If permissions are set in Inventory, it means the objects will have a different permission when a recipient rezzes them out, which is almost never what's intended - the exception being using that slam bit to get this special effect.

This is a common way to mistakenly distribute full perm containers of assets such as animations that were bought Full Perm but set with more restrictive permissions to comply with their EULAs. The recipient can then transfer from their inventory infinite copies of the container to friends, the intended permissions only applying when the objects are rezzed-out in world.

Maybe you guys have found some other way to confuse the permissions system, but it's just not what I see when I rez a simple object and set its permissions. For me, it's always when there's something inside that I didn't set to the same permissions as the containing object.

[Wulfie Reanimator]

13 hours ago, Pedlar Decosta said:

Although I feel confident now that texture permissions are secure on a non full perm object, I belatedly realized that I was storing the texture UUID's in notecards for all the next owners and possibly others to see. So although Wulfie explained for some people it isn't difficult to grab UUIDs from outside the viewer, I'm doing a crash course in encryption (in my own fashion) to at least keep the UUID's out of people's faces, most of who wouldn't know how to grab textures from 'outside of the viewer'. Because in my mind, any level of security is better than none in my opinion, and it certainly does lower the number of people that would have the ability to abuse the UUIDs.

Why do the textures need to be in a notecard? Why not in a script?

Also, as a bonus: The simplest encryption I would recommend for you is simple scrambling. Swap parts of the string around, don't bother with any hashing functions as they're either one-way (useless for you) or so wide-spread that anyone can find a decrypter online. Swapping is simple and others won't know what or how many pieces you changed. 

Edited July 27, 2020 by Wulfie Reanimator

[Pedlar Decosta]

Yeah, I'm not sure Qie Niangao. It is a bit over my head. But if I import a mesh item, rezz it and set it as full perms, take it into my inventory and check it and it is always wrong, so I change it in the inventory and use friends or alt account to double check it arrives with the correct perms. It can be annoying.

Hi Wulfie. I use notecards so the information is never lost. Other people use the system to record various sets of textures etc in their own objects. So they can do it once and be confident they won't lose the information. I used to use object description to store data (and still do in other scripts), but with all the various visual parameters (advanced materials etc) there is an awful lot of information. So with all of that info for every face of an object, a notecard seemed the best way to do it. Happy to hear suggestions though ?

As far as the encryption I've been working on utilizing the XTEA encryption. It works, except I'm still having a couple of issues integrating it. My issues aren't actually the encryption, but with the code that sets the parameters. I've done something wrong, probably made some silly mistake and I just have to find it. I also put each texture in a list of it's own because of how long it is when encrypted. Here's an example -

2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9 

I did consider trying to do some creative math and/or swapping numbers, but in the end I decided to use (or at least try) something made by the pros. Do you think I should rethink using XTEA and try to make something myself ?

 I have resisted communicating parameters between prims, like for example using the scripts in the root prim to store and message the other prims their textures or parameters. For a couple of reasons. It is more secure (uuid's for eg), it is quieter (not much chatter) and I've not seen any lag caused by it even though it's quite a large amount of information managed by the scripts. It also keeps it very user friendly and simple to use. There's is virtually no learning curve to be able to use it. You make your product look how you want and then use a parameter generator to form the readout for the notecards. The script makes a menu automatically, based on the notecards and you choose which one you want. Really easy to use.

 

[Wulfie Reanimator]

1 hour ago, Pedlar Decosta said:

Hi Wulfie. I use notecards so the information is never lost. Other people use the system to record various sets of textures etc in their own objects. So they can do it once and be confident they won't lose the information. I used to use object description to store data (and still do in other scripts), but with all the various visual parameters (advanced materials etc) there is an awful lot of information. So with all of that info for every face of an object, a notecard seemed the best way to do it. Happy to hear suggestions though ?

Get yourself an Omega Applier dev-kit and look at how they did it. You can get it from their in-world store for free. The dev kit uses two scripts -- one is full-perm and just sends the user-input (textures in Omega's case) to the actual applier-script that cannot be modified. After the textures are loaded, the full-perm script can be deleted and it's ready for customers.

Edited July 27, 2020 by Wulfie Reanimator

[Pedlar Decosta]

8 hours ago, Wulfie Reanimator said:

Get yourself an Omega Applier dev-kit and look at how they did it. You can get it from their in-world store for free. The dev kit uses two scripts -- one is full-perm and just sends the user-input (textures in Omega's case) to the actual applier-script that cannot be modified. After the textures are loaded, the full-perm script can be deleted and it's ready for customers.

I went out & got one, but I can't see what you mean. They essentially just send linked messages to the no mod script. I do this as well, I just don't send texture information, only instructions. Mine also bundles up information  and then split it at the other end. Sorry mate, but I'm scratching my head lol. Do they somehow hard code the information in the no mod script ? The only way to do this that I know of is using a remote script pin, which I do use for updates. If you wouldn't mind, I need a bit more information ?

[Wulfie Reanimator]

26 minutes ago, Pedlar Decosta said:

I went out & got one, but I can't see what you mean. They essentially just send linked messages to the no mod script. I do this as well, I just don't send texture information, only instructions. Mine also bundles up information  and then split it at the other end. Sorry mate, but I'm scratching my head lol. Do they somehow hard code the information in the no mod script ? The only way to do this that I know of is using a remote script pin, which I do use for updates. If you wouldn't mind, I need a bit more information ?

It could be that I'm just not understanding the "model" of your product. I'm assuming that at some point the product is going to end up in the hands of an end-user who no longer needs to edit the notecard -- or view its contents. Otherwise you wouldn't need to encrypt the notecard, right?

If that's the case, then you can do something similar to what Omega is doing. You have a "configuration file" (notecard or script), you pass that data into a no-modify script once (either by reading the notecard, or passing the configuration from one script to the next) so that the no-modify script will always remember the textures/instructions/whatever (so long as it doesn't get reset).

This way, the object:

1. can be easily configured/reconfigured while you (or someone else) is working on it.
2. can't be changed (or directly ripped) by the actual end-user, even if it uses no encryption at all.

[Pedlar Decosta]

1 hour ago, Wulfie Reanimator said:

It could be that I'm just not understanding the "model" of your product. I'm assuming that at some point the product is going to end up in the hands of an end-user who no longer needs to edit the notecard -- or view its contents. Otherwise you wouldn't need to encrypt the notecard, right?

If that's the case, then you can do something similar to what Omega is doing. You have a "configuration file" (notecard or script), you pass that data into a no-modify script once (either by reading the notecard, or passing the configuration from one script to the next) so that the no-modify script will always remember the textures/instructions/whatever (so long as it doesn't get reset).

 

Yes, I think you are misunderstanding the model Wulfie. For one thing, there are multiple (sometimes many) notecards for various 'Texture or visual Sets'. All of which will need to be remembered and used (an over simplification would be a color change menu - but with every single visual parameter listed for every face of every prim and for every single menu choice). The end user no longer needs to edit the notecards, but the scripts need them to affect the various changes for each menu choice, again - for every face of every prim. And from what I could tell the Omega scripts didn't encrypt the textures - at least prior to sending them to the no mod script.

And because the end user expects to have total confidence that the menu and scripts will never lose the information, resets, as you mentioned, would potentially be a big problem.

To give you an idea of how much information I'm talking about for every prim, here's an example. Remembering too that now I am putting the encrypted UUIDs on their own dedicated line in the notecard, 1 for each texture including material textures for each face (in this mock-up 6 faces). Basically it allows the creator to control every visual parameter. I don't know of one that it doesn't include, at least since I added support for the advanced materials (which by themselves is quite a lot of information)/ So picture many of these notecards (I have tested up to 25, but the menu will expand as it needs to, so I'm not sure when exactly you'd encounter problems) ;

[01:00] Object: *0,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92,<1.00000, 1.00000, 1.00000>,1.000000,<0.00000, 0.00000, 0.00000>,1.570796,<1.00000, 0.50000, 0.00000>,0,0.000000,0, 0
[01:00] Object: ^0,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92, <1.000000, 0.500000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000
[01:00] Object: ~0,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92079d, <1.000000, 0.500000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000, <1.000000, 1.000000, 1.000000>, 51, 0
[01:00] Object: %0,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9
[01:00] Object: &0,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9
[01:00] Object: !0,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9
[01:00] Object: *1,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92,<1.00000, 1.00000, 1.00000>,1.000000,<0.00000, 0.00000, 0.00000>,1.570796,<1.00000, 1.00000, 0.00000>,0,0.000000,0, 0
[01:00] Object: ^1,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92, <1.000000, 1.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 1.570700
[01:00] Object: ~1,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92, <1.000000, 1.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 1.570700, <1.000000, 1.000000, 1.000000>, 51, 0
[01:00] Object: %1,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9
[01:00] Object: &1,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9
[01:00] Object: !1,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9

[01:00] Object: *2,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92,<1.00000, 1.00000, 1.00000>,1.000000,<0.00000, 0.00000, 0.00000>,1.570796,<3.00000, 2.00000, 0.00000>,0,0.000000,0, 0
[01:00] Object: ^2,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92, <3.000000, 2.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000
[01:00] Object: ~2,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92, <3.000000, 2.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000, <1.000000, 1.000000, 1.000000>, 51, 0
[01:00] Object: %2,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9
[01:00] Object: &2,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9
[01:00] Object: !2,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9

[01:00] Object: *3,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92,<1.00000, 1.00000, 1.00000>,1.000000,<0.00000, 0.00000, 0.00000>,1.570796,<1.00000, 1.00000, 0.00000>,0,0.000000,0, 0
[01:00] Object: ^3,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92, <1.000000, 1.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000
[01:00] Object: ~3,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92, <1.000000, 1.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000, <1.000000, 1.000000, 1.000000>, 51, 0
[01:00] Object: %3,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9
[01:00] Object: &3,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9
[01:00] Object: !3,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9

[01:00] Object: *4,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92,<0.02353, 0.02353, 0.02353>,1.000000,<0.00000, 0.00000, 0.00000>,0.000000,<1.00000, 1.00000, 0.00000>,0,0.000000,2, 0
[01:00] Object: ^4,00000000-0000-0000-0000-000000000000, <1.000000, 1.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000
[01:00] Object: ~4,00000000-0000-0000-0000-000000000000, <1.000000, 1.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000, <1.000000, 1.000000, 1.000000>, 51, 0
[01:00] Object: %4,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9
[01:00] Object: &4,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9
[01:00] Object: !4,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9

[01:00] Object: *5,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92,<1.00000, 1.00000, 1.00000>,0.501961,<0.00000, 0.00000, 0.00000>,0.000000,<1.02322, 1.04781, 0.00000>,0,0.000000,0, 0
[01:00] Object: ^5,00000000-0000-0000-0000-000000000000, <1.000000, 1.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000
[01:00] Object: ~5,00000000-0000-0000-0000-000000000000, <1.000000, 1.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000, <1.000000, 1.000000, 1.000000>, 51, 0
[01:00] Object: %5,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9
[01:00] Object: &5,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9
[01:00] Object: !5,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9

**I forgot to remove the original non encrypted UUID's from the lines, so pretend they are not there lol. It is still a fair whack of data though.

Edited July 27, 2020 by Pedlar Decosta
addendum for error in the mockup nc

[Pedlar Decosta]

Something I should actually mention Wulfie is that I actually use resets, so it is a choice on the menu. One thing I use them for is if I change the product description, (I use the description for network channels, so that users can put multiple items into the network), I need to manually reset for this information to be noticed. Think of a bedroom suite that changes it's entire look, just by one menu selection as an example of usage.

[Pedlar Decosta]

UPDATE:  So I fixed the scripts and tidied them up and they are working with the XTEA encryption in the way they should. The only downside is that decrypting and then applying the textures using XTEA has slowed the process down. Instead of typically 5 seconds to finish prior to using encryption, it is now roughly 20 seconds. That isn't so bad, but now I'll take a look at scrambling them to see how much time I can save. I'd be extremely happy if I could get the parameters all set in under 10 seconds. I expect also, that if no advanced materials were being used, there'd be a lot less decryption going on and it would be faster.

So I'll be looking at what Wulfie said " The simplest encryption I would recommend for you is simple scrambling. Swap parts of the string around, don't bother with any hashing functions as they're either one-way (useless for you) or so wide-spread that anyone can find a decrypter online. Swapping is simple and others won't know what or how many pieces you changed. "

[Wulfie Reanimator]

11 hours ago, Pedlar Decosta said:

UPDATE:  So I fixed the scripts and tidied them up and they are working with the XTEA encryption in the way they should. The only downside is that decrypting and then applying the textures using XTEA has slowed the process down. Instead of typically 5 seconds to finish prior to using encryption, it is now roughly 20 seconds. That isn't so bad, but now I'll take a look at scrambling them to see how much time I can save. I'd be extremely happy if I could get the parameters all set in under 10 seconds. I expect also, that if no advanced materials were being used, there'd be a lot less decryption going on and it would be faster.

Remember that llGetNotecardLine has a forced delay of 0.1 seconds. Since you added more lines to your notecards, it's almost unavoidably going to take longer.

Edited July 28, 2020 by Wulfie Reanimator

[Qie Niangao]

If the sample data is at all representative, there's a lot of redundancy in the texture UUIDs, so if they really repeat themselves a lot, it may save time (and human effort) to use a kind of catalog, so they can be referred to by index rather than the full UUID each time. This would reduce the total length of data and mean each UUID only needs encrypting and decrypting once.

(If the real ones will be mostly unique, though, this would only add complexity.)

[VirtualKitten]

I cant see the point of encrypting something you can set with perms . I just rezed something i only own and the textures are all 00000000-0000-0000-0000-000000000000 so why do this do you have to much time on your hands and why does this need protection 

[Pedlar Decosta]

4 hours ago, Qie Niangao said:

If the sample data is at all representative, there's a lot of redundancy in the texture UUIDs, so if they really repeat themselves a lot, it may save time (and human effort) to use a kind of catalog, so they can be referred to by index rather than the full UUID each time. This would reduce the total length of data and mean each UUID only needs encrypting and decrypting once.

(If the real ones will be mostly unique, though, this would only add complexity.)

Hi Qie Niangao. That certainly sounds better. The data isn't always so redundant. That list was a mock up. It was repetitive because I just tried to show how much information there is, not because it is a good representative of an actual usage. Although it is fair to say that sometimes it would be. I do not know  how to do what you suggest off the top of my head. I'm also drinking my first coffee, so that could have something to do with it lol

2 hours ago, VirtualKitten said:

I cant see the point of encrypting something you can set with perms . I just rezed something i only own and the textures are all 00000000-0000-0000-0000-000000000000 so why do this do you have to much time on your hands and why does this need protection 

Hi VirtualKitten. The problem is the notecards really. They have the UUIDs in them. Which can then be used as far as I can tell.  If I sell of give a product away that uses a UUID that has user restrictions i.e. do not allow other people to get these with full perms, or only use them in your projects, then the notecards could be a breach and I don't want to do that.   As far as time on my hands goes it is important to remember the bulk of this script has been developed over a more than a decade. 2 things have made me revisit it 1. advanced materials which weren't supported and 2 UUID protection in the notecards.  (and since I'm tackling it I'm upgrading a heap of other things too. By the way - I have fun when coding. I love doing it.)

Edited July 28, 2020 by Pedlar Decosta
needed coffee - and finish sentence

[Mollymews]

a pretty quick string encryption method is llXorBase64.  Example here: http://wiki.secondlife.com/wiki/LlXorBase64

[Phate Shepherd]

Maybe I missed something along the way... but was it mentioned that if you store stuff in a script as constants, there is no chance they will be lost on a reset. You could have a script with all the values as constants (even lists) and that script could either act on those values directly, or if commanded, send them to another script to deal with. Or, if the script had an applier routine built in, then it could be commanded to apply its texture list, and encryption would be totally unneeded since scripts are about as secure as we are going to get in SL (assuming you don't mistakenly give the script out Mod.)

Having them stored as scripts also eliminates load time. The only limit is script memory, but it would take a serious number of multi-face linked prims to run out.

Another bonus is it is easy to set up a pin on a scripted item, and allow simple updaters to add/replace scripts in already sold items.... Such as distributing texture packs as named scripts.

I've done numerous scripted items where every face of every link has texture and color values stored in a constant array, even going so far as having a "Texture Dumper" Script that I drop in an item, and it spews out the list values for the object that I just copy from chat and past into the head of the script. Something like:

 

list	gTextures = [
		"0,20e4fa35-f47d-f607-ce9a-005af3550b96,1,20e4fa35-f47d-f607-ce9a-005af3550b96,2,20e4fa35-f47d-f607-ce9a-005af3550b96",
		"0,20e4fa35-f47d-f607-ce9a-005af3550b96,1,20e4fa35-f47d-f607-ce9a-005af3550b96,2,20e4fa35-f47d-f607-ce9a-005af3550b96"]

Of course the UUIDs would all be different, and you could put other data in there. The list is an array of sub-lists stored as comma separated values. Each line corresponds to a  link number of the object. At apply time, each line is parsed in a loop to create a sub-list for the matching link number (keeping in mind that arrays lists start at 0, and link numbers for multi prim objects start at 1). In the example, these sub-lists are a cadence of 2, first being face number, second being the UUID for the texture.

Having the face nuumber in there is kinda pointless to some extent, you could just assume the first UUID is applied to face 0, second to face 1, etc,, but I liked being able to manually edit the list and easily see exactly which face number I was dealing with.

You could extend the cadence to 3, and have face number, uuid and face color... or however many parameters you want to modify for that link.

If I am understanding right, you are looking to have a HUD that applies the textures to an object in-world. In that case, if you choose a very random channel to communicate your texture UUIDs to an applier within the object, there is little to no chance someone will figure out which of the 4 billion channels you are using. It is only link messages that are easy to snoop... llSay on a channel you pick is pretty darn secure.

Edited July 30, 2020 by Phate Shepherd

[Pedlar Decosta]

Hi Phate. I'm assuming you mean what I'd call 'hard coding' the data into the script so that the information is there all the time and would survive resets. But that is not compatible for the way it is used. I still use lists in the way you describe however. Because of the amount of data involved in saving every visual parameter, I use 6 lists. I did use 3 until I decided to use encryption and then I dedicated an entire notecard line & list to each of those encrypted UUIDs.It is not intended to be a HUD, but of course you could easily adapt it to do everything from a HUD instead of from a prim in the object. I also do use a random number routine for the menus, however the channel I use to network other objects can be set by the user manually (putting it in the description and reseting the scripts), by saying the number you want to use in chat (menu dependent), or even allowing the script to create a unique random number by itself and rest itself automatically. I always advise the creator/builder uses a long negative number.

Since there does seem to be some confusion and even an idea that these scripts allow end users to change colors and textures etc on products they purchased (which SL already furnishes users with a perfectly capable set of tools to do that with IMHO), however it is not what my scripts do.  After a creator/builder/retailer makes a product, they beautify their products using all of those SL tools. My scripts then allow the creator to get a readout of all those visual parameters in their chat log using a Texture Generator. It allows them to even use advanced materials, so a possible 3 textures per face plus all the incidentals. The readout then is copied into a notecard and named something appropriate. Once they do it again using different textures colors and materials and save it also in a notecard, the user (including the end user) can use the menu and choose which of the sets they want. The scripts do other things, but that is the main function of the Texture Plugin. So the creator or whoever adds 2 or 20 or whatever different sets and then gives or sells the product. The end user then has a product with more than one choice for how to make it look. The system is very user friendly. No learning curve at all really for the creator or the end user. I'm running beta tests right now with some furniture which I added about 12 'Texture Sets' to. My original system which I made over a decade ago, had several limitations, like no advanced materials and a limited number of  Texturing Sets. And or course I'm adding encryption for the UUIDs in the notecards because I know many creators are concerned about keeping their UUIDs secure.

The end user does not have the texture Generator or other builders tools, but can edit the access list, which includes owner only, groups and/or individual avatars, change network channels, update the scripts, rest the scripts, access the help file etc. I should also mention the original system which will also be updated once this is finished adds other plugins like Doors, Windows, Lights, Altitude Setter and user created API's. (I've used it to integrate rising platforms and guard rails as an example). I'm doing the Texture system first because I am aiming it at content creators that wish to value add different looks to their products which include the much superior advanced materials rather than the standard default SL bump & shiny. But of course it also handles those too. My apologies if I am rambling. I just got home and I'm still winding down from a big day.

 

[Pedlar Decosta]

I have been listening to Wulfie's advice about using something like Omega's system. I am guessing the best way to do it is where the creator would use a full perm script to record and 'hardcode' the texture sets into it with them then making it no modify prior to selling the product. And I do think that has some potential. But maybe for an update in the future because I really don't know if the scripts could handle the amount of information (potentially) that could be required. I'm self taught, so with a lot of things I have to have a crack at it, see if it works and come at it from other angles if it doesn't. And read what I can find from the experts. Also as you can see, I am inclined to ask here when I'm in a pickle.Then, because I want to make sure there wont be problems with the scripts, I have an extended testing period where I try over and over to break the script. It's not pretty and it's not very time efficient, but you do the best you can and I enjoy learning as I go.