llRegionSayTo() to a HUD instead of avatar?

[primerib1]

Okay so I'm creating a pair of HUDs, to be worn by different avatars. Let's say HUD-G and HUD-P.

I noticed that if HUD-G sends a message to the avatar wearing HUD-P, responses from HUD-P comes from the ID of HUD-P instead of the ID of the avatar.

If HUD-G has grabbed the ID of HUD-P, can HUD-G do an llRegionSayTo() directly to HUD-P (using HUD-P's ID, on a very negative channel) instead of doing a SayTo to the Avatar wearing HUD-P?

What are the benefits / drawbacks?

[Love Zhaoying]

I'd say yes. I would use this for 2 HUD's to share Linkset Data.  Benefit!

Don't see a drawback..

Benefit of llRegionSayTo() is, no throttling..

*I hadn't used this but planned on it from a discussion here.*

Edited January 14, 2023 by Love Zhaoying

[Qie Niangao]

I'd think the main benefit of selectively addressing the other HUD specifically is that each sent message won't wake up every other listen handling script the avatar is wearing.

Some avatars wear a lot of listen handling scripts.

Edited January 14, 2023 by Qie Niangao

[primerib1]

8 minutes ago, Qie Niangao said:

won't wake up every other listen handling script the avatar is wearing.

Ahh that's a really good point! Thanks!

[Qie Niangao]

Just now, primerib1 said:

Ahh that's a really good point! Thanks!

I am so sorry, I should have been more careful. You even mentioned "a very negative channel" and that should have woken up my sleepy brain: AFAIK, scripts waiting on a listen() event are only "woken" if they called llListen() on the same channel as that on which a message is sent. So... never mind, and again: sorry.

[Fenix Eldritch]

Qie's comment is still relevant though in the event that the avatar is wearing an unrelated script that just so happens to be listening on the same channel. While potentially rare, it's not impossible.

Sending the message to the avatar is a nice shorthand to target all worn attachments listening on the specified channel, but talking directly to the specific attachment removes any chance of outsiders picking up the message (if that is important for your application, it may or may not matter).

Edited January 14, 2023 by Fenix Eldritch
removed irrelevant aside

[Quistess Alpha]

For what it's worth, sending a message directly to the avatar is often a nice/(The only? IIRC llGetAttachmentList doesn't return HUDs) way to discover the existence of a HUD they're wearing. After you've grabbed the key, you can switch to direct communication with the HUD itself.

Tangentially relevant, if you get a response from a HUD and want to know the avatar, llGetOwnerKey(listen_ID_parameter); is very handy in these sorts of systems. Since avatars own themselves, it can even be used to differentiate HUDs/avatars and is safe to use without checking whether the ID is a HUD first .

[primerib1]

9 minutes ago, Quistess Alpha said:

if you get a response from a HUD and want to know the avatar, llGetOwnerKey(listen_ID_parameter); is very handy in these sorts of systems.

Oh wow, did not know that! Thanks!!

 

[Fenix Eldritch]

15 minutes ago, Quistess Alpha said:

Tangentially relevant, if you get a response from a HUD and want to know the avatar, llGetOwnerKey(listen_ID_parameter); is very handy in these sorts of systems. Since avatars own themselves, it can even be used to differentiate HUDs/avatars and is safe to use without checking whether the ID is a HUD first .

Aye, this is indeed handy - but be aware it only works when the ID is still in the region. If you hear something from across a region border, llGetOwnerID will return the input ID, giving a false positive on the is-avatar-test without further examination.

[Quistess Alpha]

7 minutes ago, Fenix Eldritch said:

If you hear something from across a region border

+1 for llRegionSayTo()

[primerib1]

10 minutes ago, Fenix Eldritch said:

Aye, this is indeed handy - but be aware it only works when the ID is still in the region. If you hear something from across a region border, llGetOwnerID will return the input ID, giving a false positive on the is-avatar-test without further examination.

In my case, the flow is like this:

1. HUD-G whispers "tellme:<codeword>"
2. HUD-P that matches the <codeword> responds, but *only* if the avatar owning HUD-G is in a list of allowed avatars.

If llGetOwnerKey() doesn't return an avatar ID, then it's very unlikely the avatar ID is in the list of allowed avatars, and the cross-sim whisper will be ignored as a figment of imagination 😎

[Lucia Nightfire]

8 hours ago, Quistess Alpha said:

For what it's worth, sending a message directly to the avatar is often a nice/(The only? IIRC llGetAttachmentList doesn't return HUDs) way to discover the existence of a HUD they're wearing.

Until https://jira.secondlife.com/browse/BUG-232687 is implemented.