Pathfinding across bounds

[Skidamek]

Mobs' pathfinding and enemy detection now work across boundaries.

Depending on the mob, it might also need additional patches for attack across bounds to work. For example, all mobs that implement the RangedAttackMob interface will need a mixin to adjust the x and z coordinates; a skeleton is one such example.

I also updated the dependencies to the latest stable version.

[FamroFexl]

In regards to your clip checking, that is handled by BlockGetter, an interface implemented by the Level. It doesn't need to be customized, because BlockGetter will eventually be wrapped anyway.

[FamroFexl]

Also, pathfinding no doubt does chunk requests to figure out what blocks are ahead. Those chunk requests will have to be wrapped so the entity isn't instantly confused when they cross the bounds.

[FamroFexl]

Also, pathfinding no doubt does chunk requests to figure out what blocks are ahead. Those chunk requests will have to be wrapped so the entity isn't instantly confused when they cross the bounds.

Although when their cached pathfinding coordinates are suddenly invalidated when they cross the bounds by having their unwrapped coordinates wrapped, that would also cause problems.

[Skidamek]

In regards to your clip checking, that is handled by BlockGetter, an interface implemented by the Level. It doesn't need to be customized, because BlockGetter will eventually be wrapped anyway.

Oh that's great, I also while testing got confused how does it work. I placed a wall of dirt on opposite side and entities haven't attacked me. That would make sense now.

[Skidamek]

In regards to your clip checking, that is handled by BlockGetter, an interface implemented by the Level. It doesn't need to be customized, because BlockGetter will eventually be wrapped anyway.

Oh that's great, I also while testing got confused how does it work. I placed a wall of dirt on opposite side and entities haven't attacked me. That would make sense now.

Could you link that part of code? I am confused, can't find it.

[FamroFexl]

net/minecraft/world/level/BlockGetter

[FamroFexl]

For some reason, the mob doesn't turn their face (even though their body is turned) to face the player until after they cross the border. The lookAt method you modified doesn't affect this irregularity.

[Skidamek]

For some reason, the mob doesn't turn their face (even though their body is turned) to face the player until after they cross the border. The lookAt method you modified doesn't affect this irregularity.

I think it does, just math is wrong

[Skidamek]

Okay head rotations seems fixed now, looks like - i believe - the old mojang code uses lookAt method from Mob class in some mobs which attack via bow like skeleton and also mobs such as cat, panda, enderman and slime.
However most other mobs use LookControl class for that type of stuff via LookAtPlayerGoal class and few other mob specific goal inner classes.

[Skidamek]

I believe pathfinding/detection/looking at; is overall patched now.

However attacks depending on mob will be broken, many mobs have to be patched individually, unless you have some better idea? E.g. Llama spit method, which is called from RangedAttackMob interface.

Many mobs, like llama will need a patch to modify x, z coords of their target to a proper delta literally a copy-paste of skeleton attack patch

Also mobs that i already can confirm which will need it (all implementing RangedAttackMob interface)

• SnowGolem
• Wither
• Drowned
• Illusioner
• Witch
• And probably few more which do not use that interface

And the worst thing, probably many modded mobs would require similar patches, its a mess...

[Skidamek]

I think something like creating dummy entity class extending entity class could work. This class would hold fake coordinates of the target entity but relative to the mobs' coordinate space.

I suppose it could work because essentially all of computation related to that issue is based on target entity from where it gets the x, z.

However i have one concern with this approach, there is likely quite a bit higher memory usage due to how many variables entity class holds.

[FamroFexl]

We can't use name references to capture local variables. They always crash in production due to obfuscation. Just tested it.

[FamroFexl]

Here is an issue I discovered with pathfinding.

In the first zombie spawn, I am not at the bounds. In the second zombie spawn, I am at the bounds. This doesn't occur when the wall is right at the border of the bounds, but just a block before the bounds.
https://www.youtube.com/watch?v=vNIlpDbL_8w

[Skidamek]

We can't use name references to capture local variables. They always crash in production due to obfuscation. Just tested it.

I changed it to name because there's one small problem with ordinals too, they sometimes modify what they should not. We need to slice it first.

While the original method looks like this, nowhere in f assignment (ordinal 2) is even e mentioned (ordinal 1)

For me it looks like a bug within mixin itself, unless i dont understand something