Nucleus released this version on Nov 16, 2019

2.4 MB

This has incorrectly been labelled as a promoted version by Ore. If you are looking for the latest stable version of Nucleus, please use 1.14.1-S7.1. Only use this version on TEST servers.

This is an alpha version of Nucleus 2.0.0 for Sponge API version 7.1


Please report any issues to Github Issues (https://github.com/NucleusPowered/Nucleus/issues) CLEARLY stating the version of Nucleus you are using.

This was built from Nucleus commit: 830cd396

Release Notes

If you’re having trouble, visit our Discord channel: https://discord.gg/A9QHG5H

Nucleus 2.0

Nucleus 2 is a major rewrite of much of the base code. It is designed to make future work to the system simpler, easier to understand, and hopefully, easier for people to contribute to.

As it stands, Nucleus 2 is an ALPHA quality product. Please do not use it on production servers, but I would appreciate any testing I can get. I am only one person!

Here is a rundown of some of what is new, changed, removed, fixed and crucially, known to be broken.

PSA: Before you use Nucleus 2…

Nucleus 2 does not change how your data is stored, but the entire storage system has been completely rewritten. This is to enable database support which is currently slated for Q1 2020. There may be issues with the storage system that I have been unable to test that might cause unexpected data loss. If this happens, please tell me via Github Issues.

No migration is necessary for the following:

  • main.conf
  • info.txt and other info files
  • User data
  • World data
  • Kits, warps, and other general data

Nucleus 2 also uses a new format for the commands.conf file and no migrator is provided at this time as the format is likely to change further as I complete the plugin. Please inspect commands.conf when you load and make any necessary changes.

For Server Owners and Players

This list is not yet exhaustive. There is not yet a lot to talk about, but v2 is not yet feature complete.

ADDED: Permission Levels/Powers for moderation tasks

Many of you have been asking “permission levels” because you don’t trust lower level staff to not abuse their powers and use them against higher level staff. They already existed for social spy, but now they exist for muting, jailing, kicking and banning. This feature allows you to give a numeric level to each player - by default, if your level is higher than the person you’re trying to act upon, your action will go through. By default, those with the same power for an action will not be able to affect each other.

Because this is an advanced feature, you must turn it on for the respective modules. The options in the mute, jail, kick and ban modules are:

  • use-permission-level: set to true to use permission levels
  • can-affect-same-level: set to true to let two players with the same permission level affect each other, false if not.

To specify a permission level, you have to give a specific permission option to the player in question. In LuckPerms, options are referred to as “meta”. The options you need to assign are specified in the config file (at least for now, will be on docs later), but for convenience, they are:

  • nucleus.ban.level
  • nucleus.jail.level
  • nucleus.kick.level
  • nucleus.mute.level
  • nucleus.socialspy.level (this already existed)

No prizes for guessing which one is which! In LuckPerms, you would then specify the level an option using the command:

/lp user <user> meta set <option> <level>

For a ban level of 4 on dualspiral:

/lp user dualspiral meta set nucleus.ban.level 4

If a level is invalid or does not exist, having the permission to run the command you are running is considered a level of 1, not having the permission is considered a level of 0.

This has only been lightly tested. Please report any feedback on the system to me during your testing.

ADDED: Ability to specify arbitary command names for Nucleus commands (EXPERIMENTAL)

Nucleus commands can now be given arbitary command names in commands.conf under the “root level aliases” section, and Nucleus will attempt to register the command under that alias.

This feature is still subject to some testing, but I realised it was easy to add with the new codebase.

ADDED: Per User translation of Nucleus system messages

While Nucleus’ support for translation isn’t great and I’ve not been successful in getting a translation platform running (yet), Nucleus will support sending messages to players based on their client locale. This will be available as we (hopefully) receive more translations.

You will be able to turn this off, of course, if you want all clients to see the same language.

MODIFIED: The /tp alias for /teleport defaults to disabled

Many mods, such as JourneyMap, were using the /tp command to perform teleports

Other commands may get the same treatment if the Nucleus team figures that it would be in the best interest of the community.

MODIFIED: The /mute and /unmute, /jail and /unjail commands are no longer toggles

This also has the side effect of making these actions all require their own permission.

MODIFIED: Warps now always require the permission nucleus.warps.<name> to redeem

Until recently, this was a configuration toggle. This is no longer the case. To emulate the previous behaviour, simply grant the nucleus.warps permission.

REMOVED: Debug Mode

Nucleus will just spit out errors to the console now, as they should never happen (or if they do, you should know about them).

REMOVED: The Warnings module has been removed

It wasn’t used much and, honestly, it was actually pushing the boundaries as to what Nucleus really should be doing. There are no migration paths available as it stands, however plugin developers can use the Nucleus API to extract any warnings against a player if they wish to enable such migration.

REMOVED: The Server Shop module has been removed

It wasn’t used much and it had many issues with it that were not simple to fix. There are no migration paths available.

REWRITTEN: Teleportation Routines

Player teleportation should now be more reliable as the base teleport code has been deleted and completely rebuilt.

BUG FIXES: Miscellaneous fixes

While many bugs might have been introduced, other bugs have been fixed. Notable issues that have been fixed will be noted here.

For Plugin Developers that use the API

All Nucleus API calls cannot be considered to be stable at this time. Do not build production plugins against the v2 API.

REMOVED: The Nucleus static object

I’m going to start with something that isn’t in the API - Nucleus.getNucleus(). I’ve had the occasional complaint that updates to Nucleus have broken some plugins that depend on it. It always turns out to be developers not asking for API additions (which I try to guarantee) but just decide to use Nucleus.getNucleus() everywhere. Don’t do it - I do not class that as part of the API and it was a horrible object that allowed me to be lazy. v2 is about stopping me being lazy.

You shouldn’t do it anyway, but you will not be able to do it at all in v2, because the Nucleus object has been deleted. Please use the API. If there is something missing from the API that you wish to use, please open a Github issue.

MODIFIED: All kinds of stuff

Please take a look through the API yourself for now. It’s all subject to change, but I have tried to add sensible documents. I will flesh out this section once we approach Beta.

For Developers considering contributing to Nucleus

Nucleus’ biggest changes have happened in this area. v2 no longer uses the static Nucleus object, but instead uses Guice and DI to create a series of cross cutting concerns to provide Nucleus wide actions. Commands, listeners and tasks should all have INucleusServiceCollection injected into themselves for access to these systems.

More information will be put on the website once things have settled.

Known Issues