[1.8] The kind of change that can really mess up porting mod to 1.8

[jabelar]

Just a warning to those porting there mods: there are cases where the behavior of functions has been changed substantially, possibly as new bug.

 

Beware the onLivingAttack hook for posting the living attack event now returns false if event is canceled (instead of true in 1.7.10).

 

Here is the 1.7.10 code from ForgeHooks class:

    public static boolean onLivingAttack(EntityLivingBase entity, DamageSource src, float amount)
    {
        return MinecraftForge.EVENT_BUS.post(new LivingAttackEvent(entity, src, amount));
    }

 

Here is the 1.8 code from ForgeHooks class (note the return value is negated relative to 1.7.10):

    public static boolean onLivingAttack(EntityLivingBase entity, DamageSource src, float amount)
    {
        return !MinecraftForge.EVENT_BUS.post(new LivingAttackEvent(entity, src, amount));
    }

 

I think this is a bug really, since all the other event hooks still return true if the event is canceled.

 

Anyway, I'm not so much telling you about this specific change but rather a general warning to really double-check all the functions you're calling to see that they're behaving as you've previously expected.

 

 

 

[TheGreyGhost]

ForgeHooks is an internal class... Why do you call it?

Probably because there is no header at the top of the class saying "This is an internal class whose implementation is not stable from one release to the next; the methods should not be called directly". 

 

 

To me this is always the risk with a pseudo-API that exposes its internals, you can't rely on the contract remaining stable (often can't even tell what the contract is). 

 

Personally I tend to assume that, if a Forge method has JavaDoc, it will probably remain stable.  Otherwise, better not touch it, or at least make sure your automated test cases verify it hasn't changed.  Like the Minecraft code really.

 

-TGG

[jabelar]

ForgeHooks is an internal class... Why do you call it?

 

In a custom entity I am overriding the attackEntityFrom() method.  In order to be compatible with other mods (or even other stuff I might do later in the mod) I want to fire the event just like vanilla entities do and check if the event EventLivingAttack has been canceled.  Basically something like this is the first few lines of the method:

 

    @Override
    public boolean attackEntityFrom(DamageSource par1DamageSource, float parDamageAmount)
    {
        // allow event cancellation
        if (ForgeHooks.onLivingAttack(this, par1DamageSource, parDamageAmount)) return false;

 

I thought it was good practice to post events like vanilla classes do, and also check for cancellation. And I guess I mistakenly thought the idea of forge "hooks" was that they were there to use.  So should I just call MinecraftForge.EVENT_BUS.post() directly?

 

Usually when I'm modding I look at the way the vanilla classes implement things and copy it where it works for me.  Other entities call onLivingAttack() so I did too.  Is there any real problem with doing so?

[jabelar]

ForgeHooks is an internal class... Why do you call it?

 

To me this is always the risk with a pseudo-API that exposes its internals, you can't rely on the contract remaining stable (often can't even tell what the contract is). 

 

Personally I tend to assume that, if a Forge method has JavaDoc, it will probably remain stable.  Otherwise, better not touch it, or at least make sure your automated test cases verify it hasn't changed.  Like the Minecraft code really.

 

-TGG

 

Yeah, this is a better way of stating what the point of my warning is:  many of us are relying on an "API" that isn't really an actual supported/stable API so watch out and verify at least a couple levels into the call hierarchy to make sure it still does what you think it does.