Describe the Bug

The schematicannon places a randomly textured version of the block variation that it is meant to place. The random textures coincide with the default block's preview in the creative and JEI menus. I am aware that this bug has been reported twice before, but I think I learned things that the other two bug reports have not mentioned/brought to attention.

1. DO blocks return to a "default" state after being moved by a piston, although this doesn't match the rapidly swapping textures
2. The above is a result of the blocks being tile entities
3. The safe_nbt tag does not prevent this from happening

After figuring out that safe_nbt does not work, I looked for bug reports on the DO GitHub page as well, and found this regarding the piston issue:

"I analyzed the way how Domum creates and saves block data and this behaviour comes "unfortunately" out of the way of handling textures. To describe it simple: Minecraft uses an single step block creation process and most things were more or less static. To by flexible in case of textures and to handle everything efficiently, Domum needs to go another way and has two-step init process, which is realized by the architecture cutter, which creates itemstack / block initialy with the seen textures and updates it after the creation to the correct textures from the used materials in the cutter.

What has that to do with the seen behaviour?

The root cause seems that a movement of the block inside the world creates "faulty" blocks. The crash is currently fixed since 110 by simply check the object and not returning "null". What stays is the default textured / faulty block. Some details out of my "Piston based Testing scenario":

When a piston moves a block, the block needs to be "moved" at end of the extraction process of the piston from initial postion in the map to the 'extracted' position
Minecraft realizes this movement in the way: block.Remove(oldPos); block.create(newPos)
With this behaviour only the minecraft 'first stage' were used to create the new block, which has default textures and some missing feauters, which will set by the domum 'second stage'
Result: we see flipping textures on the block, because it's a new one
How Minecraft solves this Problem

Define complex entity block objects as "unmoveable" (i.ex. Chests, ...)
Idea to fix this Piston based topics

Each block entity is marked in update process of the level "to be removable". At the point we can overwrite this behaviour to have a hook up point. Next is to examine why the block should be removed: look through to caller stack for "PistonBaseBlock". When the Piston "moves" us, then save the 'textureData' with PosData and current tick.
Later in the block "recreation", which should be in the range of 1-3 ticks, we can have a look if there were an "saved entry" in a position near the new one, so that the old texture data could be reused. In theory this should work.

The idea had some negative aspects: we need to store information outside the minecraft functional behaviour, which will be deleted when minecraft crashes. Another aspect is, when i place two pistons directly in the neighborhood, i will need more information about the new position to differentiate between both pistons and their moved blocks. And last: i need a clean up everything from time to time, so that saved textureData is skipped after some ticks, when they were not used."
source: ldtteam/Domum-Ornamentum#136 (comment)

The grammar isn't perfect, but it's serviceable. After this, a contributor replied that the issue would have to be solved on Create's side, as it has been "discussed internally many times," which is why I am writing this.

Reproduction Steps

1. Build something with DO blocks
2. Create a schematic of said building
3. Place the schematic into the schematicannon, place the correct blocks in an adjacent chest, and tell it to begin building

Expected Result

Blocks are placed with their original texture from the schematic.

Screenshots and Videos

No response

Crash Report or Log

No response

Operating System

Windows 10

Mod Version

0.5.1e

Minecraft Version

1.20.1

Forge Version

47.2.0

Other Mods

No response

Additional Context

No response

Bump this

This should be fixed by Domum Ornamentum by them using the safenbt tag create provides