Minecraft – the difference between “at” and “positioned” in “/execute”

minecraft-commandsminecraft-java-edition

The /execute command is a versatile command used to execute commands on behalf of other entities, or to test for conditionals before executing a command. It offers multiple different parameters to set who, what, when, and where to execute the command.

There are two parameters that look very similar: at and positioned as.
The Minecraft Wiki has a clear description of what each one does: at is used to position at an entity, while positioned can be used to specify coordinates.

But however, there is another way to specify an entity: using positioned as ??. This also offers us to specify an entity instead of coordinates to execute the command at.

What is the difference between these two parameters, and in which situations should I prefer each of them?

Best Answer

This is an interesting question. at changes the position of execution using the position, rotation, and dimension of the target. positioned as only uses the position of the target.

You can test this yourself by running this command from a command block in the overworld (make sure the chunk is loaded):

/execute if entity @e[tag=test] positioned as @p run setblock ~ ~2 ~ glass

The entity with the tag is just a switch so you can activate the command from the end/nether. The command will place a glass block at your position but in the overworld (which proves that positioned as only uses the position). Now try using at and you will see that the glass block is placed not only at your position, but also in the same dimension you are in.

Related Solutions

Minecraft – How to tell if two Minecraft entities are in the same body of water

This question is very difficult. Testing if two blocks are somehow connected is already difficult, two entities being in the same body of water is even harder. I have a solution, but it's not a great one. There are probably solutions that work a lot better.

I'd recommend instead looking back the actual problem that you want this solution for; see if there's another way to solve it without testing if two entities are in the same body of water.

This part is to make sure that a search will actually work and won't break your world.

First, we can easily make sure the entities are actually both in water. If either of them is not, then we can skip everything else as they can't both be in the same body of water if one of them isn't even in any water. Put an AND gate with these two commands:

/execute @e[name=Entity1] ~ ~ ~ /testforblock ~ ~ ~ water
/execute @e[name=Entity2] ~ ~ ~ /testforblock ~ ~ ~ water

Next I'd next check that the entities are at least somewhat near eachother. This is kind of a safeguard; they could still be in the same body of water thousands of blocks away, but it's unlikely and you'd crash the game trying to work it out anyway.

/execute @e[name=Entity1] ~ ~ ~ /testfor @e[name=Entity2,r=R] ~ ~ ~

Change R out with however far you want the search to go for. This solution is laggy, so you may want to keep it small.

If that succeeds (the entities are both in water, and aren't ridiculously far away from each-other) then it's time to do the actual search that'll work out if they're in the same body of water.

This part is the actual search.

The following commands make both Entity1 and Entity2 summon marker ArmorStands in every adjacent direction around them in which there is water. The -1 data type means that any type of water (flowing, source, etc.) will work:

/execute @e[name=Entity1] ~ ~ ~ detect ~1 ~ ~ water -1 /summon ArmorStand ~1 ~ ~ {CustomName:"Entity1",Marker:1b,NoGravity:1b}
/execute @e[name=Entity1] ~ ~ ~ detect ~-1 ~ ~ water -1 /summon ArmorStand ~-1 ~ ~ {CustomName:"Entity1",Marker:1b,NoGravity:1b}
/execute @e[name=Entity1] ~ ~ ~ detect ~ ~1 ~ water -1 /summon ArmorStand ~ ~1 ~ {CustomName:"Entity1",Marker:1b,NoGravity:1b}
/execute @e[name=Entity1] ~ ~ ~ detect ~ ~-1 ~ water -1 /summon ArmorStand ~ ~-1 ~ {CustomName:"Entity1",Marker:1b,NoGravity:1b}
/execute @e[name=Entity1] ~ ~ ~ detect ~ ~ ~1 water -1 /summon ArmorStand ~ ~ ~1 {CustomName:"Entity1",Marker:1b,NoGravity:1b}
/execute @e[name=Entity1] ~ ~ ~ detect ~ ~ ~-1 water -1 /summon ArmorStand ~ ~ ~-1 {CustomName:"Entity1",Marker:1b,NoGravity:1b}

/execute @e[name=Entity2] ~ ~ ~ detect ~1 ~ ~ water -1 /summon ArmorStand ~1 ~ ~ {CustomName:"Entity2",Marker:1b,NoGravity:1b}
/execute @e[name=Entity2] ~ ~ ~ detect ~-1 ~ ~ water -1 /summon ArmorStand ~-1 ~ ~ {CustomName:"Entity2",Marker:1b,NoGravity:1b}
/execute @e[name=Entity2] ~ ~ ~ detect ~ ~1 ~ water -1 /summon ArmorStand ~ ~1 ~ {CustomName:"Entity2",Marker:1b,NoGravity:1b}
/execute @e[name=Entity2] ~ ~ ~ detect ~ ~-1 ~ water -1 /summon ArmorStand ~ ~-1 ~ {CustomName:"Entity2",Marker:1b,NoGravity:1b}
/execute @e[name=Entity2] ~ ~ ~ detect ~ ~ ~1 water -1 /summon ArmorStand ~ ~ ~1 {CustomName:"Entity2",Marker:1b,NoGravity:1b}
/execute @e[name=Entity2] ~ ~ ~ detect ~ ~ ~-1 water -1 /summon ArmorStand ~ ~ ~-1 {CustomName:"Entity2",Marker:1b,NoGravity:1b}

Note that all of the new ArmorStands being summoned have the name of their summoner. This means that in the next iteration of the search, each of these ArmorStands will also summon more ArmorStands around them in directions that there is water, and so on. The entity that they come from will also be remembered by their name.

Follow all of that up with:

/execute @e[name=Entity1] ~ ~ ~ /setblock ~ ~ ~ red_sandstone
/execute @e[name=Entity2] ~ ~ ~ /setblock ~ ~ ~ red_sandstone

Any solid block will do fine. This is to mark the water blocks as already having a marker ArmorStand on them, so that the future water detects will not spawn another one on that tile.

Repeat all of this search on a clock that terminates when the search succeeds, or the search has gone on for a certain number (I'd recommend R) of iterations (or it'll keep on going forever if they aren't in the same body of water). This search should look like this for each entity:

The search of 1 entity

To test if the search has succeeded, all you need to do is:

/execute @e[name=Entity1] ~ ~ ~ /testfor @e[r=1,Entity2]

Which will make each Entity1 ArmorStand look for adjacent Entity2 ArmorStands, at which point the two entities have been connected by an adjacent route.

To cleanup the all the red_sandstone and marker ArmorStands you just created for this search, all you need to do is:

/execute @e[name=Entity1] ~ ~ ~ /setblock ~ ~ ~ water
/execute @e[name=Entity2] ~ ~ ~ /setbock ~ ~ ~ water
/kill @e[name=Entity1, type=ArmorStand]
/kill @e[name=Entity2, type=ArmorStand]

And that's it done. This is very messy, but works well from what I've tried. It can detect if entities are connected even through mazes of water.

Minecraft – Execute at a certain amount of entities in 1.9

The c parameter is only maximum count and there in no minimum variant.

You will have to use multiple command blocks to count the number of targets and run commands if that number is reached. Since you're looking for an exact number, no more or less, you can rely on the SuccessCount tag of the command block.

Get the number of required entities as the SuccessCount value. Since you want only 2, the number of times the command will be processed has been limited to 3 to reduce server lag. This way the SuccessCount value will either be 0-1 for 0-1 entities, 2 for the desired amount, or 3 for 3+ entities.
```
/testfor @e[score_isB_min=1,score_isB=1,c=3]
```
Check the SuccessCount value of the repeating command block. Change the coordinates as needed. If the value is 2, this /testforblock command will be successful.
```
/testforblock ~1 ~ ~ minecraft:repeating_command_block -1 {SuccessCount:2}
```
Conditional. If the /testforblock command was successful, this would be the command to run as a result, which would be your /execute command.
```
/execute @e[name=Marker2] ~ ~ ~ /execute @e[score_isB_min=1,score_isB=1] ~ ~ ~ /execute @e[score_isP_min=1] ~ ~ ~ /say hi
```

Best Answer

Related Solutions

Minecraft – How to tell if two Minecraft entities are in the same body of water

Minecraft – Execute at a certain amount of entities in 1.9

Related Topic