Finding Link/Face of texture change

[jak Scribe]

I have a hud containing linked prims and the user can slide a texture on to the visible face of any of those prims.

Firstly I get the user to click the face he wishes to change, and I store the link and face select..

Now I see the user could slide a texture onto another prim other than one I asked them to select!

Is there anyway to find out which link/face has this new texture?

(I do have all the textures already showing stored, but I cannot recognise the link/face of the new texture if it is already the same as one previously placed onto the non-selected link.)

[Marvin Benelli]

When you put the texture on the selected link and face you can put a log message using llOwnersay with link number, face number and texture. Then you know where the texture went.

It all sounds like you’re not using the selected link and face at all. More help can be provided when you would share some code

[Qie Niangao]

"Slide" you say? Maybe llDetectedGrab() would work here?

Trying to imagine what this HUD is actually doing, and I'm envisioning something like a palette of textures that can be "dragged" across the HUD and "dropped" onto one of some number of destination tiles. This might use a surface above all the tiles and the dragged texture that actually mediates all the dragging and dropping, so the script would know where the texture was dropped based on where the dragging stopped across that surface.

But yeah, without code, it's just luck of the draw to make a useful suggestion.

[elleevelyn]

5 hours ago, jak Scribe said:

(I do have all the textures already showing stored, but I cannot recognise the link/face of the new texture if it is already the same as one previously placed onto the non-selected link.)

it can get a bit cumbersome to track changes to linkset faces but is doable https://wiki.secondlife.com/wiki/CHANGED_TEXTURE

some p-code showing a way this can be done

// p-code

// script in the object being changed

list textures;

list getTextures()
{
    ... get the texture uuid of each link and face llGetLinkPrimitiveParams
    ... save (link,face,texture) as single csv string item to a list
    return the list     
}

default
{
    state_entry()
    {
        textures = getTextures();
    }


    changed (integer chamge)
    {
        if (change & CHANGED_TEXTURE)
        {
            list temp = getTextures();
            
            integer stop;
            integer index = llGetListLength(temp);
            while (~--index && !stop)
            {
                string item_new = llList2String(temp, index);
                string item_old = llList2String(textures, index);
                if (item_new) != item_old)
                {
                    list params_new = llCSV2List(item_new);
                    list params_old =  llCSV2List(item_old);
                    
                    ... here we have the link, face, new texture uuid and old texture uuid
                    ... do something with this info include repair if necessary
                    
                    stop = TRUE;  
                }
            }
            
            // textures list becomes temp list for next change event
            textures = temp;
        }
    }
}

 

 

[Quistess Alpha]

42 minutes ago, Qie Niangao said:

"Slide" you say? Maybe llDetectedGrab() would work here?

my assumption would be dragging from inventory onto a face to change the texture (which is very error-prone, I highly recommend doing it via the build window instead).

And in that case, the problem is that changed(integer c){  if(c&CHANGED_TEXTURE){ /*...*/}  } provides no information to the script about ~how the textures have changed. AFAIK, the only solution would have to be a rather involved script-copy of the information about all texture-parameters of the object in global variables or (much more conveniently) Linkset Data.

[Bleuhazenfurfle]

4 hours ago, Quistess Alpha said:

my assumption would be dragging from inventory onto a face to change the texture (which is very error-prone, I highly recommend doing it via the build window instead).

And in that case, the problem is that changed(integer c){  if(c&CHANGED_TEXTURE){ /*...*/}  } provides no information to the script about ~how the textures have changed. AFAIK, the only solution would have to be a rather involved script-copy of the information about all texture-parameters of the object in global variables or (much more conveniently) Linkset Data.

Isn't that going to run into issues with no-mod textures?  If all your faces report NULL_KEY for their texture, that's not going to help you very much.

Would think it better to drop the texture in as an inventory item, having the script notice and pop up a message asking you select the spot into which to load the texture.  (And then remember that, so you can remove the texture again if it gets replaced later.)

Unfortunately, LSL doesn't have any drag-and-drop support, like, you can't indicate which faces are droppable, so a slip of the mouse and your entire HUD has now been repainted (I presume that's at least part of that "very error-prone").

[elleevelyn]

16 minutes ago, Bleuhazenfurfle said:

Isn't that going to run into issues with no-mod textures?  If all your faces report NULL_KEY for their texture, that's not going to help you very much.

this raise the perennial question. When we are providing a asset that is to be applied to change the appearance of an object then why would we provide the asset as no-modify ?

as someone who uses other creators's assets when building/modding then I have zero interest in no-modify assets. They go straight to my trashbin. No-transfer sure I can work with that. No-modify am not interested

[Bleuhazenfurfle]

2 minutes ago, elleevelyn said:

this raise the perennial question. When we are providing a asset that is to be applied to change the appearance of an object then why would we provide the asset as no-modify ?

as someone who uses other creators's assets when building/modding then I have zero interest in no-modify assets. They go straight to my trashbin. No-transfer sure I can work with that. No-modify am not interested

That depends on who's using it, and what it's for — I don't recall there being enough information to make assumptions here.

The "average user" of a HUD, may not even be aware whether the texture they're applying is mod or not.  If these textures are going no further than the faces on which they're placed, then there's no good reason to restrict their mod-ness (like, a teleporter may accept an image for each destination — since text labelling sucks in LSL).

[elleevelyn]

24 minutes ago, Bleuhazenfurfle said:

That depends on who's using it, and what it's for — I don't recall there being enough information to make assumptions here.

The "average user" of a HUD, may not even be aware whether the texture they're applying is mod or not.  If these textures are going no further than the faces on which they're placed, then there's no good reason to restrict their mod-ness (like, a teleporter may accept an image for each destination — since text labelling sucks in LSL).

my assumption is that OP script is applying textures they have provided

your assumption is that OP script is applying textures the HUD user has provided

if the first assumption is correct then modify perms

if the second assumption is correct then both modify and no-modify perms can be involved

 

if I did have a question for OP it would be: Is it that we wanting to prevent the action when the user touches the wrong face for the texture they have chosen to apply ?

[Qie Niangao]

Unless somebody knows magic to which I'm not privy, no CHANGED_TEXTURE event is generated if the texturing is done by script…

Nor if it's done manually and the same texture is applied to the face… which might be what this is all about to begin with, except…

18 hours ago, jak Scribe said:

Firstly I get the user to click the face he wishes to change

which doesn't really fit either scenario.

But either way, why care if the user applies (by whatever means) the same texture to a face (selected or not)? Why not "nothing happened here" which is what the script sees anyway? So I give up: I can't make any sense of the problem as posed.

[jak Scribe]

Thanks for all your help.

I understand that it is difficult without seeing the code but the script is long and has many functions and it might be hard to see what I am doing (sometimes I even forget myself after a longer break lol)

I am trying something along the lines some of you suggested.

I already have all the textures previously given, stored in a special structure in my linksetdata. So after the User has selected the link/face where they want to place a texture, I will replace all possibe receiving links/faces with a certain texture and within the change event I will compare the actual textures on the links/faces and find the one that has changed. Then I have my change link/face

I will get back if it works, or doesn't work.

Thanks again for all your suggestions

PS. I provide an Album with many of my Huds. This enables the Users to store their own textures (static, animated, and or rotational) or for my Update to provide them other textures.  This communicates with my other Huds to pass selected textures.  Of course the User can 'slide' textures from their own Inventory as long as they have full permissions.