Particles & HUD Question

I was trying to find a way to make a HUD device activate Particles on another.

The LSL Wiki says HUD devices cant activate particle effects themselves, but can a HUD cause another device to spit off some particles?

I'm totally stuck where to go.

Any ideas?

yes, you can do it my messages between attachments, have a button on your hud when you clikc it, it will send a message threw all your attachments and have something on your hand that will throw out the particles,

i cant think of the code atm but is is very simaler to linked messages

off teh top of my head....

read up on the LSL communications section of the LSL wiki. You can assign objects a chat channel that uses the same chat as avatars do. you define a dedicated channel, and any objects with the same channel will listen in.

not sure how it works with HUD objets but it works with normal objects.

http://wiki.secondlife.com/wiki/Category:LSL_Communications#Chat

Do you know how to make an attachment that would start/stop particles by typing, say: /1 on, and /1 off?

Then that's all your 'HUD' device needs to do... say the words: "1/ on", and "/1 off". The HUD can use the usual culprits: llSay, llShout, llWhisper, or llDialog. The point being that there's nothing especially mysterious about its being a HUD device. It's just an object - a cube if you like - that you wear on a HUD point. In every other respect it's just a regular object.

basically, that "/1" is shorthand for "broadcast this message on channel 1". its like radio. some use large numbers for less risk of 'interference', such as channel 6238 or so.

listen on channel 1, for owner key, parse message in listen event

default{
  state_entry(){
    llListen( 1, "", llGetOwner(), "" );
  }

  listen( integer vIntChannel, string vStrName, key vKeySpeaker, string vStrHeard){
    vStrHeard = llStringTrim( llToLower( vStrHeard ), STRING_TRIM );
    if (!(llSubStringIndex( vStrHeard ), "on")){
      //-- code to turn on particles
    }else if (!(llSubStringIndex( vStrHeard ), "off")){
      //-- code to turn off particles
    }
  }

  changed( integer vBitChanges ){
    if (vBitChanges & CHANGED_OWNER){
      llResetScript();
    }
  }
}

Though technically, you'd be better off using a negative chat channel if you never intend to speak the commands (only have it HUD controlled).
If you define integer CHAN=100 at the top while your testing / developing it and always use CHAN, it's easy to change that one line to -100 when you're ready.
It's a lag thang. If I remember rightly negative channels are pre-filtered (avatars can never hear them) so cause less lag.

slight correction, av's can't speak on them... natively.... though they can using llDialog, and I believe on modified clients it'd be possible.
/1 chat works
/-1 chat doesn't

Av's don't hear any channel other than 0 (or debug channel, if you have that option turned on).

negative channels are good for avoiding casual avatar messages, since chattable commands must use positive ones. (llDialog is the exception). so may be less crowded.... with avatar chat anyways...

if you can't filter who or what you are listening to, it's best to use key words, to prevent parsing messages you don't need to... for example if you're listen to a command from anyone, "command" may not be the best choice... but "productName command" might work out better, since you can test for productName, and THEN if it's there, check for the specific command... a popular example would be 'ao on', 'ao off', 'ao reset' etc..

Also, never script to listen on 0 (default) if you can help it. Anything listening to channel 0 is listening to every wrod in chat and comparing it to its triggers. MAJOR lagsville.

SWEET! Thanks for the replies! Time to get to work now that I know which direction is which.

Sure, a simple say command with a listen channel.

you mean like post #6?

OMG!!! I've been searching for info on how to make HUDS do stuff i can easily do with chat commands for ages! This is soooo simple!!! This is the first time in SLS I've found a solution that's not hideously complicated and required pages of scripts that totally baffle me.

Thanks for posting this message!!! It's ended so much frustration!!

^^ KAT.

there's this DISTURBINGLY simple script that makes huds SUPER easy to make.

The premise goes like this. "Say the name of the prim that was touched". you make your hud, place this script in the core, and then, if you have a button prim on your hud (unscripted) that is named "open" when you touh it, the hud will say "open"

ANyways, here's the code.

----------------Hud Script------------------
integer hudChan = -12345;

default
{
touch_start(integer total_number)
{
llSay(hudChan, llGetLinkName(llDetectedLinkNumber(0)));
}
}
----------------------------------

Then you just do a filter on your listen in the other object. Remember you want to listen for object whose owner is the same as the listening object's owner. Don't filter your LISTEN by "owner key"... (your hud is not you, the listening object can tell the difference). Just lead off your listen event in the destination object, with this:

----------------Listening Device Script------------------
integer hudChan = -12345;

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

listen(integer channel, string name, key id, string message)
{
if (llGetOwnerKey(id) != llGetOwner()) return;
// ... remaining "on listen" behaviours ...
// for the moment we'll have a simple demo
llSay(0, "Hey! \"" + name + "\" just said \"" + message + "\" on channel " + (string)channel);
}
}
----------------------------------

As an aside, you actually CAN use particles from an HUD attachment (or you could as of about a year ago; I haven't SEEN any release notes about it), but doing so doesn't make any sense because the particles are emitted in-world from the origin of the region (global <0.0, 0.0, 0.0>.