[Feature] Duplicate first names

Bugs & Features
#1

Hi! For the second time now, I’ve been loafing someplace public and two people with the same first name, but different last names, have been conversing actively. This is rather confusing when the first name is all that’s used in says and poses and such.

Workarounds involve hovering over their name each time either one of them says something, or, as Cuprohastes has suggested, using focus to differentiate the two.

Might I suggest that last names be added for the affected users automatically when first names are duplicated? I’m not sure what other treatment would be intuitive; perhaps someone else could suggest something more elegant.

[Feature Request] Disambiguation of characters sharing first names
[Feature] make surnames optional
#2

Yeah, already been noticing instances where people have the same/similar first names. As bulky as it might be, when more than one of them is in the same room, we may need the client to automatically start making use of last names as well until there is no longer more than one of that name in the room - assuming we don’t just turn last name display always on.

3 Likes
#3

To avoid going straight to adding last names, I was thinking it might be helpful to add last initials when they’re useful to disambiguate. So, if we have “John Allen”, “John Baker”, and “John Brown”, we could do something like:

(There are no Johns in the room at the start of the example)
John arrives. (John Allen has just entered the room)
John says, “Hi!”
John B. arrives. (John Baker has just entered the room)
John A. says, “Hey! What a great name!”
John Brown arrives. (John Brown has just entered the room)
John Baker says, “It’s a John party!”

3 Likes
#4

This seems smarter. I like to think things like this will be easy but often get surprised by it not being. XD

#5

I like this suggestion for the oblique reason that it would be always a small, fun surprise when it happens. (And people will really be thankful for tab completion!)

#6

Oh! I never thought of that. I like that idea.

The technical hurdle I need to overcome, however, is how to “know” when to apply full name (or just initials).

The event in itself contains no info on who else is in the room. The event is basically just who said what and when (not even where).
The client could, of course, on rendering the event, check if the room contains someone with the same name, and rendering it accordingly. But that will not work when scrolling back to stored logs, since the client doesn’t know who was in the room at that time, nor the names of the characters at that specific time.

So, what I will probably need to resort to is; every time someone says something, the backend service must check the names of current room dwellers, and include any ‘duplicate name’ info in the event being sent to the client.

… It will add a bit of overhead. But I don’t think it will be too bad. And I think that it might be worth it!

#7

Just do it all the time? It’s not going to kill anybody, is it?

#8

I think a user side toggle to display last names may be the way to go here.

1 Like
#9

Space efficency is an issue already, is the problem with that.

#10

Resurrecting this topic a bit.
With adding initials, what to do with names such as: Aya of Mirion
Either we would:

  1. Pick the first letter: Aya o.
  2. Pick the first letter and capitalize: Aya O.
  3. Pick the first letter that is capitalized: Aya M.
  4. Make locale away handling, where words such as of, the, etc. is treated different: Aya of M.

None of them feels that great.

#11

I feel like the immediate gains of disambiguation supersedes perfect rules for said system. I think if you can make it flexible and add rules later that we like as we see usability problems in the wild, then we can chase perfection through revision after implementation.

Our starting condition should be clear info, so probably whole names when more than one is present until we start feeding it rules to trim by. (I entirely realize this could mean that some very long names will be posted sometimes, but I don’t see it as a problem. We already have some users with lengthy first names being posted, so I don’t see this as much different.)

#12

Assuming you’re matching them with a regex or something, one trick you can use (if you’re not already) is to make a list of keywords you want to remove like particles and special characters. Then just make a temporary string to match instead, and change anything you don’t like to a special character which the regex will always consider a valid match, like a period or something not allowed in names. You can also try a simplified search first, like taking the first character of each alphanumeric group (counting special characters and spaces as breaks) and looking for matches with those first without capitalization to see if you even get more than one hit (exiting the function if you don’t of course), then compare them more properly after to increase accuracy.

I’m not a programmer though so I’m just spitballing. XP

#13

I think we should select 3 as primary and 2 as backup. So, if there are no capital letters in surname, then start over with first letter.
I’m hoping that shouldn’t be too challenging to program.

#14

If we set the English epithet style naming aside for a second, how are surnames in other languages with multiple words abrieviated, like von Trapp or De la Cruz? As how those are commonly abrieviated could work in the same manner for those kinds of edge cases.

This person suggests that the solution would be to take the first letter from each word, so a character with the last name field of the Little Snack Thief would be shortened to tLST, keeping the capitalization as originally written.

#15

Ah yeah! That was the method I was referencing!

#16

There were four or five Lotuses in the Park today. Was any progress ever made on this?

1 Like
#17

Yes, this is definitely getting to be a bigger issue as time goes on.

#18

Thanks @Windchaser and @Vernon_Otter for bumping.
I will put that on my todo for the next release.

#19

This feature request is a bit of a pain to implement :sweat:

Server side supported match check

While I CAN check, with every event being sent from the server, if another character has a matching name (and how much it matches). And then embed this info as part of the event, so clients could format it correct. Depending on event, the scope for the match check would be different:

  • Room events - Say, describe, pose, ooc, whisper, lead, etc. would match against awake characters in room.
  • Global events - Message, mail, summon, etc. would match against awake characters.

This would be the “correct” way.
But it is a pain.
And it becomes even more painful when events are sent from other microservices, such as the mail service or the roller service want to send events, as they need to request this match info from core service (which handles characters and rooms).

Client side match check

A simpler solution would be to let the client do it.

That means - when the client receives an event, it checks against the InRoom list or the Awake list (depending on event type) whether or not there are other characters with matching names.

This would remove a lot of the additional complexity that otherwise would end up in the backend.

BUT…

It would not be as reliable.
The InRoom and Awake list is not necessarily in perfect sync with the stream of events.

Example

  1. You connect through mobile and go to the park
  2. You switch tab for a while. The mobile is temporarily disconnected
  3. Two people named Lotus appears and starts talking
  4. You switch back to the game tab on the mobile device.
  5. The client reconnects and resynchronizes
    5.1. The client fetches missed events
    5.2. The client fetches and updates the InRoom list.
  6. Depending on the order of 5.1 and 5.2, the communication events between Lotus A and Lotus B might be correctly or incorrectly tagged as matching names.

The question is; would that be too much of an issue?
In most cases, client side detection would be fine. But in some racing cases, and resynchronization cases, it may tag events incorrectly.

#20

You way overcomplicate this. Just make it a single tick box on client side. User can turn it on, show all full names when needed. Turn it off when not wanted.