This seems smarter. I like to think things like this will be easy but often get surprised by it not being. XD
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!)
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!
Just do it all the time? It’s not going to kill anybody, is it?
I think a user side toggle to display last names may be the way to go here.
1 Like
Space efficency is an issue already, is the problem with that.
Resurrecting this topic a bit.
With adding initials, what to do with names such as: Aya of Mirion
Either we would:
- Pick the first letter:
Aya o. - Pick the first letter and capitalize:
Aya O. - Pick the first letter that is capitalized:
Aya M. - Make locale away handling, where words such as
of,the, etc. is treated different:Aya of M.
None of them feels that great.
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.)
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
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.
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.
Ah yeah! That was the method I was referencing!
There were four or five Lotuses in the Park today. Was any progress ever made on this?
1 Like
Yes, this is definitely getting to be a bigger issue as time goes on.
This feature request is a bit of a pain to implement 
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
- You connect through mobile and go to the park
- You switch tab for a while. The mobile is temporarily disconnected
- Two people named
Lotusappears and starts talking - You switch back to the game tab on the mobile device.
- The client reconnects and resynchronizes
5.1. The client fetches missed events
5.2. The client fetches and updates the InRoom list. - 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.
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.
Yes, I agree. The solution of matching name detection is overly complicated. Let’s scrap that one.
A toggle could work. (Would it be retroactive - as in switching the naming of ALL events in the chat log? Or should it just affect the events when they arrive?)
Another thought that I had was if this can be solved with the Nickname / Alias feature?
Instead of the system trying to render unique names, maybe you should pick them yourself?
nickname Lotus Alpha = Lotus A.
And you have defined a nickname for a character, we show that one instead?
1 Like
The nickname idea isn’t a bad one Accipiter! Why not both? It would have to be retroactive since, the whole point is to gain clarity when the user is confused, I would assume.
1 Like
Personally, I prefer the checkbox option. Having to input a nickname for everyone that has duplicates that I plan to interact with sounds like it’s going to become tedious very quickly… However that doesn’t mean I wouldn’t take advantage of having an alias for other users, just that I don’t think it would be a good ‘duplicate name’ solution for me.
On a side note, I do hope that the alias/nickname command tab-complete searches the awake list, there are some gnarly names folks have been using that somehow look like completely different fonts.
Another alias side note is tab-complete when typing. Does commands search through your aliases now as well? If so does it translate that to the actual name when it’s being sent in the body of pose/say/message/whisper/etc? I can just see me having an alias for someone and tab-complete hits on that without me realizing and suddenly I’m sending a pose containing the alias instead of the character’s actual name…