Using keys instead of files for textures, sounds and animations?

Hihi,

I've been building and scripting for some time now, but there's one
thing I'm just unsure about.

Let's say I make an object. Let's further say I put a script into
that object, that plays an animation, a sound, and changes a texture.

The approach I've taken to 'storing' those anis, sounds and textures
so far was to drop copies of them into the prim along with the script.

Now, it's obviously possible to pass keys to llSetTexture, llPlaySound
or llStartAnimation... and those keys I could take directly from the
files in my inventory, so I don't have to add copies of them to the
object.

My question now:

1> ARE there any, and WHAT are the drawbacks of using keys instead of
files, to refer to anis, sounds or textures?

2> What happens if I give the scripted object to someone else? Will it
still work? Does it in ANY way depend on the permissions the files in
my inventory are set to?

3> What happens if I delete the files from my inventory? Will that
break the object for everyone else, or does the key continue to be
valid and I just deleted the 'reference' to it from my inventory?

I hope someone can shed a little light on this for me, as it MIGHT
make building for me a bit easier, especially with products I'm selling.

Thank you,
-Yina Yao

yes, and some bonuses. drawback is mostly that the user can't easily swap out the animation, without access to the script. on the bonus side, you don't have to expose the animation, the user can't take it out and use it for something else, and there's no fooling with the permissions, so no mistakes to be made there.


yup, and nope.


as long as a script somewhere has that key hardcoded in, it's not SUPPOSED to ever break, even if you delete the only actual copy... Ll keeps it on the asset server untill nothing references it... or at least that's how the system is supposed to work.

on this note

if you store the items inworld inside a prim with the right permissions, it will use that object`s key
bonus to that, if the box gets deleted, everything made grid wide would fail



correct me if i`m wrong

Hmm. I was under the impression that you couldn't play an animation just by passing the key of the animation to llStartAnimation(). Has that changed?

Technical note:

You can not trigger an animation using it's key. The animation (provided it's not a "built in animation" *MUST* be in the object's inventory.

Sounds and textures THANKFULLY do not have this limitation.

used to be you could, but they limited it because it was so easy to grab animation keys via a script... why they only thought this was a risk for animations and not textures I don't know (well ok maybe because can grab animation keys from prims it isn't in)


not sure what you mean... I know that if all the objects talk to this one to get the key (rather than storing it local to each script) then that would work.

I read somewhere that garbage cleanup checks scripts for UUID's of textures in scripts and maybe even notecards and will only delete the UUID if there is absolutely no reference to the UUID anywhere.

Yes. That is the way it is supposed to work. Supposedly it even scans literal script strings and--I think--the runtime values of global variables, so if you have a substring hanging around in source code or memory that looks like a key and happens to match the key of an asset in danger of being garbage collected, it is retained instead. But there have been defects in the process before. If you really want to be SAFE, keep it around somewhere. A junk folder is a wonderful thing.

EDIT: Oh. Also, you may have a key that doesn't LOOK like a key, and that won't keep the asset from being discarded. For example, if you have Base64 encoded the key, or stored it in two strings that are concatenated to retrieve the full key, you're out of luck.

Specifically, you can nab the animation keys from any avatar at any given time using llGetAnimationList. There are no congruent functions for retrieving external texture or sound keys.

yes, storing the right permission set item in a box and then use the key that the item has in the box`s inventory to be called by other scripts

obviously, when the box goes, everything breaks

sounds are mostly safe, textures, not so much... it's trivial to grab a texture UUID from anyones objects, no special software required. it's just not an lsl function. of course any owned object with +mod exposes all textures. and in both cases uuids can still be reused in any object, which is the part they actually disabled for animations.

that "trivial" thing has been obfuscated a bit more, and the built in "admin option" for checking texture UUID's has been removed.

Of course, that doesn't stop a custom client from reinstating it.