problem with channels (I think) on HUD to change textures

[Sylvia Wasp]

Hello, 

I wrote a texture changing HUD from scratch but I have a question.  

Basically, the HUD has button prims that when clicked, use llMessageLinked to tell their name to the main HUD prim which then hears them on a link_message. 

The main HUD prim then relays the messages to the mesh clothing (things like "button_01", "button_02" etc.) using llSay on a channel. 

The clothes hear the messages and change textures, and everything seems to work fine except ... if two people are changing clothes in the same room their HUDs affect each other and then change each others clothes.  I'm basically using the same channel and only identifying the HUD to the clothing by the name (of the HUD).  

I'm sure there must be a better way wherein two people can buy the same clothes and the HUDs they bought don't affect each others clothes?  Perhaps by setting some random channel when the HUD is attached each time?  I'm just not sure how to do this or if it's possible or if customers generally care about it.  The odds of two people buying the same product changing the texture in the same area are pretty small but it does happen.

Any help would be appreciated. 

Sylvia 🙂

[Fritigern Gothly]

Mistake #1: Using scripted buttons to communicate with the main script. I can guarantee you that you can remove all the scripts from all the buttons and use llGetLinkName(llDetectedLinkNumber(0)) to detect which button was pressed. This will cut down on your script use and therefore your memory usage. Remember that each LSL script reserves 16kb, but when compiled as Mono, it reserves 64kb, so 16 mono scripts reserves 1 MB which often shows up as memory actually used. Plus you will have all your code in a single script instead of all over the place so that if you want to change something like, i don't know, you'd want each button to glow for 2 seconds after being pressed, you can do that in 1 script (and use llSetLinkPrimitiveParamsFast()to set and unset that glow).

Mistake #2: You appear to be using a single, immutable channel for your system. Try generating a channel based on a user's UUID. this sample in the LSL library will show you how. I personally use the variant with the app key, so that the HUD for product A does not mess with product B when they are used and owned by the same owner. You will have to change the app key for each different product though. To generate the channel number, you would use integer Channel = Key2AppChan(llGetOwner(), 123456); where you would replace 123456 with a predefined integer of your own between -2147483647 and 2147483647.
If you don't want to mess with app keys, you can use the "simple" routine, which will be used as integer Channel = Key2Chan(llGetOwner()); and works fine as well, but can cause one hud to affect a different product when owned by the same user (like a dress HUD can affect shoes if they both use the simple routine).

[Sylvia Wasp]

55 minutes ago, Fritigern Gothly said:

Mistake #1: Using scripted buttons to communicate with the main script. I can guarantee you that you can remove all the scripts from all the buttons and use llGetLinkName(llDetectedLinkNumber(0)) to detect which button was pressed. This will cut down on your script use and therefore your memory usage. Remember that each LSL script reserves 16kb, but when compiled as Mono, it reserves 64kb, so 16 mono scripts reserves 1 MB which often shows up as memory actually used. Plus you will have all your code in a single script instead of all over the place so that if you want to change something like, i don't know, you'd want each button to glow for 2 seconds after being pressed, you can do that in 1 script (and use llSetLinkPrimitiveParamsFast()to set and unset that glow).

Mistake #2: You appear to be using a single, immutable channel for your system. Try generating a channel based on a user's UUID. this sample in the LSL library will show you how. I personally use the variant with the app key, so that the HUD for product A does not mess with product B when they are used and owned by the same owner. You will have to change the app key for each different product though. To generate the channel number, you would use integer Channel = Key2AppChan(llGetOwner(), 123456); where you would replace 123456 with a predefined integer of your own between -2147483647 and 2147483647.
If you don't want to mess with app keys, you can use the "simple" routine, which will be used as integer Channel = Key2Chan(llGetOwner()); and works fine as well, but can cause one hud to affect a different product when owned by the same user (like a dress HUD can affect shoes if they both use the simple routine).

Lol.  This is exactly why I rarely ask questions here.   

Many genuine thanks for this: 

integer Channel = Key2Chan(llGetOwner());

Which is basically (one) answer or one way to do it, but I have to say that I find this response extremely rude.   

- My first "mistake" isn't a mistake, it's just a choice, and the memory usage on a script in this situation is about as important as which potato chip you pick out of the bag first when eating potato chips.  I don't use mono on the buttons so we are talking about less than 200k even on my most elaborate HUD.  200k which will be in use for less than a minute when a person is changing clothes.  

It also means I never have to worry about scripting buttons (or anything to do with buttons) which saves me huge amounts of time.  I have pre-made HUDs in inventory with button arrays of two, three, four, six, eight, and twelve buttons.  I drag a HUD out of inventory with the right number of buttons, apply a texture, and change the main HUD code as needed.  Simple!

The main HUD code is always going to be comprised of a simple list of UUID's (the textures) and an if/else list for the button messages anyway, so I can just plug in the new UUIDs and maybe once in a blue moon have to edit the llSetLinkPrimitiveParamsFast()sections.  

It's a very simple, clear, practical, reusable system that works very well indeed and is totally not a "mistake".  

- My second "mistake" also isn't a mistake, it's actually the situation I posed to the forum in the first place.  The very question I asked you. 

[Wulfie Reanimator]

22 minutes ago, Sylvia Wasp said:

It's a very simple, clear, practical, reusable system that works very well indeed and is totally not a "mistake".  

Not really a mistake, no. But I would call it.. inadvisable.

To summarize, your button scripts looks something like this (times 12) :

default
{
    touch_start(integer n)
    {
        llMessageLinked(LINK_ROOT, 0, llGetLinkName(LINK_THIS), "");
    }
}

And your HUD's root script looks something like this:

default
{
    link_message(integer sender, integer num, string str, key id)
    {
        if(str == "button 1") {...};
        else if(str == "button 2") {...};
        else if(str == "button 3") {...};
        else if(str == "button 4") {...};
    }
}

 

But instead, you could delete all 12 button scripts and change your main script to:

default
{
    touch_start(integer n)
    {
        string button = llGetLinkName(llDetectedLinkNumber(0));

        if(button == "button 1") {...};
        else if(button == "button 2") {...};
        else if(button == "button 3") {...};
        else if(button == "button 4") {...};
    }
}

Which is functionally identical, requires no extra work, and makes the object 12 scripts lighter.

At least you have the foresight of setting the scripts to not-Mono, which is awesome. But even scripts that do nothing still take up sim resources, and you would be surprised by how many people keep their HUDs attached even when they aren't in use. (I'm at fault for this myself even.)

Edited June 30, 2019 by Wulfie Reanimator

[Ana Stubbs]

14 minutes ago, Sylvia Wasp said:

- My first "mistake" isn't a mistake, it's just a choice, and the memory usage on a script in this situation is about as important as which potato chip you pick out of the bag first when eating potato chips.  I don't use mono on the buttons so we are talking about less than 200k even on my most elaborate HUD.  200k which will be in use for less than a minute when a person is changing clothes.  

Memory usage is a bit of a red herring - idle scripts that do nothing have a disproportionate effect on the sim. Obviously it depends how many buttons you have, but if you're relying on the user taking the hud off before going anywhere, unless that is you or your best friend, it's unfortunately not reliable.

Quote

My second "mistake" also isn't a mistake, it's actually the situation I posed to the forum in the first place.  The very question I asked you. 

I wouldn't fixate on the word mistake. If you do, you're not going to get very far with scripting. Learn to love your mistakes, bugs, and unexpected behaviours. Any scripter who does not make mistakes is either not learning, or  is making mistakes but can't see them.

[Fenix Eldritch]

I don't think Fritigern intended to be rude, but was instead trying to point out that using one script per button is a practice that's generally ill-advised.

While it's always good to reduce your memory footprint, the sheer number of scripts (even idle ones) does have an impact on the server. The wiki mentions that each idle script in an object adds 0.001 to 0.003 milliseconds per frame of script time usage. Script time is a precious recourse that we must all share with each other. And it's also the first resource to dry up when the sim starts having other problems. So it's really important that we all try to reduce script counts where possible to help each other out. That's precisely why LL has been adding more and more of the linked function variants, so that we can do more with fewer scripts.

In your specific scenario, you mention your buttons are just sending their names to the main HUD and then the HUD relays that name to the attachments. If all you're sending is the button name, you could simplify your code by doing something like this in the main HUD script:

touch_start(integer total_number)
{
        llSay(target_channel, llGetLinkName(llDetectedLinkNumber(0));   //says link name on target_channel
}

That would just send the name of whatever prim in the linkset was clicked. No need for an intermediary script to tell the HUD's main script what was clicked, as with this, it can find out on its own.

Edited June 30, 2019 by Fenix Eldritch

[Fritigern Gothly]

41 minutes ago, Sylvia Wasp said:

Which is basically (one) answer or one way to do it, but I have to say that I find this response extremely rude.   

The rudeness is entirely yours, my dear. I went through the trouble of explaining myself, giving you examples, I helped. 
Your response? "You're rude!"

So forget it, you have received the last bit of help from nme you will ever get.

[Sylvia Wasp]

Ok, I guess I got all the scriptures mad at me, lol, BUT ...

People actually come here for help and none of this is really that helpful.  I have a product ready to go and all I need is a way to generate a channel at the top of one script and nothing said here has actually helped me out.  It's all just theoretical discussions about the details of scripty things among scriptors. 

I can make the change to reduce my 196k script load for less than one minute of the sims time later, what I need now is what I know is probably a simple snippet of code to fix my problem and no one is coming forward with it.  

integer Channel = Key2Chan(llGetOwner());

seems to be a custom function and is not working at all.  

I know that some people use a random number generator to do the same thing.  Can someone provide a clue as to how I would code that instead? 

[Ana Stubbs]

4 minutes ago, Sylvia Wasp said:

Ok, I guess I got all the scriptures mad at me, lol, BUT ...

People actually come here for help and none of this is really that helpful.  I have a product ready to go and all I need is a way to generate a channel at the top of one script and nothing said here has actually helped me out.  It's all just theoretical discussions about the details of scripty things among scriptors. 

I can make the change to reduce my 196k script load for less than one minute of the sims time later, what I need now is what I know is probably a simple snippet of code to fix my problem and no one is coming forward with it.  

integer Channel = Key2Chan(llGetOwner());

seems to be a custom function and is not working at all.  

I know that some people use a random number generator to do the same thing.  Can someone provide a clue as to how I would code that instead? 

http://wiki.secondlife.com/wiki/UUID2Channel

[Sylvia Wasp]

2 minutes ago, Fritigern Gothly said:

The rudeness is entirely yours, my dear. I went through the trouble of explaining myself, giving you examples, I helped. 
Your response? "You're rude!"

So forget it, you have received the last bit of help from nme you will ever get.

LOL.  I was so very careful not to be rude in my response to your rudeness.  I really tried, honest.  

I used smiley's and 'perhapses' and every circumlocutory prose I could think of to couch what I was saying in nice terms.  

I even thanked you profusely for your obscure and inscrutable suggestion that was given to me without any practical explanation or application ... and then *you* post a rude huffy response anyway.   

I think I know which one of us has trouble communicating with the other monkeys. 😉 

[Fenix Eldritch]

31 minutes ago, Wulfie Reanimator said:

At least you have the foresight of setting the scripts to not-Mono, which is awesome.

Wulfie, I'm curious, why would this be preferable to a mono version? Assuming the helper script is small, wouldn't it (if nothing else) be preferable to use mono for the potentially smaller allocation size and potential bytecode sharing? Or have I forgotten something?

Edited June 30, 2019 by Fenix Eldritch

[Wulfie Reanimator]

22 minutes ago, Sylvia Wasp said:

integer Channel = Key2Chan(llGetOwner());

seems to be a custom function and is not working at all.  

I know that some people use a random number generator to do the same thing.  Can someone provide a clue as to how I would code that instead? 

@Fritigern Gothly gave you a link to a wiki page going into detail on how to generate a unique channel based on a UUID/product. (Which is where that Key2Chan came from.) There's no better answer than what she already provided.

Nobody is mad at you, by the way, besides the person who was the first to answer your main question in full.

17 minutes ago, Fenix Eldritch said:

Wulfie, I'm curious, why would this be preferable to a mono version? Assuming the helper script is small, wouldn't it if nothing else be preferable to us mono for the dynamic memory size and potential bytecode sharing? Or have I forgotten something?

While Mono-scripts are faster and use inherently less memory -- due to having a dynamic memory size -- non-Mono (LSO) scripts have fixed memory size. No matter how big or small the script is, it will always use 16KB. This is important when the object containing the script rezzes (either by llRezObject functions or while teleporting), because the current memory taken up by Mono scripts needs to be calculated. This is a very slow process and it's the main reason why sims chug when a new avatar enters. LSO scripts, having fixed size, don't have this downside and are very quick to transfer/start.

Though on second though, now that I've explained all of this again, it's probably not foresight why all of those scripts have been set to LSO.
The button scripts, if set to Mono, would only use about 3876 bytes (less than 4KB) of memory. That's 4 times less than non-Mono scripts.

That's not my point though. Memory-use by itself is not important until your script starts running out of it.

Edited June 30, 2019 by Wulfie Reanimator

[Fenix Eldritch]

Ah, I didn't realize the size calculation on script rezz was such a performance hit. Thanks!

[Sylvia Wasp]

29 minutes ago, Ana Stubbs said:

Memory usage is a bit of a red herring - idle scripts that do nothing have a disproportionate effect on the sim. Obviously it depends how many buttons you have, but if you're relying on the user taking the hud off before going anywhere, unless that is you or your best friend, it's unfortunately not reliable.

I wouldn't fixate on the word mistake. If you do, you're not going to get very far with scripting. Learn to love your mistakes, bugs, and unexpected behaviours. Any scripter who does not make mistakes is either not learning, or  is making mistakes but can't see them.

Well, that was kind of my point.  "Mistake" is 100% an insult in this context.  

It's literally staring off the answer (to a clear, precise and kindly phrased question) with, "your wrong".  

That's what typically happens on the LSL scripting forum.  You ask a question about a script with an error and you get told that "your entire approach is wrong" and that the person answering it could re-write everything this other way and it would be so much better, yada-yadda ... yet somehow the original question is literally never answered.  

The only reason I bothered is because I'm on a deadline for a product that I want to roll out tonight.  

I guess I'm on my own, but I repeat ... there is a way to generate a channel number using random numbers.  If anyone wants to just post that code so I can use it at the top of my script I'd appreciate it.  

That's what makes it so galling.  I know that almost everyone answering this thread probably knows how to do that but no one wants to say it, lol.  They want to argue about "proper" procedure and who's method is the best.  

[Fritigern Gothly]

14 minutes ago, Sylvia Wasp said:

I even thanked you profusely for your obscure and inscrutable suggestion that was given to me without any practical explanation or application ... and then *you* post a rude huffy response anyway.   

Mistake #3. Not reading what I wrote. My answer was a complete one, with explanation and application examples. I included the link to the function in question  (HINT: follow the link!). I'm only sorry I went through all this trouble to help you whilst you clearly just want to be spoon fed and throw my efforts back in my face.

[Ana Stubbs]

2 minutes ago, Sylvia Wasp said:

Well, that was kind of my point.  "Mistake" is 100% an insult in this context.  

I really do think you've got the wrong end of the stick, for me, mistakes are good. It's not even that making a mistake means you're wrong. Your solution was perfectly right - It compiles and works. But it was still a typical "beginner's mistake", ie there are solutions which are better.

[Sylvia Wasp]

7 minutes ago, Wulfie Reanimator said:

@Fritigern Gothly gave you a link to a wiki page going into detail on how to generate a unique channel based on an UUID/product. (Which is where that Key2Chan came from.) There's no better answer than what she already provided.

It may be clear to you but a snippet of code without any context or explanation is of no help to me.  

I know, I know, you want me to learn all about it for myself.  You want me to use the "correct" methods or what you believe is the best methods, but the net result here is I'm going to just use a plain old number if I can't figure this out by midnight.  

So if people are really concerned about memory usage in the sims, the end result here is actually going to be the complete opposite of that intention.  

Again, I know I've seen scripts that use llFrand to generate a number that can be used as a unique channel.  Your actually responding to my second attempt to ask for information on that, yet you give me a different other method instead, lol.

A method that I couldn't understand if I had the rest of the week to figure it out, simply because you think it's a slightly better method.  

[Ana Stubbs]

1 minute ago, Sylvia Wasp said:

It may be clear to you but a snippet of code without any context or explanation is of no help to me.  

I know, I know, you want me to learn all about it for myself.  You want me to use the "correct" methods or what you believe is the best methods, but the net result here is I'm going to just use a plain old number if I can't figure this out by midnight.  

So if people are really concerned about memory usage in the sims, the end result here is actually going to be the complete opposite of that intention.  

Again, I know I've seen scripts that use llFrand to generate a number that can be used as a unique channel.  Your actually responding to my second attempt to ask for information on that, yet you give me a different other method instead, lol.

A method that I couldn't understand if I had the rest of the week to figure it out, simply because you think it's a slightly better method.  

I googled "lsl random channel" and found http://www.aliciastella.com/modules/AMS/article.php?storyid=24 , which seems to be a good, working example of exactly that.

I know it's infuriating, but if you want complete code for your exact application, you'll have to pay for that.  If you want free help, it's going to be somewhat spottty and incomplete, because we're all doing this in our free time. I'm missing my game of Primtionary trying to help you.

[Fenix Eldritch]

Instead of transmitting your HUD's message via llSay, consider using llRegionSayTo instead.

In addition to specifying a channel and message, you would also supply a target UUID/key of the thing you want to send the message to. In your case it could be the avarar's key. This is useful because any text sent to an avatar in this manner (and on a non-zero channel) is heard by all its attachments. So you could use this to isolate any cross talk from other HUDs in the area - as other avatars (and their attachments) would not be targeted, even if you used the same channel.

Edit: our other recommendations regarding script count still stands and I hope you consider them as well. Good luck.

Edited June 30, 2019 by Fenix Eldritch

[Wulfie Reanimator]

19 minutes ago, Sylvia Wasp said:

It may be clear to you but a snippet of code without any context or explanation is of no help to me.  

I know, I know, you want me to learn all about it for myself.  You want me to use the "correct" methods or what you believe is the best methods, but the net result here is I'm going to just use a plain old number if I can't figure this out by midnight.  

So if people are really concerned about memory usage in the sims, the end result here is actually going to be the complete opposite of that intention.  

Again, I know I've seen scripts that use llFrand to generate a number that can be used as a unique channel.  Your actually responding to my second attempt to ask for information on that, yet you give me a different other method instead, lol.

A method that I couldn't understand if I had the rest of the week to figure it out, simply because you think it's a slightly better method.  

Friend... you're being way too defensive over things that did not happen. Nobody is mad at you. You don't need to rewrite your scripts. You can even ignore everything I said!

And it's far from "typical" that the responses here are "everything you're doing is wrong."

Again, please click on this link, which has been given to you 3 times now: http://wiki.secondlife.com/wiki/UUID2Channel
It's not llFrand, but everything is explained there. If there's anything specific on that page that you do not understand, you need to ask more specific questions.

Using llFrand alone is not going to be a viable way to generate a unique channel, because you can't use llFrand in two separate scripts to get the same result. It requires lots of additional things for the two objects to agree on what should be the channel. Explaining those ways is going to take a lot more time and effort than creating a channel from the owner's avatar key (unique channel for each avatar, with some edge-cases).

13 minutes ago, Ana Stubbs said:

I googled "lsl random channel" and found http://www.aliciastella.com/modules/AMS/article.php?storyid=24 , which seems to be a good, working example of exactly that.

Unfortunately that's not going to be helpful to @Sylvia Wasp, because that script assumes that it is the only script, and uses llFrand to pick a random channel for a menu coming from itself, every time a menu is shown. It cannot communicate with other scripts this way.

27 minutes ago, Sylvia Wasp said:

If anyone wants to just post that code so I can use it at the top of my script I'd appreciate it.  

You'd be better off trying your luck here if that's your only goal: https://community.secondlife.com/forums/forum/313-wanted/

This forum section is for discussion and learning.

Edited June 30, 2019 by Wulfie Reanimator

[Ana Stubbs]

17 minutes ago, Wulfie Reanimator said:

Unfortunately that's not going to be helpful to @Sylvia Wasp, because that script assumes that it is the only script, and uses llFrand to pick a random channel for a menu coming from itself, every time a menu is shown. It cannot communicate with other scripts this way.

Ooops, I hadn't picked up on that part. Thanks for catching that Wufie.

Edited June 30, 2019 by Ana Stubbs

[Mollymews]

6 hours ago, Sylvia Wasp said:

[Key2Chan  seems to be a custom function and is not working at all.

i give some code examples as a FYI  about what key to channel is, why we use it, how it works, what the implications are, and how we might work around any concerns

the basic reason for using key to channel is so that a sender app and a receiver app can communicate on a known channel. While at the same time spreading app communications across a number of channels on an individual user basis, while also providing some crosstalk protection for two or more users who may be on the same region using our apps.  HUD >> Clothing/Body/Furniture being a typical case where this can happen

the first script walks thru key to channel, and comments on the what and whys

default
{
    state_entry()
    {      
        integer app_channel;
       
        app_channel = (integer)("0x"+(string)llGetOwner()) | 0x80000000;
        // the above code creates a channel number using the 1st 8 hexadecimal numerals
        // of the owner's avatar key: (integer)("0x"+(string)llGetOwner()
        // then uses OR 0x80000000 to convert this into a negative number
        
        // when this is used widely by different script apps then we can get a higher rate of our app
        // receiving understandable messages from other scripts owned by the same person, and scripts
        // owned by others that happen to use the same channel
        // which can result in our app acting on those messages when it shouldn't
        
        // we designate a unique id for our app. Each of our apps has it owns unique id

        integer app_id = 73245;      
        
        // we then XOR the channel with our appid, so that at least our apps owned by the same user 
        // will never crosstalk each other
        
        app_channel = (integer)("0x"+(string)llGetOwner()) ^ app_id | 0x80000000;
        
        // an issue with this as wrote is that we need to ensure that the result of this is not
        // equal to 0. 1 XOR 1 == 0;  When so then our app will communicate on the public channel 0.
        // to avoid this remote (but still possible) happening then we check for it      
        
        app_channel = (integer)("0x"+(string)llGetOwner());
        
        if (app_channel == app_id) ++app_id;
        app_channel = app_channel ^ app_id | 0x80000000;
        
        // for this part to be safe then our unique app_ids need to be at least 2 values apart. 1, 3, 5, etc
        
        // this doesn't protect our app from two or more of our app users who might happen to have
        // the same first 8 hexadecimal numerals as each other  
        // for protection against this and from crosstalk from other creators apps then relying on the 
        // channel value all by itself is not a safe method. No matter what channel we choose then the
        // possibility of two or more independent scripts from two or more independent creators using 
        // the same channel remains.
        // the code so far only protects our app from our other apps owned by the same user
        
        // to protect from other creators and other users of our app then see the following example codes
        // in the post
    }
}

the next two scripts show example codes putting it all together, also adding in the protective checks for owner and creator

// sender

integer app_id = 73245;

integer app_channel;


default
{
    state_entry()
    {
        app_channel = (integer)("0x"+(string)llGetOwner());
        if (app_channel == app_id) ++app_id;
        app_channel = app_channel ^ app_id | 0x80000000;
    }
    
    touch_start(integer total_number)
    {
        llRegionSay(app_channel, "Hello! how are you?");
    }
}

// receiver

integer app_id = 73245;

integer app_channel;


default
{
    state_entry()
    {
        app_channel = (integer)("0x"+(string)llGetOwner());
        if (app_channel == app_id) ++app_id;
        app_channel = app_channel ^ app_id | 0x80000000;
       
        llListen(app_channel, "", NULL_KEY, "");
    }

    listen(integer channel, string name, key id, string msg)
    {
        // here we get the owner and the creator of the sender (msg received from)
        key msg_owner = llGetOwnerKey(id);
        key msg_creator = llList2Key(llGetObjectDetails(id, [OBJECT_CREATOR]), 0);
        
        // here we compare the owner and creator of the sender to the owner and creator of
        // the receiver 
        if ((msg_owner == llGetOwner()) && (msg_creator == llGetCreator()))
        {
           llSay(0, "Hi! I am good thank you");    
        }         
    }
}

another thing to consider.  The example receiver is listening for everything on the channel.  A thing that some creators do is to also filter the listener to a named hud object. An upside is that there is a tiny gain in performance.  The downside with a name filter is that we have to make the HUD No-Modify to prevent the user from renaming the HUD which would break the receiver app

Edited July 1, 2019 by Mollymews
negative

[Erwin Solo]

In your Event: listen( integer channel, string name, key id, string message ){ ; }

just test to make sure the owner of prim being listened to is the same as the owner of the clothing doing the listening. 

in other words compare the result of  llGetObjectDetails( id, OBJECT_OWNER ), which will give you the owner of the sending hud to llGetOwner() for the clothing doing the listening.  

Dynamic channels are a good idea for other reasons, but inadvisable as a security technique. 

 

 

[Runie Xue]

Easy solution:

on this line:

llListen(app_channel, "", NULL_KEY, "");

change to this:

llListen(app_channel, "", llGetOwner(), "");

 

After this your script only hear your key and other people on same room not have any problem with that, also you can make more filters inside the event of listen but with this i think works fine.

[Mollymews]

14 minutes ago, Runie Xue said:

llListen(app_channel, "", NULL_KEY, "");

change to this:

llListen(app_channel, "", llGetOwner(), "");

the Owner key and the HUD Object key are not the same

changing the filter to llGetOwner() means that the receiver is now listening only for the key of the Owner and will not receive any message sent by the HUD