How can I test for two entities, both of which are in the same body of water?

The only way I can think of doing it is having several /testforblock commands, testing for water around the entity, and have another command block testing for other entities within a radius. Then having more command blocks testing for water, and more command blocks having bigger entity testing radius.

So in theory, if the command block finds water, AND an entity, then it will do something, but if it finds land, and an entity, it won't. Will this approach work? Is there a better approach?

  • That approach would probably work. I'd have to brainstorm efficient commands for it though.
    – RetroCraft
    Mar 12, 2015 at 22:49
  • This would be very complicated, but you could theoretically use unused data values. Something like this: 'execute @a ~ ~ ~ detect ~ ~ ~ stationary_water 0 fill ~-10 ~-10 ~-10 ~10 ~10 ~10 stationary_water 1 replace stationary_water 0'. Then, on every other player: 'execute @a ~ ~ ~ detect ~ ~ ~ stationary_water 1 scoreboard players set @p[c=1,r=1] dummyscoreboardobjective 1' Mar 27, 2015 at 14:49

1 Answer 1


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.

  • Sorry it took me forever to get back to you on this. I'm no longer working on the project that required these commands, but as far as I can tell (I haven't tested it myself) this seems to work perfectly fine. Props to you for figuring out this really complicated command block system! I'll be sure to find a use for it in the future.
    – thezi3
    Jan 22, 2016 at 14:51
  • This is very similar to something I'm had already planned to program in Minecraft one day, but my use case would have been to e.g. analyse caves or ores or whatever. I bet you can now do it in 1.13+ with much less lag and without actually changing any blocks. I'll report back here once I'm done. May 9, 2019 at 14:47
  • @FabianRöling Did you ever finish that?
    – pppery
    Jun 14, 2020 at 0:10
  • @pppery Kind of. Here is a concept: gaming.stackexchange.com/a/325284/171580 And here is the main part of it implemented: gaming.stackexchange.com/a/364446/171580 Jul 1, 2020 at 15:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .