minecraft-bedrock-editionminecraft-commands
I would like to build a 10 x 20 wall (10 blocks long, 20 blocks high) in front of the user's player.
I tried to use the following command –
fill ^0 ^1 ^1 ^1 ^20 ^10 stone
But in result, I get 'filled 892 blocks'. What is wrong with my command?
I ran the command second time, it is 592 blocks now –
The activation order does matter and is what's causing the problem. However, activation order via redstone dust does not follow a pattern nor is the order it activates guaranteed to be constant. You would be better off adding delay between the two commands or using a more reliable activation method such as a /fill clock.
Image example of activation order from a /fill clock:
In 1.9, you can simply use chained command blocks to directly specify the order commands are activated, so as to not rely on unreliable and directional methods.
/execute @a ~ ~ ~ detect ~ ~-1 ~ minecraft:stonebrick 1 /tp @p @e{type=Villager]When ANY player steps on mossy stonebrick (minecraft:stonebirck 1) it teleports the nearest player to the command block to the villager regardless if he step on the mossy cobble.
The /execute command modifies the sender of the command to that of its target. Any subsequent selectors in commands being run are going to use the executor as the sender.
This comes into play with sender bias, which forces a target selector to target the entity that ran the command. The command you've presented already uses it. The executing player will be the one to be teleported, so long as they are alive.
The @a selector is the only target selector capable of targeting dead players. If a player dies while on top of stonebrick, they will teleport the nearest living player to them rather than themselves, because @p cannot target dead players.
The fix for that in particular is to use the @a selector while reducing the count (via c parameter) to 1, which also enforces a sender bias. The command itself is still functional as you need it without having to have changed anything else.
/execute @a ~ ~ ~ detect ~ ~-1 ~ minecraft:stonebrick 1 /tp @a[c=1] @e[type=Villager,c=1]
/execute is used to change the sender and origin of commands to run. /tp is being run through the player, not by the command block. @p will be in reference to the executing player's location, and due to sender bias, @p will always target that player so long as that player is alive. Your command was originally working fine apart from the dead targeting flaw.
Best Answer
Here is the problem with your command.
Let's say you run the command while facing the solid green line shown on the page. On a computer, that's where your crosshairs are (so the green line represents the line segment between your head and your crosshairs)
Now, when facing straight, and not up or down, the crooked lines would align with the axes shown in the image. But when you are not facing straight forward, the direction of forward, backward, up, and down will change.
That means that
^0 ^1 ^1will reference a point one unit along the FORWARD line, and one unit right along the red axis. This means that diagonal movements are allowed, which means that forward will mean slightly up as well.It gets even worse with the second set of coordinates. You entered:
^1 ^20 ^10. This means one block right. Not a problem, but when you then do 20 blocks upwards, it means 20 blocks on the UP line in the picture. If you are facing the same way, it means slightly backwards as well!In Java Edition, a fix exists, by using the
rotatedsubcommand of the/executecommand. Here is a command that would work in Java Edition:Unfortunately, this fix does not exist in Bedrock Edition.
I understand that this may be confusing to understand. If you require further explanation, just comment below! Either way, I hope this answer has shown you the dangers of diagonal movements with caret
^notation.