The Ender Dragon does not dive toward the player (missing "diving" attack)

MC-167052 Was reported by me (apparently it is a duplicate even though it is the older report... Well at least somebody else has noticed this as well.) This was broken all the way back in 1.9, when the dragon fight was revamped.

This is not a bug. The dragon only charges players after it's been on the fountain for a while, an intentional change to the fight made in 1.9.

@PotholedSea40 Are you sure? The Mojang priority says otherwise. This was never mentioned in any change log. I remember that they only said in a certain snapshot's changelog that the dragon will no longer stop its attack when it is hit, which had made it easy to avoid it before. That change would be useless if the divebomb attack was intentionally removed.

And if this was indeed intentional, it wasn't a very smart change, which you will understand if you've ever run out of arrows while fighting it. You have to wait for it to land, and that can take ages. And of course the dragon fight is a lot less challenging when it never charges at you.

This attack getting unintentionally removed def made the dragon fight 100 time easier and more boring.

Imo this should be fixed when the combat snapshots get implemented because it wouldnt make sense to fix it if not alongside a combat update

Can confirm in 1.17.1. 

Yea agreed

Well, believe it or not, I use fabric-mixin, just change a single number, then I fix MC197201, MC271336, MC271337, MC272431 successfully. I test this in 26.1.2 and it works perfectly.

All the four bugs are all about Enderdragon’s incorrect y velocity, in net.minecraft.world.entity.boss.enderdragon EnderDragon.class. Previous comment mentioned that in the picture 屏幕截图 2025-12-31 164529.png I uploaded at 20251231, about line 217, public void aiStep(){}, this line is not correct:

this.setDeltaMovement(this.getDeltaMovement().add((double)0.0F, ydd * 0.01, (double)0.0F)),

ydd * 0.01 should be changed into ydd * 0.1.

I use fabric-mixin method to achieve the change needed above.

@Mixin({EnderDragon.class})
public class EnderDragonMixin {
    public EnderDragonMixin() {
    }
    @Redirect(
        method = {"aiStep"},
        at = @At(
    value = "INVOKE",
    target = "Lnet/minecraft/world/phys/Vec3;add(DDD)Lnet/minecraft/world/phys/Vec3;",
    ordinal = 0
)
    )
    private Vec3 modifyYddAddition(Vec3 instance, double x, double y, double z) {
        return instance.add(x, y * (double)10.0F, z);
    }
}

Result: Now that MC197201, MC271336, MC271337 solved, so MC272431 also done.

Now Enderdragon perches normally as that in Java 1.9-1.13 and Bedrock. Fixd MC271336 and MC271337.

Now Enderdragon can dive-fireball to player as that in Java 1.9-1.13 and Bedrock. Fixd MC197201.

For MOJANG, it’s much easier to fix these 4 bugs because they just need to change ydd * 0.01 into ydd * 0.1.

I use mixin method and ask for AI Deepseek to help me to adjust code, and I solve MC197201, MC271336, MC271337, MC272431 for just a few hours. I really don’t understand why these bugs don’t get fixed from 1.14 to 26.2!

I fix MC197201, MC271336, MC272431 by changing a single number. Which means in net.minecraft.world.entity.boss.enderdragon Enderdragon.class, Mojang only needs to change this.setDeltaMovement(this.getDeltaMovement().add((double)0.0F, ydd * 0.01, (double)0.0F)) to this.setDeltaMovement(this.getDeltaMovement().add((double)0.0F, ydd * 0.1, (double)0.0F)).

My fix code is on https://github.com/EnderdragonGateway/important-bug-fix .

Before the fix: Dive fireball fails (MC197201, 272431), Perch too slow (MC271336, 272431).

After fix to what it should be: Dive Fireball successes, Perch normally. Like what in Bedrock Edition and Java 1.9-1.13. Also this fix don’t break other dragon behaviours like node flying and dragon phase, et.

You may say speedruning has 0 and 1 cycle. However, in more than 75% cases, y speed is so slow that it make dragon perching 3 times longer, which will waste so much time on waiting.

Like mining fatigue in MC279819, this is also caused by adding an extra 0 by mistake. But I really don’t know why it’s never fixed since 1.14 and do not synchronous to Bedrock if Mojang wants to design this. It’s really that hard to remove a single number in the code? The programmer who write this code in 1.14 is absolutely irresponsible at work!

The comments here with speculations and theories are quite intriguing and confusing so I had a look behind the curtain and compared the code of 1.8.9 to 26.3…

There is no dedicated “Dive” attack defined in 26.3 (and after 1.9 in general) and it appears that the original “Dive” attack was never really removed and it instead reworked into the “Strafing” attack (shooting the player with a fireball) as some code inside DragonStrafePlayerPhase is identical to the original code used for the “Dive” attack:

So this has nothing to do with MC-272431 and it’s very likely that this was an intentional change as the attack was never really gone.

It’s real that diving is not a solitary attack method or phase. The procedure is: Jean sometimes sets a target point on player and flies toward it, comparing with shooting a fireball (On Bedrock Edition and Java Edition 1.9-1.13).

So why I say that I fixed these bugs by changing 0.01 to 0.1? After 19w08b, Mojag rewrites some code, but they type 0.1 to 0.01 by mistake, making y speed 10 times slower than expected. After changing this with mixin, I indeed fix these 3 bugs below. See Video FixMC197201-271336-271337.

MC197201: Target is player, but Jean’s y speed is too slow to reach player and just hooving for a long time and shoots a fireball in the end. I call this as the failure of diving fireball.

MC271336: Target is bedrock fountain, but Jean’s y speed is too slow to diving down, which leads to strange perching back and forward.

MC271337: Target is knot, but Jean’s y speed is too slow to get there in time, which makes Jean flying around two knots.

MC272431: Review of these 3 bugs.

Why I decide to tease Mojang every time in the comment? I know maybe Mojang won’t even look up this forum. Although this bug is so obvious and easy to fix, Mojang still drags on the fix for over 8 years. It doesn’t seem that human can make this kind of thing.