Curios API (Forge/NeoForge)

Curios API (Forge/NeoForge)

140M Downloads

Invalid dist DEDICATED_SERVER error from trying to use an event subscriber in a class implementing ICurioItem.

bconlon1 opened this issue ยท 2 comments

commented

Versions (Be specific, do not write "latest"):

  • Curios: 1.16.5-4.0.4.0
  • Forge/Fabric: 36.1.2

Observed Behavior: When using @Mod.EventBusSubscriber on an Item class implementing ICurioItem, the game will crash when trying to run multiplayer (only tested this within a development environment).

Expected Behavior: The game in multiplayer not crashing from this combination of code usage.

Steps to Reproduce:

  1. Create a class that extends Item
  2. Annotate it with @Mod.EventBusSubscriber (no parameters necessary)
  3. Make the item class implement ICurioItem
  4. runServer within the development environment
  5. The run will fail with the error java.lang.RuntimeException: Attempted to load class com/mojang/blaze3d/matrix/MatrixStack for invalid dist DEDICATED_SERVER
  6. Example: https://github.com/Gilded-Games/The-Aether/blob/abac77b99252bb97dab5ea99af991664b743fc04/src/main/java/com/gildedgames/aether/common/item/accessories/pendant/IcePendantItem.java (Note: Yes I know the subscriber is not necessary in this class specifically, I removed it later on, but it was necessary to other classes like ZanitePendantItem which had the same issue; The implementation of ICurioItem can also be found in AccessoryItem which the class extends; I also worked around this issue by just putting the subscribe events into a new class, but it would've been nice to keep them within the accessory class itself)

Crash Log: https://pastebin.com/ZqdcUwUp

This issue was narrowed down to seemingly being caused by Curios from the debug log (https://pastebin.com/1dmB6Vvd) showing the run failing when trying to load the automatic subscriber for IcePendantItem. Removing the @Mod.EventBusSubscriber annotation made the class work just fine afterwards with no crashes. When trying to troubleshoot this I was told this may be caused by ICurioItem.render() not being annotated with @OnlyIn(Side.CLIENT), but you would probably know better what the cause of the issue could be here.

commented

When this issue was first brought up, I did try to simply annotate the rendering methods with @OnlyIn(Side.CLIENT) but this only served to throw other class-loading errors and I dismissed that as a solution for 1.16.5. Today, while working on other issues, I decided to take another look at this again. For some reason, adding the annotation worked perfectly this time. Therefore, after some testing, I've included that change in the latest update and I do not believe it should cause any issues with existing implementations.

I do apologize that such a trivial fix took so long to implement.

I will also note that I refactored rendering into a separate class in 1.17+ so this issue is no longer a concern going forward.

commented

This is an issue that I'm aware of. It is indeed caused by the render methods, which will attempt to be class-loaded on the server if you try to subscribe the item to an event bus. I'm not sure if it can be readily solved by adding an @OnlyIn(Side.CLIENT) annotation, and I worry about how that might interact with existing implementations, but I'll look into it.

For now, until the rendering gets restructured in 1.17, the workaround is to implement your curios as a capability using the Item's initCapabilities method and the ICurio interface, which I believe should get around these errors. Or you can refactor your events outside the item entirely, it depends on which method is more convenient for your use-case.