Jump to content

Common texture hud scripting problem.


Phinx0126
 Share

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

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

Recommended Posts

Hello, I need any help I can get and it would all be appreciated :3. Anyways Ive been working on this script for days now not understanding the wiki well. I know thats horrible and I made a button and a reciever to change the texture based on which button is pressed. What my issue is trying to make it so it doesnt communicate with other peoples stuff who have the same hud/reciever and alter their outfit texture, so only the owner has control of their texture choice. Yes Ive read up on llRegionSayTo and still dont understand it, scripting isnt my strong suit, but im trying. 

 

 Example of one button

default
{
    touch_start(integer total_number)
    {

        llSay(-50, "5");
    }
}

 

my reciever in clothing/prim/mesh

key owner;

default
{
    state_entry()
    {
        llListen(-50, "", "", "");
    }
    listen(integer channel, string name, key id, string message)
    {
        if(message == "1")
        {
 llSetLinkTexture(LINK_SET, "uuid here", ALL_SIDES);
    }
     else if(message == "2")
        {
 llSetLinkTexture(LINK_SET, "uuid here", ALL_SIDES);
}
      else if(message == "3")
        {
 llSetLinkTexture(LINK_SET, "uuid here", ALL_SIDES);
}
      else if(message == "4")
        {
 llSetLinkTexture(LINK_SET, "uuid here", ALL_SIDES);
}
      else if(message == "5")
        {
 llSetLinkTexture(LINK_SET, "uuid here", ALL_SIDES);
}
      else if(message == "6")
        {
 llSetLinkTexture(LINK_SET, "uuid here", ALL_SIDES);
}
      else if(message == "7")
        {
 llSetLinkTexture(LINK_SET, "uuid here", ALL_SIDES);
        }
    }
}

Thankies all and again *hugs for all* :D

 

Link to comment
Share on other sites

 

        llSay(-50, "5");
        llListen(-50, "", "", "");

 Ok, you have a common problem but you're going to fall into a couple of traps here.  Your basic issue is that above, you're using a static channel, in your case -50.  Anything else listening on that within 20m range, the range of an llSay, will hear that.  Whether the message sent will be of any interest will depend on the listening script.

You have options.  You can either listen on a more unique channel, you can target only known avatar or you can construct a message that is broadcast on a static channel but where the message itself contains more identifying information.

I'd be inclined to do two of these which is to use a more specific channel and send to only the expected avatar.

First, how to get a more unique channel?  Well one thing that avatars have which is unique is their UUID.  There's a good tutorial in the LSL wiki on dialog menus (here: it teaches a lot of important things along the route http://wiki.secondlife.com/wiki/Dialog_Menus ) and to just pull the example from there:-

 

integer channelDialog; default{    state_entry()    {        channelDialog = -1 - (integer)("0x" + llGetSubString( (string)llGetKey(), -7, -1) );    }}

So what this snippet does is assigns a variable at the top, then uses llGetSubstring to grab a bit of the avatars unique UUID and then ensures it's a negative channel.  Just be aware that others may use the same snippet of code so you could still end up sending messages to other items belonging to this avatar.

 

Another option would be to use llFrand to generate a random number for the channel. 

Having done these, lets now look at llRegionSayTo.

http://wiki.secondlife.com/wiki/LlRegionSayTo

Function: llRegionSayTo( key target, integer channel, string msg );

This then is "where is it going to? on what channel? what am I sending?"

Looking in the Caveats in the wiki, the one of interest is:-

Text sent to an avatar's ID on non-zero channels can be heard by any attachment on the avatar

Wel this is handy because you know how to get a unique non zero channel, that's above.  You can find out the key of the destination avatar, well it's the owner of the garment, probably the same as the one using the HUD, so the target is llGetOwner() and now if you send the message to the target of llGetOwner() on a non zero channel, all attachments (your clothing item) will hear it. 

Yay!

But wait there's a problem.  If you use the exact same script for multiple items of clothing, how would your texture change account for changing texture of a jacket vs pants as both will hear it?

You could hope for the best that a random channel (llFrand) wouldn't collide, or you could be more intelligent with your message.  By that I mean instead of just broadcasting on a channel "set texture 1", you would broadcast "pants, set texture 1" or "jacket, set texture 1".

If you do this, then your receiving script needs to do a tiny bit more work first because it needs to parse the message and split out the parts.  llCSV2List can do this and what you'd end up with in my example would be list entry 0 (lists start at 0) would be a string called "pants" or "jacket" and list entry 1 would be a string of the texture UUID.

Now you would have an outer IF loop that first tested for this message.  Alternatively, you could make your HUD no modify and give it a name that you tested for in your listen because the name of the sending object will be in listen event as the name (second parameter).

There is one final gotcha.  You have your listen defined in the state_entry.  Unless this script is reset on transfer to a new owner, the listen will be listening to the previous owner.

This is described as the second caveat in the wiki page for the listen event

 

  • When an object changes owner any listen registered with llGetOwner will not automatically update itself until the script is reset. The scripter can catch this scenario per the example below.
    changed(integer mask)    {   //Triggered when the object containing this script changes owner.        if(mask & CHANGED_OWNER)        {            llResetScript();   // This will ensure the script listens to the new owner, and doesn't continue listening to the creator.        }    }

There's plenty that you will gain with experience, it's all part of the journey and I hope the above gets you a little further forward. I would strongly recommend that you go through the dialog tutorial though as it starts simple and builds upon the problem, tackling issues very similar to the ones you're going to come across here.  The only difference really is that you're sending messages upon hud button press vs blue menu buttons, they're almost identical otherwise.

 

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3013 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...