Is it possible to externally pull a texture UUID from clothing or bodyparts in an items inventory?

[goodlighttreeheart]

Hello <3

I'm trying out a few notions to help safeguard my textures in objects. One thought I had was to store them not as texture files in an objects contents, but hopefully as body parts or clothing that i can just grab the UUID from.

Is this even possible? as far as my noob eyes can see, you only seem able to pull item paramaters from the current prim that a given script is running in

Help me Obi Wan Kenobi, you're my only hope

[Ron Khondji]

You don't have to put the textures in the objects inventory.
You can use the textures uuid directly in functions like llSetTexture(), llSetPrimitiveParams() etc.

To find the textures uuid you can right click the texture in your inventory and then "copy asset uuid".

[goodlighttreeheart]

Yes, i know this. Thanks. what i am trying to do is find a way to pass texture uuids to another object via its inventory but without using the texture. i thought about using notecards where the notecard's name wasthe texture uuid, but i thought that would be a little risky having the uuid readable to an end user. i could put the uuid in the notecard, but im hoping to avoid reading notecards because its slows everything down.

So Is it possible to read the texture uuid from a body part or clothing item held in a prims inventory by a script in the prim?

[Nova Convair]

---

goodlighttreeheart wrote:

 

So Is it possible to read the texture uuid from a body part or clothing item held in a prims inventory by a script in the prim?

---

No.

You can read anything from any prim when it's rezzed with llGetLinkPrimitiveParams. For texture uuid's the object needs to be full perm then. If the object is in a prims inventory you only have the llGetInventoryxxx functions.

[goodlighttreeheart]

Thanks pal <3

[Innula Zenovka]

Maybe I'm misunderstanding what you want to do, but why can't you have two objects, one containing a list of the UUIDs, and one (which changes texture) that tells the first object the name of the texture it wants.

The first object checks a list of names and uuids and, if it finds the name of the texture on its list, sends the UUID back to the second object, using llRegionSayTo.

The second object uses the UUID to change its texture.

Alternatively, if this would be appropriate, you could use the new Key-Value Pairs (KVP) functionality that we now have with Experience Tools.   That way you can store your texture names and UUIDs on LL's dataserver and your scripts can access them from anywhere on the grid where your experience is enabled.

 

[Sassy Romano]

Well newsflash but texture UUIDs are available to end users no matter what you try to do.

 

It's all largely a waste of time doing what you're trying to do.