Prerequisites

• I am running the latest alpha version of MineColonies and 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.18.1
• MineColonies Version: 1.0.394
• Structurize Version: 1.0.341
• Domum Ornamentum Version: 1.0.39

Expected behavior

The panels my builder needs can be fulfilled by panels made in the architect's cutter

Actual behavior

The builder seems to request different panels than the one in the schematic building
(In the building they seem like the horizontal or vertical striped Oak Planks Panels, and the builder requests the "Full" variant)

When I craft the "full" variant, the resource scroll keeps indicating I don't have the correct panel.
I tried all other six variants of the oak planks panels, and none of them seemed to change anything in the resource scroll.

Steps to reproduce the issue

1. Make sure you have a schematic with panels in them (In my case, it is the Cavern house level 1)
2. Let a builder build it
3. Try to craft the panels requested by the builder

Logs

• latest.log: https://gist.github.com/MotionlessTrain/7e71376824dddd95665bedd74b021ff1

Notes

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.

The ones you got in the inventory not only got a different nbt tag, but even got an extra gap. What kind of panel is this? I this from a custom scan? Witch one?

It is from the Cavern citizen1

It was scanned on the 1.17 schematics server
Could it be as issue with the way the NBT works between the 1.17 version and the 1.18 version?

You could try to scan sth in 1.18 and try to build that to rule it out.

FYI I did a datamine on the Feb 3 version of cavern citizen1 and it says that there are 3 domum panel blocks that are all oak planks, yes, but the vertically_striped variant and not the full variant.

It looks like it's omitting the type tag when converting the block to an item for the resources list.

And that looks like the fault of the DoBlockPlacementHandler, which wasn't updated to understand panels.

It really looks like the IMateriallyTexturedBlock interface ought to be extended with a new method to return an appropriate ItemStack rather than trying to duplicate the logic across two different mods (which might not have matching versions). I had a quick look at an mcol-only fix, but sadly both the existing implementations on the DO side seem inadequate to the usage -- getDrops requires a LootContext (which can't be created client-side), and getCloneItemStack requires the blockentity to exist in-world, not purely in memory. (Although perhaps that argues that the placement handlers should have access to a BlueprintBlockAccess world to read block entities from -- that would also have fixed some chest-related issues and perhaps others.) Unfortunately presently that's client-side-only, while placement handlers are dual sided.

And that looks like the fault of the DoBlockPlacementHandler, which wasn't updated to understand panels.

It really looks like the IMateriallyTexturedBlock interface ought to be extended with a new method to return an appropriate ItemStack rather than trying to duplicate the logic across two different mods (which might not have matching versions). I had a quick look at an mcol-only fix, but sadly both the existing implementations on the DO side seem inadequate to the usage -- getDrops requires a LootContext (which can't be created client-side), and getCloneItemStack requires the blockentity to exist in-world, not purely in memory. (Although perhaps that argues that the placement handlers should have access to a BlueprintBlockAccess world to read block entities from -- that would also have fixed some chest-related issues and perhaps others.) Unfortunately presently that's client-side-only, while placement handlers are dual sided.

This idea was rejected.
DO correctly implements all vanilla methods to do this: getCloneItemStack needs to be used here.
This is not issue which is limited to DO only, several mods use this mechanic as well, and Structurize just needs to support this properly.

Structurize just needs to support this properly.

Well, that was the final idea that I mentioned -- getCloneItemStack could be called if it could supply a BlockAccess that contained the fully-inflated blockstate and entity. In theory it'd only take a fairly minimal refactor of BlueprintBlockAccess to make it dual-sided, although some related refactoring that should probably happen at the same time would be more extensive. (I already had a go at some of that, although it's on an abandoned branch.)

Was just missing a case on the DO handler. I know that this is not the most flexible, but it's better than having to try to get through a whole simulated world.

I can confirm it is not a 1.17 vs 1.18 issue, and that it is purely the request (and item on the resource scroll) that is wrong:
I placed those panels I crafted before down (in all seven variants), scanned it and let the builder build them again, and he asked for seven panels with only one nbt tag (of the full variant, without empty line in the tooltip), similar to the first screenshot.

To complete the house, I creatively fulfilled the request of the builder, let them finish the house, and then picked block on the placed down panels. That gave me a "correct" vertical striped oak planks panel.