Can llMessageLinked send message to attachment worn on sitting avatar

[Xxaxx Constantine]

I am trying to use llMessageLinked with LINK_SET to send a message to a script contained in a prim being worn by the sitting avatar.

Is this possible?

I know the avatar is "linked". But is this a special kind of linking?

I haven't been able to make it work as yet, and I can't tell if this is do to errors in the script, or perhaps because it's not even possible.

Just trying to make a hat color changer that you sit on to activate menu with color options.

Thanks for any clues.

[Rolig Loon]

The avatar is not linked to an attachment.  The attachment is worn by the avatar, which is something entirely different.  So no, you cannot communicate to an attachment using llMessageLinked unless you are sending your message from one prim of the attachment to another prim of the same attachment.

Try using llSay, llWhisper, or llRegionSayTo, each of which will work well and serve a slightly different purpose.

[steph Arnott]

Im not entirely sure I understand you, If you sit on the hat and you have an attachment with the menu in it, you have to do as Rolig says, If you using a sit function with a touch event I would just trigger the menu with the touch event. I.e.. You click the hat and the touch triggers the menu. Which is just one script in the hat.

Not sure if that very clear.

Added: You would need to split the touch sit and touch menu events into 2 states i.e. state one touch hat and sit, then goto state two touch hat menu, unsit back to state one.

BTW, you will need to get the avatars id so only they get the menu and  record their id while they seatted, otherwise everyone will get  a menu present to them and everyone who touches while your seated will keep giving you the menu.

Clear as mud.

 

[Innula Zenovka]

I would suggest llRegionSayTo(uuid, channel, msg) for this. That's because, if the uuid is that of an avatar, then items the avatar is wearing or sitting on (and only those items) can hear the messages, provided, of course, they're listening on that channel.

[Xxaxx Constantine]

Two very excellent responses.

I appreciate the fast and able advice.

Based on reading some of the posts in the forum when using chat between scripts I use llRegionSayTo if I know the UUID, otherwise I fall back on llRegionSay.

Seems to me that llWhisper requires the server to dynamically assemble a list of "nearby" objects whereas the llRegionSayTo and llRegionSay both use previously assembled lists created by the llListen.

Course, this all is predicated on the fact that I have never had call to listen on the PUBLIC_CHANNEL.

Anyway, thanks again for the heads up about attached and helpful reminder about the SayTo.

 

[Rolig Loon]

---

Xxaxx Constantine wrote:

[.... ]

Seems to me that llWhisper requires the server to dynamically assemble a list of "nearby" objects whereas the llRegionSayTo and llRegionSay both use previously assembled lists created by the llListen.

[ .... ]

---

I agree with Innula that the best choice is llRegionSayTo.  I mentioned llSay and llWhisper only for completeness.  There are no "previously assembled lists" created by llListen.  The llListen function serves two purposes.  First, it opens the channel you have defined, providing a trigger that will activate a listen event elsewhere in your script.  In that regard, it's like llSetTimerEvent or llSensor, both of which also serve to give the script a way to receive input that will activate an event.  Second, llListen offers filters, ways to narrow the pipeline so that your script doesn't need to hear everything that it said.  Once you have put llListen in your script, the servers will pass your script anything that is said within range on the channel you have chosen.  If you have filters in the llListen, they only pass you messages that pass those filters. 

llWhisper, llSay, llRegionSay, and llRegionSayTo each limit the way messages are sent by defining the physical range over which they can be heard or by defining exactly who can hear them, so you can think of them as filters on the sending side of your script.