Strategy for texture-change scripts - textures or UUIDs?

When making objects that have texture-change menus, is it more typical to include the textures in the object or refer to them by UUID?

If the latter, what are the criteria for being able to do that - can you do that with any texture that is in the creator's inventory full-perm, regardless of who comes to own the scripted object?

Context for my question:

I have written a menu-driven texture change script that I'm quite proud of, hee, since I am pretty new to serious scripting. At the moment it's nice and extensible - all you have to do to add more textures to the object is drop in a new texture having a certain keyword in its name, and the script will automatically add the texture to the right menu. I don't have to hard-code the names/IDs into the script.

Using UUIDs will save me giving out copies of all of our original textures with every product - but will be much more of a pain to code and maintain the scripts, especially in requiring a different script for each product.

That's why I was wondering what more experienced folks do.

You just need the UUID. Note that you can't copy the UUID of, or use llGetInventoryKey() on, a texture for which you don't have adequate permissions. You need full perms for the latter. Not sure about the former, but I'd guess it requires at least copy and transfer.

There are ways to get around that, but I'll assume you don't mean to circumvent SL's security and won't need them.

All right, thanks; that answers part of my questions.

What about the coding problem? I worked pretty hard to write a script that is extensible because it builds lists on state_entry using textures in the object.

While it might be nice not to have to include the actual original textures in the object, I'm not entirely thrilled with having to manually code the UUIDs into the script each time I add a texture or make a new product. That sounds like a recipe for a script-maintenance disaster.

What do people normally do? Is it more common to include the textures in the object, or to hard-code the UUIDs?

Neat idea! It occurs to me that it would be interesting to find a texture shop that works on a subscription based service, whereby you drop their script into your prim and it gives you access to their entire texture catalog via a menu that accesses the UUID behind the scenes.

Ok, maybe it wouldn't be viable... but it sounds neat to me.

Maybe... store the UUIDs in a notecard... or on an external webserver?

Well, storing in a notecard gives your UUIDs away, as you can always read notecards. A web server would certainly work, if you really want to go that far.

My usual is to have a configuration section at the top of the script. The only part that is meant to be modified for different scenarios. And if the object is going to be no-modify (or you encrypt the UUIDs in the link messages) you could also create a helper script whose sole job is to hold the list and transmit it to the main script.

Often if the purpose of the script is really to flip through a relatively dynamic set of textures, having them in prim inventory is the easiest way to do it. But then you have to think about permissions issues for those items....

Thanks. I could do something like this. The way I've written the script now is easiest for the person who is doing the design on the object the script is going into - she just has to do her design and drop her textures in, no need for her to change the script every time. But ...



Exactly; this is what led me to ask the question. We're going to produce the final product copy/trans I think, non-modifiable. Even though it is unlikely someone would strip the textures out and distribute them, I'd just as soon not offer the opportunity if we can avoid it.

Other than permissions issues, there are two disadvantages to using the textures in object inventory:

1) Large object inventories are hard to manage (SL gets very slow and unreliable as the number grows over 50 or 100 items, as folks who make menu furniture know).

2) You can't associate any other parameters with the texture.

If none of these is an issue, I'd probably employ the KISS principle and stick with textures in inventory.

If you want to configure them, consider splitting the configuration into a separate script that contains only the data and a means to access it, with all the features and logic in a different script. That way, if you want to update the features, you have only one script to update in each product.

Access the data in the config script using linked messages. One possibility is, on startup, send entire configuration via linked messages and then disable the config script.

Another possibility: have the config script respond to request messages.

In that case a script that stores and transmits the list of keys might be best. If the object is no-modify, you shouldn't have to worry about people inserting other scripts to listen to the link messages, but you might want to be careful of people copying the script out and inserting it into another object for that purpose. So you may want to check for something like owner != creator on script reset, or include some very basic encryption or something.

I am not sure I follow - what do I get by separating the UUIDs into a different script that I don't already get by using UUIDs instead of textures in the first place?

Also why do I care if people know the UUIDs of the textures? They can't use that information if they don't have permissions on the textures, can they? Or is that not how it works?

I also don't understand checking owner != creator - of course owner != creator, unless I am the only person using the product, which I hope will not be the case.

So I guess I am completely lost as to what you are trying to say here.

I'll just add that this is sounding like way more work than I want to do at this stage - I don't yet know how to make scripts talk to each other and I am not inclined to figure it out just to get some small protection against what already strikes me as an unlikely texture theft scenario. So if you don't feel like answering the above questions just for my edification, don't worry about it.

1.) It just means one script can be really simple and only store and transmit UUIDs. Your main script can be no-modify, or at least not change between applications. If it's not a big deal to modify the list of UUIDs at the top of the main script though, just do that.

2.) YES, they can use the UUIDs without permissions on a texture in inventory. See my first post above. The idea is that the system tries to keep people from getting the UUIDs of texture items for which they don't have adequate permissions. Once you have that UUID, you can apply the texture to particles, faces, or sculpties without restriction. This is a little different than from how animations work (and maybe sounds, but I can't remember ATM).

3.) The idea of checking whether owner and creator is the same AT THE TIME THE SCRIPT IS RESET is that if they are different, someone else was able to insert your script into another object or reset it in place (unless you purposefully reset your script for some reason; you should be able to design this system so you don't have to do that though). In either of those cases you could keep your script from transmitting UUIDs that the owner should not have. If you're going to embed the list of textures in your main script instead of transmitting it with link messages, don't worry about this bit.

I concur with Hewee on all counts.

Unless the behavior is trivial, you'll benefit by separating the config from the behavioral logic. If you update the behavior script, you can just replace that script in each version of the thing, rather than having to open each script and paste in the new code.

Two options for a config script:

A) on init, sends the entire config, in LMs
B) expects query LMs and sends response LMs

(LM = Linked Message)

A is simpler, and you can even have the script set itself to not running after sending the config, reducing script usage if a region is likely to have a number of these objects. (It's not a significant optimization if they'll be rare.)

Rather than checking owner != creator, I would check whether creator is yourself. This allows resetting the scripts without it breaking.

string MyKey = "12345678-1234-4321-12-12345678";

die_if_not_mine() {
    list details = llGetObjectDetails(llGetKey(), [OBJECT_CREATOR]);
    key creator = llList2Key(details,0);
    if (creator != (key)MyKey) {
        llDie();
    }
}


default {
    state_entry() {
        die_if_not_mine();
        ....
    }
}

(To see the code with indentation, hit the QUOTE button for this post.)

Thanks for the thoughts, folks. I do appreciate them. Still not sure I follow all of it, but as I said I'm rather a novice scripter.

I'll talk to my designer about how concerned she is about distributing copies of the textures inside the object and then decide what to do.

Thanks, Lear, that makes good sense; I don't think I would ever write a script intentionally to break on reset, because I often use reset to try to coax scripted objects into working when they get into some wonky state, and I am sure I am not the only person who does that.

True, unless you've given out a freebie object with full perms at some point or something. They'd have to know to inject the script into that, of course. So maybe it's paranoid to worry about that scenario. (I mean, there are ways to steal texture keys if you're really motivated to do it anyway, despite permissions and script security measures.)

Anyway, I should have clarified a little bit. You'd want to check whether the owner of the OBJECT is equal to the creator of the SCRIPT (since you know YOU created the script). You could certainly hard-code a key instead of using the script creator, but whatever.

Oh, BTW, if you want with some kind of simple encryption scheme, you could also store the UUIDs in a notecard, because who cares if someone can read it? Only problem with that one is that SL has no built-in encryption (only hashing/authentication). So you'd have to use one of the library functions people here have contributed. Or write your own. Eh.

Good point.

// delete the object if object creator and script creator don't match
delete_if_not_same_creator() {
    if (llGetCreator() != llGetInventoryCreator(llGetScriptName())) {
        llRemoveInventory(llGetScriptName());
    }
}


default {
    state_entry() {
        die_if_not_mine();
        ....
    }
}

BTW, I could have used simpler code earlier, but I'd forgotten about llGetCreator().

Also, I decided to just delete the script rather than the whole object. To be even nicer, set the script to not running instead:

llSetScriptState(llGetScriptName(), FALSE);

Another good point

There used to be a time when all you had to do to get the UUID of any texture, regardless of its perms, was to get the object into Edit Mode, select the texture, then via the Advanced menu choose Selected Texture Info and it spit the UUID right out. They then fixed that in a later viewer release. However, current viewers still give you that same info, with just one extra step.

Texture security is perhaps the least secure of all SL assets.

Rock