Ranks

Ranks

Ranks are used widely throughout the network and are vital part to organizing permissions and the capabilities of various players and users on the network. The main purpose of all ranks are to provide players with an easy way to both identify staff and to give players permissions based on their role on the server.

Rank Benefits

Rank benefits are the true core of ranks and their permissions. While the rank enums configure mainly the displaying of ranks and bringing everything together, rank benefits are an important part of the functionality of the role even looking beyond the chat display.

Creating A Rank Benefit

1. Navigate to com.iantapply.wynncraft.benefits
2. Create a new Java class in that folder named <Rank Name>Benefits that implements the class RankBenefit
3. Override any base RankBenefit method and set the value accordingly. In the event that a method isn't overridden, the default value will just be used that is set in the RankBenefit class.
4. You're set! Please move to the rank creation section to learn more about utilizing the permissions you have just set.

Non-Purchasable Ranks (internally - ranks)

These are ranks that are considered to not be purchasable. This includes, but is not limited to PLAYER, MODERATOR, and ADMINISTRATOR.

Creating A Non-Purchasable Rank

1. Navigate to com.iantapply.wynncraft.rank.Rank
2. Create a new enum with the following parameters
   • ID: The ID of the rank, this should be one incremented from the previously made rank ID.
   • Name: The name of the rank. This is the name of the rank used to reference it internally.
   • ShortenedName: The shortened name of the rank, for example, "Administrator" could be "Admin".
   • Description: A brief description of what the rank is used for. For example, this could elaborate on the role of moderator briefly.
   • ChatDisplay: An Adventure library component that is displayed in the chat prefixing the players name. This is commonly the Unicode character of the rank prefix.
   • Permission: The permission that is attached to the rank. Currently it is deprecated and unused, but it is suggested to still be set.
   • Benefits: A new instance of a rank benefit object. This is where we will store the permissions and capabilities of the rank. Multiple ranks can have the same rank benefits.
3. You're good to go! You can now set a users rank with the setrank command by referencing the ID of the rank.

Support Ranks

These are ranks that can be purchased from the online store. This includes but is not limited to HERO, VIP, and VIP_PLUS.

Creating A Support Rank

1. Navigate to com.iantapply.wynncraft.rank.SupportRank
2. Create a new enum with the following parameters
   • ID: The ID of the rank, this should be one incremented from the previously made rank ID.
   • Name: The name of the rank. This is the name of the rank used to reference it internally.
   • Description: A brief description of what the rank is used for. For example, this could elaborate on the role of hero briefly.
   • ChatDisplay: An Adventure library component that is displayed in the chat prefixing the players name. This is commonly the Unicode character of the rank prefix.
   • Permission: The permission that is attached to the rank. Currently it is deprecated and unused, but it is suggested to still be set.
   • Benefits: A new instance of a rank benefit object. This is where we will store the permissions and capabilities of the rank. Multiple ranks can have the same rank benefits.
3. You're good to go! You can now set a users rank with the setsupportrank command by referencing the ID of the rank.

Why Choose A Class-Based Approach Versus A Configuration-Based?

While creating the system to allow developers or users to create and manage ranks, I decided to use classes rather than configuration files. Although configurations are easier to modify over time, I like to have a solid and reliable class-based solution. Being able to create a class that anyone can learn to create even off of such a little amount of documentation is super valuable to me and reliability is always a number one priority.

The rank classes and benefit classes were made with ease-of-use in mind. Being able to quickly look at a class and truly understand the goal and capabilities of it just really cement its piece in the codebase.

Why Use Incremental Rank ID's Rather Than UUID's?

I mainly chose to use incremental ID's rather than UUID's just to give predictability. On top of this, because of the hard split between support ranks and regular ranks duplicate ID's are possible as the systems don't overlap. Additionally, UUID's are hard to reference in something like commands in comparison to regular numbered ID's so I'd rather make it easier for server administrators.

Adventure Library Components And Not Strings For Chat Displays?

With PaperMC integrating the Adventure library into their API so heavily, I chose to use the Adventure library components instead of just regular strings with possibly regular Minecraft colour coding. This implementation allows users to use custom fonts for their Unicode characters, word styling, and use of Adventure library colouring (eg. gradients, animated text, etc). All in all, the Adventure library is a huge part of the codebase and keeping it uniform and in line with our target capabilities it's an excellent decision that will stick for as long as the lifetime of the Adventure project.