Well, in my last post I was letting this drop, but since you feel the need to instruct me what an API is. I will quote the Wiki.
(API) specifies a software component in terms of its operations, their inputs and outputs and underlying types. Its main purpose is to define a set of functionalities that are independent of their respective implementation, allowing both definition and implementation to vary without compromising each other. In addition to accessing databases or computer hardware, such as hard disk drives or video cards, an API can be used to ease the work of programming graphical user interface components, to allow integration of new features into existing applications (a so-called “plug-in API”), or to share data between otherwise distinct applications.
Well That is EXACTLY what I was proposing. The core server already has online player messaging via chat and /tell etc. and I assume that can be modified and expanded by a plugin via the API. What I was proposing was an offline player to player messaging system. Call it /tellmail if you like. The API defines the core communication functions, rudimentary admin functions and database storage only.
Any plug in developer would be able to build on the API and enhance as desired. A corresponding client side GUI could be implemented to take advantage of the features implemented by the plugin, OR if missing, fall back to the server functionality and still provide minimal services.
I realize this is not a priority for sponge. Unless you have extra coders looking for something to contribute
There are lots of coders looking for anything to to here, but we don’t want them all working on sponge it self, they should instead code cool plugins.
That way we can keep things concise, packaging similar features into easily disputable and update-able independent units, we call them plugins. As apposed to putting all the features in one unit, sponge, and having it be a massive download, and a massive undertaking to update, rember that each feature we add will eventually need to be updated, and we will need to wait for all the contained features to be updated before a new version could be released. Where if we brake it up into plugins built on top of the api each can be used, distributed, downloaded, updated independently.
tl;dr
board coders: code cool plugins pls, leave the core sponge team to their devices
People with neat ideas: post them as plugin ideas, perhaps someone should start a cool plugin ideas thread so the coders can do something and people can suggest their ideas there.
God, wouldn’t that be amazing though, a modular version of essentials for each cmd/cmd suite… Dreams are nice… Maybe the essentials devs will see this lol!
I’m sure it’s been suggested. I would guess they’re just not interested in restructuring their plugins into more modules than there already is, since it is very generally modularized into Chat, Spawn, Protect, GroupManager, etc. It’s just not specific enough for a lot of people
Ok, really? I see the point that is trying to be made here but ask yourself. What is really the advantage of having a economy and / or chat API built right into sponge? Why is vault bad? Why can’t plugins / libraries similar to vault be built? Sponge is built as an API which means all it needs to do is assist the developer in connecting with the server. The last time I checked a vanilla minecraft server does not have an economy built into it so by having an economy sponge would be adding features rather than simply allowing plugins to interface with the server.
What they could do is give a checklist for the diff systems. Default download would be the same but the check list would just edit the plugin.yml file to not include certain cmds.
What @octoshrimpy said, but also, just editing the plugin.yml to remove commands would start causing the plugin to throw errors when it tries to register commands unless they checked if a value exists in the plugin.yml, which may not work well, if possible. I think it’d make more sense if they just separated the modules they have into more specific modules, or even modularized the modules into classes saved in Essential’s data folder that it’d load from, which may not be an easy thing to do.
I’ve seen a few where they have a config.yml, and a plugin.yml (which no user ever touches since it’s part of the jar >_>) and then a commands.yml
home: true
fly: true
foo: false
msg: true
bar: false
and so on. After peeking under the hood, (for safety, ofc) I noticed that any value that matched null would then be set as false, and would be written to the file as such. Not a bad idea at all.
That’d be a decent idea. Maybe just have a config that can enable or disable more specific groups of functions. Although I guess they may need to go through a lot of stuff with a fine tooth comb to make sure they handle everything.
@octoshrimpy
Nice Idea. But the problem is that 50 plugins for each command take way too much RAM to use. I am currently rewriting UltimateCore and I will make it so when a command is disabled, it doesnt cost any CPU or RAM.
Nooonononoo… all the commands are in the same plugin, but all of them are toggleable from within a command file. of course, they’ be comented with explanations, and other command dependencies (/r won’t work without /msg and so forth)
Essentials uses lazy class loading for commands, meaning that java doesn’t know the class file exists until someone tries to use it (it even checks permissions first!). That means if you don’t give anyone permission to use ‘/whois’ the code required to run ‘/whois’ won’t be loaded.
For non-command functions like Jails, this is slightly different. With this Essentials does a quick check to see if the feature is enabled, and if it is valid, for example, is there any jails set. If it isn’t Essentials will either skip registering or de-register the event listener meaning Essentials won’t even attempt to listen to unrequired events.
For people who use /timings at the moment, they would be able to test this by trying /setjail and /deljail, to create an delete jails, and seeing if the jail event listeners show up.
Assuming I get around to releasing a version of Essentials for Sponge, I will bake in the same features.
So you want to make sure offline players receive the message if they get online?
Can be done with a plugin WITHOUT having to worry about databases. So far I understood plugins will have access to NBT of entities. So its very simple.
If the player isn’t online, store message in NBT of the player. When player joins check messages and send them. No API functionality needed at all.
The problem is that you’re suggesting functionality that doesn’t translate to something generic. It has a single use case that cannot be attributed any sort of “reuse”, and thus has no place in Sponge. The functionality can be broken into three phases (online status detection on message sent, message storage, and message sending on player join), all of which can be not only handled by a plugin (all the required hotspots will exist), but abstracted away into an API by a plugin, if that’s what you want.
Or, you know, you could do things the right way and not fuck around with NBT stuff when there is absolutely no reason to do so.
NBT is 100% safe (as long you don’t overwrite existing tags). Also notice, if sponge would have a offline message system I am positive that this will happen through NBT.
