Juuz

I think the current class names are fine, and they describe what the initialisers are meant for better than just "x entrypoint". With the proposed ones, there can be some...

I think you can work around this for now with just setting it to `"build/datagen"` instead of using the file. `AbstractRunTask` does this: https://github.com/FabricMC/fabric-loom/blob/e9d1f005d927ad23bb1acbe8b78903d4a41ff1cc/src/main/java/net/fabricmc/loom/task/AbstractRunTask.java#L53-L58 (maybe `getProject().file` would be better here...

I think this can be done in a backwards compatible way pretty easily: an `Object` run directory instead of a `String` and then use `rootProject.file(path)` instead of `new File(rootDir, path)`...

I feel like BECS can be deprecated/removed (I really would like to have stuff not deprecated for essentially forever) and `sync` can be somewhere else (networking api if we deprecate...

Technically this could be solved if tasks are only registered when it's safe to run their initialisers (or register the initialisers only when it's safe to do so), but that's...

In my case it was a single project setup. I'm not sure what I did to trigger it, could've been a cancelled/failed build for example.

You haven't registered a screen with Fabric API's `ScreenRegistry`, see [this wiki article](https://github.com/CottonMC/LibGui/wiki/Getting-Started-with-GUIs#register-the-gui).

You can use `withTooltip` whenever your data is updated, or in your screen's `tick` method (note: that method is client-only, which is really what you'd want in this case).

Hmm, I'm not familiar with Plant In A Jar, but it most likely draws the slots using code instead of textures so that might not be changeable. I'll fix this...

@CodeF53 Sorry, I've completely forgotten about this issue. It's not intentional - most LibGui widgets drew themselves using code, especially originally, but I've slowly been refactoring them to use textures...