Alright so I'm creating this as a sort of plan, request for a possible AlphaChest v2.0.0. I want to get people's opinions/suggestions for this and especially kroimon and Brianetta's thoughts.

I know that AlphaChest is still only at 1.18.0 in terms of versioning but because this idea may involve a fair few changes I thought it might be worth bumping up the version to something like 1.2.0 or even 2.0.0.

I've put together some ideas I had in mind below.

Core:

• Add world restrictions via something like permissions
• Add MySQL as an additional method of storing saved chests (keep flat-file storage as the default method though)
• Add an (/alphachest) base command with several subcommands such as help, reload, info... etc

Configuration:

• Add more configurable options
• Implement common YAML standards/conventions (e.g. changing silentAutosave option to silent-autosave)

Permissions:

• Remove uppercased letters in permission nodes
• Split some permissions into 'groups' (e.g. alphachest.keepOnDeath -> alphachest.death.keep... etc)
• Add separate permission nodes for opening other player's chests and clearing other player's chests (e.g. alphachest.admin.chest & alphachest.admin.clear)
• Change alphachest.* to something like alphachest.basic as the current might seem like it would give ALL AlphaChest permissions

Sorry I didn't get to this sooner.

I'm happy to give this the nod. Database support is always welcome (and makes storage of additional info such as NBT tags so much easier), and adhering to established conventions makes maintenance easier.

Hey, no problem. I'm sure you had good reason not to.

As for the update idea, the only main concern would be with people updating the plugin to such a newer version and not noticing that there have been changes in the configuration options and permissions. I do have an idea in mind of a system that update existing configs automatically by replacing the old option names with the new ones while keeping any settings that users may have made to it. Additionally, any new configuration options would be added to the existing one as well. This would be a possible solution to avoiding any serious problems that may arise with plugin and config settings. On the other hand, permissions are a whole different problem. Users of the plugin who would want to update to this new version would have to change their current permissions to the new ones.

Any input you have on these main two concerns? (config changes & permissions changes)

AlphaChest already has a couple of points in its release history where configuration and storage has changed. In each case, it only supported automatically upgrading form the last version. This keeps the code less complex, and assumes that server admins keep their servers' plugins up to date.

Permissions changes are, as you note, extra work for the server admin. It's work that they should only ever need to do once, though.

Perhaps we should treat this as a reason to bump the major version. Seeing version 2.0 should indicate that there are changes which makes it worth reading the README, and that can do into the detail needed, about permissions being reworked and the storage back-end choices being improved.

Of course, that also gives us the opportunity to think about any other changes we might want to incorporate.

Alright, yeah. I agree with you on that.

I've started doing some work on the plugin which you can see on my forked AlphaChest repo if you want but I'm not ready to submit a pull request yet.

I have run into an issue though. So I have put together a new config.yml which I'm fairly happy with. It's essentially the same as before but just reformatted and a little nicer.

I spent some time looking into a way of updating old configs and I did come up with a possible option however, it requires the use of the config.set methods and then plugin.saveConfig(). For some reason, plugin.saveConfig() actually strips the config of all comments and blank lines. This is a bit of a problem as the comments in the config really are quite necessary and I don't think it would be a good idea to have a system which strips them.

The only solution I could come up with which really isn't much of a solution but basically it backs up the old config by renaming it to (config_old.yml) and then generating a new fresh config.yml. Backing up the old one might seem a little pointless but I just thought some people might prefer that their old config not get completely removed just in case they happen to want to use it some time. Here's the new config I put together so you can have a look at it: https://github.com/ShadowRanger/Bukkit-AlphaChest/blob/master/src/main/resources/config.yml

If you have an idea for another way of dealing with the config situation please let me know. I haven't been able to find any other solution so yeah, just let me know.

Unless and until the configuration API supports comments, I'd leave it un-commented and document it in the README. Every time the plugin saves its config the comments will be destroyed, unless we implement our own config handler.

Alright I actually did try something like that already so ill swap to that system tomorrow when I have the time and then push a commit to my GitHub fork of the AlphaChest repo. I'll let you know when I do.

On another note, it would be great if kroimon could create a wiki on this repo, the one that's build into GitHub. Would be a great alternative for documentation instead of the README.

did this ever happen? lol

These changes sound good to me. Thoughts on having AlphaChest able to store more item data e.g. NBT data?

This would fix mod items having various aspects wiped upon loading items from the save file.

What sort of NBT data are you wanting to be stored? Can you please give me an example?

Well for example in Flan's mod there are vehicles with inventories and fuel levels saved in NBT data. Currently those inventories and fuel levels are wiped at restarts.

I can see why this wouldn't be added since the plugin already handles all default MC cases and the addition could just bloat the plugin more. I'm unsure on how much would need to be changed to implement this so let me know 😄

Hmm, adding NBT data support wouldn't be such an easy task. I'll look into it though and see if I can come up with anything. No guarantees though.

Also, could kroimon or Brianetta please let me know if you're happy with doing something like this? Once you do, I will be able to start work on it and get something done within a few days.