Primitive Enderdragon

Does someone know which class file contains shield’s default components? It’s different from the default value in world/item/component/BlockAttacks.class.

This is not called bypassing totem, the real problem is that player can take multiple times of damage and die in 1 tick even if it triggers totem.

For vanilla game play, changing absorption level 2->3 is enough to defend instant-damage 2 arrows, which solves MC206307. Like this video:

However, totem needs to have {resistance V 0.05s} to defend tnt-arrow-rail-gun, or player still dies on the same tick with 2 totems triggered.

It seems that Mojang didn’t think with their brain when designing some value.

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.

@SeaOfPixels

I know these two bugs are not related in code. What I want to say is, if you just remove invulnerability time of shield blocking (Paper server has this and it brings strange shield stunning knockback), it does fix MC268147, but then you will find shield knockback defender forward because of MC147694.

So, do you think Paper does the appropriate fix? Absolutely not. It needs to fix more than 1 bugs for expected shield mechanics.

I think it’s not necessary for preventing something. This mod https://modrinth.com/mod/attack-cooldown-syncfixes this bug. During the game, I don’t find attack indicator constantly showing as you mentioned.

However, I don’t support shield stunning because this is paper’s bug but not vanilla. Shield launches player forward after 1.14, without hurtmarked player won’t take this knockback, but the next hit in the same tick triggers this. Compared with normal weak attack, this bug reduces XZ knockback and increases Y knockback.

It’s no reason to use incorrect forward knockback and call it a PVP technic.

Forward knockback is caused by MC-147694

Shield blocking triggers 10 invulnerability tick but player not turning red, so I don’t think this is a designed feature. On Bedrock Edition, after getting shield disabled, player can receive knockback normally.

However, I don’t support shield stunning because this is paper’s bug but not vanilla. Shield launches player forward after 1.14 (MC-147694), this reduces XZ knockback and increases Y knockback. The proper shield stunning (hit shield with axe 2 times in 1 tick) should have the same knockback with weak attack, but not lower on XZ and higher on Y.

Shield absolutely has no reason to launch defender forward.

Relates to MC-147694. Mojang wrote attacker.knockback into defender.knockback.

Shield absolutely has no reason to launch defender forward, like that in MC-182638(Relates to).

If this is used to reduce defender knockback, what’s wrong with Mojang to forget adding defender.hurtMarked True after defender.knockback(…)?

There is a mistake: 19w08b does fix MC87942 and MC91858, and 1.14 does add knot flying mechanics. But that’s not relate to this bug.

The real reason is that this is completely manual typing mistake from a irresponsible staff of Mojang, the correct y speed is this.setDeltaMovement(this.getDeltaMovement().add((double)0.0F, ydd * 0.1, (double)0.0F)) , but he wrote this.setDeltaMovement(this.getDeltaMovement().add((double)0.0F, ydd * 0.01, (double)0.0F)). So Jean can’t dive to landing location in time, because y speed is not enough, which leads to flying back and forth around the target knot.

Just change 0.01 to 0.1 can fix this bug, including these related bugs: MC197201, MC271337, MC272431. Slow y speed dragon after 1.14 doesn’t exist on bedrock and java 1.9-1.13 at all!

There is a mistake: 19w08b does fix MC87942 and MC91858, and 1.14 does add knot flying mechanics. But that’s not relate to this bug.

The real reason is that this is completely manual typing mistake from a irresponsible staff of Mojang, the correct y speed is this.setDeltaMovement(this.getDeltaMovement().add((double)0.0F, ydd * 0.1, (double)0.0F)) , but he wrote this.setDeltaMovement(this.getDeltaMovement().add((double)0.0F, ydd * 0.01, (double)0.0F)). So Jean can’t reach that knot y speed is not enough, which leads to flying back and forth around the target knot.

Just change 0.01 to 0.1 can fix this bug, including these related bugs: MC197201, MC271336, MC272431. Slow y speed dragon after 1.14 doesn’t exist on bedrock and java 1.9-1.13 at all!

This relates to 3 bugs(197201、271336、271337) for the same reason: y speed is too slow to fly to target spot in time, but X/Z speed is correct. Because this.setDeltaMovement(this.getDeltaMovement().add((double)0.0F, ydd * 0.1, (double)0.0F)) was written as this.setDeltaMovement(this.getDeltaMovement().add((double)0.0F, ydd * 0.01, (double)0.0F)) by mistake in 19w08b. And it’s not introduced by fixing any bugs in the snapshot, but just a manual typing mistake by a irresponsible staff of Mojang.

MC197201: Target is player, but Jean’s y speed is too slow to reach player, which leads to the failure of diving fireball. The boss can’t even touch me after 1.14. And that’s so boring because Mojang can’t even make boss fighting work well in the main thread.

MC271336: Target is bedrock fountain, but Jean’s y speed is too slow to diving down, which leads to the 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 these knots.

Again: 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 it’s never synchronous to Bedrock if Mojang really 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!

I confirm this is a bug for sure. Because Mojang’s logic is bad in ItemStack.class. Switching items calls isSameItem(), which just refers to item’s name but ignore other components like enchantments.

In survival item can loss durability, so we can’t use isSameItemSameComponents(). Instead we should consider all the components expect damage. But Mojang doesn’t write that function.

Datapacks may make different components on same type items, like one item with unbreakable{}, weapon{} but the other not. This bug makes game can’t recognize them.

So my mod makes isSameItem() compare both item types and enchantments like this, and it can fix the bug in vanilla range.

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!

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!

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!

I can fix MC28289 and MC272517 finally. And I finally know the main reason. The game does set the correct item, but attribute-modifiers and attackstrengthticker (a varient in Player.class) don't update timely. Not only for weapon but also for armor. Like this soul-speed-swapping (It makes player move faster permanently if don’t reload world).

My fix code is on https://github.com/EnderdragonGateway/important-bug-fix. It solves MC28289, MC147694, MC182638, MC197201, MC271336, MC271337, MC272517.

Basically, in ServerGamePacketListenerImpl.class, add these four functions like this. In LivingEntity.class, need to change collectEquipmentChanges() into public, because this function can updates attribute modifiers and don’t broke other part of codes.

Which means the game's original code in ServerGamePacketListenerImpl.class should be changed like this.

I have tried so many circumstances and don't find any problem. My fix works same to the fix in PaperMC and what expected in this ticket.

I abuse this bug in PVP and do get advantages, but I fully agree if Mojang fix this. Because it brakes the balance of 1.9 cooldown mechanics.

I know how to fix this bug now and it works finely in my game. The server needs to refresh attributes and attack cooldown instantly when items change.

In server.network.ServerGamePacketListenerImpl.class, handleSetCarriedItem method, when receive ServerboundSetCarriedItemPacket, add these methods:
resetAttackStrengthTicker() //[method from world.entity.player.Player.class, to reset attack cooldown]
CollectEquipmentChanges() //[method from world.entity.LivingEntity.class, to reset item and attributes]
doTick() //[method from server.level.ServerPlayer.class, to avoid spear problems. I'm not sure which part of this works, but without this a wooden spear can create a mace with 1.56 attack speed. And ((ServerPlayer) player).tick()、Player.createAttributes() don't work]

Vanilla cooldown bypassing, mace crits and spear lunges much faster: (with some indicators)

Now attack-swapping performs as what expected. No more cooldown bypassing. The fix, refers to mod “AttributeSwappingFix“ and I add doTick(): (with health indicators)

However, there are some problems left:
Attacking and swap to spear, the attack fail but client still plays spear stab sound. Maybe some sound event problems in client.Minecraft.class.
Holding spear, and attack-swapping, it's 0 charge attack of the new item. But it still has 4.5 blocks reach. That's because vanilla server won't check if the attack is valid. I can't fix this.

My successful rate of attribute swapping manually is about 70% and I abuse this bug in pvp servers for sure. So I know this really destroys the 1.9 attack cooldown mechanism and much worse for developing minigame items and mod servers. Glass sword in twilight forest, 40 damage, 1.6 speed, only 1 durability, but this bug can bring a mace with 40 damage, 1.6 speed, 500 durability.

Can confirm in 26.3-snapshot-1. Actually the renderer is strange when X/Z>16777216, a little bit similar to the stripe land on Bedrock Edition. Why Mojang still set world border limit to 2*29999968 instead of 2*16777216 to deal with this bug? lol

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!