Too Many Things Doing Same Damn Thing

but why dont u ask for the feature thats missing? now i have one more problem of splitting-.-

 

Your plugin support more than only the core. You also managed the storage of the values etc. This system here only tries to make the economy plugin replaceable. For example the permission system. There is your Permission plugin, than a newer Permission plugin, Group Manager and the discontinued group... Or forgot the name.

Fabian
--- merged: Mar 4, 2011 12:02 PM ---

Some times the developer don't want to add the feature?

Fabian

 

for i like to code, if i would ask for the feature i wanted then i would not use any other part of the plugin and i feel that is a waste

 

ok thats a poit i anderstand, so now we have some plugins that have a new idea and growing bigger and some plugins that only support some features because the devolopers think the rest is a waste.
i think there some possibilities:
1. one developer makes the basic plugin with an good api and the others build plugins for this plugins with the features (this is the craftbukkit concept)
2. all features are in one plugin and there is the possibilitie to disable the not needed features (e.g HuckleberryGeneral)

 

I've been thinking of making a plugin of my own. A plugin in which I will require money, cuboids, protections, etc. But looking at the available plugins from a distance I do not know if I'll be able to use some of the existing plugins. I heard something about putting the jar files directly in the root allowing other plugins to access their functions without exposing the commands of those plugins to players? I might give that a try.

Some people like me need functions provided by some plugins but without some of their features. I know that removing the permissions to those function is a possibility but it is troublesome to maintain if I update the plugin and some new commands have been added, and I can't keep the older plugin version because it is no longer compatible with X version of bukkit.

P.S. Another thing I am wondering, say developper A created plugin 123 but did not provide the source and he decides to stop updating it and making it compatible with the newer bukkit versions. What must we do?

 

Well, the thing about plugins is, regardless if you write a wrapper to wrappers, you will still have to deal with a wrapper that wraps your wrapper for a wrapper in the next wrapper.

Initiate loop sequence.

People need to request, and stop thinking "I like coding" or "I didn't like this single thing" and request, or offer to create it. I'm not opposed to people coming over and adding things to a plugin.

Anyway, I don't oppose to the idea, I just think that there are better ways.

 

Guys, I meant creating an API for economy. It would simplify the whole thing. Consider getting help from current Econ developers like Niji to speed up the process.

 

As long as you count Permission/Economy plugin to the wrapper. I wouldn't and the English Wikipedia also:

Your plugin don't provide adapter/wrapper like methods, because you providing the core functionality (and some more) to provide economy like support. But the adapter (as I linked before) only “translate” or find a economy plugin. So it is easy to create a new economy supporting plugin and registered it. Now another plugin which want to use the functionality by simply asking: “Give me an economy plugin”. I mean mostly only some general features are needed. If a plugin need special features of this plugin this plugin could use the old way for search specially for this plugin.

Fabian

 

What I said went over your head and no, it does exactly as described in shade's post as to what it should do.

Therefore, mine is an actual wrapper for an economy. Obviously, you don't read the api much.

 

Okay I see what you mean (And the API is very basic). Now lets try to redefine my approach: I want to prevent that there are different standard. Instead I want that the plugin which uses the economy plugin only has to know one plugin and ask him for the economy plugin installed on my server. So it won't replace your plugin it only manages each economy plugin, so some body else could simply write a economy plugin, register the adapter and every plugin used the adapter manager could use the new plugin. The advantage is, that the new plugin don't have to write a plugin which simulate to be another plugin.

Fabian

 

Like Fabian points, we dont want a system like GroupManager pretending to be Permissions...

 

Here's the problem: Once you write your API wrapper, who says all the API devs are going to switch to your wrapper? Writing a wrapper for Economy won't make iConomy 2.2, 3.0, and 4.0+ plugins all able to coexist. It would make it so plugin authors, who already are frustrated by the amount of changes to accommodate various versions of various APIs, are frustrated by the thought of having to switch, yet again, to something that claims to provide compatibility for all, but will end up mostly being another point of failure to confuse the mess.

When it inevitably fails, and isn't updated within the minute, it will only further fragment the community as plugin authors blame you for the failure, and switch their plugins back, or to other systems yet again.

 

But at the moment it isn't better. Because I as a developer has to implement support for each single implementation. I think if the developers of economy plugins could share one basic API it should be a lot easier. I mean, they could break the API each other (as happened with Permission > 2.1 and GroupManager). This is really annoying and you as a plugin developer couldn't decide what you want to support. I want to use GroupManager so I could edit the permissions on the fly without editing the file.

I don't meant that I have to decide which API they should use. Instead the main developers of permissions/economy/… plugins could discuss together and create an easy long term supported API. I mean when Permissions don't match the previous API? Only once (with the multiverse support), but I don't know how often I couldn't update my server, because some plugins couldn't use the new Permissions and others could use them.
Also my plugin don't restrict the API. It is possible to easily add an own API by simply adding the name and create an Interface extending the Adapter Interface.

Fabian

 

Where I am working at, we are developping a single universal software that will be used throughout each divisions. But, we are going to change the UI to hide and show the different options they each require or don't require. The backend is the same but the frontend will be different.

 

I added a pull request that could help with this.

It allows interfaces to be registered with the server. A plugin that wants to use that function would then call

server.getInterfaceManager().getInterface("SomeOtherInterface");

Interfaces have an interface name, but also a name for the implementation.

 

The problem with this is that software written in this manner is inefficient. It may work fine for the purposes your employer is using it for, and it is likely why it is written in this manner. Efficiency of execution was not as large a concern for this application as was ease of deployment. That's why you have a job, and why you designed it this way. The software fits the task it is designed for.

Writing realtime interactive applications, and especially multiuser realtime applications require efficiency of execution as their primary function. In terms of server software for realtime applications, and specifically for a core server API less really is more. The less cpu cycles, RAM, and numbers of lookups the core requires, the more it does its job of being an API geared toward enabling the plugin developer to execute complex systems based upon that core functionality, because the backend to his super awesome AI, or terraforming algorithm has less to worry about fighting the core server process for system resources.

The concept of permissions is a pretty much universal constant, and as we know it's already going to be part of the core backend of Bukkit.

Economy is a dicier prospect. I'm sure several of the economy plugins are great at what they do, and it's such an abstract system that it really should be as transparent as possible. However, unlike permissions not every server admin wants or needs an economy, just like not every server admin wants or needs a complicated pvp ruleset, or a log, and rollback control for vandalism, or exploding chicken eggs and ion cannons.

Some servers have absolutely no need for an arbitrary currency system in minecraft. The base game itself is simple, functional, and fun without it. My server, and the plugins I use and develop for it are specifically tailored to my needs as an admin. My server has absolutely no need for currency.

The thing to remember is that Bukkit, by design is meant to be a transparent and extensible API that allows admins to add functionality on an as needed basis. A good baseline for what should be incorporated in to the core of that system is simply to take a look at vanilla minecraft and see which systems really define the core of the game.

Permissions and now whitelisting are important core features that are of use to everyone. Even if you run a chaos server, you'll want that whitelist avaliable if you need to upgrade/test new systems or builds in a live environment. Permissions support is an extensible QoL upgrade to the basic op list that needs to exist to support plugin developers in an abstract manner. Economy is a far more niche system and is really served better as a well designed external interface to bukkit rather than part of the bukkit core.

I guess the point I'm trying to make is that at the end of the day we're modding the same base game, so a project like bukkit should be far more concerned with making the interface for plugin developers as transparent and efficient as possible. It isn't Bukkit's job to extend minecraft. It's Bukkit's job to extend what plugin developers can DO to minecraft.

 

Umh just wanted to make a note here, that i created an APIHandler-Plugin which now needs to get its standards defined...
http://forums.bukkit.org/threads/misc-apihandler-0-2-connecting-plugins-3-501.7338/