Too Many Things Doing Same Damn Thing

There are 5 different economy plugins. 5 different plugins that do basic permission support. Building a plugin on one set of these will have your users cry out to support all of them god damn it. Fuck.
/End Rant

What I'm proposing, is a handler/middleman plugin for the general things that most build on. The two major ones being Economy and Permissions. This middleman would act like How Bukkit is the middleman for Plugins and Craftbukkit (not that we have other flavours of Craftbukkit yet).

Basically, all the current Ecomony + Permissions plugins would have to include this plugin in their build path (oh noes), in order to have their main class (that extends Plugin) implement an interface along with it's desired methods. These would be standardize functions necessary for other plugins to use.

Let's cut to the chase and give an example or two.

Here's the MoneyHandler API. As you can see, it follows it's own standards (as the plugin is essentially just a proxy with a config letting you choose which).

Code:

public class MoneyHandlerProxy extends JavaPlugin implements MoneyHandler {
    @Overrride
    public void onEnable() {
        this.moneyPlugin = getConfig().getMoneyPlugin();
        Plugin test = getServer().getPluginManager().getPlugin(moneyPlugin);
        if (test == null)
            ... disable ...
        else
            moneyHandler = (MoneyHandler)test;
    }
    @Overrride
    public MoneyAccount getAccount(String id) throws UnregisteredException {
        return moneyHandler.getAccount(id);
    }
}

public interface MoneyHandler {
    public MoneyAccount getAccount(String id) throws UnregisteredException;
    public MoneyAccount newAccount(String id) throws InvalidIdException;
    public List<MoneyAccount> getAccounts();
}

public interface MoneyAccount {
    public boolean canPay(int amount);
    public void pay(int amount) throws MoneyException;
    public void pay(int amount, MoneyAccount target) throws MoneyException;
    public void collect(int amount) throws MoneyException;
}

What the economy/permissions plugins need to do:

Code:

public class GoldyBankster extends JavaPlugin implements MoneyHandler {
    public Map<String,GoldyAccount> accounts = new HashMap<String,GoldyAccount>();
    @Overrride
    public MoneyAccount getAccount(String id) throws UnregisteredException {
        MoneyAccount account = acccounts.get(id);
        if (account == null)
            throw new UnregisteredException(id + " is not a registered account id.");
        else
            return account;
    }
    ... other methods ...
}

public class GoldyAccount implements MoneyAccount {
    public GoldyAccount(String id, Runnable load, Runnable save, allable<Integer> getBalance, MoneyRunnable setBalance) {
        ... boring shit ...
    }
    @Overrride
    public void pay(int amount) throws MoneyException, InsufficientFundsException {
        int newBalance = balanceAfterDeduction(amount);
        if (amount < 0)
            throws InsufficientFundsException("Insufficient funds in account " + getId() + ".");
        else {
            setBalance.run(newBalance);
            save.run();
        }
    }
    public int balanceAfterDeduction(int amount) {
        return getBalance.call() - amount;
    }
    @Overrride
    public boolean canPay(int amount) {
        reuturn balanceAfterDeduction(amount) >= 0;
    }
    ... other methods ...
}

An example of it in the works:

Code:

public class Towny extends JavaPlugin implements MoneyHandler {
    @Overrride
    public void onEnable() {
        Plugin test = getServer().getPluginManager().getPlugin("MoneyHandlerProxy");
        if (test == null)
            ... don't handle money ...
        else
            moneyHandler = (MoneyHandler)test;
    }
    @Overrride
    public void payTaxes(String id, int amount) throws MoneyException, InsufficientFundsException {
        moneyHandler.getAccount(id).pay(amount);
    }
}

Of course I do know that iConomy has just decided to use doubles for money values... (tut tut). They can either decide to Math.floor(balance*100), or we can have a debate here on why all plugins should use double for the handler (int can convert to double so there's no real problem, it's just using floating points for money in general...).

However, for permission type plugins, the most useful is checking if the player has x permission node (and inheritance [grousps etc]). Everything else is secondary really, but could totally be added.

Why am I suggesting this? Well we've already had quite a lovely fiasco with Permissions and iConomy being simple with a large amount of support behind them. Dominating the permission and economy sector. They may be stable now, or on their way to again, but from this, a ton of others popped up. Sure we can place all our trust in these new plugins, just like we might have done with their ancestors, but we should also be planning into the future (need I remind you that Bukkit itself was making it's own permissions setup).

/End of the ramblings

 

Creating another common interface that is not bukkit only further compounds the issues.

Permissions should and will be implemented in bukkit.

Economy... I don't really use, so if you wish to further muddle the field, have fun.

 

I don't mind if it was included into bukkit, the permissions proxy at least as they will have their own built in, and it seems that will be dependant on yml, which some aren't as fond of, meaning an alternative should be there. However since economy has pretty much jack to do with minecraft itself as most are arbitrary credit system, it should be it's own plugin.

 

Same goes for the banlist. I've had the ban list reset at least twice because we changed plugins... A ban list should be a specific file in the root folder that every ban plugin use.

 

Jep that would be nice, it you could easily replace the permission/economy plugin. For example I'm as developer has to decide which plugin I could support. And mostly the only need basics. The only problem is, if you use more than one plugin which the same abilities (e.g. two economy plugins because they also support some other useful stuff (not economy related))? Also how I could get the helper plugin? Should I test every plugin if it is there and enabled?

Fabian

 

Many plugins are doing the same and thank god for that!
That's like saying "all the car companies do the same - 4 wheels, windows, it goes forward, backward, ...".

 

There is one good side about many plugins doing the same : competition.
In a world with competition, it makes the plugin creators want to come out the best in this race.

 

I'm not sure the idea behind Capitalism always applies here. You've got plugins with a virtual monopoly (WorldEdit, WorldGaurd, Minecart Mania), but they are all extremely high quality. Then you've got 5 plugins competing for permissions, and none of them can see to do it right.

The open source idea of collaboration is key here. With the permissions plugins, every author is god, and any naysayers are heretics. That's not how it should work.

 

Yep and I don't know how this is in your contry, but here the cars maximum width is 2,55 m. So every car company has to design cars within this width. But they could do other changes like, colors, automatic shifter (? don't know the english word), 3 or 5 doors etc. But all cars could use the same street. But in Bukkit there are cars that drive on the left some on the right side etc.

Fabian

 

Maximum Car Width = McDonalds Drive Through space

 

Then maybe I should go ahead and finish my own variant of Permissions after all, and increase the entropy a bit

 

But if they are not replaceable, because some plugins need this plugin and other plugins need the other ones, the developers of the plugins don't have to be affraid of that some admins don't use them.

Fabian

 

My post shouldn't be interpreted to be for or against the OP, I was responding to the quoted post.

However, I am in favor of a universal standard.

 

Ah okay sorry for misinterpreting. Without changing bukkit this could be done by a Serving plugin. Every plugin with a universal interface implementation could register (e.g. an economy plugin could register it at this plugin that this economy plugins is available). Then the plugin which want to use a universal interface can query this plugin which plugin is available.

Fabian
--- merged: Mar 3, 2011 9:48 PM ---
Okay I tried to create a (very) basic version. At the moment the two variables are bugging me. So I'm working on a nicer version. But I want to know if this is what you meant.

Fabian

 

I am sorry for what I posted above, I also am for having only 1 plugin for each things.

The way I see it happen is that Developper A wants a plugin to do X. The existing plugin made by Developper B isnt updated so Developper A creates his own plugin. Developper B updates his plugin. Now we have 2 plugins, loop goes on...

What would have been better is if Developper A took the source of Developper B and fix it, but this isn't always possible. Sometimes you want to get permission before you apply modifications and sometimes developpers dont like when people take their code and applies changes in a different way.

Edit : The other scenario is when you have 2+ plugins and none of them work

 

Argh I missed to add a link.

@ZachBora: But this happens to all plugins. But in this thread only the server administrators have to manage this. For example what if I want to support GM and Permissions? Either I decide me for one implementation, or implement both. What you mean is that features don't walk back to the original thread. Mostly this happens if the first developer don't want to have this feature.

Fabian

 

Or Developer A make some changes to Developer B's code and makes a pull request so Developer B can merge the fix with his own changes.
I think collaboration works much better for the end product than competition in this case. Instead of having 100 plugin developers doing different versions of ScrapBukkit, why not fork / contribute ScrapBukkit and make it do what they want the open source way?
Plugin developers rushing new features just to compete with other duplicates should also not help Bukkit stability in general.
I guess common API's like you're proposing (like Bukkit itself) are a good step on the way and would definitely make everything play together better especially for economy plugins.

 

I've only started last week with Bukkit on our server and I can already see problems caused by the many plugins. I've tried different combinations. We lost the ban list 2 times. We lost the homes 2 or 3 times. We lost the warps 1 time. (I'm excluding in that calculating everything that we had to reconfigure from moving from hmod to bukkit.)

 

Yeah i already made a thread about this in the plugin developer forum (was called "Interfaces Interfaces Interfaces") but people didnt seem to like the idea, or maybe my english is just too bad so they just didnt understand me.

All it needs is a description field in the config.yml (for the topics that this plugin is covering) and an Observer pattern for each topic where plugins, that cover certain topics, can register to. While each topic (eg. permissions, groups, currency ...) also needs its own interface, a plugin has to implement.

Other plugins can then refer to the so called subject (the one that is broadcasting to all teh listeners) and each plugin could make use of permissions no matter what permissions plugin is used.

 

Remove all Permissions and Economy plugins. Let Bukkit handle that alone. People can only connect to them like we do to the current ones.

 

Bukkit has no built-in economy system.

 

yes, this is what we see with craftbukkit. only think about what would happen if somebody decides to make a new CB with new features-.- this would be a nice chaos...

 

Dude, awesome. That's way more dynamic that I would have done (I was considering one proxy per type >.<). Props.

Lies: http://forums.bukkit.org/search/482557/
Unless, of course, you're talking about a secret forum which I'm not a part of. In which, I hate you all. Purple me dangit!

Even when your code is the dominant thing used, you should still code your plugin against an API. Collaberation is great so long as everyone involved has the same idea in mind. The fact that anyone wanting to fork the idea using something else, shouldn't create a whole new standard (ie all the old code would be rendered useless for it). Which is generally why GroupManager had so much sucess (it's fake plugin is actually what sparked my thoughts on this).
--- merged: Mar 4, 2011 9:49 AM ---

Except it would only break the plugins that are retarded enough to compile against craftbukkit. Craftbukkit itself revolves around the API Bukkit.

 

iConomy is built to be an economic core, and thats what we are / have been doing since the beginning.

If you don't want to have a credit system, there are physical systems but really the credit / money system is basically better.

Physical is the same as just having it in your inventory and therefore no need to use one.

 

She IS talking about a secret forum which you're no part of I think the problem is much more apparent now then it was at the time. Anyway, I meant to say that I really support you're idea, regardless of wishing to see less duplicate work. Hope you didn't misunderstand.

 

But permissions is not in the master branch and there is no economy api available. So I think here we could start defining one.

Thanks a lot.

And also you search don't work:
Bukkit Forums - Error

The requested search could not be found.

Have a look there: her thread found by: Advanced search after “Interface” from member “Isabaellchen”. Returns three results.

Fabian

 

i made my own econ mod for i don't like iConomy and my friends are thinks my econ mod is better then iConomy

 

This statement is like saying your mom thinks your art is a Mona Lisa. Just saying. The point here is that if you followed this standard, your plugin would be able to use every economy addon that adopted by this standard as well.
--- merged: Mar 4, 2011 11:49 AM ---

Niji, the point is people want to make their own cores, but all the addons for iconomy won't work for the new core. They addon dev would have to then compile against all cores. This lets those devs and the cores code against the same thing. If you want something besides the standard api, request it to be added to the api for all the other cores to standardize with. Hell, I'm thinking of a PlayerOfflineException or possibly seeing if there's a way to edit the inventory of an offline player for economy based on that. Credit based economies wouldn't worry about throwing it.
--- merged: Mar 4, 2011 11:49 AM ---

D:
--- merged: Mar 4, 2011 11:51 AM ---

I think searches are restricted to an IP then. Btw, I can't see that. >.>

 

Or cookies. But maybe you have to be a plugin developer, to visit this forum.

Fabian

 

i don't really understand. why i made my econ plugin is for i dint like iConomy so i made my own