This is still evident in 20w45a, the issue appears to be that the correct attachment position is only saved to the blockPos tag in the structure's nbt file, and not the normal pos tag. The blockPos tag is never used to load the entity, only the pos tag, thus paintings are always spawned in the incorrect location.
MC-85473
This is still evident in 20w45a, the issue appears to be that the correct attachment position is only saved to the blockPos tag in the structure's nbt file, and not the normal pos tag. The blockPos tag is never used to load the entity, only the pos tag, thus paintings are always spawned in the incorrect location.
Still an issue on 1.18.x, would be much better if entries were to be sorted by either output item or recipe ID.
The cause is actually because display entities are not ticked at all, even passenger logic.
This means the position of the display is not updated, but is saved and loaded correctly (which is why relogging fixes it temporarily)
It also means any passengers of a display entity are also not ticked (which is the root cause of
MC-259805too).I think the best solution would to still remove most of the entity ticking, but still allow the riding and passenger tick logic to run.