MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002303Zandronum[All Projects] Suggestionpublic2015-06-11 19:222024-04-09 13:55
ReporterLeonard 
Assigned ToLeonard 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusresolvedResolutionfixed 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version3.0-beta 
Target Version3.1Fixed in Version3.1 
Summary0002303: Omit color codes in name's length limit.
Description
<Leonard> I was wondering and just to be sure
<Leonard> Did you close'http://zandronum.com/tracker/view.php?id=1861 [^]' because of the limit extending suggestion?
<Leonard> Because I think it's still a great idea to not count color codes but not increase the limit
<Dusk> i can't remember the details of the discussion that led into that decisoin
<Dusk> decision*
<Dusk> but i was recently thinking about something similar
<Leonard> Well "consider using a simpler color scheme" is not easy when using newtextcolors
<Leonard> Not to mention people can have long names (Dusk is 4 letters long so it's easy to consider a new scheme)
<Dusk> well yes of course
<Dusk> but netname is still a fixed size buffer that is sent over the network so there will always be a length limit
<Leonard> Didn't the userinfo_t struct change heavily when upgrading the zdoom base?
<Dusk> .. oh right
<Leonard> I read that userinfo.GetName() returns a pointer
<Dusk> a pointer to a cvar
.
.
.
<Leonard> So do you think I could make a ticket for this?
<Dusk> maybe? meh

Here is a link to the referenced ticket.

Since the new userinfo is in 3.0 I think this is doable.
I checked in the latest GZDoom and I can change my name to a very long length.
The only limit is when writing the DEM_UINFCHANGED command which zandronum doesn't even use and the name is cleaned/truncated before it's written in anyways.
MAXPLAYERNAME can also be set to be actually 32 since the "\c-" color code appended at the end won't be counted.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
child of 0002268closed Dusk rcon playerinfo doesnt update properly 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-06-11 19:22LeonardNew Issue
2015-06-11 20:10carpathiaNote Added: 0012653
2015-06-12 15:12DuskRelationship addedchild of 0002268
2015-07-04 22:54MaxRideWizardLordNote Added: 0012829
2015-07-05 00:39DuskNote Deleted: 0012829
2016-02-10 14:52DuskNote Added: 0014413
2016-02-10 15:41LeonardNote Added: 0014415
2016-02-10 15:47LeonardNote Edited: 0014415bug_revision_view_page.php?bugnote_id=14415#r8714
2016-02-11 17:41DuskNote Added: 0014424
2016-02-23 22:37DuskNote Added: 0014487
2016-02-23 22:37DuskAssigned To => Dusk
2016-02-23 22:37DuskStatusnew => needs review
2017-11-09 22:52LeonardNote Added: 0018848
2017-11-09 22:52LeonardAssigned ToDusk => Leonard
2017-11-09 22:52LeonardStatusneeds review => assigned
2021-08-08 02:06KaminskyNote Added: 0021681
2021-08-08 02:06KaminskyStatusassigned => needs testing
2021-08-08 02:06KaminskyTarget Version => 3.1
2024-04-09 13:55Ru5tK1ngNote Added: 0023579
2024-04-09 13:55Ru5tK1ngStatusneeds testing => resolved
2024-04-09 13:55Ru5tK1ngResolutionopen => fixed
2024-04-09 13:55Ru5tK1ngFixed in Version => 3.1

Notes
(0012653)
carpathia   
2015-06-11 20:10   
THIS! How has it taken so long for someone to consider colour code not being counted towards name length...
(0014413)
Dusk   
2016-02-10 14:52   
This one is actually more difficult than in ZDoom since existing code inherited from Skulltag still uses fixed-size char arrays that rely on the length limit.

And in any case an absolute length limit must exist because this string gets sent over the network. What I guess we could do is set a fixed name length limit (say 24 chars for instance) and an absolute length limit of 3x that (72) for color codes that is harder to actually reach, even with longer form colors such as the ones provided by NewTextColors.pk3. The former limit would thus be the actual restricting name length and the 72 char limit as a technical maximum.
(0014415)
Leonard   
2016-02-10 15:41   
(edited on: 2016-02-10 15:47)
I totally forgot about this ticket.
I actually did this a few months ago but I forgot about it because I started working on other stuff.
Basically I did exactly what you said dusk, I had the MAXPLAYERNAME define be the actual character limit and a new define "MAXPLAYERNAMECHAR" which was the string limit.
I also realised the char arrays zandronum uses were problematic so I actually resized all of the ones that used the player's name in any way (by searching for each GetName() instance).
I'll attach the original patch I made if that helps but it may need some testing.

EDIT: Couldn't figure out how to attach on the tracker so here's a link.
(0014424)
Dusk   
2016-02-11 17:41   
Hmm, interesting. Though I wonder if we could instead expend the effort to using FStrings in the affected code.
(0014487)
Dusk   
2016-02-23 22:37   
You know what, let's just add it now

'https://bitbucket.org/Torr_Samaho/zandronum/pull-requests/71 [^]'
(0018848)
Leonard   
2017-11-09 22:52   
I'll revive this sometime in the near future.
(0021681)
Kaminsky   
2021-08-08 02:06   
In 3.1, colour codes are no longer included in the length of a player's name, meaning players can use more complex colour schemes without hitting the 32-character limit, even when using the new text colours.

Ask Dusk suggested before, there's an absolute limit for how long a name can actually be, including the colour codes (96 characters long). However, this limit should be hard to reach under normal use, and primarily exists so that names aren't too big when sent across the network.
(0023579)
Ru5tK1ng   
2024-04-09 13:55   
Verified that this works correctly online.