Nickname manager V1.0.0 [API 4.1.0] [MC 1.8.9/1.10.2]

Nickname manager

Nickname manager allows you as a server owner to apply rules and restrictions to a player when changing their nickname at the cost of a nickname token.

The nickname token

When a player wants to change their nickname, they will need to have atleast 1 nickname token to do so or have a bypass permission.


  • Sync nicknames to other server, including bukkit servers with mysql
  • Give/sell nickname tokens to players
  • Previewing your nickname before using a token
  • Blacklist some words in the nickname (regex)
  • Change any message send to players the way you want it to be send
  • Option to force players to accept the nickname rules first
  • Buildin cooldowns
  • Permissions to bypass most restrictions
  • Admin/Moderator commands
  • Player friendly ingame help command /nick & /adminnick Wiki
  • Tab completion Wiki


You can find the bukkit release on the spigot forums


The wiki home page can be found here and will explain everything you need to know.

All the links below can be found on the wiki but are also listed here for your comfort.


Latest release: Download here

Initial setup

See the wiki entry Wiki

Commands & permissions

See the wiki entry Wiki

Compatibility with other plugins

See the wiki entry Wiki


A lot of time has been spend trying to optimise the plugin as best as I could. More info can be found on the wiki.
See the wiki entry Wiki

Reporting bugs, issues or ideas

See github

Neat plugin! I wish you success - I can see this being useful on various server networks.

Just skimmed your compatibilty section, and would like to offer advice about how Nucleus works. Rather than just disabling /nick, server admins should actually disable the entire nickname module. To do this, in main.conf, find the nickname module under the modules section, and set it to DISABLED. That way, Nucleus won’t try to do anything with display names AT ALL, making sure that Nucleus doesn’t mess up your hard work!

modules {

Nice job on your first plugin; you’ve certainly got a handle on the API.

Notes on the plugin
  • Commands should be registered in GameInitializationEvent, not GameStartingServerEvent. If a server starts and stops multiple times, or never starts at all, such as in the case of a singleplayer/LAN world, it’ll get registered multiple times.
  • Your Optional handling in VanillaNicknameApplier can be avoided by using event filters. You’d add a Player argument to your listener, annotated with @First.
  • I know you’re trying to maintain compatibility with Bukkit, but just throwing out there that Sponge has a wonderful system for storing data on players and other things dynamically (and saving them to NBT automatically), completely eliminating the need for wrappers.
  • Just a tip - if you don’t explicitly specify a command argument as optional using GenericArguments.optional(), then it’s always present; you don’t need to check the Optional. This applies a few other places too; in Sponge, Optional marks things that could possibly return null - but this doesn’t mean that you never know if it would return null. Some things you don’t need to check, like required arguments.
  • Also on the topic of commands - if a command wasn’t successful, don’t return CommandResult.success(). It’s in the method name; it signifies that the command was successful. If something goes wrong, including user error, throw CommandException.
1 Like

Updated the wiki, thanks :slight_smile:

Edit: Apparently you still need to disable the nickname commands, tho it’s probably better to also disable the module aswell so the wiki will tell you to disable both.

Thanks for the feedback, this isn’t my first plugin that i develop. I have made some private plugins before. I did this project to revive an old (now broken) bukkit plugin but with sponge compatibility and new knowledge of coding. I wanted to challenge myself and see how well I can make this project work. Making this public is a way of giving back to the community which I have learned from but also allows me to improve by people like yourself who have more experience.

That being said, here is my thought on your notes

  • The docs state that commands should be registered on the server started event. Could you explain in what situation these events get called multiple times? I just started a SP world (FTB infinite lite 1.10), started a lan server but it did not trigger the GameStartingServerEvents.
  • I had seen someone use that, I wasn’t sure what exacly it did. Now that I know, I will definitly apply that.
  • I wouldn’t mind adding a sponge exclusive storage system but I will need to experiment with that since I have no experience with it. Just to be clear, this will require the Data API right?
  • I realise that the checks aren’t needed but I am forcing myself to get used to working with optionals. My own way of working with them is to ALWAYS do checks. If I get lazy I may also start skipping checks that are needed.
  • Throwing the error does make more sense. This will actually make some things easier on me!

That really shouldn’t be the case, disabling the module should disable the command too. I’ll check this out on my end.

Yes, it will involve the data API.
As for the docs, they state when command registration is handled, not when you’re supposed to do the registering. You can see the intended state in the JavaDocs.

@TPNils I just checked that disabling the Nucleus nickname module also disables the commands, and it does, so I don’t know why you think you need to disable the commands separately because you don’t - you just need to disable the module and restart the server. The commands.conf entry will then be ignored.

Is it known whether this works with UltimateChat? It doesn’t seem to pickup nicknames from here, only from Nucleus

This doesnt work at all, its for an old api version that hasnt been updated in 4 years.