Lucky Block

Lucky Block

1M Downloads

Lucky Block Addons won't read structures within a .zip file

XanolResagan opened this issue ยท 2 comments

commented

Versions used: Lucky Block 1.18.1-10.0 on Forge 39.0.79

I have noticed a rather unusual glitch while fixing out a bug in the Summer Lucky Blocks where structures won't load at all.

[22:13:26] [modloading-worker-0/ERROR]: Error reading structure 'sunbrella.nbt'
java.lang.NullPointerException: null
	at mod.lucky.java.loader.ReadStructuresKt.readNbtStructures(ReadStructures.kt:53) ~[lucky-block-forge-1.18.1-10.0.jar%2352!/:?]
	at mod.lucky.java.loader.LoaderKt.loadAddonResources(Loader.kt:178) ~[lucky-block-forge-1.18.1-10.0.jar%2352!/:?]
	at mod.lucky.java.loader.LoaderKt.loadResources(Loader.kt:203) ~[lucky-block-forge-1.18.1-10.0.jar%2352!/:?]
	at mod.lucky.java.JavaLuckyRegistry.init(JavaLuckyRegistry.kt:89) ~[lucky-block-forge-1.18.1-10.0.jar%2352!/:?]
	at mod.lucky.forge.ForgeMod.<init>(ForgeMod.kt:74) ~[lucky-block-forge-1.18.1-10.0.jar%2352!/:?]
	at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:?]
	at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77) ~[?:?]
	at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:?]
	at java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499) ~[?:?]
	at java.lang.reflect.Constructor.newInstance(Constructor.java:480) ~[?:?]
	at net.minecraftforge.fml.javafmlmod.FMLModContainer.constructMod(FMLModContainer.java:81) ~[javafmllanguage-1.18.1-39.0.79.jar%2355!/:?]
	at net.minecraftforge.fml.ModContainer.lambda$buildTransitionHandler$4(ModContainer.java:120) ~[fmlcore-1.18.1-39.0.79.jar%2354!/:?]
	at java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804) [?:?]
	at java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1796) [?:?]
	at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) [?:?]
	at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) [?:?]
	at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) [?:?]
	at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) [?:?]
	at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) [?:?]

More precisely, when the Lucky Block addon in question is saved as a .zip file when downloaded (which most users keep it as it is), it is unable to locate the structures properly like shown in the log, effectively making the structure drops become empty/ do nothing.

Oddly enough however, is when you extract the .zip as a folder in ./lucky/[addon] (which is my default workflow when making Lucky Block addons), it will just do fine generating them, which means: another extra step for the addon installation.

Incidentally, someone else also reported a similar issue on the Fire Lucky Block page, where the custom fire wishing well will not spawn at all, despite there being a text message for it.

This issue is so far affecting all lucky blocks that uses some custom structures as a structure/drop, regardless of whatever filetype it is, and will effectively downgrade some addons that specfically rely on custom structures as a base for their drops, and it might be concering for some.

commented

thanks for the detailed report, I can reproduce the issue but only on Windows. I'm still investigating

commented

it was an issue with Linux paths (/) versus Windows paths (\), fixed in v11