Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reducing damage of an EntityDamageEvent allows future damage to bypass NoDamageTicks partially #11393

Open
D1SR3G4RD opened this issue Sep 13, 2024 · 4 comments
Labels
status: input wanted Looking for community feedback on this issue. type: bug Something doesn't work as it was intended to. version: 1.21.1

Comments

@D1SR3G4RD
Copy link

D1SR3G4RD commented Sep 13, 2024

Expected behavior

This issue applies to all damage types, but is specifically more noticeable in damage types that attempt to deal damage each tick (lava, cactus), so i will use lava as an example.

When standing in lava, I expect armor to take damage every 10 ticks as it does in vanilla, regardless of the amount of damage the lava deals.

Observed/Actual behavior

Armor takes damage and lava burn sounds are played every tick.

Steps/models to reproduce

  1. Create a plugin with the following handler in a Listener:
    @EventHandler
    public void onLava(EntityDamageEvent event) {
    if (event.getCause() == EntityDamageEvent.DamageCause.LAVA) {
    event.setDamage(event.getDamage() * .99);
    }
    }
  2. Run the server and equip armor.
  3. Stand in lava.
  4. Observe your armor taking damage each tick, instead of every 10th tick.

Plugin and Datapack List

Nothing except this listener.

Paper version

This server is running Silvera version 1.21.1-DEV-main@9d0a210 (2024-09-13T02:50:33Z) (Implementing API version 1.21.1-R0.1-SNAPSHOT)

This is a private fork, but is based off of latest and has no related changes, several other servers have run into this issue, presumably on other forks or standard Paper. I can replicate it on latest if necessary.

Other

This appears to be the source of the issue. d98db39

image
This is caused by amount being set to a lower value before lastHurt is assigned to this value.
For example, lava deals 4 damage, but if this is reduced to 3 damage, lastHurt will be 3 on the next tick, but amount will be 4, resulting in the if case failing and damage attempting to be dealt.

@D1SR3G4RD D1SR3G4RD added status: needs triage type: bug Something doesn't work as it was intended to. labels Sep 13, 2024
@D1SR3G4RD
Copy link
Author

D1SR3G4RD commented Sep 13, 2024

Presumably something like this should work, but unsure what other issues this could create if the damage actually dealt and CraftLivingEntity.getLastDamage are not the same.
this.lastHurt = Math.max(amount, originalAmount);

@strainxx
Copy link
Contributor

Can reproduce

@Doc94
Copy link
Sponsor Contributor

Doc94 commented Sep 15, 2024

Confirmed and in teory the issue is https://github.com/PaperMC/Paper/blob/master/patches/server/1028-Only-call-EntityDamageEvents-before-actuallyHurt.patch because in upstream this not happen. but really unsure what is a proper fix

@lynxplay
Copy link
Contributor

Well this is a bit rough. The behaviour is what you'd expect from vanilla when the damage event is interpreted as "This entity is about to take n points of damage".

Idk if there is a point in potentially exposing a "pls re-check if the damage should still be dealt after damage modification" option to the entity damage event, but the alternative would be to either call entity damage event before that check, which obviously leads to completely wrong calls for the event, or to set the lastDamageAmount to the wrong value, which is also incorrect.

Such a "pls recheck" option cannot be true by default either, because it would break a plugin just setting the value to something less but still expecting the damage to be dealt.

@codebycam codebycam added status: input wanted Looking for community feedback on this issue. and removed status: needs triage labels Sep 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: input wanted Looking for community feedback on this issue. type: bug Something doesn't work as it was intended to. version: 1.21.1
Projects
Status: Needs Work
Development

No branches or pull requests

5 participants