Nucleus released this version on Sep 9, 2018

3.9 MB

This is a pre-release version of Nucleus for Sponge API version 7.0


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 as USER in the permission tables
  • nucleus.mod that acts as a “super permission” for any permission labelled as MOD in the permission tables
  • nucleus.admin that acts as a “super permission” for any permission labelled as ADMIN in the permission tables
  • nucleus.owner that acts as a “super permission” for any permission labelled as OWNER 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.


  • 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.