This is a pre-release version of Nucleus for Sponge API version 7.0
THIS IS A PRE-RELEASE VERSION AND MAY NOT BE STABLE
This was built from Nucleus commit: 4f8ddc7d
If you’re having trouble, visit our Discord channel: https://discord.gg/A9QHG5H
This is a pre-release to get testing on the permission updates. Please note that no permissions have been changed, only role permissions have been added.
When I first set out to create Nucleus, the design of the permission nodes was to group like commands together. So,
nucleus.tppos, for example, related to the
nucleus.home was the logical grouping of the
/home commands, including
/home list etc., due to Sponge’s inheritance.
However, this way of doing it has caused problems:
- Owners want vanish on login as a permission, like Essentials, but complain that
*makes them vanish on login
- There is an AFK exemption permission,
nucleus.afk.exempt.toggle, activated by
nucleus.connectionmessages.disable- give yourself * and you won’t be broadcasted to the server
I maintain my opposition to the * permission. It is a bad idea and is far simpler and intuitive than what Bukkit did. In fact, Sponge’s permission system was not even designed to support
*, or any wildcard.
I also recognise how much of a pain the current setup is for some use cases. So, this commit introduces the following permissions that automatically grants defaults:
nucleus.userthat acts as a “super permission” for any permission labelled as
USERin the permission tables
nucleus.modthat acts as a “super permission” for any permission labelled as
MODin the permission tables
nucleus.adminthat acts as a “super permission” for any permission labelled as
ADMINin the permission tables
nucleus.ownerthat acts as a “super permission” for any permission labelled as
OWNERin the permission tables
This does not, and will never, override any explicit permission that has been set.
As an example, you give your moderators the
nucleus.mod permission. This, for example, gives them permission to enter staff chat. However, maybe you don’t want them to access this. If you set
false, this will override
nucleus.mod. The same can be said for parent permissions, if you set
false, a check to
nucleus.staffchat.base will return
false, regardless of whether
nucleus.mod is set.
While this is cleaner than using
/nucleus setupperms, you must be aware of the following:
- These “role” permissions will never be given by default by
- Any permissions added to Nucleus that fall into one of these roles WILL be granted by default if you have the role permission. It is the responsibility of the server owner to check for any new features that may be added to these roles.
/nucleus setuppermswill continue to exist, and will not grant new permissions if they are added in new releases.
If you want to use our suggested template and do not mind following our recommendations, use the role permissions. If you want to use our suggested template but DO want full control over what permissions you have, remain with
If you do not want to use the role permissions, this can be turned off in the config by setting
false and reloading.
- Sometimes, an incorrect custom prefix might be selected. Nucleus uses whatever the permission plugin hands back, check your inheritance with the permissions plugin.