I don't have nickname, nor will I likely get it considering I already have the coolest username on the server, however the general consensus of opinions seems to point to yes, so if it can be applied then +1

 

Personally I won't have any problem if I ever get nick+ (;)), but I feel for those with averylongname. :D
+314!

 

This is a limit of the plugin used to enforce the nick limit, there isn't an option in the config file to allow this, and the plugin won't be adding this option.
Andrewkm has already set the nick length limit to longer than the recommended value, which is recommended due to conflicts with other plugins.

Minecraft internally counts colour codes as two characters, so even if it's not displayed that way, it takes up space in the message. That means when plugins like survival games outputs messages which use a player nickname, these could mess up if the invisible characters made the message exceed the 'max length' limit of minecraft.

This might sound innocent, but this could cause players not to get their inventory restored, lottery winners to not get their money, players who vote not to get their netherstars because the code crashed when trying to send the message.

These sorts of things are why the nick plugin imposes the limit the way it does, because while you don't see it, the characters are actually there.



>that said, I can think of a way to implement it on ecc, without having to rewrite the whole command. But I have no way of addressing the concerns above, it would simply need testing with different combinations, and hope for the best.

 

But minecraft itself doesn't use the nick?

I was under the impression that a displayname was not something any plugin interacted with aside from things like chat messages.

 

Think about how often you see the display name in global messages in-game.

 

Yes, but that's only the chat part.

I don't see where the problem lies, chat message can be VERY long. The chat packet can be up to 32767 bytes big.

Although I understand that because of the json chat packets it can grow fairly large, if you simply set the limit a little higher then it's fine. It's not like every president will use /nick and breach the max-size of the chat packet.

The only thing that's MAYBE a problem is /list, and that's a very implausible situation.

The suggestion itself is simply asking for 26 characters of space instead of 20.
My own nickname would be

Code:

{"text":"**","color":"gold","extra":[{"text":"Kuke","color":"green","bold":"true"},{"text":"le","color":"yellow","bold":"true"},{"text":" kuuk00","color":"dark_green","bold":"true"}]}

(all the letters are bolded)

Which is 194 bytes, which uses 24 characters.

My current nickname, with 20 characters, uses 167 bytes.

So let's say 26 characters are 208 bytes, we would need 158 maxed out nicknames on a single line before it becomes a real problem. And that's just not something that's going to happen, considering nick+ is $100 and people have different ranks.

It's also barely a difference, from the current nick limit.

 

As I explained the limit is per char, not per visible char.
If this functionality was switched, it would be possible to have a 4 letter name have 10000+ bytes, which would cause a problem.

If this was to be added it would need to be an ecc custom solution, and I mentioned I have an idea.

 

Explain to me how anyone can make a 4 letter name up to 10k bytes. You would only be able to add 11 colourcodes. And duplicates get filtered out. (&l&l becomes &l, because there can be only 1 "bold" key in each object.)

So the only possible way to max out is by alternating colourcodes and formatting codes, let's say. "&6&l&m&uk&6&l&m&u&6u&l&mke" then you will have possibly up to 300-350 characters. Which is still not much of a problem, because there's not enough people who will ever have nick+ and be online at the same time and be the same rank. It's mostly tycoon+ that have nick+

 

It doesn't really matter about the json packet the client sends, but the string that is used inside of bukkit (although this code pre-dates the json chat packet). The nickname themselves are used by plugins to display text. Plugins like itag/tagme and essentials own playerlistname, displayname kit lore and books all use the getdisplayname method, and still use the old character based formatting, which colour codes take up character spaces, and thus need limited by the same toggle.

But as I repeat again, I already have an idea, so this argument is moot...

 

This such a great idea! +1

 

+1

 

Yea, what's this idea :D

 

Is there any chance for this to be implemented? @KHobbits @kukelekuuk00

 

KHobbits said he has an idea. btw did you read their "developer chat" above lol :p