Testing environment

• Minecraft version: Minecraft 1.19.2
• Mod loader: quilt-loader 0.17.4
• PuzzlesLib version: 4.3.10, 4.3.9, or 4.3.8
• Other mods:
  • StylishEffects 4.3.0
  • ForgeConfigAPIPort 4.2.6
  • qfapi-4.0.0-beta.13_qsl-3.0.0-beta.16_fapi-0.62.0_mc-1.19.2

Description

PuzzlesLib 4.3.8 and above contain a regression that causes a crash when used with Quilt QFAPI/QSL and StylishEffects.

This crash is specific to QFAPI/QSL, and is unrelated to quilt-loader. Using quilt-loader combined with Fabric API (※ this is an unsupported configuration and is used for testing only) will result in the crash not occurring and the game working normally.

I have confirmed the reproducability of this crash with just a bare minimum set of mods, listed above.

The last version of PuzzlesLib not affected by this issue is 4.3.4.

Stacktrace

https://gist.github.com/akemin-dayo/0f515a301f849371c4f646e32e698633

This seems to be related to the opening menus with additional data feature I implemented in v4.3.5. Really not sure though why Stylish Effects causes it to crash, it doesn't use that feature...
The mods that do use it (Straw Statues and Armor Statues) work fine...

Yeah, I honestly don't quite see how PuzzlesLib+StylishEffects could be causing the crash to occur either. I'll see about asking around in the Quilt Discord server.

(Also, I've confirmed that the same behaviour occurs on 4.3.10.)

Ok, so I did a bit of testing and the issue comes from this one of my classes being loaded.

The loading happens during mod construction, since in all my mods I create a wrapper for mod loader specific mod loading events from here:

The first class I linked where the issue occurs is also an SPI which is also loaded when something on this CoreServices class is first invoked.

The thing is though, the CoreServices class is loaded in all my mods directly at the beginning of the mod's initialisation, there's nothing Stylish Effects does differently. I also don't see any reason why Stylish Effects would be loaded earlier than any other of my mods. The Fabric main class which has the call to CoreServices is also referenced from nowhere (it just contains one line anyways), it's only loaded by the mod loader itself. And as far as I know Fabric (not sure about Quilt, but I think they are essentially the same) usually loads mods in the order they are present in on the file system, so Stylish Effects really shouldn't be the first mod to load.

I've now simply wrapped the problematic code in FabricAbstractions inside of a Runnable which is executed immediately when the method is called. This should prevent early class loading of the anonymous ExtendedScreenHandlerFactory implementation which is causing the issue (this is the kind of hacks you learn from working on Forge where they do stuff like that everywhere for client-only classes haha). Works fine for me on Quilt now, can you confirm that?
https://mega.nz/file/KZczSTgK#lpOuXrOabXuDwYMJDlU1uUuLdhYnVBafg0Z-GAT6Q9Q

Not a nice solution, maybe in the future I'll just move SPI's not need during mod loading out of my CoreServices class...

Huh, that is certainly… strange. Yeah, I really don't know why SE specifically would be running into this issue (and not your other mods). (I'm also fairly sure that quilt-loader loads mods in the same order as fabric-loader does…)

Anyway, I can confirm that PuzzlesLib 4.3.10.527 has fixed this issue!

Just published that version as v4.3.11.

Actually found the real cause of this issue now in Stylish Effects: it's this line.

Class loading all my SPIs in a MixinConfigPlugin is just a really bad idea since mixins from other mods haven't had their chance to apply and I'm already loading a bunch of classes here, wasn't aware of that until recently.

Well time to fix that properly for 1.19.3 then haha.