
Issue with booting up betterx mods and bclib in developper envirnoment [Bug]
StonksMan001 opened this issue ยท 5 comments
What happened?
Ok so I have a mod wich has better end, better nether and bclib as dependencies, and when I try to execute runClient task it always gives me the error message shown below, the files are:
bclib-3.0.10
better-end-4.0.7
better-nether-9.0.7
I also tried running the same .jar files in normal mc (not dev enviroment) and it worked there.
BCLib
3.0.10 and 3.0.9 (I havent checked other versions yet)
Fabric API
0.83.1+1.20.1
Fabric Loader
0.14.21 but I am not sure
Minecraft
1.20.1
Relevant log output
pictures above
Other Mods
my mod I guess
Btw. Why do you include local copies of our mods? They are available as prebuilt developer binaries on JitPack to be easily included when developing.
Also, please note that I do not consider the API of BetterNether or BetterEnd public, so it may change (and thus break your mod) with every update.
still doesn't work.
Error message:
Uncaught exception in thread "main"
java.lang.RuntimeException: Failed to read accessWidener file from mod fabric-command-api-v2
at net.fabricmc.loader.impl.FabricLoaderImpl.loadAccessWideners(FabricLoaderImpl.java:480)
at net.fabricmc.loader.impl.launch.knot.Knot.init(Knot.java:151)
at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:68)
at net.fabricmc.loader.impl.launch.knot.KnotClient.main(KnotClient.java:23)
at net.fabricmc.devlaunchinjector.Main.main(Main.java:86)
Caused by: net.fabricmc.accesswidener.AccessWidenerFormatException: line 1: Namespace (intermediary) does not match current runtime namespace (named)
at net.fabricmc.accesswidener.AccessWidenerReader.error(AccessWidenerReader.java:285)
at net.fabricmc.accesswidener.AccessWidenerReader.read(AccessWidenerReader.java:84)
at net.fabricmc.loader.impl.FabricLoaderImpl.loadAccessWideners(FabricLoaderImpl.java:478)
... 4 more
Our mods are built using mokant mappings. I think this might be caused by the combination of the yarn mappings you use and the mojang mappings we apply.