"Resident" appended to names when Isabel Schulze's PonyLife V2.0.2 hud worn

[Chorazin Allen]

Original report from Carina Asbrink, see Kokua bug ticket #529

The viewer user is wearing the locked PonyLife hud with hearing restrictions enabled.

The speaker is using normal speech (ie NOT going through a renamer of any kind), has a * Resident login name and does not have a displayname set.

When the viewer user hears speech interpreted by the hud, the speaker's name has 'Resident' added to it. See attached screenshot. The first and third lines are the avatar speech. The second and fourth lines are generated by the PonyLife hud.

I bought the hud for testing and can pass it over if desired.

[Marine Kelley]

Could it not be the object renaming itself before and after speaking, exactly like renamers or my RR gags ? I don't remember having made the viewer append "Resident" anywhere in the RLV code.

[Chorazin Allen]

Yes, it probably is the object renaming itself, however I'm assuming this is newly observed behaviour with 2.9.24 and the spurious "Resident" would have been noticed previously.

A scenario that seems likely is that the object names itself "XYZ Resident" and prior to 2.9.24 the viewer was stripping off that "Resident".

Carina plans to try it with another similar hud and report back.

[Chorazin Allen]

replicated with this simple script - I'll next go back to 2.9.23.2 and try there

default { state_entry() { llListen(0,"",NULL_KEY,""); }

listen(integer channel, string n, key k, string s)
{
    string original=llGetObjectName();
    llSetObjectName(n);
    llOwnerSay(s);
    llSetObjectName(original);
}

}

Gives

[04:34] BaneMistress: test <-- the avatar speaking [04:34] BaneMistress Resident: : test <-- the object speaking

[Marine Kelley]

Alright, then I'll look into it soon.

[Chorazin Allen]

I was wrong - it's not new in 2.9.24 - same thing happens with 2.9.23.1

[Chorazin Allen]

Finally for now, another test run with 2.9.23.1

[05:00] SubListen & SubSpeak HUD v3.02: : First use, resetting scripts!

[05:00] SubListen & SubSpeak HUD v3.02: : Reset to all scripts!

[05:00] SubListen & SubSpeak HUD v3.02: : RLV Version: RestrainedLove viewer v2.09.23.01 (5.1.4.39411)

[05:01] SubListen & SubSpeak HUD v3.02: Locked by Selene Annamemnon

[05:04] BaneMistress: test <--- unfiltered speech

[05:04] SubListen & SubSpeak HUD v3.02: - Listening restricted to word list

[05:04] SubListen & SubSpeak HUD v3.02: - Listening restricted to word and letter list

[05:05] BaneMistress Resident: … <-- this was the avatar speaking, but within the chat Resident is not printed although it appears in this copy/paste

[05:05] BaneMistress Resident: : -e-- <-- object speech: the Resident here did appear in chat history. I'll upload a screenshot in a moment

[Chorazin Allen]

2.9.23.1 with SubListen/SubSpeak hud

[Marine Kelley]

I've just tested, although we do see "Resident" in the name of the object imitating the avatar's username when speaking, it looks like this is intended behavior because looking at the "process_chat_from_simulator" function, the "from_name" variable already includes the "Resident" part.

Moreover, if you create an object and put this script inside it :

default {
  state_entry () {
    llListen (0, "", NULL_KEY, "");
  }

  listen(integer channel, string name, key id, string message) {
    llOwnerSay (name);
  }
}

... then when you speak the object says your username on the chat, and surprise it does contain the "Resident" part as well. So in my view, if it is done this way in LSL, it should be the same way in the viewer to stay consistent.

Now of course, I could remove the "<space>Resident" part in "from_name" in the viewer, but it's probably there for a reason.

[Chorazin Allen]

I think there's a higher level question here - when an object is using the name of a nearby avatar, should the object name display follow the same rules as the avatar so that the two appear the same or not?

Your example script is slightly away from the topic of the bug report - this is about the object's name as shown in chat not the content of what it chats. See my sample script and screenshots.

[Marine Kelley]

I know the script I showed is not completely related to the issue as it merely displays the username of whoever is speaking. My point was to show that in LSL, "Resident" is automatically appended.

Now as to whether an object imitating the name of an avatar should drop the "Resident" part, probably. I just wanted to point out that I don't like it that the viewer would take a different direction than one that was seemingly taken by LL on purpose.

[Chorazin Allen]

Agreed about the first point, not showing Resident looks like a last-moment decision in the chat window logic - if you flip to compact view you'll see 'Resident' appear where it was previously suppressed, so the decision not to show it is very late in processing and it can reappear over changes in display layout.

We are indeed talking about doing something different to the standard LL behaviour; but then the whole of RLV is different to standard LL behaviour. I think the question is more whether objects spoofing nearby avatars should look more convincing (same name processing, maybe also the avatar icon) or stay the same as the standard viewer. I see it as "is this desirable for RLV?" question more than a "should it be the same as LL?" question. I'll leave it there... over to you! :)

[Marine Kelley]

Resolved in 2.9.24.1, an object which name ends with " Resident" with the space will have this part removed in the chat window no matter the RLV restrictions currently in place.