We should create a standard for Plugin Development.
This standard should define:
What folders should a plugin create (Lowercase, the same as the plugin name, …)
What permission nodes should the plugin declare (All nodes with a standard name like pluginname.whatever)
What commands does the plugin handle (I hate commands that register commands like /world or /player, they should register /pluginname whatever, unless we are talking about essentials (/spawn, /home…) or complex plugins.
Also Sponge should check the list of plugins loaded and check it with an optional config list (To check that all expected plugins are loaded) and to stop the server if the owner expects some plugin to be loaded that is not loaded (Because it may have crashed).
The plugin folder should/would be the name of the actual plugin (ID).
As for every other point, stop trying to police. It’s not our job to do so. If a shitty plugin is made no one will use it. If they do then there is a demand and WE should adapt to support what the community want.
I will agree with Kevin96AT on the matter of adding a file with permissions and possibly the commands associated with it. It’s simple and it was one of the weaknesses of Bukkit, having to go to every individual page for every plugin to hunt down the plugin permissions and commands associated with it. With his suggested idea, you only have to look at one place for permissions, your own plugins folder. I’d definitely support adding that to the system.
I think there should be a kind of guidelines for plugins - if there will a distribution platform, plugins which do not match these maybe could get banned. This leaves the opportunity for server owners to create shitty plugins, but if they want to release them via the platform, they have to pay attention to those little formalities.
Would make permission management or something like that a lot easier!!
In my opinion, those guidelines don’t have to be very strict - I think it’s okay if they are limited to name + folder, the permissions format and no reload command but handling a ConfigurationReloadEvent (of course only if it’s implemented ;)) - last thing would require that the files are checked by a staff, as some plugins don’t have a config.
Also a permissions.json, a commands.json, a help.json and using the translation API (if implemented) should be suggested and the uploader should get warned about not including them.
Pretty much the only thing that I agree with the OP is that there should possibly be some basic formatting control of the plugin folder name for its config, if you do it through the plugin ID name then you could restrict the plugin id name to common non-special character names, kind of like what they do with bukkit.
Some of the plugins in bukkit do this already(like /wg for the worldguard control commands.), but it’s the decision of the plugin authors whether or not they want to do that, and it should stay that way(That’s my opinion.).
Well I kind of replied with the mind set of what the OP would want which sounds a bit like a restriction of command names, which is why I may have come off in a bit of a brash way.
I really like this idea. With the permissions I suggest that the permissions for that specific plugin can be divided into groups as said, but there is still a central permission file that would inherit from these groups using pluginname:group.
For example, Essentials permission file would have a group like teleport, that allowed all teleportation commands, then in the central permission file you could just give the owner the teleport group. This way the next day you could give the same teleport group to donators without a lot of work.
If you ban one on a guideline you have to ban ALL who break that same guideline. Then it’s not a guideline it’s a rule.
If you want to create a tutorial for writing plugins you are more than welcome. Forcing people to use it is definitely a no-no.
Sponge is an API to help and encourage plugin development. If we go the route of “YOU MUST DO IT OUR WAY” we fall into the horrible ways of Bukkit.
Innovation comes from experimentation and in most cases it comes from people not trained/brainwashed into thinking the same as everyone else. Lets not stifle that creativity before it’s even had a chance to see the light of day.
Actually. If you open up a bukkit plugins jar-file with winrar or some other archiver you’ll notice that most include the permissions in the plugins.yml file that you can find there.
The plugins yml file is being done away with in sponge, so you would have to rely off of getting the perms off of the plugins pages for the individual plugins, if there isn’t another way if getting these perms.
Use a plugin if you want to. If a plugin is well documented and contains what I need, I will most definitely use it over a plugin that is not well documented and has no readily available support.
I think the idea of having the commands.json, permissions.json is definitely a great idea, but thats provided the dev keeps those files updated as they make changes to the plugins, there is nothing more frustrating with bukkit than having to dig around for permission nodes or nodes that don’t match up to what they have listed, sometimes resorting to checking the plugin.yml to find its incorrect as well so turning to a decompiler and digging throug hsource for them.
as a developer (and i know there’s a handful that agree with me on this) i kinda found it unnecessary for there to be anything outside of the code (e.g. the plugin.yml in Bukkit). of course, this is purely preference but outside configuration files everything can be done by implementable classes and/or annotations as done in the main class of a Sponge plugin (@Plugin(id="", name="", version="")).
