[Unsafe] ambiguous getHealth() workaround\dhack

Discussion in 'Resources' started by RawCode, Feb 15, 2014.

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

    RawCode

    note: version\platform dependant, not for beginners, this text is red big letters.

    1) Expecting you to have eclipse or other IDE running and alive workspace with craftbukkit as only imported library.

    2) Your workspace must have priority over all other libraries and classes, in other case this wont work as expected (wont work at all)(workspace priority on by default but easy to messup when adding new jars into project).

    3) Copypaste sourcecode of Damageable.class bundled with javadocs or source code of Bukkit.jar into your workspace, final shoud looks like this:
    1.png

    4) Fix package and name if needed, it must match exactly including case and root node.

    5) You dont need to include this class into your projects, you can add excludion for jarpacker and it will work just fine.

    6) Also you can just ignore it, ever if imported it wont cause any issues with craftbukkit itself and other plugins.

    Now reason of this:
    I using JBE for bytecode operation, but anything will work, since interfaces in java have very simple class structure, lets decompile Damageable.class bundled with CraftBukkit:
    2.png

    As you probably noticed, names of methods for bundled class does not match source code, that have additional deprecated methods marked like this:
    void _INVALID_setMaxHealth(int health);

    Since now we have control over interface, we can edit it, lets change getHealth output to "int" recompile and test - it will work and return proper type.

    Reason this to keep compatability for older plugins and completely disallow usage of deprecated methods.
    Since there is no reason to force disallow usage of methods, IMHO main reason to discourage noobs from using CraftBukkit jar directly.

    This method can be used to overcome limitations in any similar cases, just import troublemaker interface into your workspace.

    Interfaces have trick with them, method invocation done with only two checks (interface chain and class chain, both can be ignored with a bit of unsafe) and if interfaces extend eachother you dont need to overcome any checks, they always passed anyway.

    You are free to add:
    EntityType getType();
    or any other method from compatable interface to your Damageable and it will work without any issues, also you still dont need to add custom interface into your plugin, this can be used for little obfuscation.
     
  2. Online

    timtower Administrator Administrator Moderator

    RawCode Other way ( much safer and suggested )
    1. Add both Craftbukkit and Bukkit to your build path
    2. Go to order and export
    3. Put Bukkit above Craftbukkit
    4. Profit
     
    stirante, desht and Datdenkikniet like this.
  3. Offline

    RawCode

    Looks like captain obvious inside thread! timtower

    What about no?
     
  4. Offline

    BR3TON

    If its so obvious why would you use your way? Especially if your way is unsafe.
    Seems stupid.
     
  5. Offline

    RawCode

    Its perfectly safe for me, actually much safer then adding both bukkit and craftbukkit into workspace. BR3TON
     
  6. Offline

    Garris0n

    ...well why not?
     
  7. Offline

    Cirno

    Or just cast Damageable to the entity and not have to do all of this?
     
    DSH105 and ZeusAllMighty11 like this.
  8. Offline

    RawCode

    and how this going to help if craftbukkit embedded class with name damageable.class have this methods messed up?
     
  9. Offline

    Garris0n

    Would you mind explaining what exactly is so unsafe about using both CraftBukkit and Bukkit in your build path?
     
  10. Offline

    RawCode

    Garris0n i never stated then adding both cbukkit and bukkit unsafe...
     
  11. Offline

    desht

    I'm trying really hard to parse this sentence, but it just doesn't make any sense.

    Your entire approach is frankly bizarre, when there are two safe approaches to this with no drawbacks: 1) build against Bukkit, not CraftBukkit, and 2) use the Damageable interface.
     
    Cirno and DSH105 like this.
  12. Offline

    RawCode

    it already damageable, why soo hard to check this simple feature?
    open eclipse, highlight method, press f3.

    as long as there is no bukkit.jar included into workspace casting wont do anything.
     
  13. Offline

    Minnymin3

    Um... Okay... What? Your solution is adding in a class that exists WITHIN the API itself, last time I checked, is the thing that each and every single plugin (except for the Scala WIP plugins... Don't ask...) is based upon? Why not just build on the API jar called Bukkit whilst using CraftBukkit as the dependancy volatile code only like you are supposed to.

    Edit: Sorry for the kind of angry sounding response...
     
  14. why so complicated?? just use this simple code:
    Code:Java
    1.  
    2. player.sendMessage("Your Health is: "+((damageable)player).getHealth());
    3.  

    :D
     
  15. The easier way:

    Download bukkit from github
    Edit damagable class file
    Recompile with Maven

    OR

    The super complex method

    Barrow(Steal) Minecraft Forges Access Transfromers and find out a way to add them to a plugin and edit the class with a simple method
     
  16. Offline

    AoH_Ruthless

    Heckya1234 (The_3_gamers)
    Why would you edit the damageable class file?

    The two solutions that others have continuously pointed out work just fine.
     
Thread Status:
Not open for further replies.

Share This Page