FYI: llGetPrimitiveParams gotcha with textures

I had a weird issue with texture UUID's fetched with llGetPrimitiveParams on PRIM_TEXTURE returning the "Smoke" texture, which is what you get if you set a texture with a NULL_KEY.

Thanks to some suggestions on what to look for from Lex Neva and Argent Stonecutter, I found out the problem: LINKED prims with more restrictive permissions prevent llGetPrimitiveParams from working for texture queries.

In detail, it turns out that if you call llGetPrimitiveParams on PRIM_TEXTURE in a prim that you have FULL permissions on (including the textures), but that same prim is linked to another prim that is NOT full permissions, llGetPrimitiveParams will return the NULL_KEY for texture UUID queries, despite the fact that llGetPrimitiveParams is only returning information on the prim that you already have full permissions on.

If you unlink the prim that is NOT full permissions, the llGetPrimitiveParams on PRIM_TEXTURE works fine.

Bah.

This sort of thing is useful to know - thanks! So many problems boil down to inherited permissions - particularly a nuisance when one has to incorporate third party scripts that are not full perms.

It sounds like the same problem with llGetInventoryKey of ANYTHING thats NO COPY, it will return NULL_KEY which is a total pain!

If I had looked at the nitty gritty fine-print of LSL Wiki mirror, I would have noted:



The key word is OBJECT, which is distinct from PRIM, which is what I mentally incorporated.

Oh well, LOL. Perhaps my headache and debugging will save some of you others the same.

Wow, that's a nasty little gotcha. So nasty I'd consider it a bug and bug report it, personally, although I imagine they'll decide it's not a bug.

Incidentally, in this case, the contents of the prims did NOT contribute to the problem. All of the prims contained scripts that were COPY / NO MOD / NO TRANSFER, but that didn't seem to affect returning texture UUID's on the prims -- it was purely a linked prim / permission of the prim itself issue.

However, HAVING the scripts in there, of course, made it more difficult to figure out WHAT the permissions were, because often all you see is the least common denominator inherited permissions. I went through a bit of clearing out all scripts from the prims, and adding things back one at a time, one link at a time, to get the final answer.

It's a pain but it is reasonable, you can use a UUID to set a texture or play a sound or read a notecard. The NULL_KEY return of llGetPrimitiveParams and llGetTexture were added as a response to one of the hubbubs about script base cloning (long before the copybot fiasco). Course it is all a moot point considering that SL is open source now.

Oh I agree with the reasoning behind it, its just a royal pain sometimes. I have one particualr project which would have been very much simpler but for the fact the animations I was manipulating where NO_COPY so I couldn't transmit the key to the slave objects. With the slave objects being temporary as well it just made the system far more complex than it needs to be.

/me goes green in the face and clutches her stomach.

When you link prims, individual prim permissions are no longer checked, but instead the permissions on the object as a whole are checked (which is the most restrictive combination of all prim properties when linked). That's not including permissions on prim inventories.