If you use setblock command and use the [shape=] block state, it will ignore it.
Can replicate with this command:
/setblock ~ ~ ~ minecraft:stone_stairs[shape=outer_right]Linked issues
is duplicated by 2
relates to 2
Attachments
Comments 20
@TheZaius
Is basically this bug but in 1.16.1 MC-106127
Brody, looks like it. Really, the adventure map I'm working on completely relies on these commands working so I'll have to wait until this bug is fixed before using 1.16. Back to 1.15.2, I guess.
It seems this is happening for setblocking doors as well, as when I try to setblock a closed door to an open one, nothing happens.
Also affects iron bars and glass panes.
So to summarize, any block state that indicates a connection with another block.
Why is this important issue taking so long to fix? It's a regression, so the coding error should be easy to find.
Heh, I'm still on 1.15.2 because of this one bug. Completely ruins my adventure map I've been working on for over five years. I've just gotta hold out a little while longer.
It is not a regression, now the issue is with the placement of the block, previously it was that those states were read only. If you're going to call something a regression, at least actually check your claim.
Previous: still saved with data values, shape was in-memory only
Now: command refuses to use the state provided (shape is actually saved and not just in-memory)
Can confirm in 21w06a.
Relates to [MC-129367]
Is this also the case with /fill?
Brevort, my initial comment back in June of last year mentioned seeing this with both /setblock and /fill.
Additionally, although this particular bug only mentions /setblock in the description, MC-191096, which mentions /setblock and /fill, is listed as a related bug.
I hope this is intentional, because fixing this would bring back MC-129367 which is a worse issue for me.
Yusufulus, nooooo, you don't understand this issue. The bug you brought up is easily fixed by specifying the states, as DutchMC mentioned in the comments of that bug, an option that was BROKEN by THIS current bug.
This bug is the single reason why I haven't updated to 1.16+. I am still on 1.15.2. I have scripts constantly running that use /setblock and /fill with specific block states that specify which blocks should have certain block states under which conditions. With this current bug, I no longer have control over that.
The issue you brought up has always been easily rectified.
This bug has no workaround whatsoever until Mojang fixes it.
Then this issue needs to be fixed. I think debug stick can still control these block states but that probably doesn't fix your issue.
Yes, debug stick works great but not on an automated, massive scale. Not even /clone works, as inconvenient a solution as that would be. It just sets everything to automatically connect, even if the cloned source has some blocks connecting and others not connecting.
1.16+ has a lot of great additions and options... but this bug completely holds it back in my view.
Affects 21w42a
Can confirm in 1.19.2.Relates to MC-255254
This bug, a major inconvenience to world builders, has been reported independently by several people. It was officially opened as an issue on 24 June 2020, more than four years ago, in Minecraft Version 1.16. With each subsequent release, it has been acknowledged, but as of today's date, 7 August 2024, it remains unresolved and unassigned. If you're not going to fix it, please just close this issue so we can all stop hoping for a resolution.
Thank you.
Shugoh
I've observed this being an issue with /setblock and /fill commands and it also impacts fences and walls, specifically the east, west, north, south, and up states. I get a message saying "Could not set the block." It's as if when I type something like
The game just reads it like
As if the [east=true,north=true] part was never typed.