Nucleus is everything you want from, and love about, essentials plugins and more. Built from the ground up on @dualspiral’s QuickStart foundation to be modular and extremely configurable - Nucleus takes @HassanS6000’s EssentialCmds and puts it on steroids!
Nucleus has the following exciting features:
Most of the features from EssentialCmds, updated to use the latest Sponge API features and to be more functional.
Modular system that allows users AND plugins to manage functionality.
The ability to disable specific commands.
Warmup, cooldown and charging options for many of the commands.
An API to allow other plugins to hook into Nucleus.
Please note - I have noticed that the Nucleus name has been used elsewhere in the Minecraft world. The Nucleus plugin is not affiliated with any server, server network or business of the same name. @dualspiral does not accept donations, requests for work, nor endorses any other developer, plugin or server.
It is very pleasing to see this new development, and I wish you great success.
Can I ask that you ensure easy economy integration? A lot of the features (eg Kits) could use it.
To answer your question, absolutely. There is already a framework (using the Sponge Economy Service) for charging users to run many of the commands (I made sure that was in right from the beginning), and it is on the roadmap to add per-kit charges. I’ll make it a priority to add that in before we provide a build - sounds like it’s something that would be of interest.
Hmm. The problem is that some server admins would expect to see an immediate change - if you disable a command live, some might expect to see another command take it over without a restart.
Nevertheless, such a command would be useful for setting warmups/cooldowns/costs live anyway. I’ll consider how to do that.
It’s not a priority, but it’s something I’ve been toying with. There are plenty of economy plugins that do a decent job now, though I realise it would be nice if we had basic support.
I think economy support would be great. You have an API to allow other plugins to hook into Nucleus. Are you thinking about having economy like Essentials had? Maybe just better and able to hook in with other economy plugins or other economy plugins can hook into this,
Right now, we already hook into the Sponge EconomyAPI service - so we already support charging for commands and kits if an Economy plugin is installed.
There are no specific plans for our own economy right this moment.
Question/Suggestion:
Will the config/data storage be more organized?
(e.g. All config options generated on first load /&/ Data such as last deaths, homes, warps, etc. in their own respective storage files.)
Suggestion: WorldEdit commands and item. WorldEdit has become an essential and can so see it here.
Suggestion 2: Powertools just to add something fun for admins and for other purposes it may be used for.
Thank you. I can’t wait for it to be available for use!
To answer your question: yes. I decided to go down a more Essentials like route, for the simple reason it makes it much easier to obliterate data for a specific player. In fact, I’ve written a reset command that will do that for you - and will probably make an event that other plugins can listen to that asks them to do the same thing (plugin devs, would that be useful?). All configs that are intended to be user editable are autogenerated at startup, data files are only created as needed.
The current structure is that I have split configs and data, config files go in /config/nucleus, data files go in /nucleus (location of the data files are subject to change, but I do not want to put data files in /config). Opinions are welcome.
/config/nucleus/main.conf - main config options, including module config and other general options. /config/nucleus/commands.conf - turning specific commands on and off, along with warmup, cooldown and charging information
/nucleus/userdata/ - one JSON file per player. My data file would be at /nucleus/userdata/df/dfe5c2a0-28bb-4449-ac73-a95980850077.json, for example. /nucleus/worlddata/ - one JSON file per world. /nucleus/general.json - one file for per server settings, such as blacklist.
/nucleus/warps.json, /nucleus/jails.json also exist, but I will likely move this data into the general data store.
Part of the reason I haven’t published a build yet is because I’m still getting the structure down, and I think it would be irresponsible to publish a plugin that is subject to large change that will mean server owners will have to update their files over and over. However, I think we’re just about there on this sort of thing, so I’ll put a build out soon.
WorldEdit is essential I agree, but it also exists for Forge and I think there is a Sponge wrapper. It’s not a priority, and it would be lot of work to implement ourselves.
There’s an SpongeAPI version planned, but unfortunately WorldEdit still uses int ids to recognize blocks and we don’t have a solution for Sponge yet that would let it only use string IDs.
I just want to give a quick update to where we are with the plugin, i.e., the good ol’ fashioned “we’re not dead” post!
I’ve been restructuring a bit of the plugin to make it a bit friendlier to contribute to (I hope!) and to make it easier to generate documentation. On that note, I’ve created a small website that contains the commands and permissions that Nucleus has. It’s quite basic at the moment, but I’m hoping to expand the descriptions and the site functionality sooner rather than later.
These command and permission references can be found at http://nucleuspowered.org/docs/. Note that the “suggested permission levels” are also provided to compatible permissions plugins via the permissions API.
Other features that have made it include the ability to customise any user facing message, which could have uses for localisation, and, by request, charging for kits.
So, if anyone is interested, please feel free to look though the commands and if you feel anything is missing, please let us know via here or the Github issues site - http://github.com/NucleusPowered/Nucleus
Unfortunately, no official beta release yet because we’re still working on a couple of small structural things that might mean file locations/structures might change, and it’s no fun for anyone if you keep having to start over! However, I think we’re close to that point and I hope to share it more widely soon.
See 