Causes reload during first data load (and incompatible with Anvil Crushing Recipes)
supersaiyansubtlety opened this issue · 4 comments
This line: https://github.com/RubixDev/Rug/blob/1.19/src/main/java/de/rubixdev/rug/RugServer.java#L243
is starting a reload before the first load has finished.
This makes Rug incompatible with my mod, Anvil Crushing Recipes (issue on my side here), because of this line in ACR, which requires the assumption that one reload finishes before another begins.
I can remove the exception and instead just log an error, which I plan to do if only to prevent hard conflicts like this.
However causing an additional load really isn't a good idea. It's inefficient and can lead to strange interactions like this one with ACR.
It looks like the reload simply enables a builtin datapack. If this is the case, you could use Fabric API's registerResourcePacks, which I actually do in ACR here.
Thanks for the hint, the ResourceManagerHelper.registerBuiltinResourcePack method should I think do what I want, but I don't have the necessary internet connection to test right now
Actually after having a closer look now, I don't think that method works. It requires the datapack to be in the mod jar file, but the whole reason why I manually copy the files into the datapack directory is that I need the pack to be dynamic, depending on what rules are set the contents of that pack vary.
As previously discussed in #17 (comment), I am also pretty much unable to create the datapack files before the default first load starts, because carpet only parses the rule config after that.
If you have another suggestion for a potential solution or I simply misunderstood the registerBuiltinResourcePack method, please tell me. You seem a lot more experienced with fabric mod development than I am. Otherwise I sadly might have to close this as wontfix...
My recommendation would be: for each carpet rule that controls a datapack, remove it, and replace it with a builtin datapack.
The only difference for users would be that they enable/disable them with /datapack enable/disable <data pack name> instead of /carpet <carpet rule name> true/false.
That won't work with rules like unpackableIce however, as they can be customized with a user specified integer value. Also I like the way these rules are integrated with the others, so users don't have to think about them being any different.
So, as the hard conflict between our mods seems to have been resolved on your side, I will close this now.