insane96mcp

Ender dragon has a 2 tick cooldown on attack (checks when was the last time the entity was hit) but only for wings. Head attack has no cooldown so you (well, your shield) take damage 20 times / sec.

This can be easily fixed.
Minecraft 1.20.1 using Parchment mappings.

private void knockBack(List<Entity> pEntities) {
   double d0 = (this.body.getBoundingBox().minX + this.body.getBoundingBox().maxX) / 2.0D;
   double d1 = (this.body.getBoundingBox().minZ + this.body.getBoundingBox().maxZ) / 2.0D;

   for(Entity entity : pEntities) {
      if (entity instanceof LivingEntity) {
         double d2 = entity.getX() - d0;
         double d3 = entity.getZ() - d1;
         double d4 = Math.max(d2 * d2 + d3 * d3, 0.1D);
         entity.push(d2 / d4 * 4.0D, (double)0.2F, d3 / d4 * 4.0D);
         // if (!this.phaseManager.getCurrentPhase().isSitting() && ((LivingEntity)entity).getLastHurtByMobTimestamp() < entity.tickCount - 2) { original check
         if (!this.phaseManager.getCurrentPhase().isSitting() && (((LivingEntity)entity).getLastHurtByMobTimestamp() < entity.tickCount - 10 || ((LivingEntity)entity).getLastHurtByMob() != this)) {
            entity.hurt(this.damageSources().mobAttack(this), 5.0F);
            this.doEnchantDamageEffects(this, entity);
         }
      }
   }

}

As for the head damage, a new conditions must be added like the one above

private void hurt(List<Entity> pEntities) {
   for(Entity entity : pEntities) {
      // if (entity instanceof LivingEntity) { original
      if (entity instanceof LivingEntity  && (((LivingEntity)entity).getLastHurtByMobTimestamp() < entity.tickCount - 10 || ((LivingEntity)entity).getLastHurtByMob() != this)) {
         entity.hurt(this.damageSources().mobAttack(this), 10.0F);
         this.doEnchantDamageEffects(this, entity);
      }
   }

}

This is easily fixed

Using Mojmaps 1.20.1
In the aiStep method the code calls the addParticles method but as pointed out by other users the inLove ticks aren't sent client side.

if (this.inLove > 0) {
  --this.inLove;
  if (this.inLove % 10 == 0) {
      double d0 = this.random.nextGaussian() * 0.02D;
      double d1 = this.random.nextGaussian() * 0.02D;
      double d2 = this.random.nextGaussian() * 0.02D;
      this.level().addParticle(ParticleTypes.HEART, this.getRandomX(1.0D), this.getRandomY() + 0.5D, this.getRandomZ(1.0D), d0, d1, d2);
  }
}

This can be fixed by checking if the code is running server side and then send the particles to clients

if (this.inLove > 0) {
  --this.inLove;
  if (this.inLove % 10 == 0) {
    double d0 = this.random.nextGaussian() * 0.02D;
    double d1 = this.random.nextGaussian() * 0.02D;
    double d2 = this.random.nextGaussian() * 0.02D;
    //Note, I didn't use the speed calculated above
    if (this.level instanceof ServerLevel serverLevel)
      serverLevel.sendParticles(ParticleTypes.HEART, this.getRandomX(1.0D), this.getRandomY() + 0.5D, this.getRandomZ(1.0D), 1, 0, 0.1f);
  }
}

This is caused by the fact that the Ender Dragon knockbacks entities server side only, so momentum stacks and when it's updated client side they're launched in the air. This is easily fixable by setting `hurtMarked = true` to pushed entities in `EnderDragon#knockBack` which makes the knockback applied server side being sent client side

This is due to the AI applying the follow range before it's actually changed.

(Using Mojang mappings) The NearestAttackableTargetGoal is applied to mobs in the creation of the entity (when is actually instantiated), where the follow range is taken from TargetGoal#getFollowDistance, and, at that time, is the default one.

So, the only way to actually make it apply is to leave and join back the world, where, when the entity is created, the mob has already the correct attribute (modifier) and the Goal takes the correct follow range.

One way to fix this is to change the target search to query the mob's follow range every time the distance is needed, but I really don't know how it would affect performance.
I tried doing this in one of my mods and seems like it doesn't affect performance.

This happens due to calculating the Regeneration effect (but the same applies for Wither and Poison) based off the remaining duration of the potion.

In MobEffect#isDurationEffectTick (using Mojang mappings) the duration is divided by the amount of ticks when the effect should apply, so changing the duration (e.g. applying it continuously with a repeating command block) will completely break the potion effect, never actually applying.

The fastest solution to fix this would be to replace (in the apply check formula) the duration with the entity's ticksExisted, so the apply of the potion wouldn't be tied to the potion duration, but to the entity time in the world.

Related to MC-158205

Finally after two hours of debugging I've found out why you can't hit the dragon sometimes. It has to do with where the dragon is (chunk wise) and where you're aiming at.

But first off, why can't you hit wings? Seems like they're swapped between client and server. So if right wing has Entity ID 1 and left wing has Entity ID 2 on the client, for the server it'll be Entity ID 2 for the right wing and Entity ID 1 for the left wing. With this the server thinks that you're hitting the far away wing so since there's a max range for the hit of 6 blocks you can't reach it and so the hit is registered on the client (MC-225055) but not on the server.

For the problems about not hitting her at all is a little bit more complicated.
The problem arises when you aim at any of the dragon's part: if you're aiming at the chunk in the direction where the center position of the dragon is you'll hit her, otherwise the hit will miss, that's because the ender dragon is not found in the chunks you're raycasting in so the hitboxes aren't checked at all.

Let's make an example.
Here the player, the ender dragon's head hitbox and the ender dragon position are all in chunk 0,0. When the player tries to hit the Ender Dragon's head he searches for the Ender dragon in Chunk 0,0 and -1,0 (the direction looking). The dragon is found in 0,0 so raycasts are made to find the head and in the end (pun intended), the attack lands, dealing damage to the dragon.

In this case the hit will not land as the Ender Dragon is searched for in chunks -1,0 and -1,-1, but she's in 0,0 thus not found, the finding of the head is not done and the hit fails.

"Why most of the times I can hit her while in the portal?"
Because the raycast actually starts from 2 blocks behind the player so most of the times 0,0 will be searched for the dragon.

While in this case your hitbox doesn't load 0,0 so the dragon is not found and the hits will not land

Note that in the examples the Ender Dragon center position is always in 0,0 but can be in any of the 4 chunks when slightly off.

Related to MC-158205

With mods magic I've managed to summon at the actual position of the ender dragon's parts (head, neck, wings and tail) some angry villager particles. (Tested in singleplayer) As you can see the client sees the dragon there (both hitboxes and actual model) while on the server she's ahead.

The tail parts:

For the Ender Dragon the code specifically says that only Thorns damage (direct or indirect) is applied when the generic attackEntityFrom is used, while to apply damage from players attackEntityPartFrom should be used.

I'm pretty sure there's some kind of desync problem as sometimes when in creative you try to hit her (melee) you can't (with a weapon you see the Sharpness particles but no hit is registered).

EDIT: Found out MC-225055

Can confirm in 1.16.2.
Get some experience, /xp set @p 0 and /xp set @p 0 levels will keep the score to the old value. This is so annoying for datapacks while dealing with experience.

Can still confirm as 1.15.1

Still an issue in 1.15.1

Still happens in 1.15.1 ... died on skyblock (built in bottom slabs) due to a skeleton going crazy. This seems to happen on any non full block, e.g. when the skeleton is not at perfectly rounded Y coordinate

Related or duplicated of MC-156522

Can confirm for 1.14.3
When the dragon attacks most of the times misses the player because is too above or too below the player

Why?

 @Torzod this is Minecraft Bedrock edition (1.11.4) not Java edition (1.14.1)

Can confirm in 1.11.3