Prerequisites

• I am running the latest alpha version of Structurize for my Minecraft version.
• I checked the MineColonies/Structurize wiki and made sure my issue is not covered there.
• I made sure that this issue is not a duplicate of any existing issue.

Context

• Minecraft Version: 1.16.5
• Structurize Version: 0.13.167
• MineColonies Version (if related bug): 0.14.131
• Related Mods and their Versions:

Expected behavior

When the green check mark is pressed, after positioning my custom schematic, and the build button is pressed in the resulting window, that a build order is would be created for the builder to execute.

Actual behavior

Nothing happens. There is a null pointer exception recorded in the log.

Steps to reproduce the issue

1. Place schematic buildtest8.blueprint in the structurize/scans/new directory.
2. Attempt to place a build order for the schematic using the build tool.
3. Nothing happens.

Logs

• latest.log: https://gist.github.com/dupontct/011cd9646e07444922f7f870bce9cfeb
• This is the blueprint that will cause the bug: buildtest8.zip

Notes

The buildtest8 schematic was created using the structurize scan tool.

Viewers

• Add a thumbs-up to the bug report if you are also affected. This helps the bug report become more visible to the team and doesn't clutter the comments.
• Add a comment if you have any insights or background information that isn't already part of the conversation.

Although this is a very stale issue, I was able to reproduce it. I do not know if it has been fixed in recent versions, but my searching on the minecolonies discord leads me to believe that handling of decorative schematics has changed, so the bug that caused this issue may no longer be present. Regardless, I am posting my troubleshooting and conclusion in case anyone else is playing old versions and encounters the same problem.

It seems the issue, at least in the version I am running, is that custom schematics cannot end in numbers other than 1 unless a schematic of the same name and earlier number exists. Doing so results in the error message indicated at the end of my post. These schematics can be pasted using creative mode, but attempting to create a build order (whether in creative or survival) will fail. My assumption is that one of the mods - perhaps minecolonies after all - is treating the schematics ending in numbers as upgrade tiers to huts, even though decorations don't work that way and no hut is part of the schematic. Conversely, schematics beginning with SCAN_ (i.e., generated automatically by shift-right-click of the scan tool) may be special cased to ignore this.

My testing was as follows:

Minecraft 1.15.2
(Craft to Exile 3.1.5)
Minecolonies 1.15-0.13.646-RELEASE
Structurize 0.13.109-ALPHA-universal.jar

Enter creative mode.
Create a townhall, colony, and at least 1 builder's hut, staffed.
Set dimensions of an area and create a schematic with the scan tool. (I used 2 leaf blocks over a 2x8 area, as builders do not require resources to place leaf blocks.)
Shift right click the scan tool on air to create the schematic with a generated name.
Using the build tool, right click a block to begin placement of the schematic.
Confirm as is. A build order will be created. (This demonstrates the schematic is valid.)
Begin placement of the schematic a second time.
Rename the schematic, altering the number value of the generated name.
Cancel out of the build placement session i.e., press the X button. (This is necessary, as confirming the build order at this time will simply paste/fill it out immediately, as though you used the creative paste function, even when only clicking the checkmark.)
Place the schematic again. A build order is created. (This confirms that schematics can be renamed and still be valid.)
Rename the schematic again, using only text.
Place the schematic. A build order is created.
Rename this schematic, appending 1 to the name.
Place the schematic. A build order is created.
Rename the schematic again, appending the text name with any number other than 1.
Place the schematic. Build orders will not be created and the error will be generated in the log file.
Rename this schematic so that the final character is 2
Create a new scan/schematic, naming this the same text as used above, ending with the final character 1. It need not have any physical similarity to the 2 schematic.
Attempt to place schematic 2. This will now create build orders, but only for for 1.

[Server thread/FATAL] [minecraft/ThreadTaskExecutor]: Error executing task on Server
java.lang.NullPointerException: null
	at com.minecolonies.coremod.util.ColonyUtils.calculateCorners(ColonyUtils.java:42) ~[?:unspecified] {re:classloading}
	at com.minecolonies.coremod.colony.workorders.WorkManager.isWorkOrderWithinColony(WorkManager.java:309) ~[?:unspecified] {re:classloading}
	at com.minecolonies.coremod.colony.workorders.WorkManager.addWorkOrder(WorkManager.java:261) ~[?:unspecified] {re:classloading}
	at com.minecolonies.coremod.network.messages.server.BuildToolPlaceMessage.handleDecoration(BuildToolPlaceMessage.java:312) ~[?:unspecified] {re:classloading}
	at com.minecolonies.coremod.network.messages.server.BuildToolPlaceMessage.onExecute(BuildToolPlaceMessage.java:177) ~[?:unspecified] {re:classloading}
	at com.minecolonies.coremod.network.messages.splitting.SplitPacketMessage.lambda$onExecute$1(SplitPacketMessage.java:128) ~[?:unspecified] {re:classloading}
	at net.minecraftforge.fml.network.NetworkEvent$Context.enqueueWork(NetworkEvent.java:215) ~[?:?] {re:classloading}
	at com.minecolonies.coremod.network.messages.splitting.SplitPacketMessage.onExecute(SplitPacketMessage.java:128) ~[?:unspecified] {re:classloading}
	at com.minecolonies.coremod.network.NetworkChannel.lambda$setupInternalMessages$4(NetworkChannel.java:264) ~[?:unspecified] {re:classloading}
	at net.minecraftforge.fml.network.simple.IndexedMessageCodec.lambda$tryDecode$3(IndexedMessageCodec.java:128) ~[?:?] {re:classloading}
	at java.util.Optional.ifPresent(Unknown Source) ~[?:1.8.0_181] {}
	at net.minecraftforge.fml.network.simple.IndexedMessageCodec.tryDecode(IndexedMessageCodec.java:128) ~[?:?] {re:classloading}
	at net.minecraftforge.fml.network.simple.IndexedMessageCodec.consume(IndexedMessageCodec.java:162) ~[?:?] {re:classloading}
	at net.minecraftforge.fml.network.simple.SimpleChannel.networkEventListener(SimpleChannel.java:80) ~[?:?] {re:classloading}
	at net.minecraftforge.eventbus.EventBus.doCastFilter(EventBus.java:212) ~[eventbus-2.2.1-service.jar:?] {}
	at net.minecraftforge.eventbus.EventBus.lambda$addListener$11(EventBus.java:204) ~[eventbus-2.2.1-service.jar:?] {}
	at net.minecraftforge.eventbus.EventBus.post(EventBus.java:258) ~[eventbus-2.2.1-service.jar:?] {}
	at net.minecraftforge.fml.network.NetworkInstance.dispatch(NetworkInstance.java:84) ~[?:?] {re:classloading}
	at net.minecraftforge.fml.network.NetworkHooks.lambda$onCustomPayload$1(NetworkHooks.java:78) ~[?:?] {re:classloading}
	at java.util.Optional.map(Unknown Source) ~[?:1.8.0_181] {}
	at net.minecraftforge.fml.network.NetworkHooks.onCustomPayload(NetworkHooks.java:78) ~[?:?] {re:classloading}
	at net.minecraft.network.play.ServerPlayNetHandler.func_147349_a(ServerPlayNetHandler.java:1279) ~[?:?] {re:mixin,pl:accesstransformer:B,re:classloading,pl:accesstransformer:B,xf:fml:randompatches:RandomPatches ServerPlayNetHandler Transformer,pl:mixin:APP:performant.mixins.json:connection.ServerPlayNetHandlerMixin,pl:mixin:A}
	at net.minecraft.network.play.client.CCustomPayloadPacket.func_148833_a(CCustomPayloadPacket.java:42) ~[?:?] {re:classloading}
	at net.minecraft.network.play.client.CCustomPayloadPacket.func_148833_a(CCustomPayloadPacket.java:12) ~[?:?] {re:classloading}
	at net.minecraft.network.PacketThreadUtil.func_225383_a(SourceFile:21) ~[?:?] {re:classloading}
	at net.minecraft.util.concurrent.TickDelayedTask.run(SourceFile:18) ~[?:?] {re:classloading}
	at net.minecraft.util.concurrent.ThreadTaskExecutor.func_213166_h(SourceFile:144) [?:?] {re:mixin,pl:accesstransformer:B,re:classloading,pl:accesstransformer:B}
	at net.minecraft.util.concurrent.RecursiveEventLoop.func_213166_h(SourceFile:23) [?:?] {re:mixin,re:classloading}
	at net.minecraft.server.MinecraftServer.func_213166_h(MinecraftServer.java:731) [?:?] {re:mixin,pl:accesstransformer:B,re:classloading,pl:accesstransformer:B,pl:mixin:A}
	at net.minecraft.server.MinecraftServer.func_213166_h(MinecraftServer.java:141) [?:?] {re:mixin,pl:accesstransformer:B,re:classloading,pl:accesstransformer:B,pl:mixin:A}
	at net.minecraft.util.concurrent.ThreadTaskExecutor.func_213168_p(SourceFile:118) [?:?] {re:mixin,pl:accesstransformer:B,re:classloading,pl:accesstransformer:B}
	at net.minecraft.server.MinecraftServer.func_213205_aW(MinecraftServer.java:714) [?:?] {re:mixin,pl:accesstransformer:B,re:classloading,pl:accesstransformer:B,pl:mixin:A}
	at net.minecraft.server.MinecraftServer.func_213168_p(MinecraftServer.java:708) [?:?] {re:mixin,pl:accesstransformer:B,re:classloading,pl:accesstransformer:B,pl:mixin:A}
	at net.minecraft.util.concurrent.ThreadTaskExecutor.func_213161_c(SourceFile:127) [?:?] {re:mixin,pl:accesstransformer:B,re:classloading,pl:accesstransformer:B}
	at net.minecraft.server.MinecraftServer.func_213202_o(MinecraftServer.java:694) [?:?] {re:mixin,pl:accesstransformer:B,re:classloading,pl:accesstransformer:B,pl:mixin:A}
	at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:641) [?:?] {re:mixin,pl:accesstransformer:B,re:classloading,pl:accesstransformer:B,pl:mixin:A}

1.15 is really old and not supported these days, feel free to reopen if you can reproduce in 1.19+

This is actually a client->server sync issue. I'll move it to structurize. Been reworked anyway.

@Raycoms can you please elaborate why this is structurize issue?

Seems like a client->server synch issue for me of schematics. This crashes when the blueprint is null.

Does this happen for all custom schematics? Does it also happen for built-in schematics?

Just that particular schematic. I had another schematic that would build just fine.

And you've tried rescanning it?

This should have nothing in common with schematic, the only thing which may affect it from schematic side is its size - but I doubt it's bigger than your render distance.

Rescanning lead to inconsistent behavior, some of the scans would cause the null pointer exception others would not. I was never able to create a reproducible event sequence to create a schematic that would cause this null pointer exception.

Nightenom, The schematic is a 8x16 block footprint that is 14 blocks tall. So it's definitely not render distance.