Jump to content

Weird texture change: Fine when I own object, Goes blank when others own it


You are about to reply to a thread that has been inactive for 4693 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

// Set the object texture to show the whole texture, including "Please click to pay etc"
// and set the image darker blue to show busy.
myShowBusy( ) {
    
    key kCurTexture = llGetTexture(iTouchFace);
    llSetLinkPrimitiveParamsFast(0, [
            PRIM_NAME, sItemName,
            PRIM_TEXT, sInUseHdr + sItemName  +  "...\nRight-click to 'Pay' .",
                gvTitleColor, 1.0,
            PRIM_TEXTURE, iTouchFace, kCurTexture, <1, 1, 1>, <0,0,0>, 0.0,
            PRIM_COLOR, iTouchFace, <0.7, 0.8, 1.0>, 1.0
            ] );
}

// Set the object texture to show the whole texture, including "Please click to pay etc"
// and set the image darker blue to show busy.
myHideBusy( ) {

    key kCurTexture = llGetTexture(iTouchFace);
    llSetLinkPrimitiveParamsFast(0, [
            PRIM_NAME, sName + sVersion,
            PRIM_TEXT, " ", gvTitleColor, 1.0,
            PRIM_TEXTURE, iTouchFace, kCurTexture, <1, 0.945, 1>, <0,-0.027,0>, 0.0,
            PRIM_COLOR, iTouchFace, <1, 1, 1>, 1.0
            ]); /* */
}

 

When I own the object and click on it, the "oversize" main texture squashes down so you can see the instructions in the top part of it. When done, the texture expands vertically to hide those instructions. This works great for me.

BUT, when I pass the object (no mod, COPY, no transfer) to a friend and they rezz it and either of us tries it, the texture disappears completely when the face is clicked, and does not return when done with the interaction.

HELP!

Please.

 

Link to comment
Share on other sites

the texture permissions need to be set to full perms in your inventory for next owner, then reapplied if you are going to get the texture name by script... or include the texture in inventory.

alternatively, you can avoid all that none sense by using llScaleTexture, and llOffsetTexture to set those attributes without having to muck about with getting the texture uuid.

PS
the third parameter in the vectors for texture offset and scale are unused, so zero is preferred for clarity (otherwise people might look at an think that it does something, and never be able to figure out what.

PPS
always use complete float values and not integers in code that expects floats, otherwise the compiler will automatically add a float cast which is another 2 bytes and an additional instruction, your code below has an extra 26 bytes, and 13 instructions after being compiled that you don't see. not horrible but it adds up fast and slows down your code.

Link to comment
Share on other sites

Thanks, all, but...

The main texture in my inventory is Full perms for next owner, and always has been.

When other owners first rez the object, we all see the texture just fine. It is only when the object is squeezed that the texture disappears and does not come back.

(Void, thanks for the notes on the casting)

Link to comment
Share on other sites


Void Singer wrote:

see my notes on using llScaleTexture, and llOffsetTexture...  this prevents you from needing the uuid of the texture, and any permission related problems form the texture itself or the object it's in.

Was using those a while back, but they happen in sequence, so it's ugly. Not keen on that.

I have re-uploaded the texture several times, re-assigned it, etc. The texture is  on two faces, and only one at a time disappears when you click on the and ShowBusy happens. The other face is still visible until you click it and it runs ShowBusy.

Link to comment
Share on other sites

This behaviour is documented on the page I referred you to earlier (and Winter mentioned it as well) - so you will have to live with it - at least for a while ;)

If you don't like Void's proposal, use the UUID straight away. Since you don't want the customer to mod the thinggie, I guess yoou provide the textures.

Link to comment
Share on other sites

you can try either of the following, if those functions aren't satisfactory....

apply the texture by UUID in the script, you can get the texture uuid from your inventory in the right click menu,

drop a copy of the texture in the objects contents

 

This is strictly a permissions based problem, and i'm unsure if it is due to a change or not, but could be... there was a permissions exploit that would allow capturing the uuid of permissions limited textures a while back, so we could be seeing fallout from a fix for that.

NVM darkie has it... it's the longstanding permissions idiocy caused mostly by the chaining of all texture attributes in the prim params functions

Link to comment
Share on other sites


Darkie Minotaur wrote: use the UUID straight away. Since you don't want the customer to mod the thinggie, I guess yoou provide the textures.

Yes, Darkie, thanks. I suspected as much, and I will add some code to set the faces to the texture in the contents. If I make copies of the object, will the UUID change? And thus need to change the script, or make it auto-take the first texture in inventory?

btw- It seems strange you can't directly add a texture to a face from contents, but you can with a script. By this, I mean there is no edit-window facility to do this.

 

Link to comment
Share on other sites

You have to provide something you can identify the texture with:

  • The name, if the texture is in tzhe object's inventory (of course you can retrieve the name from the inventory)
  • The UUID if the texture is somewhere in SL

The problem is not the assigning of the texture, but the getting of the UUID of it - you can't - if the object is no mod - get it with llGetTexture() - if you think about it, it will occure to you why.

Link to comment
Share on other sites


Darkie Minotaur wrote:

You have to provide something you can identify the texture with:
  • The name, if the texture is in tzhe object's inventory (of course you can retrieve the name from the inventory)
  • The UUID if the texture is somewhere in SL

The problem is not the assigning of the texture, but the getting of the UUID of it - you can't - if the object is no mod - get it with llGetTexture() - if you think about it, it will occure to you why.

Yes, I understand Darkie, but:  If I make copies of the object, will the UUID change? 

I assume not, as the texture "belongs" to LL once you upload it, and inventories and objects simply reference it.

Side question: Are textures ever deleted from LL servers? "garbage collected" etc? Again I would think not; perhaps if the texture is not requested in 2+ years they could, I guess.

 

Link to comment
Share on other sites

texture uuid's never change, because they are not modifiable resources.... neither do sounds or animations. any resource that is modifiable will change it's uuid whenever the actual item is saved again.

the exception are objects, which change their accessible uuid when rezzed, but that is the prims themselves only. once rezzed they retain their uuid until derezzed.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4693 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...