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
THIS IS AN ALPHA VERSION. IT IS INCOMPLETE AND WILL NOT BE STABLE. DO NOT USE ON PRODUCTION SERVERS. LIKE ALWAYS, NO WARRANTY IS IMPLIED. NOTE THAT THE RISK OF DATA LOSS IS VERY REAL. IT IS NOT THE FAULT OF THE NUCLEUS TEAM IF ANYTHING GOES WRONG.
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
If you’re having trouble, visit our Discord channel: https://discord.gg/A9QHG5H
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.
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:
info.txtand 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.
This list is not yet exhaustive. There is not yet a lot to talk about, but v2 is not yet feature complete.
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
ban modules are:
use-permission-level: set to
trueto use permission levels
can-affect-same-level: set to
trueto let two players with the same permission level affect each other,
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.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.
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.
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.
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.
This also has the side effect of making these actions all require their own permission.
Until recently, this was a configuration toggle. This is no longer the case. To emulate the previous behaviour, simply grant the
Nucleus will just spit out errors to the console now, as they should never happen (or if they do, you should know about them).
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.
It wasn’t used much and it had many issues with it that were not simple to fix. There are no migration paths available.
Player teleportation should now be more reliable as the base teleport code has been deleted and completely rebuilt.
While many bugs might have been introduced, other bugs have been fixed. Notable issues that have been fixed will be noted here.
All Nucleus API calls cannot be considered to be stable at this time. Do not build production plugins against the v2 API.
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.
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.
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.
- This is an ALPHA version. It is likely to be unstable and incomplete.
- Some plugins and mods are known to be incompatible with Nucleus. See https://nucleuspowered.org/docs/compatibility.html for more information.