Register - Now accepting all Payment Methods (Economy API) [Stable]

Thank you, everyone! I ended up going with the source option and things appear to be loading normally. Now, on to testing!

(Ping: @ltguide @hatstand)

 

@Nijikokun I would like it if you would add a function to Method that gives the smallest value you can add to an account. To start off, I know iConomy5's is 0.01 and BOSEconomy7's is given with getFractionalDigits()

 

Is there a way I can use this to get prices from essentials items.csv and add that money to an iconomy account?

 

@LRFLEW I just use doubles, you if you REALLY wanted, you could add Double.MIN_VALUE

I developed MultiCurrency, BTW.

 

I actually did figure out the maximum amount of fractional digits in each plugin by a means of guessing and checking, then adding them to their respective Method classes (My Fork). I did notice that both MultiCurrency and EssentialsEconomy both don't round (and return -1 using my function), while BOSEconomy6 is just 0 . All the iConomy versions all seem to just be 2 decimal places, however I never got iCon6 to work, so I don't know for sure .

Like I didn't figure that out from your signature

Oh, and @ashtheking there is the problem with MultiCurrency being called "Currency" in the plugin.yml file and how Register tries to use it. Do you have any plans on changing the plugin.yml name or not?

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

Yeah, i realize now that i had it as Currency because I didn't realized that Plugins are provided their own data folder, and it was causing clashes. I'll add that to my next release.

 

I would rather this not become like Permissions where there are multiple different libraries to do the same thing. Just fork update the issues and send a pull request back, yes, I know the license allows you to do whatever, and If you feel like I am in the wrong you can completely do so, I would just rather there not be that entire issue AGAIN.

 

I understand your concern. The only reason I made my own version is that I felt that we had different opinions when it came to how this should be implemented. I am just about to release a new plugin, and I'm using my "Register" to support economies. I only posted it because I wanted an easy way for server owners to find updates easier and to allow people to try my way and get feedback on my implementation. If you want to integrate, feel free, and I'll drop my version. If you don't and still don't want this "duplicate" issue, I will be more than willing to remove my version from the plugin list and only use it for personal projects. I sure hope were on the same page

and what do you mean Again?

 

Permissions < to the Again question.

And your paragraph makes no sense, You never gave me a page to be on, and finding updates easier? It's already here, that's easy enough unless there is something missing.

I went through your code, it's the same as mine just the namespace has been changed and you made stuff static, which is not needed since it's already done previously in methods.

Preferred should be handled by the plugin, but I have an idea to fix the need for that anyway.

 

Ok, we are not quite on the same page. My "version" is pretty much the same, but instead of it being an AIP that gets added as source to the project, it's a plugin itself that plugins hook into. The reason Methods is static is it is the way plugins hook into it without having to find the instance of the plugin.

As for the page and "easy updating", I was referring to a page I made on dev.bukkit of my Register version (I thought that was clear). I added it because I wanted a way for when I released plugins that use my version of Register, I wanted a page I could easily link sever owners to so they can download it and for them to watch it for updates.


The way I see it, two things can happen from here that will make both of us happy.

1. We merge into my version. Although I see this as a long shot, you could decide you prefer my method of implementation, and you merge our versions. Feel free to do this , but I realize you most likely won't.
2. We merge into your version. I do have a couple things other than being static that could be merged (see Method.fractionalDigits() ), and as for my version, I would only use it for my projects and remove the dev page.

I see where you are coming from, and I want to make sure we can come to an agreement

 

Register is already setup as a plugin, thats why the jar is there.
But sure, merging is fine, the original is the one it should be merged into. I think you may have not noticed that Register is optionally a jar or source code. It's both, not a single method, some people prefer one way others prefer another.

 

ok. I thought since you didn't provide a plugin.yml file in the source that it wasn't a plugin.

I'll push a new pull request.

EDIT: https://github.com/iConomy/Register/pull/8

 

@Nijikokun

Making a plugin right now that will use register for econ support...getting this definitely.

I also want to give you thanks for this....as much as I really hate having so many plugins that seem to do the same thing (Permissions is a clear example here, Econ a smaller one), I appreciate not having to import all those classes and making code to support each of them.

You saved me a headache and a half for that....thanks!

 

Okay, for all this plugin.yml annoyance, my newest build fixes all of that.

 

You could've used [synt^ax=java] [/syntax]

Just remove the ^ and put the stuff in between those tags.

 

I seem to be having the same problems as Southpaw018, I did what you said, by adding all the JARs in the lib folder as an external jar, but I'm still getting the same error...

Code:

13:17:06 [SEVERE] Error occurred while enabling MoneyTest v1.0 (Is it up to date
?): com/nijikokun/register/payment/Methods
java.lang.NoClassDefFoundError: com/nijikokun/register/payment/Methods
        at com.unlucky4ever.money.Economy.<init>(Economy.java:17)
        at com.unlucky4ever.money.MoneyTest.onEnable(MoneyTest.java:25)
        at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:126)
        at org.bukkit.plugin.java.JavaPluginLoader.enablePlugin(JavaPluginLoader
.java:885)
        at org.bukkit.plugin.SimplePluginManager.enablePlugin(SimplePluginManage
r.java:278)
        at org.bukkit.craftbukkit.CraftServer.loadPlugin(CraftServer.java:178)
        at org.bukkit.craftbukkit.CraftServer.enablePlugins(CraftServer.java:161
)
        at net.minecraft.server.MinecraftServer.e(MinecraftServer.java:286)
        at net.minecraft.server.MinecraftServer.a(MinecraftServer.java:273)
        at net.minecraft.server.MinecraftServer.init(MinecraftServer.java:149)
        at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:337)
        at net.minecraft.server.ThreadServerApplication.run(SourceFile:422)
Caused by: java.lang.ClassNotFoundException: com.nijikokun.register.payment.Meth
ods
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at org.bukkit.plugin.java.PluginClassLoader.findClass(PluginClassLoader.
java:36)
        at org.bukkit.plugin.java.PluginClassLoader.findClass(PluginClassLoader.
java:24)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        ... 12 more

Line 17:

Code:

this.Methods = new Methods();

 

@Unlucky4ever Here's how I did it. Credit to @ltguide for the simple and solid Class.forName solution.

In your plugin.onEnable() code, don't declare your server listener as final or instantiate it. After your class variable declarations and before you print to the console or log that your plugin is enabled:

Code:JAVA

if (!loadRegister()) return;

and that function:

Code:JAVA

//Return values: true, loaded; false: not loaded OR was just downloaded and needs reboot
    private boolean loadRegister() {
        try {
            Class.forName("com.nijikokun.register.payment.Methods");
            serverListener = new MyPluginServerListener(this);
            return true;
        } catch (ClassNotFoundException e) {
            try {
                BlueTelepads.log.info("[MyPlugin] Register library not found! Downloading...");
                if (!new File("lib").isDirectory())
                    if (!new File("lib").mkdir())
                        BlueTelepads.log.severe("[MyPlugin] Error creating lib directory. Please make sure Craftbukkit has permissions to write to the Minecraft directory and there is no file named \"lib\" in that location.");
                URL Register = new URL("[URL]https://github.com/iConomy/Register/raw/master/dist/Register.jar[/URL]");
                ReadableByteChannel rbc = Channels.newChannel(Register.openStream());
                FileOutputStream fos = new FileOutputStream("lib/Register.jar");
                fos.getChannel().transferFrom(rbc, 0, 1 << 24);
                BlueTelepads.log.info("[MyPlugin] Register library downloaded. Server reboot required to load.");
            } catch (MalformedURLException ex) {
                BlueTelepads.log.warning("[MyPlugin] Error accessing Register lib URL: " + ex);
            } catch (FileNotFoundException ex) {
                BlueTelepads.log.warning("[MyPlugin] Error accessing Register lib URL: " + ex);
            } catch (IOException ex) {
                BlueTelepads.log.warning("[MyPlugin] Error downloading Register lib: " + ex);
            } finally {
                pm.disablePlugin(this);
            }
            return false;
        }
    }

and the serverListener:

Code:JAVA

//Credit for the below: Nijikokun @ [URL]https://github.com/iConomy/Register/blob/master/src/com/nijikokun/register/example/listeners/server.java[/URL] :)
public class MyPluginServerListener extends ServerListener {
    private MyPlugin plugin;
    private Methods Methods;
 
    public MyPluginServerListener(MyPlugin instance) {
        this.plugin = instance;
        Methods = new Methods();
    }
 
    @Override
    public void onPluginDisable(PluginDisableEvent event) {
        if (Methods != null && Methods.hasMethod()) {
            Boolean check = Methods.checkDisabled(event.getPlugin());
 
            if (check) {
                plugin.Method = null;
                MyPlugin.log.info("[MyPlugin] Payment method disabled. No longer accepting payments.");
            }
        }
    }
 
    @Override
    public void onPluginEnable(PluginEnableEvent event) {
        // Check to see if we need a payment method
        if (!Methods.hasMethod()) {
            if (Methods.setMethod(event.getPlugin())) {
                plugin.Method = Methods.getMethod();
                MyPlugin.log.info("[MyPlugin] Payment method found (" + plugin.Method.getName() + " version: " + plugin.Method.getVersion() + ")");
            }
        }
    }
}

That'll take care of it, included as a library. Just add the reference to your Jar manifest (example).

 

I just went ahead and updated to the newest register (to support iCo6), and it seems that there are some API changes. However, your linked example usage was apparently neither updated, nor does it still exist (this one).
So I'm kind of not sure how to exactly use the new calls ...

Also, your API listing on the first page is outdated as well. It is no longer Methods.setMethod(Plugin) but Methods.setMethod(PluginManager) and there is a new Methods.createMethod(Plugin).

Please update your explanations and maybe post another example usage.
(I'll tag your name @Nijikokun just to be safe ... Dunno if you still follow this thread)

 

I just read it, I'll change it. It happened when I pulled the changes.

 

Thank you ... Now since I still can't find any documentation, I looked at the sample JavaPlugin implementation on github (I know it's not a full plugin, but it's worth a try ...).
Now I have come to the assumption that it is now just enough to call that in onEnable:

Code:java

Methods.setMethod(getServer().getPluginManager());
 
// and checking if it succeeded like that: (?)
if(Methods.getMethod() == null) ...

Correct? Not correct? Also, what should I add to the soft dependencies in plugin.yml?

Methods seems to have a working getDependencies() method, but what use is that when I can only access it when my plugin is already loaded? Should I just manually add all the listed entries in softdepend?

Questions over questions ...

 

Since I'm %150 responsible for this API change, I'll answer this one.

Yes, you have the right idea. I changed Methods.setMethod(Plugin p) to Methods.setMethod(PluginManager pm) because after looking at the code, I saw it was scanning the plugin's plugin manager anyways, and this made it simpler once you add in the (soft)depends system.

This is suppose to be it's own plugin with soft dependencies already defined (as of my pull), however as of #1060, hard dependencies don't work right, and makes making it it's own plugin too complicated. Feel free to add the soft depends to your project (or not . You can always just use the listener and call Methods.getMethod(plugin.getPluginManager()) when there is a new plugin loaded and Methods.hasMethod() == false)

oh, and @Nijikokun it never got changed from when I changed it to "com.LRFLEW.register.*" due to compatibility issues . Mind changing that back for me .

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

which location?

 

Can you please add Git tags on each release? I often have to hunt around to find the stable version after it has been buried under mountains of commits...

 

o_o git has tags?

Also, 1.2 is out, using the jar as a dependency is preferred.

 

Using Register as an external dependency is turning out to be problematic. Have a look at this post: http://forums.bukkit.org/threads/mi...-on-signs-maps-1060.18424/page-11#post-681972

Basically if any other plugin is loaded which contains an older version of Register (CommandSigns is probably the culprit here), then the method described in http://forums.bukkit.org/threads/re...s-economy-api-stable.16849/page-5#post-631610 won't work, since the Class.forName("com.nijikokun.register.payment.Methods") check will find the older version, and then an exception gets thrown when you try to use it.

Seems to me I'll need to move back to including Register in my plugin with a package name change - any other suggestions?

 

Yup, I've had this issue previously as well. I rename the package and include in my source in order to avoid problems like this.

 

Please help, I don't know how to use this for my plugin :S

 

That's what I've ended up doing too. An external dependency would be nicer (avoids duplication of code, primarily), but I think it's too fragile a solution. Any plugin which pulls it in locally will break this scheme, as I've discovered - for example CommandSigns uses a very old version of Register statically, so any servers which still have this plugin loaded won't be able to use any plugin which tries to dynamically connect to Register.

Here's a probably controversial idea: why not treat economies like permissions, and get a "supereconomy" API into Bukkit, allowing economy plugins to register themselves as economy providers? If this could happen, I suspect every plugin author who's ever had to support an economy system would breathe a huge sigh of relief. One API to support, no external dependencies, and server managers can still install the economy plugin of their choice.

Admittedly, there are some obstacles:

• Agreeing on the API in the first place, but Register has shown that this is possible - in fact, given that quite a few plugins already use it, it might be feasible to use this as the supereconomy API
• Getting the API accepted into Bukkit
• Getting economy plugin authors to update their plugins to work with the new API, similar to how permissions plugin authors updated theirs

Thoughts?

 

@desht - look at Bukkit's ServiceManager API.

 

Looks useful from the reference on jd.bukkit.org, but I couldn't find any docs on how to use it, or indeed real-world examples of it actually being used. Do you know of any?

Also found this thread: http://forums.bukkit.org/threads/services-api-economy.12748 which made for some fairly depressing reading.