Make object listen only to avatars?

I evidently have brain diminishing stupiditis. How to make an object listen only to avatars and ignore other objects chatting on the same channel?

Adam

obtain the key of the speaker and check its size to determine its avatarness.

Ok, so my brain's not so diminished after all: that's what I thought, but it's not very graceful really is it? Would be nicer to have 'integer type' in the parameters of the llListen call, as in llSensorRepeat. Anyway, thanks Squirrel.

The owner key of an avatar is always (I think) the same as the avatar key. Maybe doing something like this would be easiest...

    listen (integer channel, string name, key id, string message)
    {
        if (llGetOwnerKey(id) != id)
        {
                  llSay (0, "avatars only! stop talking to me, bozo!");
                  return;
        }
...

Testing for a non-zero vector should be faster than comparing two keys.

What, Deanna? Sorry, but can you say more about why this is a unique test for avatar-ness?

Absolutely right but.. uh.. which vector would listen look at and test vs zero?

EDIT: Oooops, had it backwards!

//temp.esl	2008-01-29T19:16:52.505500Z
//Created by: Jesse Barnett
//Copyright: None; Use it as you please!

default {
	state_entry() {
		llListen(66, "", "", "");
	}
	listen(integer channel, string name, key id, string message) {
		if (llGetAgentSize(id) != ZERO_VECTOR)
			llOwnerSay(message);
		else {
			return;
		}
	}
}

Even easier, since ZERO_VECTOR evaluates as FALSE:

if( llGetAgentSize( id ) )
{
// id is that of an avatar
}

Do we know that llGetAgentSize is less expensive than llGetOwnerId plus a key compare?

Unfortunately, 'llGetOwnerKey(id)' also returns the value of 'id' if called on an object not in the sim. So this may return false positives.

Also, llGetAgentSize() returns ZERO_VECTOR for agents not in the sim. So you may get false negatives.

The most sure way to test whether a speaker is an avatar or not is probably to do a 'llRequestAgentData(id, DATA_NAME)', but unfortunately that requires waiting for another event and implementing some kind of timeout. It might be that llGetObjectDetails() might help here too, but I'm not sure.

And if the dataserver is running slower than expected, that too would essentially return a false negative.

Hmmm... could try llGetObjectDetails( id, (list)OBJECT_CREATOR ), which would return a list containing NULL_KEY if id were an agent, or just a null list if id is outside the sim, so at least this method should distinguish between the two, even if outside-of-sim agents and objects are still indistinguishable from each other.

BTW, sorry for the confusion above, all. I was over-succinctly comparing Squirrel and Meade's methods.

just to be odd, I have no idea if it'd work, or if it suffers the same false negatives for out of sim avs (likely), but it's an idea...

if (llGetAnimation( id ) != ""

another to try would be object details and object creator (null for av's)

and I'm not sure what llGetObjectPrimCount would returns on an av, could be 0 could be every attachment....

This is really interesting. I usually just assume alot, like that since the agent just triggered a listen event, I expect the sim to be able to do llGetOwnerKey...

And it kinda seems like if it couldn't do that, I wouldn't expect it to be able to do llGetAgentSize either...

Yup, returns a blank string for Avs outside the sim, so it'd give false negatives.

Is there an echo in here?

Returns 0 for Avs... but curiously, also returns 0 if passed the key of an attachment in the same sim. And, of course, also returns 0 for objects outside the sim, so that's 2 possible types of false positive.

depends, what's the behavior today for avatars and objects talking accross sim boundries? (I say today because I'll be damned if I remember what it is now, only that I remember it having changed in the last 4 years at least once)

/me had a new JIRA suggestion for llDetectedType all ready to submit so that people could easily do what the OP wanted. Then, for some reason, I checked the wiki and found that it's already there.

I know the OP was looking to filter for avatar types and not have the listen event triggered at all for objects but, lacking the ability to do that, isn't this exactly the thing to use?

http://wiki.secondlife.com/wiki/LlDetectedType

No, because the llDetected* functions only work inside sensor, touch* and collision* event handlers, not listen. What would be needed is a function to which one can pass a key (i.e. the id parameter of the listen event handler) and have it return the type of the associated object/avatar.

Oh yeah.. There's that whole "it doesn't work" bit. That would be a problem, wouldn't it?

Never mind. Ignore me.

s'ok meade, I had the same thought before realizing there's no detected* in listens, I even considered firing a sensor, but that seems like a lot of work for a simple problem.

really, the simplest solution is just:

if (llGetOwnerKey(id) != id) return; // bail out, speaker is not a person.

This screens out all objects.
The owner of an agent, is the agent. The owner of an Object, must be an agent.
If speaking id is the same as the owner of the speaking id, then yes, it's an agent.

conversely, if you want to screen out all chat that is not from the owner's objects (like huds)

if (llGetOwnerKey(id) != llGetOwner()) return; // bail out, speaker is not my owner or owned by my owner.

This filter has the upshot of also allowing llDialogs and manually typed commands from the owner. (whereas, the llListen(0, "", llGetOwner(), ""; type of filter will NOT hear huds!)

Except it was established:Adding a bit to the "echo" if llGetObjectDetails() ends up working the way I think is intended after the fix for SVC-774, it should accurately discriminate between objects and agents up to 96m away in another sim. But that still leaves a 4m thick arc in that neighboring sim from which a shouting agent and an llShout()ing object couldn't be distinguished.