This is a follow on from #50 - cost per kit was not implemented. This is so we track this for later.

See #27 - similar thing.

Self explanatory, I hope. Going into to spawn module.

Currently we are using #essentialcmds as our main conversation base. However with essence, we will ultimately need to move to a new channel. However here I was thinking of perhaps switching to Gitter instead. Put some pros and cons merged for both services.

This may have to wait until the Sponge API makes this possible.

• Create a World Config loader, like the User Config loader
• Create world configuration files

This blocks #5

I had a rather long conversation with @20zinnm last night over IRC about the module system. While I believe it's fit for purpose and I initially dismissed much of it, I've slept on it, and have been considering if I could do it better.

There are a few things I'm thinking of. Any of these may or may not come off, this is currently a thought dump:

• Modules should be self contained in their own package, so we get the structure:

modules.<module>.<packages for module, including commands, listeners, runners>

• Modules get their own control file, which controls where to get the commands and such from. This will contain methods that get the command objects, task objects, listener objects and config adapter objects
• Config adapters can be provided for the various config/data files in the system, which gets registered at runtime with the appropriate config type. Commands and such then request data from an adapter from the config, manipulate it, then send it back to the config file. This will save our config methods getting too large. Commands that work over other modules data need to be aware that some adapters will not be available.
• The CommandBase may need a couple of tweaks to accomodate the way commands get loaded, but this will not affect the way we currently do things.
• The Module annotation may cease to be because of the way things will get loaded.
• The module registration service where plugins can turn off modules will be updated to use strings, and can be queried for existing modules.

This is a very complex change, and as such, I will be making these changes should I believe this is the best way to move forward. Please do not start offering PRs and such for this - I am still thinking about them and this may be abandoned.

Note that this is not for use externally, however, I may spin this out into a separate plugin too.

Basically so @hsyyid is not left asking which module does (put feature here) goes under 😉

Much like we have user and world JSON data files, we might need a server JSON data file too. I can see this might be useful for blacklisting, for example.

Is there a use for a "global" data store? I only want to do this if this is required.

Some server admins may prefer to have multiple colors in the messages. This would be very easy to do, all you do is add TextSerializers.FORMATTING_CODE.deserialize() to the method already used to get all messages.

Thoughts? This will make it so messages aren't just one color 😄

I see you've put it into EssentialCmds, but I don't know if it belongs in an "essentials" plugin - is it going to be well used? Gut feeling says no, but I'd like input.

We could write an "Extra" plugin that contains less used things - so non-essential stuff can go into there. We could put it in anyway.

Worth thinking about.

I would rather do this on the teleport event if we can - but it's unimplemented! We'd need a way to prevent /back from logging teleports to/from jail though.

Objectives:

• - Add the Worlds module.
• - Transfer and adapt the world commands I wrote for EssentialCmds over to Essence.
• - Add world configuration structure (@dualspiral - #10)

We will want to support the Sponge API Localization API when API 5 comes out, rather than use the resource bundle solution we have at the moment.

SpongePowered/SpongeAPI#1088

This is here as a placeholder so that we don't forget about it.

When I run the /tp command without any arguments, I get the following:

[23:05:20] [Server thread/INFO] [essence]: dualspiral ran the command: /tp
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]: java.util.NoSuchElementException: No value present
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at java.util.Optional.get(Unknown Source)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at io.github.essencepowered.essence.commands.teleport.TeleportCommand.executeCommand(TeleportCommand.java:115)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at io.github.essencepowered.essence.internal.CommandBase.startExecute(CommandBase.java:317)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at io.github.essencepowered.essence.internal.CommandBase.execute(CommandBase.java:310)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at org.spongepowered.api.command.spec.CommandSpec.process(CommandSpec.java:332)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at org.spongepowered.api.command.dispatcher.SimpleDispatcher.process(SimpleDispatcher.java:331)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at org.spongepowered.common.command.SpongeCommandManager.process(SpongeCommandManager.java:252)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at net.minecraft.command.ServerCommandManager.func_71556_a(SourceFile:83)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at net.minecraft.network.NetHandlerPlayServer.func_147361_d(NetHandlerPlayServer.java:815)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at net.minecraft.network.NetHandlerPlayServer.func_147354_a(NetHandlerPlayServer.java:794)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at net.minecraft.network.play.client.C01PacketChatMessage.func_148833_a(SourceFile:37)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at net.minecraft.network.play.client.C01PacketChatMessage.func_148833_a(SourceFile:9)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at org.spongepowered.common.network.PacketUtil.onProcessPacket(PacketUtil.java:106)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at net.minecraft.network.PacketThreadUtil$1.redirect$onProcessPacket$0(SourceFile:51)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at net.minecraft.network.PacketThreadUtil$1.run(SourceFile:13)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at java.util.concurrent.FutureTask.run(Unknown Source)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at net.minecraft.util.Util.func_181617_a(SourceFile:44)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:660)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at net.minecraft.server.dedicated.DedicatedServer.func_71190_q(DedicatedServer.java:344)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:605)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:481)
[23:05:21] [Server thread/INFO] [STDERR]: [io.github.essencepowered.essence.internal.CommandBase:startExecute:333]:     at java.lang.Thread.run(Unknown Source)

If I add arguments, it tells me there are too many. So, I'm thinking there is something wrong with the argument parsing, possibly the way I've used "firstParsing". I want /tp [-f] <player> to work with no extra permission check, whilst /tp [-f] <playerFrom> <player> should work only with the "others" permission. The NoCost and NoWarmup arguments can be removed for now if they make things harder to debug.

This follows on from #76.

I've been building https://github.com/NucleusPowered/QuickStartModuleLoader to try to make it a little easier to manage our modules. See #76 for rationale, but this issue will track implementation.

I've used automated tests to test QSML, so it looks like it should work.

• Depend on QSML.
• Create custom module constructors.
• Create AbstractModule that does common things like loading commands, events and runnables.
• Reorganise modules and add module control files.
• Add Config Adapters for anything that uses the main config.
• Shadow in the library.

I'll add more here as I work out what we need.

As title. Need to try to translate the configuration over to make migration simple, if possible.

Change those yellow messages that users see when they log in/out.

Not sure which module I'd put this in yet - probably its own. Naming it is hard then!

• Create new module (if appropriate) - this means new listener!
• Add ability to change the system message for a player joining or leaving.
• Add defaults to the main.conf file, one for join, one for leave.

Bonus:

• Allow it to be per player (subject to permissions)

All the permissions need to be updated to use essence rather than quickstart.

I know its WIP but for the future having documentation of what is in and (could start this now) what will be added.

Also would be nice to know what the plans are for how the modules are broken up, how easily they could be en/disabled.

List only shows display names and if someone is vanished currently. This needs more work.

It seems this is a popular feature in EssentialCmds - so we should take it. It should prevent other users from using, placing, mining specific blocks.

Module: blacklist

I run the command, I get no output, even with debug-mode set to true. Not sure what is going on...

Not sure of the module, could be its own. It's not warping, it's not teleporting.

Currently PluginModule has the keys in the enum:

public enum PluginModule {
    MESSAGES("messages"),
    WARPS("warps"),
    HOMES("homes"),
    BANS("bans"),
    JAILS("jails"),
    MUTES("mutes"),
    KICKS("kicks"),
    MAILS("mails"),
    ENVIRONMENT("environment"),
    ITEMS("items"),
    PLAYERINFO("playerinfo"),
    TELEPORT("teleport"),
    CHAT("chat"),
    MISC("misc"),
    FUN("fun"),
    AFK("afk"),
    COMMAND_LOGGING("command-logging"),
    SPAWN("spawn"),
    ADMIN("admin"),
    VANISH("vanish"),
    NICKNAME("nickname");
}

However the keys can also be gotten by doing PluginModule.SPAWN.toString().toLowercase().
It might that the keys exist for convenience but just wanted to point it out,

Things like burn, smite, maybe even kittycannon.

We need to co-ordinate this - so that we have a good post to tell people about what we're doing. We should not announce this until we think we can use some testers.

What should we talk about? Spiritual successor to EssCmds that builds upon my technology? I'm quite happy to flesh it out, but it should be an open process!

API 4.0 has been released. We should target this and use any features that have been added.

Going to do it like Essentials did - a rules.txt file, rather than command based.

Before we started this merged project, a friend of mine was going to come and help me do some commands, starting with this one. I'm keen for this to be left for said friend, see if we can use it to onboard another person to help with the core plugin. Please don't take this issue!

Currently we don't a standard issue and pull request format. The users may provide only as much information as they think may help us. Sometimes that might not enough and we might have to ask more information. To prevent that, I think its best to have github templates for the PRs and issues.

Proposal for issue template:

We categorize issues into three types:

• Bug
  • Sponge
    • Implementation: SpongeForge or SpongeVanilla
    • Build version: The build number of the implementation.
  • Nucleus version
  • List of plugins/mods
  • Expected Result
  • Actual Result
  • Steps to Reproduce
  • Comments
• Feature Request
  • Required Fields:
    • Request
    • Use-cases

Proposal for pull request template

Required Fields:

• Changes made in the PR
  Optional Fields
• Related: any issues that this PR relates to
• Comments

I liked the idea of calling it Essence until I found that Essence is also (at least) intended to be a Spigot plugin that is a replacement of Essentials. Having seen that @kinggoesgaming also has tried to start a port of it, and therefore I'm very sure that's where the name came from, I'm not sure we should be named the same because I don't want to be associated with an entirely different plugin, especially when it's one that intends to charge users if they just download it.

Yes, the plugin might have stalled, but I'm shaky about using the name.

@hsyyid - I really think we need a better, more original name to avoid being associated with other projects with the same name, even if they aren't Sponge based.

Obviously, I liked "QuickStart" (which was going to become "QuickStart-Essentials"), but that's not something I'm wedded to, and I don't want it to seem that you've just come into my project. We just need something original.

Suggestions and thoughts welcome.

Objectives:

• - Add Config for Kits module
• - Add commands for Kits module
• - Add Kits module
• - Add Kits cooldown/interval
• - Add Kits cost (Can be done later)
• - Add Kit specific permissions

Follows on from #21, create a messages file that can be altered by server owners.

More of a question than an issue or a request, but i was wondering what is planned for the /give feature set. I was wondering if some of my old data files for Essentials (Bukkit) would be of use for you.

I have a CI server which I'll link into the plugin. I'll be just rambling on about how I configure it here - this issue is just for me.

In the build.gradle file I found the repo for forge defined, but no dependency added for it. So I am wondering if it is needed? If it is not needed i will remove it in #7

After thinking about it this morning, it occurred to me that actually, we don't have a good branching strategy. The following came to mind.

The point of the "develop" branch is actually redundant. I'm hoping that we'll get a lot of contributions for this plugin once it gets off the ground and everyone will target master. So master should be our main development branch.

HOWEVER, master should be stable at all times. To do this, all development should be done on branches. Branches can break, that's fine, master should not.

Release versions should go on a release branch. Once we release version 1.0, we branch for 1.0 (release/1.0), and master will target 1.1. Hot fixes for 1.0 can be backported, so the release/1.0 branch will contain fixes for 1.0.1, for example.

So, my proposal is:

• Remove the develop branch - IMO it tends to work only for single developers, if everyone works on the develop branch, there is likely to be a lot of conflicts.
• The master branch is the current development code
• We aim to release new minor (1.x) releases every so often, but not necessarily after every feature (we could promote beta builds)
• All development, bar minor bugs, go onto branches before master.

If you think the develop branch should stay, please give me justification. @kinggoesgaming - do you have a rationale?

@Tzky requested a feature:

A feature i'd like to see is the ability to enable/disable commands from Console, eg via editing the config.

Example:
/nucleus command <name of command> <true/false>

This would save administrators from having to mess with the config in the server folder.

https://forums.spongepowered.org/t/wip-nucleus-the-ultimate-essentials-plugin-a-joint-project-between-dualspiral-and-hassans6000/11792/5

Not sure when I'll get to this, but I think it's a good idea. Targetting 1.1 for now, if I think of a good way to do this sooner, I'll try to get it in for 1.0.

Popular feature, but needs to be considered.

I think we need:

• Powertool object that contains the ID of the item and the command to run.
• A new list entry in the UserConfig that will contain this information
• The command

This includes the name and the lore. Should these be subcommands?

In principle, sounds good. However, it's use is currently limited, and it would be nice to be able to have beta channels.

How do we use it? I guess we might need to choose a tagging format before we use it.