Jukitsu

*enderdragon, sorry for typo

The code above is in net.minecraft.world.entity.boss.enderdragon.EnderDragon::aiStep, in the net/minecrat/world/entity/boss/ender/EnderDragon.class class file.

The “bouncing off” phenomenon may have to do how the game handles the client-server syncing. Arrows aren’t AI authoritative entities and thus their handling is somewhat kept client side. Regardless, I don’t think it gives us more insight other than the projectile is probably phasing through server-side nonetheless.

Afaik, it is still not fixed in the current snapshot. Can anyone confirm ?

Can confirm for 1.21.5

Note that the ramifications of this bug are quite large. Fixing this typo would virtually invalidate all strategies of speedrunning and one cycling.

I am dubious that the bug was caused by a fix in the rendering of the entity. Dragon phases and rendering are pretty much completely seperate in the codebase, and my testing has suggested that it was rather the typo in aiStep (cf. MC-272431) that causes the bug rather than anything to do with the phases. (I did some comparisons between the codebase of 1.12 and 1.21 and found no obvious discrepancies)

After some testing, I determined a slight issue with Chumbanotz's fix: while the followingTargetEvenIfNotSeen check is problematic as it causes a short circuit (since it forces a return statement for all mobs not having this flag set to true), removing the check itself causes the goal not to stop when the entity has reached its target. This is problematic because for a target which doesn't move, there are situations where the mob would create an improper path where it wouldn't be able to reach the entity within its hitting distance, and it would be stuck not being able to attack, virtually causing MC-147516 again. (The details of whether and why this happen is unclear to me though). Rather than removing the check, it would be better to replace it something in the lines of:

...
else if (!followingTargetEvenIfNotSeen && this.mob.getNavigation().isDone()) {
    return false;
}
...

This forces an attacker which has reached its target to properly update its path towards the target as it hits by constantly cancelling and reactivating the goal (but only works properly if the lastCanUseCheck check is removed as the original fix suggested), which is probably what this check was originally intended to do.

As a side note, this causes virtually the blocker to be knocked towards the attacker. Therefore, this issue relates to MC-182638 as the report shows the inverted knockback is visible on the beam attack, which counts as magic, and thus does not trigger the knockback reduction of shields.

After testing, I have noticed that there's a slight error in Fuzs' fix: the vector constructed is flipped and would cause the mob to get knocked towards the blocker. The appropriate code should be:

(using 1.20.4 Mojmaps)

public void blockedByShield(LivingEntity livingEntity) {
    this.knockback(0.5, livingEntity.getX() - this.getX(), livingEntity.getZ() - this.getZ());
}

This is likely caused by the GroundPathNavigation which checks whether the entity is on the ground to perform its pathfinding; However, when you hit an entity, it gets knocked back and thus is in the air. If the timeframe is unfortunate, the pathfinding check may thus fail and the mob needs to wait until the next pathfinding, which can be several ticks later. For some reason, some of them seem to fail for other reasons.

I made a new bug report further detailing the root issue that causes both bugs here: MC-272431

I see, however if my hypothesis is true, which I'm more and more convinced it is, then it means that the 2 issue corresponds to one same bug. Maybe I should make another bug report which would be more descriptive of the issue (namely incorrect velocity) if I have enough evidence?

If it is confirmed that this is the issue causing it, I suggest we move to MC-201937 as it is more descriptive of the issue. There was no point splitting the issue from the first place.

Confirmed in 1.20.6.

This issue is not invalid: the Ender Dragon has incorrect vertical velocity (roughly a tenth of what's its supposed have), causing most of the AI issues described here.
This issue should be reopened.

@PotholedSea40 While it is true that this version caused a lot of buggy behavior from the dragon, I don't think it is related to the fix of the bug. My best guess is that in the process of fixing the bug they also overhauled other parts of dragon code, breaking its AI in the process.

Also, I think I've found the issue. It seems comically stupid, but the ender dragon seems to (roughly) get a tenth of the vertical velocity it supposed to have while flying. At least, that is the case compared to 1.12.
I'll provide the details a later date, when I figure out how to properly get the decompiled 1.13.2 code and after further testing.

My early very surface-level testing seems to suggest that this may be due to an issue on how the Ender Dragon dives in general, it seems to struggle to get the proper vertical velocity when flying to a target, thus making unnecessary turns back and forth and perching too high

The aforementioned bugs were purely visual/rendering bugs that despite being related to the Ender Dragon, and don't seem to have anything to do with dragon AI, so it's likely they were unrelated. I think that the bug might have been introduced by an internal rewrite of some sort.

Note: the Dragon does charge the player, but only if the dragon has been sitting enough time on the end podium and the player is not too close to it.