Minecraftforge: Adding an ItemConsumptionEvent

[CalmBit]

I'm looking to implement an event that will be posted on the "consumption" of any item. This includes food, potions, buckets of milk, etc. This would require a field for both the player (EntityPlayer) and the item (ItemStack) within the event, along with fields for the amount of saturation (float) and hunger (int) to be refilled.

For example, to aggro mobs in a certain range from the player after eating a particular type of food:

@SubscribeEvent
public void onFoodConsumption(ItemConsumptionEvent event) {
    if(event.getConsumedStack().getUnlocalizedName() == "porkchopRaw") {
        List<Entity> ents = event.getPlayer().world.getEntitiesWithinAABB(EntityPigman.class, [some AABB]);
        for(Entity e : ents) {
            // Aggro the entity, somehow
        }
    }
}

Replacing saturation on the fly:

@SubscribeEvent
public void onFoodConsumption(ItemConsumptionEvent event) {
    if(event.getConsumedStack().getUnlocalizedName() == "melon") {
        ItemFood melonItem = ((ItemFood)event.getConsumedStack().getItem());
        float oldSaturation = melonItem.getSaturationModifier();
        event.setSaturation(oldSaturation+[whatever value]);
    }
}

Does anyone have questions/concerns/objections, or other ideas on how things like the above could be implemented with the current system?

[asiekierka]

My objection is that using getUnlocalizedName() and == is an absolutely terrible example - but it seems like a nice idea, and AppleCore already does it so there's probably demand too.

[CalmBit]

I'll totally agree it's an awful example, but it's really just terrible pseudo-java to get across the feel of what I'm going for.

[liach]

What's its difference between the destroy item event and this one?

[CalmBit]

Assuming you're talking about PlayerDestroyItemEvent: from my tests, it doesn't seem to fire when a player consumes food.

As it stands that event probably could fit the bill, but without the semantics of 'item consumption' (i.e. eating, drinking). Additionally, we'd lose the ability to directly change saturation modifiers before their application, without doing more legwork.
We'd also lose the possibility of the optional component, as PlayerDestroyItemEvent isn't cancelable, and doesn't return any result.

[Alpvax]

I don't think it should be cancelable. That would imply that it is fired when the consumption starts, not when it ends. What happens if the player stops eating half way through? I think that it needs to be fired at the end of eating. However, having a result (ALLOW | DEFAULT = continue, DENY = do not apply effects) could be useful, especially regarding potions (potions of healing hurting vampires for example).
I think that it might be better just having a general item use finished event though (doesn't something like that already exist though?).

[CalmBit]

Yes, the idea it was cancelable has essentially been canned because of the complexity of implementation, along with how little uses we could actually muster for it. Currently, the plan is to allow overrides of saturation/hunger/effects with ALLOW and retain default behaviour with DEFAULT.

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity in a long time. If this issue is still relevant and should remain open, please reply with a short explanation (e.g. "I have checked the code and this issue is still relevant because ___." or "Here's a screenshot of this issue on the latest version"). Thank you for your contributions!

[stale[bot]]

This issue has been automatically closed because it has not had activity in a long time. Please feel free to reopen it or create a new issue.

[strikerrocker]

Can be useful.

[CalmBit]

Oh wow, I've been sitting on this for way too long. If this hasn't already been covered, I'd love to finish implementing everything and submit this.

[AfterRebelion]

I still see a need for this event. AppleCore is still practically required if you want to do anything related to hunger without breaking a ton of mods.

[CalmBit]

There's probably still a good rationale for it, but at this point I'm not sure whether or not it's even the direction forge wants anymore - I'm still figuring out the landscape after the 1.13 update. AppleCore is still definitely required for this stuff, but it's also not the worst dependency in the world. I would like to see this functionality in forge, though.