When a cushion is placed in a cauldron, it will snap to the nearest pixel height of where you clicked in the cauldron. the same is true for composters. (Ex. you clicked halfway up the inside of the cauldron/composter, the cushion appears halfway up the cauldron/composter.) the expected result (congruent with other blocks) is that it either snaps to the bottom/one position in the cauldron/composter or snaps to top.
Linked issues
relates to 2
Attachments
Comments 12
[Mod] ManosSef
I feel like having this fixed wouldn’t leave for more interesting designs, such as overflowing witch cauldrons.
Mojang will incur the wrath of the community if they remove this. Also, this seems like an intentional feature, considering this is how you place them inside stairs.
This issue has been reviewed by our team.
Please add new, relevant information if it helps us understand or reproduce the issue. To show that you’re affected, use the vote feature rather than commenting.
If a fix is implemented, it will be listed in our official changelogs.
For major outages or urgent assistance, visit the Minecraft Help Center.
no reason to fix an “issue” that just makes an intended feature easier to use i feel? This is just a positive thing to have in the game.
In an upcoming fix, we will add BlockTags that controls this behavior. This means players, who want to keep the previous "sub pixel" placement behavior, will still be able to do so after we resolve this bug.
The fix only affects the placement issue on Cauldrons, Composters, and Hoppers. Other cushion placement techniques discovered so far are intended behavior and will not be affected by this change.
Going forward, if we discover other blocks with the same vertical surface Cushion placement issue, we will be adding them to the BlockTag.
The issue with fixing this is that it means the funny LED floors won’t be possible anymore, since those rely on subpixel placement. Personally i always prefer when things don’t rely on datapacks to work, though this is still a better approach than just removing it outright with no way for players to re-add it.
Regarding Pout’s complaint - you do not need this bug for “LED” floors.
You can get the required alignment by simply placing the cushion on the top of a wall banner or sign.
Not only is this glitchless, it also makes the positioning fully consistent, rather than the Y position of the cushion being dependent on the exact (float-precise) position and viewing angle of the player.
There's no denying that Sicarious's method makes LED floors even better. But this bug allows for much more flexible height placement — almost any height you want. If it gets fixed, there might be some good creations relying on it that would no longer be possible (even if they haven't been created yet). Still, I support the fix, because after all, it makes everything more Minecraft-like.
@Felix Jones What exactly is this new BlockTag? The statement:
if we discover other blocks with the same vertical surface Cushion placement issue, we will be adding them to the BlockTag
seems to be something broader (possibly using a "if it's in the tag, the placement mechanics are different" approach in the positioning).
But in reality, this only affects blocks that have an InteractionShape (called an "auxiliary interaction box" on the Minecraft Wiki). This behavior occurs precisely because the clicked face can be considered "up" due to the InteractionShape, even if the clicked position isn't (since that's defined by the Shape).
So, naturally, blocks in this tag would consider the click direction in Shape instead of the InteractionShape direction (this secondary direction would have to be saved in the UseOnContextfor that). Therefore, the only blocks that would have any additional effect on the tag, besides those mentioned, are scaffolding blocks. They wouldn't be able to discover new blocks simply because all the others have an empty InteractionShape.
In this case, it would be important to add scaffolding to the tag to ignore the InteractionShape in order to resolve MC-309858.
