Common Mistakes

Discussion in 'Plugin Development' started by mbaxter, Sep 12, 2012.

Thread Status:
Not open for further replies.
  1. Offline

    KollegahDerBoss

    Oh, you mean calling it in the Main Thread.. not in another Class.
     
  2. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı Retired Staff

    Doesn't matter what class you call it from, it matters what thread is executing the method in that class.
     
  3. Offline

    Hoolean Retired Staff

    Out of interest, how does one go about multithreading? (not in bukkit, I know how to use the scheduler api)
     
  4. Offline

    desht

    MrBluebear3 likes this.
  5. Offline

    rmh4209

    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.
     
  6. Offline

    iKeirNez

    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.
     
  7. Offline

    CorrieKay

    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
     
  8. Offline

    fireblast709

    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
     
  9. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı Retired Staff

    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.
     
  10. Offline

    CorrieKay

    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 :p
     
  11. Offline

    chaseoes Retired Staff

    There's no point in building against Craftbukkit if you're not going to use any of it's methods.
     
  12. Offline

    iKeirNez

    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.
     
  13. Offline

    CorrieKay

    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.
     
    bobacadodl likes this.
  14. 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.
     
  15. Offline

    iKeirNez

    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.
     
  16. Offline

    Ewe Loon

    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
     
  17. Offline

    Cirno

    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.
     
    CorrieKay likes this.
  18. Offline

    welsar55

    Forgetting to do
    saveConfig();
     
  19. Offline

    PhonicUK

    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.
     
  20. Offline

    Sagacious_Zed Bukkit Docs

    PhonicUK
    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.
     
  21. Using deprecated methods in the scheduler. (.schedule) instead of the new .runTas
     
  22. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı Retired Staff

    How is that a mistake that has any present effect?
     
  23. Isn't really but its preferable not to use deprecated methods.
     
  24. Offline

    Ribesg

    http://mcstats.org/global-stats.php#Java+Version
    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 !
     
  25. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı Retired Staff

    Minecraft is built for java 5 (Though soon, moving up to Java 6).
     
  26. Offline

    x0pk1n

    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?
     
  27. Offline

    Ribesg

    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 ?
     
    Spawnstah likes this.
  28. Offline

    Me4502

    A possible addition: Storing BlockStates, as they are only valid for that one time they are collected, and may be wrong later on.
     
  29. Offline

    ferrybig

    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
     
  30. Offline

    psychic94

    Does this apply for getting the primary group?
     
Thread Status:
Not open for further replies.

Share This Page