When creating a custom structure, I noticed the bell orientation doesn't get saved properly. It seems to load with the same orientation as it was saved. This means sometimes a bell that hangs on the side of blocks ends up floating when loaded. Even bells that stand noticeably keep their stone legs along the same axis as saved instead of rotating with the structure (through natural, command, or structure block placement). I assume hanging bells do too, but this isn't really noticeable since they hang by a point and can swing in any direction. Additionally, when I tried loading the custom structure that has a bell that hangs from a side wall with a structure block and applying a rotation, the bell didn't even load at all.
Related issues
relates to
Attachments
Comments
migrated
migrated
Seems the facing state doesn't change along with rotation/mirror unlike numerous other blocks' facing states.
Sniper1.1
I just want to add that the directions don’t update properly with the in game villages upon closer inspection. I’m not sure if there’s any centers that use a wall bell, but you can see on the few that the bell stands on the stone legs that it’s always in the same orientation regardless of how the structure is angled.
ampolive
Related to MC-169827?
Sniper1.1
Maybe? I don’t seem to see that bells are still that bad, so maybe they fixed that the type wouldn’t save (standing, hanging, wall) but forgot to also include the direction needs to save or it wasn’t implemented properly.
Sniper1.1
New development! Bells are not the only block impacted it seems. Beehives don't get rotated either. Item frame rotation also isn't changed depending on structure orientation, but they are entities so they likely work differently.
ampolive
Item frames are tracked in MC-248855. I'll add beehives to the summary.
KirbAvion
This may technically be a duplicate of MC-227255, albeit a more actively maintained one.
migrated
Beehives part, yes, bells, no.
Sniper1.1
Rails also seem to share this issue.
migrated
Please keep this report about bells only, the others all already have their own reports, and each need their own fix.
Sniper1.1
I suppose we can keep them as separate reports, but I would’ve thought it’d be the same underlying issue and as such useful to include them all in one. But, since we are keeping them separate, this seems to be the rails report here: MC-104231
Brain81505
Can confirm in 1.19.3 and 23w06a.
Conure512
Confirmed in 1.20-pre5, I was just about to report this