How do I get My HUD to Stop Listening to Other HUDs, on the same channel???

I have a HUD and it works great except when someone else has the same HUD I get there Menu as well as mine.

What can I do??

Thank-you in advance for the help!

Is this a scripting question? If you have access to the HUD's main script you can begin the touch_start event with a conditional that compares llDetectedKey to llGetOwner and only proceeds to display the dialog if the keys are the same - llDetectedKey checks who initiated the touch_start event, llGetOwner checks the owner, if they're the same than the owner initiated the event, so proceed, otherwise send some kind of error message or do nothing.

Of course if other people's HUDs are on the same channel and don't have this form of security built into them then there's nothing you can do to avoid getting their dialogs as well aside from using a less common channel for your own.

I hope that helped

Which HUD is it?
The HUD must be incredibly badly written for this to happen.
A dialog can only be displayed to a specific AV by Key, so for you to get their dialogs would require that the HUD is chatting its command to activate the Dialog.

If you have access to the source then I suggest you look at exactly how the dialogs are called up and secure the activation correctly.

Yes, this is a scripting question, ita a HUD i made for an item I made to make it much easier to use. Thank-you for your reply, will try it out when SL gets back up.

As I said before it is impossible for you to receive someone elses Dialog as it is sent to a particular AV. What is actually happening is that the script controlling the generation of the dialog is being triggered by 'cross channel interference'

So is it the HUD that is getting the wrong data or the object? or both?

There are several methods to secure the data, you could include the owner key in all request/responces so that the scripts can reject any that doesn't match (As per Jessica's suggestion) or you could use the owner name or key to generate a semi unique channel number to be used by both the HUD and the Object. Both systems are reasonably easy to implement, the former probably easier than the later. In both cases a change of ownership should be catered for.

In the listen evet, use something like

if (llDetectedOwner(id)==llGetOwner())

EDI: Error. Corrected a few posts below.

So your HUD will respond only if the message received comes from your own objects

I think llDetectedOwner will only work in side touch sensor or collision type Items, not listens.

Simple solution is to use a variable to hold the channel number. On rez from any state, call the random number function to get a new channel number and store that to the variable. Use the variable in your calls to llDialog or llListen.

I do this for normal objects with menus, in case I have more than one rezzed. However, this shouldn't happen for objects owned by different people, as mentioned above.

Also, you should specify llGetOwner() as the id parameter to llListen() -- otherwise, your script is much more run-time expensive than it should be. This keeps you from hearing from objects owned by anyone else.

Newgate is correct that llDetected...() calls ONLY work for 'touch' events. Instead use the parameter to llListen to screen out other speakers. (Which shouldn't be necessary ...)

However, the LSL page for llDialog() doesn't say anywhere that the chat is private (sent only to owner). It's a testable hypothesis.

I think you have missed a point though Learjeff. Although I agree with you entirely a random channel in this instance wont help as there are two seperate units that must communicate.

Yes, I missed the point that the HUD controls another object, in which case a random channel would NOT work!

Specifying the owner in the call to llListen() would sort this out -- but your HUD would control all your objects, not just one of them. If that's what you want, then all you need is passing llGetOwner() to llListen().

If you want specific control for different objects via the HUD, then you need an acquisition protocol. All your controllable objects would listen on a well know channel. Each would pick a random channel for its own messages.

The HUD would have an "update" or "acquire" button. When pressed, it sends out the "Tell me about YOU" message. All units respond and tell the HUD their specific channel number, and perhaps some other text info to identify themselves, or a location.

After that, the HUD can control them all (using the standard channel) or just one (using the individual channel).

Cheers
Jeff

Yes, my mystake. This is the one I wanted to express:

 
listen( integer channel, string name, key id, string message )
{ 
	 if (llGetOwnerKey(id)==llGetOwner())
	 .....
	 .....
}
 

Yes. However, it's more efficient to pass the owner's ID to the llListen call for the special channel. In this case, only the owner's messages will appear, and there is no need to check. More importantly, this is more efficient for the server because it needs to send fewer messages to the script. The server runs faster handling chat and your script runs faster when it gets the message. Win/Win.

Also note that if you're listening for multiple things (e.g., including chat on channel zero -- best avoided but never mind that now), you can test the channel number in the listen() handler rather than checking the owner, to detect a menu message.

Therefore, I'd suggest:

listen (integer channel, string name, key id, string message)
{
    if (channel == my_menu_channel)
    {
        // handle menu messages
        ...
    }
}

The problem will be that unless the HUD button text correlates 1 to 1 with the parameters being sent to the object its wont be the owner speaking but there HUD.

Ah, good point Newgate!

So, checking the channel number should still be best, but passing the owner ID to llListen() would be wrong. Thanks for keeping me honest.

how har is it to filter for owner only in the listen?

llListen(somechannel, "", llGetOwner(), "");

now the chat listened for by the hud will hear the owner
even more you can filter only for the hud's chat from the owner .

llListen(somechannel,"hudname", llGetOwner(), "");

don't use variables to store the ownerkey,call it right from the llListen like above and you'll never even have to worry about coding the HUD to haveto reset on owner change if you , say, gave oneto a friend.

I know Ive been pondering for hours how I could solve my problem to get the root listening to the hud, having a

llListen( channel, "", llGetOwner(), ""); 

command, before I realized it was the hud speaking and not the owner :°|

conclusion: egocentered and lacking empathy