MC-118643/setblock same blocks throws imprecise error "Could not set the block" + maybe also /fill-inconsistency "No blocks filled."
This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat imprecise error message "The block couldn't be placed." (Since 17w46a: ) "Could not set the block.".
Furthermore, the message is inconsistent with the one for /fill in a similar setup: "No blocks filled".
As by now also the error messages for commands improved greatly, I feel the error message for this case should also be changed, as the output is "too vague".
Test setups for /setblock
If I try to set an air block where there is nothing, basically "already air", it gets me the error message "The Block couldn't be placed." (Since 17w46a: ) "Could not set the block."
/setblock ~ ~ ~ minecraft:air
The same also goes for e.g. a naturally spawned white/yellow sandblock, if you stand on it and do
/setblock ~ ~-1 ~ minecraft:sand
and even if you insert its (currently still in the game) datavalue like so:
/setblock ~ ~-1 ~ minecraft:sand 0
then it still gives you that error message.
Wouldn't it make more sense/be more precise to output an error message along the lines of e.g.:
"Same block already at destination" or "No block changed" or similar?
Inconsistency with error message for /fill
If you try to /fill an area that you already filled before with stone, again with stone, you get at least the error message displayed in the command block: "No blocks filled."
If you try to fill just a single block that you already filled before with stone, again with stone, you get a different error message displayed in chat than the /setblock-error message: "No blocks filled."
This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat misleading or inconsistent error message "The block couldn't be placed.". It would be maybe better for both beginners in CBing, as well as advanced CBers for debugging their maps/contraptions, if the (error) message would be more precise, like suggested above, and maybe also consistent with the /fill-message, if the Devs think this would be better for CBers.
- Unresolved
Meri Diana- 4
- 0
- Confirmed
- Commands
- /fill /setblock error-message fill setblock
1.12 - 24w38a
1.12 1.12.1-pre1 1.12.1 1.12.2-pre1 1.12.2-pre2 1.12.2 17w43a 17w43b 17w45b 17w46a 18w01a 18w03b 18w16a 18w19a 1.13-pre1 1.13-pre2 1.13-pre6 1.13-pre7 1.13-pre8 1.13 1.13.1-pre1 1.13.2 18w48a 18w48b 18w49a 19w03b 19w03c 19w05a 19w06a 19w07a 19w12b 19w13b 1.14.1 1.14.2-pre2 1.14.2-pre3 1.15.2-pre1 20w17a 21w07a 24w38a
Created Issue:
/setblock ~ ~ ~ air causes error message if nothing there
Pardon me if this behaviour is from your perspective obviously "works as intended", I personally find it a bit puzzling, as by now also the error messages for commands improved greatly, and thus I feel the error message for this case should also be changed, for consistency.
If I try to set an air block where there is nothing, basically "already air", it gets me the error message "The Block couldn't be placed." (see attached screenshot).
/setblock ~ ~ ~ minecraft:airWouldn't it make more sense to output an error message along the lines of e.g.:
"Block is already air" or similar?I searched on Mojira but only found that issue if it replaced a tile entity, which is not the case here, just simply "nothing"/air. Sorry if I overlooked an already-posted bug, or if this error message was already declared "WaI" for this special case somewhere and I missed it
Attachments1
/setblock ~ ~ ~ air causes error message if nothing/air there, /setblock same blocks throws same error
/setblock~ ~ ~ air causes error message if nothing/air there, /setblock same blocks throws same error/setblock same blocks throws error "The block couldn't be placed" + maybe also /fill-inconsistency
Pardon me if this behaviour is from your perspective obviously "works as intended", I personally find it a bit puzzling, as by now also the error messages for commands improved greatly,and thusI feel the error message for this case should also be changed,for consistency.If I try to set an air block where there is nothing, basically "already air", it gets me the error message "The Block couldn't be placed."
(see attached screenshot)./setblock ~ ~ ~ minecraft:airWouldn't it make more sense to output an error message along the lines of e.g.:
"Block is already air" or similar?I searched on Mojira but only found that issue if it replaced a tile entity, which is not the case here, just simply "nothing"/air. Sorry if I overlooked an already-posted bug, or if this error message was already declared "WaI" for this special case somewhere and I missed it
As by now also the error messages for commands improved greatly, I feel the error message for this case should also be changed, as the output is "too vague".
If I try to set an air block where there is nothing, basically "already air", it gets me the error message "The Block couldn't be placed."
/setblock ~ ~ ~ minecraft:airf you stand on a naturally spawned grassblock and execute this command here:
/setblock ~ ~-1 ~ minecraft:grassit will also tell you "The block couldn't be placed."
The same also goes for e.g. a naturally spawned white/yellow sandblock, if you stand on it and do
/setblock ~ ~-1 ~ minecraft:sandand even if you insert its (currently still in the game) datavalue like so:
/setblock ~ ~-1 ~ minecraft:sand 0then it still gives you that error message.
Wouldn't it make more sense to output an error message along the lines of e.g.:
"Block is already air" or similar?I searched on Mojira but only found that issue if it replaced a tile entity, which is not the case here, just simply "nothing"/air. Sorry if I overlooked an already-posted bug, or if this error message was already declared "WaI" for this special case somewhere and I missed it
As by now also the error messages for commands improved greatly, I feel the error message for this case should also be changed, as the output is "too vague".
If I try to set an air block where there is nothing, basically "already air", it gets me the error message "The Block couldn't be placed."
/setblock ~ ~ ~ minecraft:airf you stand on a naturally spawned grassblock and execute this command here:
/setblock ~ ~-1 ~ minecraft:grassit will also tell you "The block couldn't be placed."
The same also goes for e.g. a naturally spawned white/yellow sandblock, if you stand on it and do
/setblock ~ ~-1 ~ minecraft:sandand even if you insert its (currently still in the game) datavalue like so:
/setblock ~ ~-1 ~ minecraft:sand 0then it still gives you that error message.
Wouldn't it make more sense to output an error message along the lines of e.g.:
"Blockisalready air" or similar?I searched on Mojira but only found that issue if it replaced a tile entity, which is not the case here, just simply "nothing"/air. Sorry if I overlooked an already-posted bug, or if this error message was already declared "WaI" for this special case somewhere and I missed it
As by now also the error messages for commands improved greatly, I feel the error message for this case should also be changed, as the output is "too vague".
/setblock ~ ~ ~ minecraft:airIf you stand on a naturally spawned grassblock and execute this command here:
/setblock ~ ~-1 ~ minecraft:grassit will also tell you "The block couldn't be placed."
The same also goes for e.g. a naturally spawned white/yellow sandblock, if you stand on it and do
/setblock ~ ~-1 ~ minecraft:sandand even if you insert its (currently still in the game) datavalue like so:
/setblock ~ ~-1 ~ minecraft:sand 0then it still gives you that error message.
Wouldn't it make more sense to output an error message along the lines of e.g.:
"Same block already at destination" or "No block changed" or similar?If you try to /fill an area
As by now also the error messages for commands improved greatly, I feel the error message for this case should also be changed, as the output is "too vague".
/setblock ~ ~ ~ minecraft:airIf you stand on a naturally spawned grassblock and execute this command here:
/setblock ~ ~-1 ~ minecraft:grassit will also tell you "The block couldn't be placed."
The same also goes for e.g. a naturally spawned white/yellow sandblock, if you stand on it and do
/setblock ~ ~-1 ~ minecraft:sandand even if you insert its (currently still in the game) datavalue like so:
/setblock ~ ~-1 ~ minecraft:sand 0then it still gives you that error message.
Wouldn't it make more sense to output an error message along the lines of e.g.:
"Same block already at destination" or "No block changed" or similar?If you try to /fill an area
As by now also the error messages for commands improved greatly, I feel the error message for this case should also be changed, as the output is "too vague".
/setblock ~ ~ ~ minecraft:airIf you stand on a naturally spawned grassblock and execute this command here:
/setblock ~ ~-1 ~ minecraft:grassit will also tell you "The block couldn't be placed."
The same also goes for e.g. a naturally spawned white/yellow sandblock, if you stand on it and do
/setblock ~ ~-1 ~ minecraft:sandand even if you insert its (currently still in the game) datavalue like so:
/setblock ~ ~-1 ~ minecraft:sand 0then it still gives you that error message.
Wouldn't it make more sense to output an error message along the lines of e.g.:
"Same block already at destination" or "No block changed" or similar?If you try to /fill an area that you already filled before with stone, again with stone, you get at least the error message displayed in the command block:
As bynowalso the error messages for commands improved greatly, I feel the error message for this case should also be changed, as the output is "too vague".
/setblock ~ ~ ~ minecraft:airIf you stand on a naturally spawned grassblock and execute this command here:
/setblock ~ ~-1 ~ minecraft:grassit will also tell you "The block couldn't be placed."
The same also goes for e.g. a naturally spawned white/yellow sandblock, if you stand on it and do
/setblock ~ ~-1 ~ minecraft:sandand even if you insert its (currently still in the game) datavalue like so:
/setblock ~ ~-1 ~ minecraft:sand 0then it still gives you that error message.
Wouldn't it make more sense to output an error message along the lines of e.g.:
"Same block already at destination" or "No block changed" or similar?
If you try to/fill an areathat you already filled before with stone, again with stone, you get at leastthe error messagedisplayed in the command block:This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat misleading or inconsistent error message "The block couldn't be placed.". (Details below)
As by now also the error messages for commands improved greatly, I feel the error message for this case should also be changed, as the output is "too vague".
/setblock ~ ~ ~ minecraft:airIf you stand on a naturally spawned grassblock and execute this command here:
/setblock ~ ~-1 ~ minecraft:grassit will also tell you "The block couldn't be placed."
The same also goes for e.g. a naturally spawned white/yellow sandblock, if you stand on it and do
/setblock ~ ~-1 ~ minecraft:sandand even if you insert its (currently still in the game) datavalue like so:
/setblock ~ ~-1 ~ minecraft:sand 0then it still gives you that error message.
Wouldn't it make more sense to output an error message along the lines of e.g.:
"Same block already at destination" or "No block changed" or similar?
This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat misleading or inconsistent error message "The block couldn't be placed.". It would be maybe better for both beginners in CBing, as well as advanced CBers for debugging their maps/contraptions, if the (error) message would be more precise, like suggested above, and maybe also consistent with the /fill-message.
This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat misleading or inconsistent error message "The block couldn't be placed.". (Details below)
As by now also the error messages for commands improved greatly, I feel the error message for this case should also be changed, as the output is "too vague".
The Block couldn't be placed."/setblock ~ ~ ~ minecraft:airIf you stand on a naturally spawned grassblock and execute this command here:
/setblock ~ ~-1 ~ minecraft:grassit will also tell you "The block couldn't be placed."
The same also goes for e.g. a naturally spawned white/yellow sandblock, if you stand on it and do
/setblock ~ ~-1 ~ minecraft:sandand even if you insert its (currently still in the game) datavalue like so:
/setblock ~ ~-1 ~ minecraft:sand 0then it still gives you that error message.
Wouldn't it make more sense to output an error message along the lines of e.g.:
"Same block already at destination" or "No block changed" or similar?
This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat misleading or inconsistent error message "The block couldn't be placed.". It would be maybe better for both beginners in CBing, as well as advanced CBers for debugging their maps/contraptions, if the (error) message would be more precise, like suggested above, and maybe also consistent with the /fill-message.
This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat misleading or inconsistent error message "The block couldn't be placed.". (Details below)
As by now also the error messages for commands improved greatly, I feel the error message for this case should also be changed, as the output is "too vague".
/setblock ~ ~ ~ minecraft:airIf you stand on a naturally spawned grassblock and execute this command here:
/setblock ~ ~-1 ~ minecraft:grassit will also tell you "The block couldn't be placed."
The same also goes for e.g. a naturally spawned white/yellow sandblock, if you stand on it and do
/setblock ~ ~-1 ~ minecraft:sandand even if you insert its (currently still in the game) datavalue like so:
/setblock ~ ~-1 ~ minecraft:sand 0then it still gives you that error message.
Wouldn't it make more sense to output an error message along the lines of e.g.:
"Same block already at destination" or "No block changed" or similar?
This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat misleading or inconsistent error message "The block couldn't be placed.". It would be maybe better for both beginners in CBing, as well as advanced CBers for debugging their maps/contraptions, if the (error) message would be more precise, like suggested above, and maybe also consistent with the /fill-message.
/setblock same blocks throws unprecise error "The block couldn't be placed" + maybe also /fill-inconsistency "No blocks filled."
/setblock same blocks throwsunprecise error "The block couldn't be placed" + maybe also /fill-inconsistency "No blocks filled."/setblock same blocks throws imprecise error "The block couldn't be placed" + maybe also /fill-inconsistency "No blocks filled."
This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat misleading or inconsistent error message "The block couldn't be placed.". (Details below)
As by now also the error messages for commands improved greatly, I feel the error message for this case should also be changed, as the output is "too vague".
/setblock ~ ~ ~ minecraft:air
If you stand on a naturally spawned grassblock and execute this command here:/setblock ~ ~-1 ~ minecraft:grassit will also tell you "The block couldn't be placed."
The same also goes for e.g. a naturally spawned white/yellow sandblock, if you stand on it and do/setblock ~ ~-1 ~ minecraft:sand
and even if you insert its (currently still in the game) datavalue like so:/setblock ~ ~-1 ~ minecraft:sand 0then it still gives you that error message.
Wouldn't it make more sense to output an error message along the lines of e.g.:
"Same block already at destination" or "No block changed" or similar?
This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat misleading or inconsistent error message "The block couldn't be placed.". It would be maybe better for both beginners in CBing, as well as advanced CBers for debugging their maps/contraptions, if the (error) message would be more precise, like suggested above, and maybe also consistent with the /fill-message.
*This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat imprecise error message "The block couldn't be placed.".
Furthermore, the error message is inconsistent with the message displayed for /fill in a similar setup. *(Details below)As by now also the error messages for commands improved greatly, I feel the error message for this case should also be changed, as the output is "too vague".
Test setups for /setblock
/setblock ~ ~ ~ minecraft:airThe same also goes for e.g. a naturally spawned white/yellow sandblock, if you stand on it and do
/setblock ~ ~-1 ~ minecraft:sandand even if you insert its (currently still in the game) datavalue like so:
/setblock ~ ~-1 ~ minecraft:sand 0then it still gives you that error message.
Wouldn't it make more sense/be more precise to output an error message along the lines of e.g.:
"Same block already at destination" or "No block changed" or similar?Inconsistency with error message for /fill
This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat misleading or inconsistent error message "The block couldn't be placed.". It would be maybe better for both beginners in CBing, as well as advanced CBers for debugging their maps/contraptions, if the (error) message would be more precise, like suggested above, and maybe also consistent with the /fill-message, if the Devs think this would be better for CBers.
*This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat imprecise error message "The block couldn't be placed.".
Furthermore, the error message is inconsistent with the message displayed for /fill in a similar setup. *(Details below)As by now also the error messages for commands improved greatly, I feel the error message for this case should also be changed, as the output is "too vague".
Test setups for /setblock
/setblock ~ ~ ~ minecraft:airThe same also goes for e.g. a naturally spawned white/yellow sandblock, if you stand on it and do
/setblock ~ ~-1 ~ minecraft:sandand even if you insert its (currently still in the game) datavalue like so:
/setblock ~ ~-1 ~ minecraft:sand 0then it still gives you that error message.
Wouldn't it make more sense/be more precise to output an error message along the lines of e.g.:
"Same block already at destination" or "No block changed" or similar?Inconsistency with error message for /fill
This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat misleading or inconsistent error message "The block couldn't be placed.". It would be maybe better for both beginners in CBing, as well as advanced CBers for debugging their maps/contraptions, if the (error) message would be more precise, like suggested above, and maybe also consistent with the /fill-message, if the Devs think this would be better for CBers.
This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat imprecise error message "The block couldn't be placed.".
Furthermore, the message is inconsistent with the one for /fill in a similar setup: "No blocks filled".As by now also the error messages for commands improved greatly, I feel the error message for this case should also be changed, as the output is "too vague".
Test setups for /setblock
/setblock ~ ~ ~ minecraft:airThe same also goes for e.g. a naturally spawned white/yellow sandblock, if you stand on it and do
/setblock ~ ~-1 ~ minecraft:sandand even if you insert its (currently still in the game) datavalue like so:
/setblock ~ ~-1 ~ minecraft:sand 0then it still gives you that error message.
Wouldn't it make more sense/be more precise to output an error message along the lines of e.g.:
"Same block already at destination" or "No block changed" or similar?Inconsistency with error message for /fill
This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat misleading or inconsistent error message "The block couldn't be placed.". It would be maybe better for both beginners in CBing, as well as advanced CBers for debugging their maps/contraptions, if the (error) message would be more precise, like suggested above, and maybe also consistent with the /fill-message, if the Devs think this would be better for CBers.
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat imprecise error message "The block couldn't be placed.".
Furthermore, the message is inconsistent with the one for /fill in a similar setup: "No blocks filled".As by now also the error messages for commands improved greatly, I feel the error message for this case should also be changed, as the output is "too vague".
Test setups for /setblock
"The Block couldn't be placed."/setblock ~ ~ ~ minecraft:airThe same also goes for e.g. a naturally spawned white/yellow sandblock, if you stand on it and do
/setblock ~ ~-1 ~ minecraft:sandand even if you insert its (currently still in the game) datavalue like so:
/setblock ~ ~-1 ~ minecraft:sand 0then it still gives you that error message.
Wouldn't it make more sense/be more precise to output an error message along the lines of e.g.:
"Same block already at destination" or "No block changed" or similar?Inconsistency with error message for /fill
This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat misleading or inconsistent error message "The block couldn't be placed.". It would be maybe better for both beginners in CBing, as well as advanced CBers for debugging their maps/contraptions, if the (error) message would be more precise, like suggested above, and maybe also consistent with the /fill-message, if the Devs think this would be better for CBers.
This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat imprecise error message "The block couldn't be placed.".
Furthermore, the message is inconsistent with the one for /fill in a similar setup: "No blocks filled".As by now also the error messages for commands improved greatly, I feel the error message for this case should also be changed, as the output is "too vague".
Test setups for /setblock
"The Block couldn't be placed."(In: 17w46a: ) "Could not set the block."/setblock ~ ~ ~ minecraft:airThe same also goes for e.g. a naturally spawned white/yellow sandblock, if you stand on it and do
/setblock ~ ~-1 ~ minecraft:sandand even if you insert its (currently still in the game) datavalue like so:
/setblock ~ ~-1 ~ minecraft:sand 0then it still gives you that error message.
Wouldn't it make more sense/be more precise to output an error message along the lines of e.g.:
"Same block already at destination" or "No block changed" or similar?Inconsistency with error message for /fill
This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat misleading or inconsistent error message "The block couldn't be placed.". It would be maybe better for both beginners in CBing, as well as advanced CBers for debugging their maps/contraptions, if the (error) message would be more precise, like suggested above, and maybe also consistent with the /fill-message, if the Devs think this would be better for CBers.
/setblock same blocks throws imprecise error "The block couldn't be placed" + maybe also /fill-inconsistency "No blocks filled."/setblock same blocks throws imprecise error "Could not set the block" + maybe also /fill-inconsistency "No blocks filled."
This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat imprecise error message "The block couldn't be placed.".
Furthermore, the message is inconsistent with the one for /fill in a similar setup: "No blocks filled".As by now also the error messages for commands improved greatly, I feel the error message for this case should also be changed, as the output is "too vague".
Test setups for /setblock
"The Block couldn't be placed."(In:17w46a: ) "Could not set the block."/setblock ~ ~ ~ minecraft:airThe same also goes for e.g. a naturally spawned white/yellow sandblock, if you stand on it and do
/setblock ~ ~-1 ~ minecraft:sandand even if you insert its (currently still in the game) datavalue like so:
/setblock ~ ~-1 ~ minecraft:sand 0then it still gives you that error message.
Wouldn't it make more sense/be more precise to output an error message along the lines of e.g.:
"Same block already at destination" or "No block changed" or similar?Inconsistency with error message for /fill
This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat misleading or inconsistent error message "The block couldn't be placed.". It would be maybe better for both beginners in CBing, as well as advanced CBers for debugging their maps/contraptions, if the (error) message would be more precise, like suggested above, and maybe also consistent with the /fill-message, if the Devs think this would be better for CBers.
This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat imprecise error message
"The block couldn't be placed." (Since 17w46a: ) "Could not set the block.".
Furthermore, the message is inconsistent with the one for /fill in a similar setup: "No blocks filled".As by now also the error messages for commands improved greatly, I feel the error message for this case should also be changed, as the output is "too vague".
Test setups for /setblock
"The Block couldn't be placed."(Since 17w46a: ) "Could not set the block."/setblock ~ ~ ~ minecraft:airThe same also goes for e.g. a naturally spawned white/yellow sandblock, if you stand on it and do
/setblock ~ ~-1 ~ minecraft:sandand even if you insert its (currently still in the game) datavalue like so:
/setblock ~ ~-1 ~ minecraft:sand 0then it still gives you that error message.
Wouldn't it make more sense/be more precise to output an error message along the lines of e.g.:
"Same block already at destination" or "No block changed" or similar?Inconsistency with error message for /fill
This bugpost is not about forcing success if you /setblock or /fill an already-existing block( s ), but about changing the somewhat misleading or inconsistent error message "The block couldn't be placed.". It would be maybe better for both beginners in CBing, as well as advanced CBers for debugging their maps/contraptions, if the (error) message would be more precise, like suggested above, and maybe also consistent with the /fill-message, if the Devs think this would be better for CBers.
![[Helper] Lord_Quadrato](../../../data/avatars/users/26105.png){kind=small}
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mod] Anthony Cicinelli](../../../data/avatars/users/10122.svg){kind=small}
![[Mod] ManosSef](../../../data/avatars/users/61702.png){kind=small}
/setblock has always worked this way. If you want to force success (even when the blocks are the same), you can try /setblock ~ ~ ~ air default destroy.
[Mod] tryashtar Fair enough, but it's not about a "workaround so it renders success without throwing an error", but really just about the (from my perspective) misleading error message itself, even more considering that those error messages were highly improved.
But I just saw FVbico closed it as invalid, and I trust you guys you know what you're doing/saying.
Aside from that, it's a rather small thing, so I'm not insisting
Have a good week, y'all.
Changing of the error message would be a feature request.
Thank you, same ti you.
I have to disagree that it would be a feature request, as I'm asking for consistency with other, better explained, error messages. Although you can't 100% compare it, it also was not seen as feature request that the word "white" was added to regular wool etc. >;]
But like I said, I won't insist, it's not important enough for me, I was just worried that CB newbies might be puzzled, that's all
Take care.
Well, asking for a different error message is considered more a request; white not being mentioned was inconsistent with other colored blocks.
Anyway, I'll stop this here.
Are there any situations that throw this error message besides this one, i.e. trying to place a block that's already there?
[Mod] tryashtar Oh yes, of course it does, with any block that is there before, either naturally or artificially set by you.
As soon as you try to replace it with the very same block, it happens.
E.g. if you stand on a naturally spawned grassblock and execute this command here:
it will also tell you "The block couldn't be placed."
The same also goes for e.g. a naturally spawned white/yellow sandblock, if you stand on it and do
and even if you insert its (currently still in the game) datavalue like so:
then it still gives you that error message.
Anything is affected from it, as far as I can tell.
Obviously I didn't have the time to check all of the blocks there are in the game.
I thought it might be a problem for beginners in CommandBlocking, but if you guys decide it's not an issue, then I'll accept it, as I don't have you guys' directives and insight on what Mojang may considered "WaI" or what is, by your directives, a "feature request/suggestion" which doesn't belong here on Mojira.
From my perspective this is definitely not a feature request/suggestion for the aforementioned reasons, but it's up to you guys to decide; it wouldn't be the first time myself or people close to me would have an opposing opinion to some of you guys' decisions or statements
<3, but all I can do is to inform you about what I personally find an issue; I don't want to start a fight or anything along those lines. My personal opinion is just one out of many, so please don't misunderstand my intentions here, I'm always solely worried about the community, so it may seem sometimes that I might step on you guys' toes every now and then, for their sake.
In any case, y'all have a good week!
If you can(and want), pass my greetings and "thumbs up" to the other guys in your chat, your voluntary work here on Mojira surely isn't always very easy, and you may not get nice words too many times here
Take care!
PS: I maybe should add that this only affects blocks that are either not directional, or if they are, you'd have to insert the same directions to place them.
E.g. if you manually place an (undamaged) anvil facing East>West, but then execute this command:
it will of course succeed, as the default orientation the game sets the anvil is "0", North>South.
It would not succeed and throw the "The block couldn't be placed" message, if you'd have inserted:
instead, as it's the same orientation that was there before.
Leaves are also a special case due to the decay-check, but I think after that example above, you understand very well when this error gets thrown and when it does not.
So, I'm done now
Yes, what I meant by that question was, "is there any situations other than those in which this error message is thrown?"
We've established that changing the block with /setblock has a success message, but when it doesn't change, we get this error. Is this the only time this error is shown? If so, I would argue it's a very vague message for a very specific scenario.
I'm not 100% sure if I understood you correctly, my brain is still afk, but let's see
"block couldn't be placed" inserted into Mojira's search box renders 188 issues: https://bugs.mojang.com/issues/?jql=text%20~%20%22block%20couldn%27t%20be%20placed%22
I searched through these issues before I wrote mine here, but couldn't find the exact issue that I've got here.
There was a recent fix, the same thrown error if a tile entity was replaced with a setblock-air which actually succeeded, but the game threw that error regardless (
MC-50166), and I knew that bugpost/fix of it.That's why I thought this issue here might be a valid one.
MC-91459is considered valid, probably because the error message deviates from the other "out of the world / maxbuildheight" messages, but I still can't see why "my" issue here wouldn't be, as I find the error message indeed, as you called it, "too vague".Apparently it seems that the game can detect if one tries to /setblock the same block that already is set at the same position, otherwise it wouldn't throw that message? So why does it not just give a message like: "Same block is already at destination" or so? Which brings me to a different question I need to test asap regarding /fill, which defaults to "replace" even without any "oldBlockHandling" inserted last time I checked, but I don't want to make this issue here more confusing, unless you'd say there should be some sort of consistency between /setblock and /fill?
I feel /setblock behaves a bit inconsistent, if it only replaces a block if it's not the same that was there before with the basic command, and if that behaviour is "WaI", then the error message should at least display that behaviour, which might be less confusing for beginners in CBing. That's all I meant, but, again: That's just my personal opinion
Have a nice Sunday, I'll try to wake up my brain now with some jogging in fresh air
Fair enough, reopened, but no promises that another mod won't close it.
lol
thanks on behalf of my CB-beginners-weak heart 
I'll add a bit more info into the OP when I'm back from jogging and breakfast, and did some testing with /fill
Confirmed for 1.13-pre6.
Confirmed for 1.13-pre7.
Confirmed for 1.13-pre8.
Confirmed for 1.13.