Oops, I didn't break your plugins - ambiguous getHealth()

Discussion in 'Plugin Development' started by EvilSeph, Jul 1, 2013.

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

    EvilSeph

    With the release of Minecraft 1.6(.1), Mojang has made a big change to the way entity health is handled and stored. Prior to Minecraft 1.6.x, Minecraft used integers for health values which many plugins have grown to rely on. From Minecraft 1.6.x onward, Mojang have switched health over to using floats instead, leaving us in a tough position: we would have to break all plugins expecting integer health.

    Fortunately, as the name of this thread suggests, we put in many hours trying to figure out a way to avoid just flat out breaking plugins and managed to come up with a solution we think everyone will be really happy with. Through the use of a cool new Maven plugin Wolvereness developed, we are now able to provide a backwards-compatibility layer for this change for plugins. This means that plugins that rely on health being integers will still work until we remove the temporary compatibility mechanism.

    As a result, all plugins will still function, giving you time to work on a solid update to your plugin instead of having to rush a fix out to your users. We will eventually remove the compatibility layer so you'll still want to update your plugins to use the new double methods as soon as you can.

    What's going on?
    Minecraft 1.6.x uses floats for health instead of integers, which means all plugins expecting integer health need to be updated. Luckily, we've managed to come up with a way to support both old (integer) and new (double) health formats until plugin developers are able to update their plugins accordingly.

    Wait, why doubles and not floats?
    We've decided to go with double health to provide us with future-proofing against the possibility of a similar change from taking place in the future (from floats to doubles).

    Although our handling of this problem meant extra work on our part and added complexity within the project's compile process, we still believe that this is the best solution for everyone and are confident you'll feel the same way. We hope that the extra effort we've put into this update makes dealing with Minecraft 1.6.1 easier for you guys, removing the stress of needing to immediately update your plugin to support the change to health.
     
  2. Offline

    RiotShielder

    Awesome! Thanks for thinking about the plugin devs and us server owners, EvilSeph!
     
    Sw_aG, tyzoid, KingFaris11 and 5 others like this.
  3. Offline

    Gamecube762

    Keep up the good work. Cant wait to see the API updated with the new 1.6 features =D
     
  4. Offline

    LaxWasHere

    * gives 1.0 <3 to the bukkit team.
     
  5. Offline

    AstramG

    Oops.
     
  6. Offline

    LadyCailin

    For those of you trying to compile CraftBukkit locally, you may need to give maven more heap memory than you did before. To do so, run set MAVEN_OPTS="-Xmx1024M" for Windows or export MAVEN_OPTS=-Xmx1024M for unix, then mvn clean install.
     
  7. Offline

    riking

    For the plugin developers that are attempting to compile against CraftBukkit, you need to do this:

    Make the Bukkit API jar a HIGHER-PRIORITY DEPENDENCY than the CraftBukkit jar.
    Yes, this means you need both.
    Code:
    Maven POM example:
            <dependency>
                <groupId>org.bukkit</groupId>
                <artifactId>bukkit</artifactId> <!-- THIS GOES FIRST -->
                <version>1.6.1-R0.1-SNAPSHOT</version>
            </dependency>
            <dependency>
                <groupId>org.bukkit</groupId>
                <artifactId>craftbukkit</artifactId> <!-- THIS GOES SECOND -->
                <version>1.6.1-R0.1-SNAPSHOT</version>
            </dependency>
            <!-- DO YOU UNDERSTAND NOW? GOOD. -->
    
    Again, to reiterate the information in the original post: old compiles still work, new compiles must be changed to use doubles.
    This post has been edited 17 times.
     
    _LB, MnMaxon, NathanWolf and 10 others like this.
  8. Offline

    Rprrr

    Great work!
     
  9. Offline

    GreySwordz

    +1 For the Bukkit team. You guys really did an amazing job:)
     
  10. Any information on how the new float (double) value for health corresponds to an old value?

    Is it a percentage of the entities max health? (e.g 0.5 health, 20 maxhealth = 5 Hearts, or 10 (int) in the old system)
     
  11. Offline

    Rprrr

    Wait - how do I get rid of all those ambiguity issues? ;l
     
    Bawat and microgeek like this.
  12. Offline

    Wolvereness Bukkit Team Member

    As of implementation, getters will use Math.ceil(). I can't speak for if this will stay, but those methods follow NO contract (they shouldn't even exist).

    /edit: Just realised you meant how it's calculated... It's just health like it used to be, but with higher precision.
     
    tehbeard likes this.
  13. Offline

    desht

    This.

    Plus: I know there are people who like to use CraftBukkit as their build dependency instead of Bukkit, even when they don't need to make any NMS calls. This change should serve as a lesson on why that is a Bad Idea.
     
  14. Offline

    moneykid777

    Im not a coder or anything like that but wouldnt this mean that the coders out there could have percentages of health instead of bars?
     
  15. When I try do do this: if(player.getHealth() - event.getDamage() <= 0) {
    it gives the error on getHealth(): The method getHealth() is ambiguous for the type Player
    How to fix this?
     
    bubblefat_ and Bawat like this.
  16. Offline

    desht

  17. Offline

    desht

    That's part of a Maven POM. If you're not using Maven to build your plugin, then check your build dependencies in whatever IDE you're using. If you're not using NMS code, don't use craftbukkit.jar as a build dependency; use bukkit.jar. If you are using NMS code, use both bukkit.jar and craftbukkit.jar as build dependencies, in that order.
     
  18. Offline

    I_TK_I

    I can't imagine Mojang will ever update the precision of health to become double instead of float. Its understandable that they might want more than 20 possible values, but ~2^32 possible values is way more than enough. It doesn't make sense to think we want to be able to measure health so precisely.

    It seems to me to have been a rash decision. But ok, it's not like there's any real damage. (Converting from double to float, now that would be real-damage :p )

    Btw: why didn't they use short instead of int in the previous version?
     
  19. Thaaaaanks ^^
     
  20. Offline

    caelum19

    It's decissions like these that make me want to donate, however I can't as of right now.
     
  21. Offline

    kreashenz

    There's been one question on my mind since 1.6.1.. WHY DID THEY CHANGE? Why is it that they changed from integers to floats, when integers were working completely fine. It's gunna get annoying for us devs, if the Bukkit staff can't find a way to transform it back to integers.

    Anyway, thanks for atleast making it doubles, this'll still work fine :)
     
  22. Offline

    caelum19

    I think it's due to the fact that 20 health, is all 10 bars.
    because each heart counts as two health, and this is one fine way of doing it, but it's not the standard way. the standard is having half a heart be 0.5, instead of 1 which is kinda weird, tbh
     
  23. Offline

    desht

    Mojang made the change, presumably to allow for much greater precision - fractional health means a lot more flexibility with damage modifiers, for example; you can now have a weapon which does 1%, 2%, ... more damage, whatever you want. A lot of interesting possibilities open up, so this change is a Good Thing (tm).

    The Bukkit staff (read: Wolvereness) have made a huge effort to maintain backward compatibility, and the only people hurt by this change are those whose build configurations are wrong in the first place.

    True, plugins which used the old int methods will need a (trivial) change to compile against Bukkit 1.6, but runtime compatibility is preserved, which is the important. Having to modify code to deal with a double return value instead of int is not much of a hardship, really.
     
  24. Offline

    kreashenz

    desht I know it's easy to change from int to double, but I just found it a little weird why they would do it, but what caelum19 said would really help me in fractional help, like custom enchantments or something awesome like that.
     
  25. Offline

    caelum19

    Mhmm. Why did Mojang use int in the first place?
     
  26. Offline

    desht

    *shrug* Notch wrote the earliest incarnation of Minecraft single-handed, and I suspect forward planning wasn't the top thing in his mind at the time (which isn't really a criticism... I frequently revisit & redesign code that I wrote and later realised wasn't too clever -I'm probably not alone in that :) ).
     
  27. Offline

    caelum19

    Yeah, but the old method isn't even easier code.. I wonder what he was thinking at the time...

    it is probably the case of Notch having intended to have only hearts, not having hearts half-able, then he decided that being able to half them is better.
     
  28. Offline

    LegendaryViper

    How do change player health now on 1.6? I need some info on how to change a player's health now since the old code was changeed. This was my original code for 1.5.2:
    Code:
                    targetPlayer.setHealth(20);
     
Thread Status:
Not open for further replies.

Share This Page