Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
bconlon1 opened this issue Apr 1, 2021 · 2 comments
Assignees
Labels
type: bug Something isn't working

Comments

@bconlon1
Copy link

bconlon1 commented Apr 1, 2021

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.

@bconlon1 bconlon1 added the type: bug Something isn't working label Apr 1, 2021
@TheIllusiveC4
Copy link
Owner

TheIllusiveC4 commented Apr 1, 2021

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.

@TheIllusiveC4
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants