Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Getting a script to listen to itself only

Dnel DaSilva
Master Xessorizer
Join date: 22 May 2005
Posts: 781
05-28-2007 00:52
I'm working on a script that when touched will chage the colour of itself using llDialog.

All attachments listen on the same channel as they will also listen for commands from a HUD. I have the HUD working perfectly.

My problem is when a button is touched is says a command that all the attachments listen for, since they all use a common script, and of course they all hear it. I'm trying to figure out a way to get the script to listen to itself only and not commands from the dialoges in the other attachments.

I have tried to filter them out by key, but the key I can get from the prim is not the key of what is saying the commands, I suspect this is because it is the script that is actually doing the talking, not the prim. There is no reliable way to get the key of the script, as getting the key of an inventory item is not possible if you do not have full perms on the script, which an end user will not.

I can do this using a second listen generated randomly at state entry and on rez, but I am trying to avoid more than one listen.

Any tips would be greatly appreciated.

EDIT: Well I know why the key isn't the same, becasue its the avatar pushing the button saying it, doens't help me though as I can not filter by owner, as all attachments will ahve the same owner.

I thnk I'm stuck with using a second listen.
_____________________
Xessories in Urbane, home of high quality jewelry and accessories.

Coming soon to www.xessories.net

Why accessorize when you can Xessorize?
Marcush Nemeth
Registered User
Join date: 3 Apr 2007
Posts: 402
05-28-2007 02:34
A prim can not hear it's own whispers (though I think a prim can hear itself if the message was sent in llRegionSay), so it might be an idea to set up master and slave scripts. The master script just talks and reacts according to the input it gets from touching, dialogs, whatever, while the slave scripts can only listen.
To circumvent the script listening to other scripts, put it (and the listen scripts in other prims) on a seperate channel. There are litteraly millions of channels available :)
Newgate Ludd
Out of Chesse Error
Join date: 8 Apr 2005
Posts: 2,103
05-28-2007 03:24
All you really need to do is qualify the command in some way so that only the specific object listening for it will react. There are numerous wasy to do this, seperate channels for each is common, but another is to prefix all commands with who they are destined for. This can be subtly i.e. prefix with a single charcater that defines its target or coudl be the whole name, it really depends on what you are most comfortable with scripting up.

Also remember that the attachments dont necessarily have to hear everything that is selected on teh dialog. The HUD could receive all of the Dialog processing on one channel and then forward on exactly what is required on the channel the attachments are listening too.
_____________________
I'm back......
Qie Niangao
Coin-operated
Join date: 24 May 2006
Posts: 7,138
05-28-2007 04:08
Well, I think you *should* use two different listens in the attachments, one for the HUD and one--on a temporary, random channel--for the touch-triggered dialogs. When the dialog is done, you can llListenRemove() the handle returned by the corresponding llListen() and open a new one the next time the prim is touched.
Dnel DaSilva
Master Xessorizer
Join date: 22 May 2005
Posts: 781
05-28-2007 11:49
Thanks for the replies. Master and slave scripts won't change anything for me as the 'slave' that listens will still hear everything on the channel, splitting the script up won't change that. Also, whispering won't help becasue all the attachments (on one av) will be well within the 10m range of a whisper.

I was thinging of qualifying the command, but since I can't append anything silently to a dialog button (there is one unique variable per script) it would have to show in the buttons, and would not look right, the alternative would be to append a period or coma or dash or something relatively unatrusive to the button, but that would require a bit more work and still show something on the buttons. Calling the command back to the HUD for filtering encounters the same issues as well as the fact that the touch options are intended to be used as an alternative to the HUD.

From: Qie Niangao
Well, I think you *should* use two different listens in the attachments, one for the HUD and one--on a temporary, random channel--for the touch-triggered dialogs. When the dialog is done, you can llListenRemove() the handle returned by the corresponding llListen() and open a new one the next time the prim is touched.


This is actually what I did do last night. I hate having to use more than one listener so I call the listen on touch then send the dialog, then remove the listen after the change is done. Unlike a lot of jewelry makers in SL I pay a lot of attention to my scripts, never a channel 0 listen and I filter them as finely as I possible can without breaking them and have a bling script that actually doens't update 20 times a minute, well actually it never updates whle running ;)

Thanks again, hopefully this thread is of use to others that have similar questions.
_____________________
Xessories in Urbane, home of high quality jewelry and accessories.

Coming soon to www.xessories.net

Why accessorize when you can Xessorize?