HUD controls

is there a way that you can make a HUD item talk to another item you are holding IE to a gun unsafe or safe modes or semi or burst fire i know there is a way i just cant figure it out...... and someone help me?

thank you in advance

Yes and no.

The fastest way would be to use llMessageLink(); , but since that only works with linked objects, it will not work with what you want to do.

The other methods would be to use llWhisper, llSay, llShout, or the email function.

All will work, but are slower. Also, by using one of the first three, you are forced to leave a listen channel open all the time, and that causes lag. =C

how would i set up a E-mail for that dont they change keys everytime i rez them? and these are for many people so i dont think LL Wisper will owrk

Your right about the emails, the key will change. If you want to communicate with objects only owned by the same person, ie the person owns the hud and the person owns the object you wish to communicate with, use an encryption function that uses the owner name in it as your channel. I would suggest using negative channels as well, as only prims can speak on negative channels unless a player uses a dialog box, then technically the player is speaking on the negative channel, but it still works. Look at the encryption functions and see if they help you. llGetOwner() would be a good idea, imo.

llSay() should work just fine.

There are a few ways you can filter the listen without needing encryption. The simplest is almost certainly to set up an llGetOwnerKey filter in the listener. It also stops people controlling each other's toys with their own HUDs if there are two or more in the area.

i also use is having the object give the owner key in the message.

 llSay(101010,(string)llGetOwner() + "|" + "activate");

and then for the listening end just have it parse the list.

 
list temp = llParseString2List(message,["|"],[]);
if(llList2Key(temp,0) == llGetOwner())
{
	 if(llList2String(temp,1) == "activate")
	{
		 //Do so and so
	}
}

and if you want to go one step farther you could also encrypt the string before sending it with either llXorBase64StringsCorrect or llString2Base64.

Leaving a listener open on a non-zero channel does not cause any significant lag.

The listener hadling code at the server end is only triggered when there is a message sent on that comms channel.

This is a problem on channel zero since there is always comms chatter there, which would have to be processed by every single script listening on ch#0.

However for the other channels (try to pick an uncommon one so you don't happen to hear people telling their pose balls to show and hide all the time) the lag caused is really negligible.

I agree, if you can avoid doing so, don't keep a listener open, but they really aren't as bad as some people seem to think.