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: 2fe35eb2
Release Notes
If you’re having trouble, visit our Discord channel: https://discord.gg/A9QHG5H
Important Updates
Updated Requirement: SpongeAPI 7.1 & Implementation Changes
Now SpongeAPI 7.1 has been released, many compatibility hooks for API 7.0 have been removed. There is now no guarantee that Nucleus will run on an API 7.0 server.
Also, I have taken the time to refactor some service loading code. Please test this, there may be a couple of services that have not registered properly.
PLEASE READ: nucleus.<role>
permissions
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 /tppos
command. nucleus.home
was the logical grouping of the /home
commands, including /home other
, /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.user
that acts as a “super permission” for any permission labelled asUSER
in the permission tablesnucleus.mod
that acts as a “super permission” for any permission labelled asMOD
in the permission tablesnucleus.admin
that acts as a “super permission” for any permission labelled asADMIN
in the permission tablesnucleus.owner
that acts as a “super permission” for any permission labelled asOWNER
in 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 nucleus.staffchat.base
as false
, this will override nucleus.mod
. The same can be said for parent permissions, if you set nucleus.staffchat
to 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
setupperms
. - 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 setupperms
will continue to exist, and will not grant new permissions automatically if they are added in new releases (but will if you re-run the setupperms commands).
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 /nucleus setupperms
.
If you do not want to use the role permissions, this can be turned off in the config by setting core.enable-parent-perms
to false
and reloading.
Bugfixes
- Fixed incorrect text on
/sellall
(thanks NickImpact)
Known Issues
- Sometimes, an incorrect custom prefix might be selected. Nucleus uses whatever the permission plugin hands back, check your inheritance with the permissions plugin.