HUD Injector

[SundanceHaiku]

Shin, very, very cool solution! I love the "super secret compartment"!

I'm not sure if this is a problem for OpenSim. On the SL platform, the following line (line 48) sends a null texture to the body receiver:

list linkParamList = llGetLinkPrimitiveParams(1,[PRIM_TEXTURE,f]);

The fix in SL, is to change the link number 1 to 0. Then it works.

I just thought I point it out. Best, Sundance

[ingen-lab]

Thanks, I'll try it in OS to see if it will complain, if not, I will update to 0. I wonder why link 0? there's got to be a technical explanation for that which I'm sure will add to my knowledge base.

BTW-- I was trying to filter the llListen(r2Chan,"","","") on the receiver to only listen to the avatar uuid. Documentation says you simply just put llListen(r2Chan,"",llGetOwner(),"") but that is not working for me. Have you dealt with that before?

[ingen-lab]

Okay, docs says

0 means the prim is not linked, 1 the prim is the root, 2 the prim is the first child, etc. Links are numbered in the reverse order in which they were linked --

maybe the best approach is to just get it from llGetLinkNumber().

[SundanceHaiku]

Oh gosh . . . it's hidden at the bottom: http://wiki.secondlife.com/wiki/LlGetPrimitiveParams

"If an object consists of only one prim, and there are no avatars seated upon it, the (root) prim's link number is zero. However, if the object is made up of multiple prims or there is an avatar seated upon the object, the root prim's link number is one."

Will check on the llListen question.

[SundanceHaiku]

I have the hardest time with that. Even when you first posed the question, I started playing around with some code and couldn't get it to work. Then I realized that I had written about it in the sending & receiving paper.

llListen(r2Chan,"",llGetOwner(),"")

The code works if the message is being sent by an avatar, because the id coming into listener is the avatar. If it's being sent by an object, then the id coming into the listener is the name of the object.

Here's what I wrote. I need to repeat this for my benefit, because it has a hard time sticking with me . . .

"In a HUD situation, it is good practice to check to make sure the message is coming from the owner of the prim. It's possible (but very unlikely in our case), that some other object owned by a different person is using the same channel. You can check to make sure it's coming from the owner (the avatar which owns the HUD) by using this in the listen event code:

if (llGetOwnerKey(id) == llGetOwner())

I had a problem with understanding the "id." I kept thinking it was the owner of the prim. But if a prim (or more specifically, a HUD) is sending the message, "id" is the key, the UUID of the HUD prim. When an avatar is sending the message then "id" is the UUID of the avatar.

In the situation when a prim (a HUD) is sending the message, you can determine the owner, but it can't be done with the llListen function. You have to wait until the listen event is triggered and then use the code above."

[typhartez]

lI confirm for the listener

It's a bad limit of llListen() that you can't specify a list of UUID to listen from, because in most case scripts need to listen from the owner (dialogs) or objects owned by the owner (huds, etc..). The only way, and it is almost a standard, is to listen globally, and filter in the listen event. One way to prevent too much listening, is to associate a channel to the owner key.

Here is my method (used by many others, as far as I could see):

First, I get a UUID which represents my project. Using the copy key of a rezzed object is good enough, then I keep the first 8 characters of the UUID (it's likely it won't reproduce often. Not unique, but rare enough to filter): integer APP_KEY = 0x12345678; // obviously, this is not to be used as is! ;-)

chan = 0x80000000 | ( ( (integer)("0x" + llGetSubString(llGetOwner(), 0, 7)) ^ APP_KEY); llListen(chan, "", "", "");

Then in the listen event: listen(integer channel, string name, key id, string msg) { key owner = llGetOwner(); if (id != owner || llGetOwnerKey(id) != owner) return; ....

2018-03-01 1:20 GMT+01:00 Sundance Haiku notifications@github.com:

I have the hardest time with that. Even when you first posed the question, I started playing around with some code and couldn't get it work. Then I realized that I had wrote about it in the sending & receiving paper.

llListen(r2Chan,"",llGetOwner(),"")

The code works if the message is being sent by an avatar, because the id coming into listener is the avatar. If it's being sent by an object, then the id coming into the listener is the name of the object.

Here's what I wrote. I need to repeat this for my benefit, because it has a hard time sticking with me . . .

"In a HUD situation, it is good practice to check to make sure the message is coming from the owner of the prim. It's possible (but very unlikely in our case), that some other object owned by a different person is using the same channel. You can check to make sure it's coming from the owner (the avatar which owns the HUD) by using this in the listen event code:

if (llGetOwnerKey(id) == llGetOwner())

I had a problem with understanding the "id." I kept thinking it was the owner of the prim. But if a prim (or more specifically, a HUD) is sending the message, "id" is the key, the UUID of the HUD prim. When an avatar is sending the message then "id" is the UUID of the avatar.

In the situation when a prim (a HUD) is sending the message, you can determine the owner, but it can't be done with the llListen function. You have to wait until the listen event is triggered and then use the code above."

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Outworldz/Ruth/issues/25#issuecomment-369430531, or mute the thread https://github.com/notifications/unsubscribe-auth/APytPq5qVos2X0YISj0sKQ6fydN3Hj7Uks5tZz7WgaJpZM4SXXMS .

-- It is easier to disintegrate an atom than a prejudice (Albert Einstein)

[ingen-lab]

Thank you @SundanceHaiku and @typhartez, we are all pretty much doing the same thing with the receivers. Inworld, each avatar wearing Ruth will have six(6) listeners active and with the recommended use of llResionSayTo(llGetOwner(), chan, message) I think she will be more efficient than some trigger/receiver systems that I have examined before.

I am chasing information how I can keep the script active after a hypergrid jump and also a Null Exception error in the older OS libraries especially when it is running under DotNet. I think there are times when the receivers are picking up packets that are empty and the llToUpper() raises an exception error so I added a logic to examine and process only messages that will produce atleast 3 list items.

[typhartez]

@ingen-lab for the hypergrid jumps, maybe it's the issue of scripts not compiling the first time you enter the grid. A workaround is to jump to another region of the same grid, and then the scripts compile and run.

I have a dormant (not running) script for my own project. The script is activated only on demand to avoid consuming region memory when it's not needed. And once I passed the issue mentionned above, I have no problem running it. However, I don't have any workaround to make it work on the fly without a second teleport on the same grid the first time the script is compiled on it.