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.
Features
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 & /adminnickWiki
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!
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.
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!
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.
