Fuzss

Not using data gen on Fabric, but this mixin fixes the issue for NeoForge. https://github.com/Fuzss/puzzleslib/blob/main/1.21/NeoForge/src/main/java/fuzs/puzzleslib/neoforge/mixin/DatagenModLoaderNeoForgeMixin.java

I just went ahead and added those classes directly to Forge Config Api Port in the latest version for now as I was also very much looking forward to getting...

Still an issue in 1.20.4 on Macs. A workaround is to simply resize the game window, the framebuffer size will match the window size again after that. May be related...

Just a personal preference for the event style syntax in favor of the constructor. Wouldn't mind the event being removed for streamlining the mod setup process. Actually there is a...

Mod setup during construction in multiple places that are not bound to the `@Mod` class. For me it's useful for client-only setup in a separate class via marking the class...

For the setup I linked above I just really like that the client setup can be fully separate from common, just like Fabric, where there is `ClientModInitializer`. I far prefer...

Well, the original report is still valid. There remains a disparity between the `@Mod` class constructor and `FMLConstructModEvent`. At least turning the `ModContainer` getter public would be great. Besides that...

Since all other mod loading stages are triggered via events such as `FMLCommonSetupEvent`, `FMLClientSetupEvent`, `FMLLoadCompleteEvent` it just seems much more intuitive and logical for the very first stage to be...

Another thing that just came to mind (maybe worth a separate issue): On Fabric client mod initialization is always guaranteed to happen after common mod initialization. This is very useful...

Great, thanks! And coming back to the original issue regarding `FMLConstructModEvent` parameters, what's the conclusion for that? Can the `ModContainer` getter be made public? What's the future of the event,...