Jump to content

FIXED Issues with Texture Change HUD


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

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

Recommended Posts

Hello :)

I am new to LSL so I'm not sure where I am going wrong. I'm trying to create a colour change hud for an outfit I've recently created. I have written two scripts, one that is in the object I want to change and another which is the button to change the texture. In the hud you can change the colour of 3 separate components of the outfit, top, skirt and boots. 

Here is an example of the script inside the object:

integer ch=46879421563;

default
{
     state_entry()
    {
       llListen(ch,"",NULL_KEY,"");
    }

   listen(integer channel, string name, key id, string msg)
   {
       if (llGetOwner() == llGetOwnerKey(id))
       {
           llSetTexture(llGetSubString(msg,0,-1),ALL_SIDES);
        }
    }
}


 

 

and the one in the button 

integer ch=46879421563;

default
{
     touch_start(integer total_number)
    {
       llSay(ch,"6de65ebe-5fef-7f52-dd05-da49df98833c");
    }

}

 

Each separate item has their own unique number in the integer "ch" but for some reason, some of the buttons end up changing more than just the object with the same channel. 

any help would be appreciated

Edited by buubbleguum Emerald
problem resovled
Link to comment
Share on other sites

You do not have a handle to the listening. Try to add this:

integer nHandle;

in your state_entry()

 nHandle = llListen(ch, "", NULL_KEY, "");

Now listening is a resource and should be limited in its use, so having different buttons with their own unique channel is a little overkill, I would advice against. Instead use the message you send from the button to tell the outfit, what should be changed, for example: 1 = top 2 = skirt 3 = boots

llSay( ch, "1,6de65ebe-5fef-7f52-dd05-da49df98833c");

Now your clothing should be something like this:

integer ch=46879421563;
integer nHandle;
integer FACE= ALL_SIDES;

default
{
     state_entry()
    {
       nHandle= llListen(ch,"",NULL_KEY,"");
    }

   listen(integer channel, string name, key id, string msg)
   {
        if (llGetOwner() != llGetOwnerKey(id)) return;
               
        integer nAction= (integer) llGetSubString(msg,0,1);
        if (nAction==1)
        {
            string strTexture=  llGetSubString(msg,2,-1);
    
            llSetTexture( strTexture, FACE);
        }
    }
}

 

Edited by Rachel1206
  • Like 3
Link to comment
Share on other sites

A signed 32 bit integer has the range -2147483648 ... 2147483647
LSL will turn 46879421563 into -1. Using invalid numbers will always result in using -1.

Are you aware that "llGetSubString(msg,0,-1)" is the same as "msg"?

However Rachel gave you an example how to make use of llGetSubString and is right that listens are a resource. One listen is enough for one piece of clothing.

Besides of that details your script is supposed to work.

  • Like 3
Link to comment
Share on other sites

5 hours ago, Rachel1206 said:

You do not have a handle to the listening. Try to add this:


integer nHandle;

in your state_entry()


 nHandle = llListen(ch, "", NULL_KEY, "");

This is true and, in general, a good idea.  It's not necessary in this case, however, since you are not intending to close the channel (with llListenRemove) or switch it on and off (with llListenControl).  Keep it in mind, though, because there will be many scripts in which you do want to close or suspend the channel -- for example, to script a time out response or to guarantee that successive users of the script always get different channels for a dialog.

I'd also note in passing that it's probably not necessary to add the filter:

5 hours ago, Rachel1206 said:

if (llGetOwner() != llGetOwnerKey(id))

It's unlikely that someone other than the owner is going to be sending an intelligible command on the specific channel you have chosen.  It certainly doesn't hurt, but it's probably overkill.

Neither of these comments is meant to indicate that these choices are "right" or "wrong".  They are matters of personal preference.  I'm only pointing them out so that you are aware that you have the choices.

  • Like 2
Link to comment
Share on other sites

On 5/30/2017 at 0:31 AM, Rolig Loon said:

This is true and, in general, a good idea.  It's not necessary in this case, however, since you are not intending to close the channel (with llListenRemove) or switch it on and off (with llListenControl).  Keep it in mind, though, because there will be many scripts in which you do want to close or suspend the channel -- for example, to script a time out response or to guarantee that successive users of the script always get different channels for a dialog.

I'd also note in passing that it's probably not necessary to add the filter:

It's unlikely that someone other than the owner is going to be sending an intelligible command on the specific channel you have chosen.  It certainly doesn't hurt, but it's probably overkill.

Neither of these comments is meant to indicate that these choices are "right" or "wrong".  They are matters of personal preference.  I'm only pointing them out so that you are aware that you have the choices.

Thank you for the information :) I think that those options will come in handy for a script I'm working on at the moment using dialog menus with listen channels so that they are not constantly running. I appreciate the input

Link to comment
Share on other sites

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