Discussion in 'Plugin Development' started by mbaxter, Sep 12, 2012.
Oh, you mean calling it in the Main Thread.. not in another Class.
Doesn't matter what class you call it from, it matters what thread is executing the method in that class.
Out of interest, how does one go about multithreading? (not in bukkit, I know how to use the scheduler api)
This one isn't so much of a mistake as a pet peeve of mine: When developers post plugins and include something in the description along the lines of "This is my first plugin, be gentle."
I see plugin development as developing a product and after you develop it, you have to sell it. If you said something like that in a sales presentation, I personally would not buy from you.
As far as mistakes go, compiling against CraftBukkit when they really only need to compile against Bukkit. I've seen that mistake far too many times - I've been guilty of it myself recently, after the amount of time I've been spending mucking about with NBT tags.
I used to think that it was really bad if you compile against CraftBukkit instead of Bukkit but I have since learnt more.
I just compile against CraftBukkit anyway as it contains Bukkit but will allow you to do hacky things if needed.
I have started sending in some PRs to CraftBukkit and Bukkit to fix these hacky ways. If you use the Bukkit jar only, then your plugin should work with all other variations of Bukkit.
If you use CraftBukkit then it should still work for other variations unless you do something that isn't in the Bukkit API.
Believe it or not, i started learning java and then moved on to making plugins... always using the craftbukkit jar.
Ive just for some reason, always known to differentiate between org.bukkit and net.minecraft
There should be no problem compiling against CraftBukkit using reliable methods that don't change alot over time. For example I found a method to create an explosion without damaging blocks, which is not in Bukkit. This method is used by bukkit and defaults to damage the blocks and does not fire any explosion events (afaik).
Obviously, if you use NMS methods that use methods which change with each major version of minecraft (or to be exact: when the method names change) you can have a problem with non-existant methods
All methods, fields, classnames within CraftBukkit and net.minecraft.server can change at any time. Some haven't changed in a few versions but that doesn't mean they won't in the near future, breaking any plugin compiling against it.
oh, derp. I meant i referenced craftbukkit.jar, but i always used the bukkit methods. I only use the craftbukkit methods if im doing something that requires it
There's no point in building against Craftbukkit if you're not going to use any of it's methods.
I always build against CraftBukkit so that I only need one version, some of my projects use CraftBukkit methods, some don't. I try my hardest not to use CraftBukkit code but sometimes I have to.
But i do use craftbukkit methods, i said that i only use craftbukkit code if i need it, and some of my code does indeed need it.
I think you should include a debug mode option for your plugin and catch as many possible errors as possible. That way when someone says "it not working" you can ask for the error and you will have a way for them to fix the problem sooner than if you didn't have debug messages or catch the errors.
Even better, add a message before and after the stack trace so that they know what to send. I was also thinking of adding a feature to my plugin so that any stack traces could be emailed to me.
here is an error i have seen a bit latly
changing inventory in an event and having the default event change it back because they didnt cancel the event
I haven't seen this, but it may come up.
Compiling your plugin against an older version of the Bukkit API and/or compiling against an old CraftBukkit version.
Forgetting to do
The one that's giving me grief at the moment is devs not checking/specifying the file encoding to be used when reading/writing files. In some environments the default is set to UTF8, which results in some plugins failing to read their configuration files because they're ANSI encoded.
You can cause it to happen by adding '-Dfile.encoding=UTF8' to the launch arguments.
To be fair, all of bukkit's operations default to the system encoding. In fact developers have to do a bit of leg work to read configs in UTF-8, as there is no simple setting to change bukkit's default.
Using deprecated methods in the scheduler. (.schedule) instead of the new .runTas
How is that a mistake that has any present effect?
Isn't really but its preferable not to use deprecated methods.
Java 8 will be out in around 6 months now.
If your host doesn't let you use Java 7, change host.
It's time to evolve !
Minecraft is built for java 5 (Though soon, moving up to Java 6).
Stats from McStats, 10% of their servers use Java 1.6! I agree, people need to get Java 7, what's the point in using 1.6. From what I know, there are no benefits. I thought Java 7 was superior to 1.6, no?
I agree with you, but I understand what mbaxter said. Our plugin depends on Bukkit which depends on Minecraft, and Minecraft is Java 1.5. Good practices says that everything Minecraft related should be Java 1.5.
Now, Java 1.6 is a lot better than Java 1.5. For 1.7, there is no major improvement that would justify the lose of a lot of players.
I'm still building my plugins on 1.7. Yes Minecraft client should not be updated too fast because some computers have issues with Java 6/7. But for servers, who cares ?
A possible addition: Storing BlockStates, as they are only valid for that one time they are collected, and may be wrong later on.
I have a note:
Importing individual permissions or chat plugins for chat formatting (prefix/suffix)
you saying the solution is to use vault, but I think the metadata is actually a better way because you don't need a dependency
Does this apply for getting the primary group?
Separate names with a comma.