Update to 1.20.4

[SquidDev]

Hilariously broken right now, mostly due to teething issues with NeoForge.

To do list

• Finish off the NG port. Upstream is a bit of a moving target now, so expecting this to take a few weeks.
  • Rename the "forge" project to "neo"/"neoforge". Name undecided right now.
  • Fix gametests
  • Can we simplify our testFixtures code? We avoided the built-in plugin for this due to FG reobf issues, but that shouldn't be an issue now.
• Clean up sprite rendering to use mcmeta files. This may be later work - it's definitely not a blocker.

[SquidDev]

Updated this PR to 1.20.3, though looking like there's going to be a 1.20.4 pretty soon. The actual core functionality seems relatively okay (I can get in-game and interact with computers), but still a long way to go:

• Capabilities aren't invalidated properly when the block state changes. I'm also not 100% sure about cap invalidation for generic peripherals.
• Game tests crash due to missing structures (???) on Fabric, and aren't even set up for NF.
• NeoGradle migration is very incomplete.

That said, I think there are some API changes that are worth flagging now for mod devs:

• TurtleUpgradeSerialiser and PocketUpgradeSerialiser are gone:
  • TurtleUpgradeSerialiser.registryId() is replaced with ITurtleUpgrade.serialiserRegistryKey (and likewise for pocket upgrades).
  • All other use-case should be replaced with UpgradeSerialiser.
• Peripherals are now entirely backed by capabilities (accessible via PeripheralCapability.get()). This means IPeripheralProvider has been removed, as its functionality is now available within NeoForge. See NF's blog post for more information.

I would quite like to change turtle/pocket upgrades to be backed by Codec<_>s (much like recipes are), but not 100% sure this will happen in this update. There's a few corner cases that I'm not 100% sure about right now.

I'll write some more detailed migration notes when it comes to release this.

[SquidDev]

I spent some more time looking at this over the weekend.

First, some good news: gametests now pass on both Fabric and NeoForge. There's still a minor issues (speakers are broken right now), but it's otherwise looking stable. I'm currently in the process of backporting some of the refactors to the 1.20.1 branch (e.g. be4512d) to make future maintenance a little easier.

However, there is some less good news:

• I hadn't realised this, but NF has removed the concept of default providers from their capability system. This does make me a little worried about my plan to remove IPeripheralProvider. It is possible to have a fallback provider by registering one on every block with a low priority, but is a little ugly.

• I'm having a really miserable time with NeoGradle - it doesn't fix any i the issues I had with FG, and has introduced many more. This is making NeoForge work much more painful than I'd like. I'm going to switch back to VanillaGradle for the common project, which should at least reduce some of the pain.

  More generally, I'm probably going to put off NF support until later, possibly 1.21. I'll try to get Fabric out some time this month.

[SirEndii]

Just out of curiosity, what kind of issues do you have with NG

Have you tried to contact NF or will you report the issues you have with NG?

[SquidDev]

Just out of curiosity, what kind of issues do you have with NG [...] will you report the issues you have with NG?

The main problem is that the Minecraft decompilation+patching process is implemented as Proper Gradle tasks, rather than the weird hacks they had before. This is definitely conceptually nicer, but means that any change to a build plugin causes Minecraft to be re-decompiled all over again (twice!, due to the forge/forge-api projects!).

This is a known problem, and was an intentional tradeoff on NG's part. I feel there are better ways of handling it, but do NOT want to get involved in that discussion :p.

[SirEndii]

I understand your complains

I guess I could start spending more time into AP fabric for 1.20.4 then

[SquidDev]

It should definitely be possible to start work on updating AP (you can publish CC:T to a local maven repo with ./gradlew publishToMavenLocal and just depend on it normally), I'm just not sure I want to publish a Proper(TM) build.

[SirEndii]

You're right, I'll try that

But I have other AP todos before I will get into that

[vico93]

Just stumble with this PR today, i'm not familiarized with Github's PR aspect, so i missed it entirely until now. Will subscribe to follow the update process. Anyway, i'm happy to see that, after all this years, you still give your love to CC:T. Thank you so much for that!

[SquidDev]

Tracking this now on the mc-1.20.y branch. I probably should just rename trunk 1.20.1, but then that's a bit of a faff for open PRs.

[SirEndii]

❤️