MantisBT - Zandronum
View Issue Details
0000144Zandronum[All Projects] Suggestionpublic2010-10-28 10:242022-10-15 20:41
Eruanna 
Torr Samaho 
normalfeatureN/A
closedfixed 
98d 
3.03.0 
0000144: Disallow duplicate names (use pseudo-aliases such as Player2, Player3, etc)
The main intent behind this is server administration. I think that servers should disallow any 2 people using the same name, even if the colors are different. This would make it easy on a server admin, for example, if say Player2 was acting out of hand. In the current system, this would put other "Player"s on the spot since such a system does not currently exist. The only way to deal with the offending "Player" is to ban all "Player"s since you absolutely cannot tell who is who.

Additionally, when assigning pseudo-aliases, the game should check of course, if the new name exists, and bump the number accordingly.
No tags attached.
has duplicate 0002996closed  Same Player name causes many issues 
related to 0001676closed  Make kick votes use player ID rather than player's name 
Issue History
2010-10-28 10:24EruannaNew Issue
2010-10-28 11:35Dark-AssassinNote Added: 0000477
2010-10-28 11:59user35Note Added: 0000478
2010-10-28 19:38unknownnaNote Added: 0000480
2010-10-28 19:44unknownnaNote Edited: 0000480bug_revision_view_page.php?bugnote_id=480#r213
2010-10-28 19:56unknownnaNote Edited: 0000480bug_revision_view_page.php?bugnote_id=480#r214
2010-10-28 20:00unknownnaNote Edited: 0000480bug_revision_view_page.php?bugnote_id=480#r215
2010-11-01 05:27AnonymousNote Added: 0000495
2010-11-01 12:04AlexMaxNote Added: 0000500
2010-11-12 18:51AnonymousNote Deleted: 0000495
2010-11-14 10:40user35Note Deleted: 0000478
2010-12-09 18:19AnonymousNote Added: 0000666
2010-12-09 18:24AnonymousNote Deleted: 0000666
2010-12-09 18:57AnonymousNote Added: 0000667
2010-12-09 19:04AnonymousNote Added: 0000668
2010-12-09 19:11AnonymousNote Added: 0000669
2010-12-09 19:18AnonymousNote Added: 0000670
2010-12-09 19:25AnonymousNote Added: 0000671
2010-12-09 19:32AnonymousNote Added: 0000672
2010-12-09 19:39AnonymousNote Added: 0000673
2010-12-09 19:46AnonymousNote Added: 0000674
2010-12-09 19:53AnonymousNote Added: 0000675
2010-12-09 20:01AnonymousNote Added: 0000676
2010-12-09 20:07AnonymousNote Added: 0000677
2010-12-09 20:14AnonymousNote Added: 0000678
2010-12-09 20:21AnonymousNote Added: 0000679
2010-12-09 20:28AnonymousNote Added: 0000680
2010-12-09 20:36AnonymousNote Added: 0000681
2010-12-09 20:42AnonymousNote Added: 0000682
2010-12-09 20:50AnonymousNote Added: 0000683
2010-12-09 20:57AnonymousNote Added: 0000684
2010-12-09 21:04AnonymousNote Added: 0000685
2010-12-09 21:11AnonymousNote Added: 0000686
2010-12-09 21:18AnonymousNote Added: 0000687
2010-12-09 21:25AnonymousNote Added: 0000688
2010-12-09 21:33AnonymousNote Added: 0000689
2010-12-09 21:40AnonymousNote Added: 0000690
2010-12-09 21:47AnonymousNote Added: 0000691
2010-12-09 21:54AnonymousNote Added: 0000692
2010-12-09 22:01AnonymousNote Added: 0000693
2010-12-09 22:08AnonymousNote Added: 0000694
2010-12-09 22:15AnonymousNote Added: 0000695
2010-12-09 22:22AnonymousNote Added: 0000696
2010-12-09 22:30AnonymousNote Added: 0000697
2010-12-09 22:37AnonymousNote Added: 0000698
2010-12-09 22:44AnonymousNote Added: 0000699
2010-12-09 22:51AnonymousNote Added: 0000700
2010-12-09 22:58AnonymousNote Added: 0000701
2010-12-09 23:05AnonymousNote Added: 0000702
2010-12-09 23:12AnonymousNote Added: 0000703
2010-12-09 23:19AnonymousNote Added: 0000704
2010-12-09 23:26AnonymousNote Added: 0000705
2010-12-09 23:33AnonymousNote Added: 0000706
2010-12-09 23:40AnonymousNote Added: 0000707
2010-12-09 23:46Blzut3Note Deleted: 0000667
2010-12-09 23:46Blzut3Note Deleted: 0000668
2010-12-09 23:46Blzut3Note Deleted: 0000669
2010-12-09 23:46Blzut3Note Deleted: 0000670
2010-12-09 23:47AnonymousNote Added: 0000708
2010-12-09 23:48Blzut3Note Deleted: 0000671
2010-12-09 23:48Blzut3Note Deleted: 0000672
2010-12-09 23:48Blzut3Note Deleted: 0000673
2010-12-09 23:48Blzut3Note Deleted: 0000674
2010-12-09 23:48Blzut3Note Deleted: 0000675
2010-12-09 23:48Blzut3Note Deleted: 0000676
2010-12-09 23:49Blzut3Note Deleted: 0000677
2010-12-09 23:49Blzut3Note Deleted: 0000678
2010-12-09 23:49Blzut3Note Deleted: 0000679
2010-12-09 23:49Blzut3Note Deleted: 0000680
2010-12-09 23:49Blzut3Note Deleted: 0000681
2010-12-09 23:49Blzut3Note Deleted: 0000682
2010-12-09 23:49Blzut3Note Deleted: 0000683
2010-12-09 23:49Blzut3Note Deleted: 0000684
2010-12-09 23:49Blzut3Note Deleted: 0000685
2010-12-09 23:49Blzut3Note Deleted: 0000686
2010-12-09 23:49Blzut3Note Deleted: 0000687
2010-12-09 23:49Blzut3Note Deleted: 0000688
2010-12-09 23:49Blzut3Note Deleted: 0000689
2010-12-09 23:49Blzut3Note Deleted: 0000690
2010-12-09 23:50Blzut3Note Deleted: 0000691
2010-12-09 23:50Blzut3Note Deleted: 0000692
2010-12-09 23:50Blzut3Note Deleted: 0000693
2010-12-09 23:50Blzut3Note Deleted: 0000694
2010-12-09 23:50Blzut3Note Deleted: 0000695
2010-12-09 23:50Blzut3Note Deleted: 0000696
2010-12-09 23:50Blzut3Note Deleted: 0000697
2010-12-09 23:50Blzut3Note Deleted: 0000698
2010-12-09 23:50Blzut3Note Deleted: 0000699
2010-12-09 23:50Blzut3Note Deleted: 0000700
2010-12-09 23:51Blzut3Note Deleted: 0000701
2010-12-09 23:51Blzut3Note Deleted: 0000702
2010-12-09 23:51Blzut3Note Deleted: 0000703
2010-12-09 23:51Blzut3Note Deleted: 0000704
2010-12-09 23:51Blzut3Note Deleted: 0000705
2010-12-09 23:51Blzut3Note Deleted: 0000706
2010-12-09 23:51Blzut3Note Deleted: 0000707
2010-12-09 23:51Blzut3Note Deleted: 0000708
2010-12-10 21:36EruannaNote Added: 0000711
2010-12-10 21:36EruannaNote Edited: 0000711bug_revision_view_page.php?bugnote_id=711#r333
2010-12-10 21:37EruannaNote Edited: 0000711bug_revision_view_page.php?bugnote_id=711#r334
2011-03-17 23:07Dark-AssassinNote Added: 0001165
2012-08-30 14:57ZzZomboNote Added: 0004521
2014-06-11 21:51WatermelonNote Added: 0009125
2014-06-11 21:51WatermelonStatusnew => acknowledged
2014-06-11 22:16FritsNote Added: 0009133
2014-06-12 12:37DuskAssigned To => Dusk
2014-06-12 13:58Edward-sanNote Added: 0009143
2014-06-12 14:54DuskNote Added: 0009144
2014-12-04 15:21DuskStatusacknowledged => assigned
2014-12-05 01:00DuskNote Added: 0011036
2014-12-05 01:00DuskStatusassigned => needs review
2014-12-28 16:03Torr SamahoNote Added: 0011102
2014-12-28 16:03Torr SamahoStatusneeds review => feedback
2014-12-28 17:46ZzZomboNote Added: 0011105
2016-02-02 12:41DuskStatusfeedback => assigned
2016-02-03 19:56Ru5tK1ngNote Added: 0014305
2016-09-15 15:27MarcaekNote Added: 0015641
2016-09-15 17:56EmpyreNote Added: 0015642
2016-09-25 05:17FoxBoyNote Added: 0015699
2016-09-25 13:09DuskNote Added: 0015700
2016-09-25 14:58FoxBoyNote Added: 0015701
2016-09-25 14:59FoxBoyNote Edited: 0015701bug_revision_view_page.php?bugnote_id=15701#r9547
2016-09-25 15:02FoxBoyNote Edited: 0015701bug_revision_view_page.php?bugnote_id=15701#r9548
2016-09-25 15:03FoxBoyNote Edited: 0015701bug_revision_view_page.php?bugnote_id=15701#r9551
2016-09-25 15:33FoxBoyNote Edited: 0015701bug_revision_view_page.php?bugnote_id=15701#r9552
2016-09-26 07:25ZzZomboNote Added: 0015706
2016-10-03 10:17Torr SamahoNote Added: 0015740
2016-10-03 10:17Torr SamahoAssigned ToDusk => Torr Samaho
2016-10-03 10:17Torr SamahoStatusassigned => needs testing
2016-10-03 10:17Torr SamahoTarget Version98d => 3.0
2016-10-10 04:30unknownnaNote Added: 0015878
2016-10-10 20:41Laggy BlazkoNote Added: 0015887
2016-10-11 19:29Torr SamahoNote Added: 0015903
2016-10-11 19:29Torr SamahoNote Edited: 0015903bug_revision_view_page.php?bugnote_id=15903#r9672
2016-10-11 19:30Torr SamahoNote Revision Dropped: 15903: 0009671
2016-11-06 12:28Torr SamahoNote Added: 0016150
2016-12-16 21:53Ru5tK1ngNote Added: 0016505
2016-12-16 21:53Ru5tK1ngStatusneeds testing => feedback
2016-12-28 00:45CombinebobntNote Added: 0016558
2016-12-30 12:24DuskStatusfeedback => assigned
2017-01-27 20:19Ru5tK1ngRelationship addedhas duplicate 0002996
2017-01-29 14:47Torr SamahoNote Added: 0016712
2017-01-29 14:48Torr SamahoStatusassigned => needs testing
2017-02-02 04:31DecayNote Added: 0016749
2017-02-05 22:48Ru5tK1ngNote Added: 0016761
2017-02-05 22:48Ru5tK1ngStatusneeds testing => resolved
2017-02-05 22:48Ru5tK1ngResolutionopen => fixed
2017-02-05 22:48Ru5tK1ngFixed in Version => 3.0
2018-09-30 21:50Blzut3Statusresolved => closed
2022-10-15 20:41WaTaKiDRelationship addedrelated to 0001676

Notes
(0000477)
Dark-Assassin   
2010-10-28 11:35   
I so totally agree.
(0000480)
unknownna   
2010-10-28 19:38   
(edited on: 2010-10-28 20:00)
I think that one of the first steps to prevent impersonators would be to disable name changing in-game online. Although players could simply disconnect and then change their names, it'd at least be an obstacle. The playerinfo could also be printed before/after each chat (and "<playername> has connected") message in the server console.

EDIT:

But yeah, if the player impersonating someone else isn't saying anything at all, it's difficult to know who's who.

(0000500)
AlexMax   
2010-11-01 12:04   
I agree with Anonymous, except that I think that server logs should also keep track of IDX through renames and connects/disconnects.
(0000711)
Eruanna   
2010-12-10 21:36   
(edited on: 2010-12-10 21:37)
Not only IDX, but IP too.

This isn't an impersonation issue though. This is an issue of "who's who" when there's multiple people with the same name. Most games have a system that keep everyone's name unique and assigns numbers when there's a collision.

The presence of such a system - by itself - makes things a lot easier on a server admin. Instead of having 5 "player"s to deal with, you have player, player2, player5, player6, and player8. You know exactly which one to ban.

(0001165)
Dark-Assassin   
2011-03-17 23:07   
I am going to have to agree on this.
1 problem is having to mass kickfromgame Player if there are more than 2.
That is only if they refuse to change their name.

But for impersonation issues, it can be a little harder.
(0004521)
ZzZombo   
2012-08-30 14:57   
Better pattern would be "Player 1", ..., "Player 64".
(0009125)
Watermelon   
2014-06-11 21:51   
Yeah this is annoying
(0009133)
Frits   
2014-06-11 22:16   
This is added in kpatch.
(0009143)
Edward-san   
2014-06-12 13:58   
Does this apply also to names like "player" and "player " (the space(s) aftr the name)?
(0009144)
Dusk   
2014-06-12 14:54   
I think that should be the case..
(0011036)
Dusk   
2014-12-05 01:00   
'https://bitbucket.org/Torr_Samaho/zandronum-stable/pull-request/115 [^]'
(0011102)
Torr Samaho   
2014-12-28 16:03   
I added comments in the pull request.
(0011105)
ZzZombo   
2014-12-28 17:46   
I more like the Source pattern of renaming "(1) Player", "(2) Player", etc, because it makes it extremely obvious the player didn't name himself this way.
(0014305)
Ru5tK1ng   
2016-02-03 19:56   
What about Player4? He is actually someone from zd that plays time from time.
(0015641)
Marcaek   
2016-09-15 15:27   
Any kind of differentiation would be great.

What would happen if someone theorectically had a name with max char limit and a person of the same name joins?
(0015642)
Empyre   
2016-09-15 17:56   
In that case, truncate the name just enough to add the number, sort of like DOS did with Windows-style long names: longfilename.txt becomes longfi~1.txt and longfilesize.txt becomes longfi~2.txt.
(0015699)
FoxBoy   
2016-09-25 05:17   
This is really a serious issue when handling impersonators.

SRB2 handles it this way:
- Every joining player starts with the name "Player 1", "Player 2" and so on.
- The client auto-names themself.
- If a duplicate name happens, it plucks one letter from the name until it's no longer a duplicate.
- If it can't make a name, it simply keeps the name "Player #"

Though, while this method is nice, it doesn't work for the Zandronum community.

I feel it should handle it like this. Every joining player joins, but if the name is a duplicate, a 4-digit random number is added to the end of the name. If there's not enough room to add the numbers, letters are plucked off, and the number added, removing as many characters as needed. It generates these four-digit values until the name is unique.
(0015700)
Dusk   
2016-09-25 13:09   
I think we can just simply name colliding players like "Player####" with a "####" standing for a random four-digit code. The problem is to inform the connecting player that his name is different.
(0015701)
FoxBoy   
2016-09-25 14:58   
(edited on: 2016-09-25 15:33)
What happens if we meet a name that is too long to fit a four digit code? Do we truncate letters until it fits? Or, do we refuse the name altogether? This is another problem that might come along.

Me and some others over at TSPG brainstormed for a while over this. this is what we came up with and felt was most effective while being transparent:
- an arbitrary "clone number" value is given to a player that is separate from the name itself. It starts at (1). Though, if they are the only one, this value isn't visible in the game.
- When someone duplicates a name, they are given the value (2), the next one (3), and so on...
- This arbitrary number appears after names in the list, chat, messages, and PlayerInfo, only if there is at least one duplicate.
- If (1) disconnects when (2) and (3) exists, they will move up to fill in their place, becoming (1) and (2).
- If (1) and (2) both exist, and (1) disconnects, (2) becomes the new (1) and the clone indicator disappears.
- The original name values are left untouched.

This may require substantially more effort to introduce, though.


I'd also like to suggest that very similar characters (Like 0 and O, 5 and S) be treated as duplicates.

(0015706)
ZzZombo   
2016-09-26 07:25   
Guys, everything was already thought of. If you follow my advise of using "(1)Player" we won't have to bother with name lengths and whatnot.
(0015740)
Torr Samaho   
2016-10-03 10:17   
I implemented this using the name pattern suggested in 0000144:0015700.
(0015878)
unknownna   
2016-10-10 04:30   
This seems to work initially, but breaks locally for a renamed client that reconnects, i.e. the renamed client sees his own name as it was before he was renamed.

Is there a reason why players are renamed to "Player #" and not just "<duplicate name> #"?
(0015887)
Laggy Blazko   
2016-10-10 20:41   
So, this is something interesting. I tried this in a local server:
- A client joined as "pepe".
- Another client joined as "pepe2"
- "pepe" disconnected by using the "disconnect" command.
- While disconnected, "pepe" renamed to "pepe2".
- This client joined the server again and sees itself as "pepe2" but everyone else sees it as "pepe".
- This client reconnects using the "reconnect" command and was renamed to "player 3866". Everyone including itself sees this name.
- This clients uses the "disconnect" command and renames to "meme".
- It reconnects again and sees itself as "meme" but everyone else sees it as "player 3866".
- This client quits Zandronum and joins again.
- Now it shows up as "meme" for everyone.
(0015903)
Torr Samaho   
2016-10-11 19:29   
Quote from unknownna
Is there a reason why players are renamed to "Player #" and not just "<duplicate name> #"?

To make them more easily distinguishable and to encourage the renamed player to switch to a proper unique name.

I'll have to look into why this is breaking locally when using reconnect.

(0016150)
Torr Samaho   
2016-11-06 12:28   
The local problems when reconnecting should be fixed now.
(0016505)
Ru5tK1ng   
2016-12-16 21:53   
Hmm local issues still seem to persist.

Client 1 joins as Alex
Client 2 joins as Alex but is renamed to Player8989
Client 1 disconnects and renames itself to Alex2 and reconnects
Client 2 sees Client 1 as 'Alex'
Client 1 sees his name as Alex2
(0016558)
Combinebobnt   
2016-12-28 00:45   
Got the same issue as rust, restarted a map in deathmatch and 1 client renamed them right, while the other client still displayed duplicate names.
(0016712)
Torr Samaho   
2017-01-29 14:47   
0000144:0016505 should also be fixed now.
(0016749)
Decay   
2017-02-02 04:31   
I ran a LAN server using version 3.0 170129-2032 and it seemed to have resolved the issues described by Rustking
(0016761)
Ru5tK1ng   
2017-02-05 22:48   
Given that the local issues are fixed, I'll mark this as resolved. Reopen if necessary.