setNoDamageTicks is broken

[spring-dependency-management]

Expected behavior

setNoDamageTicks should make a given player invulnerable for the given amount of ticks

Observed/Actual behavior

They still take damage (in my case from explosions)

Steps/models to reproduce

player.setNoDamageTicks
world.createExplosion next to the player
they die from explosion damage

Plugin and Datapack List

N/A

Paper version

This server is running Paper version 1.21.4-DEV-main@a35cfe9 (1970-01-01T00:00:00Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are 1 version(s) behind
Download the new version at: https://papermc.io/downloads/paper
Previous version: 1.21.4-DEV-cd9d6d6 (MC: 1.21.4)

Other

No response

[spring-dependency-management]

perhaps this is relevant:

        if (this.invulnerableTime > (float) this.invulnerableDuration / 2.0F && !damageSource.is(DamageTypeTags.BYPASSES_COOLDOWN)) { // CraftBukkit - restore use of maxNoDamageTicks

BYPASSES_COOLDOWN isn't a real damage type tag in 1.21.4

[lynxplay]

So, this is a rather weird mechanic.

Previously, minecraft players had a spawn invulnerability which would behave like you described above (negate all damage).
setNoDamageTicks on players specifically would set the entities invul timer and the spawn invuln timer.
That is now gone in 1.21.4, changed by mojang. Players will take damage the second they load into the world.
The player setter hence cannot set that, and now players behave like any other entity in this regard, which is
"you are only invulnerable to damage sources that deal less damage than the damage that initially caused your invul", which in case of setNoDamageTicks is 0, so everything just damages.

This can obviously be fixed, but it feels pretty hacky and isn't a mechanic we really would wanna maintain I don't think?
Especially when better, event driven mechanics approaches exist to prevent damage on players.

[spring-dependency-management]

setNoDamageTicks

Can we not just set the initial cause damage to Int.maxvalue inside setNoDamageTicks to fix it?

[lynxplay]

Yea we could but there is already a method for this and it would mess with the API getters on the last damage.
So the API was relying on internal behaviour that has been removed, at which point the usual way to go would be deprecation and then removal of the method, but in this case only the player-speciifc side effect was removed, which makes this a rather ugly case as we don't have a clear migration path for this.

In my honest opinion, this should just be implemented via EntityDamageEvent cancellation (that code would work backwards as well, no one is loosing anything there), but I'll leave it open for others as well.
Alternatively we could re-implement the dropped vanilla feature as a "deprecation" means to allow the behavior to exist for a version longer, but that would be an instant deprecate for removal too, so you are at best gaining a version until you then have to fix it anyway.

[Doc94]

Maybe just mark that for player like Obsolete, i think better that than mess in reimplement