Scaling and offsetting a texture on child prim

[Highstaker]

I have a linkset. I already have a texture applied to a face 1 of prim 2.

I want to scale and offset it from a script that is in the root prim.

I tried

integer prim = 2;
list cur_textures = llGetLinkPrimitiveParams(prim,[PRIM_TEXTURE,1]);
 llSetLinkPrimitiveParamsFast(prim, [
PRIM_TEXTURE,1,llList2Key(cur_textures, 0),<0.5,1.0,1>,<0.5,0,0>,0
            ]);

But the problem is that when I give an object to someone else, the texture just grays out. My object is no-trans, and llGetLinkPrimitiveParams(prim,[PRIM_TEXTURE,1]) returns a NULL_KEY because of the following caveat (http://wiki.secondlife.com/wiki/PRIM_TEXTURE):

"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."

LlScaleTexture and LlOffsetTexture might work, but I am modifying parameters of textures on child prims.
if there were llLinkScaleTexture and LlLinkOffsetTexture, it would be cool. But there are none 8(

Is there some other way to scale/offset textures on child prim from a script in a root prim while avoiding the problems above?

[Innula Zenovka]

Sounds to me as if the problem is with the texture permissions, not the script itself (which looks OK at first sight, though I haven't looked very closely).

You can only read the uuid of a texture in a prim's inventory by script if that texture is full perms to the current owner.   So if you've made the textures in the root prim anything less than full perms to the next owner, that's why it works for you and not for anyone to whom you give it.   Otherwise you need to call the textures by name, not uuid, and the textures and script have to be in the same prim you want to texture.

To fix this, you need either to make the textures full perms or call them by UUID from a script in the root.   The only alternative would be to have the textures and texturing script in the child prims and use link messages, but that would be pretty messy,

[Highstaker]

Thank you for your reply. 8)

 

I sticked with fixed UUID in script.

Had to tinker a bit to add more options, but it seems fine for now.

 

Now we need to ask LL to add llLinkScaleTexture and llLinkOffsetTexture, heheh

[Dora Gustafson]

---

Innula Zenovka wrote:

Sounds to me as if the problem is with the texture permissions, not the script itself (which looks OK at first sight, though I haven't looked very closely).

You can only read the uuid of a texture in a prim's inventory by script if that texture is full perms to the current owner.

  So if you've made the textures in the root prim anything less than full perms to the next owner, that's why it works for you and not for anyone to whom you give it.   Otherwise you need to call the textures by name, not uuid,

and the textures and script have to be in the same prim you want to texture.

To fix this, you need either to make the textures full perms or call them by UUID from a script in the root.   The only alternative would be to have the textures and texturing script in the child prims and use link messages, but that would be pretty messy,

---

This: You can only read the uuid of a texture in a prim's inventory by script if that texture is full perms to the current owner is not sufficient

In fact the whole object must be full perm for a script to read the UUID of a texture or a sculpty

At least it used to be like that for a long time

The wiki is rather vague about it

:smileysurprised::smileyvery-happy:

[Highstaker]

This looks like a good idea https://jira.secondlife.com/browse/SVC-6916 We only need to wait for eternity before it's implemented

[Innula Zenovka]

I've just tested it with this script and an alt.   So long as the two textures are full perms to my alt, the two-prim object changes properly when I give it to her as mod/copy, no transfer.

integer toggle;list textures;default{    state_entry()    {        textures += [llGetInventoryKey(llGetInventoryName(INVENTORY_TEXTURE,0))];        textures += [llGetInventoryKey(llGetInventoryName(INVENTORY_TEXTURE,1))];        llSetLinkTexture(LINK_SET,llList2Key(textures,toggle),ALL_SIDES);           }        changed (integer change){        if (change & CHANGED_OWNER){            llResetScript();        }    }    touch_start(integer total_number)    {        toggle = !toggle;       llSetLinkTexture(LINK_SET,llList2Key(textures,toggle),ALL_SIDES);    }}

 

 

[Nova Convair]

I made the exact same observations as Dora.

So I never read textures in scripts, since I have flagged that (for me) as not working.

It doesn't matter if it works under this or that condition, that is way to unsafe to use it.

[Innula Zenovka]

All I can say is that I've never had any trouble reading the UUIDs of full perms textures, no matter what the other permissions are like.   It's not something about which I normally worry, since I almost always use uuids anyway, but it's news to me that it could be a problem.

There's no suggestion in the Wiki article for llGetInventoryKey that the containing object's permissions, as opposed to those of the inventory item whose UUID you want to know, should be an issue.

ETA -- Obviously llGetTexture doesn't work unless the object is full perms, but it's the UUID of a texture in the object's inventory we're interested in here, not that of one of the object's faces.

[Dora Gustafson]

From the 2. caveats It looks like:

1. llGetTexture works in a full perm object without textures in inventory
2. llGetTexture also works in not full perm objects if the textures on the prim are also included in the prim inventory

This is what I gather from reading the caveats carefully
I have not experienced or tested it

:smileysurprised::smileyvery-happy:

[Innula Zenovka]

I've just had a play with this in world and, as far as I can make out, if the texture is in the prim's inventory, llGetTexture returns the texture's name, not its uuid, whatever the object's permissions.   It's only if the texture isn't in the object's inventory that it returns the UUID, and then only if the object is full perms.

[Dora Gustafson]

You came a long way now:)
This matter ought to be clarified in the wiki by someone who have the time to analyze it
Could be me, you or someone else

Reading a sculpty texture is related and should also be worked over

:smileysurprised::smileyvery-happy: