shartte

Since you didn't enable the checkbox to allow comitters access, I'll have to open my own PR with the changes

Opened https://github.com/AppliedEnergistics/Applied-Energistics-2/pull/8266 with the changes

> How do you even get the `VersionConstraint`? Like this? > > versionCatalogs.named("libs").findVersion("neoForge").get() > > We could potentially add a helper method that will perform these steps from the version...

So looking into it: We'd need to remove `setForgeVersion(String)` and replace it with `setForgeVersion(Object)` to prevent Groovy from coercing the version. We can't have both setters simultaneously as Groovy refuses...

@lukebemish When I debugged this (by changing the setter to take an Object), I *did* get a rich version constraint object wrapped in a Provider, but we can't actually do...

I have not yet validated this, but just by looking at the Gradle code, javadoc should use the main source-set compile classpath by default. Can you please post a link...

> As a workaround, I think you can force the main Gradle build to use UTF8 on Java 17. On Java 18+, the JVM defaults to UTF8 anyways. Which is...

Ok that's a bit sad, since you will always require such a library if you use GLFW in a cross-platform way. Well, unless you write the needed code yourself, ofcourse....

> Heyo! Sorry to bug but what's the current state of this PR? Is it roughly working (enough to throw on a server?) or is it still an early stage...

Can / Should we gametest this? @2No2Name And yes, the onNeighborChange vs. neighborChange is *extremely* confusing, and I think that's likely a leftover thing from very very old Forge patches...