LivingBreatheEvent and LivingDrownEvent

[Meldexun]

This PR adds three new events to allow modders to control if a living entity can breathe and how air is consumed/refilled.
With the LivingBreatheEvent modders could easily prevent players from breathing in something like a moon dimension or allow players to breathe everywhere while wearing a specific item.
Withe the LivingConsumeAirEvent and LivingRefillAirEvent modders could change how air is consumed/refilled or add an item which can hold air which will be refilled when the players air is full.

Currently a problem could be something like this:
When a modder adds a moon dimension where the player can't breathe then he has to revert the refilling of the air supply and the make the player consume air. This would be a lot cleaner and compatibility between mods would be easier to achieve with the LivingBreatheEvent.

I also added two test mods which each add an item with make usage of the events.

[ChampionAsh5357]

Question for you: why do you need three events to handle this logic? I'm pretty sure this could be done in a single cancelable event. For example, if the event is canceled, execute Forge logic where it checks if it can or can not breathe and then sets the amount. Calling three events every tick for something that could be done in one seems resource consuming.

[ChampionAsh5357]

This is really invasive. You do not need this much of a rewrite to handle this logic. You can simply add the event below #isAlive, post it, and then store the result in the flag to pass into multiple places. You also reverse the logic of when the entity stops riding which in vanilla's case doesn't break behavior but could in other mods. You can also use ForgeHooks to handle the actual event creation bring this down to just three lines added with a few more modified.

[ChampionAsh5357]

Same applies here that this could all go in ForgeHooks to reduce the amount of calls.

[ChampionAsh5357]

Fires event unnecessarily. The point of the event is to refill. If you are not or your air meter is full, you should have no reason to fire the event.

[Meldexun]

So I formatted the forge classes and added the missing license headers.

This is really invasive. You do not need this much of a rewrite to handle this logic. You can simply add the event below #isAlive, post it, and then store the result in the flag to pass into multiple places.

This is basically the vanilla code:

if (isUnderWater && !notInBubbleColumn) {
    if (!canBreatheUnderwater && !hasWaterBreathing && !damageIsDisabled) {
        // consume air
    }
    // check if vehicle can be ridden underwater
} else if (air < maxAir) {
    // refill air
}

So to insert the events the only way I could think of was to:

• move the vehicle check out of that statement
• merge the first two if statements

You are free to help me making this less invasive though I didn't see a way to keep the original structure in tact. Which is the reason why it is how it is now.

Question for you: why do you need three events to handle this logic? I'm pretty sure this could be done in a single cancelable event. For example, if the event is canceled, execute Forge logic where it checks if it can or can not breathe and then sets the amount. Calling three events every tick for something that could be done in one seems resource consuming.

(two events every tick not three)
For example maybe I want to add an item which can store air.
I could use the consume event to first extract air out of my item and only when the item is empty the players air supply is used.
And the refill event could be used to fill the item once the players air supply is full (which is also the reason why the air < maxAir check was removed).

Fires event unnecessarily. The point of the event is to refill. If you are not or your air meter is full, you should have no reason to fire the event.

As described above

[ChampionAsh5357]

You are free to help me making this less invasive though I didn't see a way to keep the original structure in tact. Which is the reason why it is how it is now.

You can just create a method within ForgeHooks to handle the logic for you and then just return what you need. That reduces those three line patches to a single line or even less in some cases.

And the refill event could be used to fill the item once the players air supply is full (which is also the reason why the air < maxAir check was removed).

But...that would never do anything. #setAirSupply is always hardcoded to choose the minimum between the added value and max air. Sure, you could add logic within the event to consume the item if used, but it's quite pointless to remove the check if literally nothing will happen when its called.

This is why I said the three event calls could be reduced down to one. That one event would be cancelable and set if the user can breathe and the amount to add/remove. When canceled, the event will execute the forge data retrieved from the event.

[Meldexun]

Hm I guess this could work.
Should I rather copy the if (air == -20) then DROWN into the ForgeHooks method or do more changes to the vanilla class?

[ChampionAsh5357]

You should always do the least amount of lines added/modified as possible within the vanilla class.

[Meldexun]

So I update this again. Now it is only one event which is fired inside a ForgeHooks method and thus the changes required to the vanilla class are very small now.

[sciwhiz12]

Hello! @Meldexun, please leave a comment whether you wish to continue this PR and update it to the latest active version of 1.18 (or leave an explanation why this PR's changes are not applicable to 1.18). If we do not hear back from you after some time, this PR will be closed for inactivity.
If anyone else wishes to continue the work of this PR, please create a PR with a link to this PR for reference.
Thank you for your contributions. 👋

[Meldexun]

Hi, yes I would like to continue this PR. I have created a new branch in my fork for MC 1.18 https://github.com/Meldexun/MinecraftForge/tree/living-breathe-event-1.18. So how should I proceed now? Should I create a new pull request?

[sciwhiz12]

@Meldexun, you have two options here:

• Force-push the commits from that new branch to the branch of this PR, then change the base branch of this PR to the 1.18.x branch. I personally prefer this, as this preserves the history of the PR.
• Create a new PR with that new branch, and close this PR as superseded by the new pull request.

[Meldexun]

I updated everything to MC 1.18 now. Also I moved pretty much all changes into the ForgeHooks#onLivingBreathe(LivingEntity, int, int) method and added a living drown event which allows modders to control how fast an entity takes damage while drowning or cancel the event when the entity is suffocating in a space dimension to not spawn the bubble particles and to not play the underwater drown sound.

[TheCurle]

This may be easier to implement in 1.19 with the new fluid API.

I'm going to close this old one for inactivity (which is entirely our fault!) and we can continue if you'd like in a new PR.