First off this is my first question on here, so I am sorry if it isn't the best.
In Minecraft 1.10.2, we can use the commands detect
and execute
. I am using these commands to make mobs move around where I want them. Now the problem is I need to be able to execute a detect, when a mob is standing on a block, then execute another detect to test if it is also on another block, then tp
.
I can detect one block and tp, that is:
/execute @e ~ ~ ~ detect ~ ~-4 ~ red_sandstone_stairs 0 /tp @e[c=1] ~0.1 ~ ~ -90 0
And this is the command I am trying to use. Anyone have any ideas on how to tidy it up? I would just use multiple commands but there will be multiple mobs, so it needs to test them individually and act individually which can only be done through (as far as I am away):
/execute @e ~ ~ ~ detect ~ ~-2 ~ purpur_stairs 0 detect ~ ~-9 ~0.4 red_sandstone_stairs 3 tp @e[c=1] ~ ~ ~-0.4
The error I am getting is:
Failed to execute 'detect ~ ~-9 ~0.4 red_sandstone_stairs 3 tp @e[c=1] ~ ~ ~-0.4' as Bensley69
Because I use @e
it can also detect me, and it is just easier to test on me, if you're wondering why it uses my username.
Any help or work-arounds would be much appreciated.
Best Answer
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:If you want to have nested "detect" functions, you need to use nested
/execute
commands, while using sender bias viac=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 usingr=0
(though will present issues for armor stands due to MC-88533). Do not user=0
if your base selector is@a
(explained in the next section below):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 astype
.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.
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 parametersr/dy/dx/dz
are not specified. Usingr=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.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.
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.
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:But for smaller structures, it would be much less complicated to simply use nested
/execute
commands.