Just hold the shield where you want to block.

No guarantees this would work because Minecraft is Minecraft, but still

LivingEntity has a isDamageSourceBlocked method we'll probably have to mixin to.

isBlocking() holds our blocking check, so we can probably just put in a mixin at the head, run the default function if the immersive is disabled, and replace it with return true if we have a shield in one of the hands.

isDamageSourceBlocked can be mixin'd to follow similar logic to what's there in vanilla, but use the hand vector instead of the view vector. Same as above where if the config option is off, we just run vanilla behavior though.

Hopefully that'll work. This wouldn't be a full-on hitbox, but it would mimic Vanilla's behavior pretty well, and would also account for shield tilting, which our friendly AABB's wouldn't be able to handle.

EDIT: Realizing that this would mean you don't necessarily need to hold the shield where the projectile is coming from, only point it in the direction. To solve this, we should put a hitbox around the hand holding the shield and check that a ray coming from the attacker to the defender is in that hitbox. We should also iterate through both hands since dual-wielding shields would be hilarious, even if not practical.

EDIT 2: Realizing that for projectile attacks, the attacking entity is already in the player, so holding a shield outwards wouldn't make much sense. On top of the above everything, we should also check the hitbox of the shield in an onPlayerTick for any entities that would be blocked by a shield (arrows, etc.). If so, we should do some reflection. Sadly, it looks like arrow reflection is done in onHitEntity in the else branch of the entity.hurt() call, so we'll have to effectively re-write this logic manually.

New plan from square one-ish.

If we're holding a shield in some hand, return true in isBlocking. This way we actually get player slowdown.

We sadly can't really do a hitbox approach, because we're stuck with AABBs. If I ever decide to spend the painful time getting fully-rotatable hitboxes working, I'll look back into this.

Instead, shields will use a similar "look" check like how it does now, but the look will come from the hand direction instead. We'll implement the check for all hands holding a shield in isDamageSourceBlocked.

A large known flaw that will happen from this is you don't necessarily need to hold a shield in the correct spot, only point it in the right direction.

It's good to go!

Reopening as I make a bunch of improvements

Hitbox work doesn't seem to be fully possible, so I'm shelving that beyond early detection for projectile hits, at least for now.

So with that, shield is done :)

Instead of checking that the dot product is < 0, what if we instead check that the angle is in some range? Right now, the < 0 check effectively has 180 degrees of coverage. We should shrink that to be at most 90 (or probably less) degrees in the direction the shield is facing.

787e6ec