Nested /execute
"detect" is not a command, but rather a literal argument of the /execute
command (just like "entity" is a literal argument in /stats entity ...
). Syntax:
/execute <target> X Y Z detect x y z <block> <metadata> <command>
If you want to have nested "detect" functions, you need to use nested /execute
commands, while using sender bias via c=1
to always ensure the executor is re-targeted, and while attempting to reduce server strain caused by expensive distance-sorting alongside a straight @e
by using r=0
(though will present issues for armor stands due to MC-88533). Do not use r=0
if your base selector is @a
(explained in the next section below):
/execute @e ~ ~ ~ detect ~ ~-2 ~ purpur_stairs 0 /execute @e[c=1,r=0] ~ ~ ~ detect ~ ~-9 ~0.4 red_sandstone_stairs 3 tp @e[c=1,r=0] ~ ~ ~-0.4
However, be aware that this is a potential cause for performance loss server-side, as all selectors must be re-evaluated upon every activation, running through expensive operations each time. Using a straight @e
selector will severely decrease performance when used excessively in this manner. You should reduce targets as much as possible first via proper parameters such as type
.
CommandStats & /testforblocks
While performance may not present as much of an issue for locating smaller structures, deeper /execute
nesting will start slowing the server down. You can instead use CommandStats to detect a specific structure around the entity using /testforblocks
. The downside of this is that there must be a pre-built structure in loaded chunks (primarily the spawn chunks) in order to compare to.
CommandStats are a set of triggers that will modify a score depending on the type of command an executor is running, with the score being relevant to that command. Since CommandStats can be applied to entities, that makes it multi-target friendly without having to deal with a large chain of nested /execute
commands.
Prerequisites
First, the objective to hold the return value from CommandStats.
/scoreboard objectives add NearStructure dummy
Next, the CommandStat trigger to apply to targets. In this case, the "AffectedBlocks" trigger will set the executor's score equal to the number of blocks found or modified by a command (and any commands not modifying blocks will result in no change). If new targets can newly exist at any time, this may need to run on a clock.
The initial "target" is who to apply the trigger to, while the "internal target" is not processed and is stored literally as written on the target, to be temporarily processed with each relevant command execution. In this case, all players will set their own "NearStructure" scores.
@a
is the only selector that can target dead players, but only if parameters r/dy/dx/dz
are not specified. Using r=0
is not advised because it throws out any dead players, which can severely skew scores when dead players continue executing commands but are changing the wrong scores.
/stats entity <target> set <trigger> <internal target> <objective>
/stats entity @a set AffectedBlocks @a[c=1] NearStructure
In order for CommandStats to modify a target's score, that target must be tracked on the scoreboard prior. This may also need to run on a clock.
/scoreboard players add @a NearStructure 0
And finally, you will need to build a structure in the spawn chunks that you would want to detect.
Detection
The following must be run in numerical order on a clock.
Causing players to test for a structure around them. Modify the coordinates as needed so that it points to the pre-built structure as well as the relevant location around the player.
/execute @a ~ ~ ~ /testforblocks x1 y1 z1 x2 y2 z2 X Y Z
When each player runs the /testforblocks
command, they trigger their "AffectedBlocks" CommandStat, which will set the player's "NearStructure" score equal to the number of blocks matched with /testforblocks
. It will be 0 for failure, or the total number of blocks in the structure upon success. You can detect a minimum score of 1 to target those players:
/tp @a[score_NearStructure_min=1] ~ ~ ~-0.4
But for smaller structures, it would be much less complicated to simply use nested /execute
commands.
Since a redstone timer method is allowed, here's my solution.
More information:
- The lever is the input. Replace it with your diamond block detector.
- The redstone lamp is the output. Replace it with your command block.
- All the repeaters are set to 4 ticks, apart from the one closest to the redstone lamp, which is set to 1 tick. This is required for the correct duration of 1.5 seconds.
- The piston is sticky.
- You can put any (moveable) block on top of it, it does not have to be stone.
- The screenshot is from Minecraft 1.11.2 PC/Linux (vanilla), although Pocket Edition should work exactly the same for this task.
It's probably possible to get the redstone much more compact than this, but I'm not too good at that.
EDIT: Spent about an hour compacting and writing instructions to re-create this 2x4x10 design:
It's 2 blocks wide, but you'll need to leave a space in between if you want to tile these. I'm not going to keep trying for a tileable version with no gap, but I'm sure it's possible.
Best Answer
Create two scoreboard objectives like following:
And:
Then on a fill clock run:
How this works is that it effects all players with a fall distance statistic score of the minimum 1 which also has a damage taken statistic score of the minimum 1. After that it resets the scores so that it can happen again.