Jukitsu

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.

As @fyberoptic has pointed out, this bug is due to the client no longer predicting the position of entities and relying on server packets, which they ssmooth the position accross 3 ticks. There is no easy fix: one fix would, as Jeff did, revert the change made in 1.8 to client prediction: but this would bring back the stutterness caused by conflict between client prediction and server packets. Another solution, which seems more viable to me, is increasing the rate of packets sent by the server, which would eliminate the need for linear interpolation which cause the visual slowness: however, sending entity packets every tick has its own share of issues, but it could be considered for integrated servers (Singleplayer) as no real network traffic is required for packets between the server and the client.

I have tried implementing such fix on a personal mod, where I simply forced the server to send entity move packets every tick instead of using their built-in update interval, and client-side I would disable the linear interpolation and directly set the position: the result looks similar to 1.2.5 SSP mobs, minus the slight (but virtually invisible) latency between Client and Server. However, the downside of this is that a slight tick lag would cause all mob movement to stutter and be unsmooth, but at least it isn't a glaring issue.

@TorutheRedFox Unfortunately, quads are deprecated in OpenGL 3.2, so this is not a viable solution anymore.

(I know it's been 3 years but I thought i'd clarify this)

From my testing, looks like Bedrock must be interpolating the red color with a intensity of 50% before color shading while Java interpolates the red color AFTER color shading with an intensity of about 30%

From what I've seen in the code and in the default shaders, this is due to the fact that entities who use the specific eye renderer don't integrate the overlay texture coordinates (which determines the color of overlays like damage tint or creeper flashing) in their rendering pipeline. As such, it doesn't render it.

Eyes are infamous to have wreaked havoc on the damage tint behavior, just look at spiders and endermen before 1.8, and the ender dragon before 1.15.