Actually pass mob to pathfinding methods

[Matyrobbrt]

The current code would only pass null to getAdjacentBlockPathType and getBlockPathType. This PR fixes it by introducing overloads with the mob and storing the mob in the PathfindingContext.
Fixes #791

[neoforged-pr-publishing]

• Publish PR to GitHub Packages

Last commit published: 50f5f2adcc263d79a97b28f33d65151a2cb14bb9.

PR Publishing

The artifacts published by this PR:

• 📦 net.neoforged:neoforge:21.4.35-beta-pr-1745-gh-791
• 📦 net.neoforged:testframework:21.4.35-beta-pr-1745-gh-791

Repository Declaration

In order to use the artifacts published by the PR, add the following repository to your buildscript:

repositories {
    maven {
        name 'Maven for PR #1745' // https://github.com/neoforged/NeoForge/pull/1745
        url 'https://prmaven.neoforged.net/NeoForge/pr1745'
        content {
            includeModule('net.neoforged', 'neoforge')
            includeModule('net.neoforged', 'testframework')
        }
    }
}

MDK installation

In order to setup a MDK using the latest PR version, run the following commands in a terminal.
The script works on both *nix and Windows as long as you have the JDK bin folder on the path.
The script will clone the MDK in a folder named NeoForge-pr1745.
On Powershell you will need to remove the -L flag from the curl invocation.

mkdir NeoForge-pr1745
cd NeoForge-pr1745
curl -L https://prmaven.neoforged.net/NeoForge/pr1745/net/neoforged/neoforge/21.4.35-beta-pr-1745-gh-791/mdk-pr1745.zip -o mdk.zip
jar xf mdk.zip
rm mdk.zip || del mdk.zip

To test a production environment, you can download the installer from here.

[XFactHD]

While this solution seems obvious and perfectly fine at the surface, I don't think it works as expected in practice when the PathTypeCache gets involved: if an entity of type A pathfinds through a block with entity-dependent path types, thereby populating the cache, and then a different entity of type B pathfinds through the same block, then the second entity will re-use the path type computed for the first entity, no matter whether the block would have actually returned the same type or a different one for the second entity. I'm not sure there is a good way to solve this though.

[Matyrobbrt]

I think we only have two options. We can either remove the extension methods as being unusable (considering they always receive a null mob) or we could change the path cache to also be entity-type scoped, though I'm not sure what the best way to do it in a memory and CPU efficient is (we could have an array of path type arrays and then use entity type int ids? It would be fast, but that's not memory efficient). Even if we go for the latter, we would need to mention that the extension methods should ideally not use entity data and where possible only entity types as the cache would be shared between them.

[XFactHD]

We can either remove the extension methods as being unusable (considering they always receive a null mob)

The extension method would still be required even if the mob parameter stays dead or is removed since there is otherwise no way to assign a path type to custom blocks.

we could have an array of path type arrays and then use entity type int ids? It would be fast, but that's not memory efficient

This is also an idea I had, the major downside of it (apart from memory cost, which isn't huge) is that path type results which should aren't mob type sensitive would not be shared anymore by different entity types. The only way around that which I can come up with would be to add a hasDynamicPathType() extension method which blocks using the mob parameter need to override. If that method returns true, then the entity type gets written to the additional array, otherwise null gets written to it to indicate that the type is shared. The issue with that is that there is no way to get the block from which the path type was retrieved back to the place where the cache is written.