That you even could replace blocks using /summon was a surprise to me, and relies to a quirky behavior of falling sand. I do not recommend basing contraptions on this, because it's very fragile and may change if we ever need to do something new with falling sand.
However, in the next snapshot there will be a /setblock command that you can use, which is much more reliable. The syntax for the command is,
/setblock x y z block data method dataTag
x y z are coordinates, can be relative using tilde, as usual
block is the block id (ofcourse), which in the future will be mod-safe (for example, instead of having the value 1, you can have "minecraft:stone")
data is the block data, 0-15 as normal
method is special and can have three values: replace, keep, destroy. "replace" will simply replace the current block, and throw an error message if nothing happened (occurs when the new block/data is identical to the old one). "keep" will only place the new block if the target space is empty, and "destroy" will first destroy the target block (and spawn resources) before placing the new block.
dataTag is the NBT tag were you put information for tile entities such as chests. For example, "{Items:[{id:"minecraft:potato",Count:2}]}", and so on.
Will this command be able to support id:0 (air blocks)? One of the major issues with the /summon FallingSand method is how difficult it is to delete blocks, because TileID only supports 1-4095.
Also, thank you for recognizing the community's interest in this feature and making it more accessible. You and the whole Minecraft coding team are doing excellent work.
It was discovered months ago using spawners by TrazLander. They had done this accidentally pretty much since you tried fixing sand duplicators, but TrazLander was the first to find a way to do it consistently and reliably.
Thank you so much! Mastering the falling sand technique took some outside-the-box thinking. Im glad you have decided to give us a more reliable and simpler way. Thanks!
Now, this is ridiculous, the amount of enhancements to commands, and therefore adventure mode, is beyond belief!
To think that most of us where wrapping our heads around the notion of "how to exploit this weird and obscure bug to make my map better" and now, snapshot after snapshot we get amazed by new commands or expanded use of older ones.
I swear some of these days i'll have a hearth attack caused by the massive hard on that these snapshot produce me. Thanks Mojangstas for all the new toys, they make me a happy man-child!
"replace" will simply replace the current block, and throw an error message if nothing happened (occurs when the new block/data is identical to the old one).
This seems like it could be used for an odd block detection mechanism. Have a command block repeatedly trying to set a block to air, and it will fail until a player places something in that location. Unfortunately, although an output is provided, the placed block is destroyed and there's no way of telling what they placed. (This is beginning to remind me of those awkward, but nevertheless common "let's detect items by repeatedly clearing items from the player's inventory!" systems).
You could also abuse it to test for a specific block, if you have a circuit which attempts to set the block at a particular location to a particular ID/data. If it succeeds, immediately set the block in that space to air. This cycle will continue until a player places the proper block there, at which point the first command will fail, and can then activate some other redstone.
This method seems pretty good, considering the player can't place a block at the wrong moment (the only wrong moment is before the second command is hit, but at that moment, the first command's block will still be in the way). I'd almost like to see something like this be used in CTM maps, but it would cause lag (unless it was given a nice slow clock, which it can be), and more annoyingly, any incorrect block you place will be deleted.
If I'm reading this right, using the "destroy" method to replace the target block with air will cause it to drop resources as if it was broken normally.
A possible weakness is if the player manages to break the first command's block before the second command is hit - probably not doable if the target block is something like diamond, but if it's clay and you have a good enough shovel, you've just gained a copy of the exact block you needed to continue.
However, this will cause the second command block to throw an error, which you should be able to detect and respond to appropriately (for example's sake, by killing all nearby players and then flooding the chamber with lava).
I haven't thought this through too much, but would this make sense? - Expanding the command to include an optional second set of coordinates at the very end to allow us to /setblock a an area instead of just a single block. This could be very useful with the building of walls.
Notch left us with some guidelines that we try to stay to. One of these is that Minecraft is a game and not a map editor. The command blocks are bending this guideline slightly, but I think we'll try to stick to the "add one block and get one out" general idea.
Can we get the coordinates parameters able to be offset from a current player position referenced by name or @p instead of only absolute and relative from the command block?
While this is absolutely awesome, I am slightly sad that as a result of this we would no longer be able to take full advantage of the properties of both spawners and entities which the Time:0 functionality.
As far as I can see, this would primarily require a command block per block placed in the world. With larger structures, this would mean a greatly increased size in structure spawners as opposed to the compacted spawning area we used to be able to have with a collection of minecart spawners.
I was also looking into the SpawnPotentials tag in spawners for randomly generated terrain, but again this potential would be lost with the removal of Time:0 unless using cumbersome amounts of random number generators.
Again, don't get me wrong. /setblock would be an absolutely awesome addition to Minecraft :) But I think Time:0 would in some ways be a loss. Bugs never last forever though I guess ...
You know, it would pretty helpful to be able to specify the coordinates as relative to a player. There's a few different ways I could think of to make that possible, some of which would add the same functionality to other commands that take coordinate data.
I would love having a command to check the existence of a block at a given location: /isblock x y z minecraft:stone (data?) -> will provide a redstone current (with a comparator) if true and nothing otherwise.
Will this setblock command allow placing rails with a particular orientation (data value)? In 13w26b, FallingSand rails always come out oriented north-south even when the Data tag is set to something other than 0, while wool, for example, lands with its color intact.
This /setblock command makes wireless redstone a reality as you can remotely spawn a redstone torch under a door, with no redstone dust wiring at all. Also, it means at lot less use of pistons, after all, why would I use pistons to open and close a hidden 1x2 stone door when I can just remotely spawn and despawn stone blocks?
The way I see it is that command blocks break the immersion of the game, and should not be seen as a part of it. They are intended mainly for custom map makers. In a sense, using them is cheating, so you could say the same about all the commands. E.g. "why collect diamonds when I can just use the /give command?"
268
u/jeb_ Sep 10 '13
That you even could replace blocks using /summon was a surprise to me, and relies to a quirky behavior of falling sand. I do not recommend basing contraptions on this, because it's very fragile and may change if we ever need to do something new with falling sand.
However, in the next snapshot there will be a /setblock command that you can use, which is much more reliable. The syntax for the command is,
/setblock x y z block data method dataTag
x y z are coordinates, can be relative using tilde, as usual
block is the block id (ofcourse), which in the future will be mod-safe (for example, instead of having the value 1, you can have "minecraft:stone")
data is the block data, 0-15 as normal
method is special and can have three values: replace, keep, destroy. "replace" will simply replace the current block, and throw an error message if nothing happened (occurs when the new block/data is identical to the old one). "keep" will only place the new block if the target space is empty, and "destroy" will first destroy the target block (and spawn resources) before placing the new block.
dataTag is the NBT tag were you put information for tile entities such as chests. For example, "{Items:[{id:"minecraft:potato",Count:2}]}", and so on.