For situations like this, I'd recommend running the command being executed itself (the /fill command) to see what the error is.
The main error appears to be that you're trying to fill a quarter of a million blocks, which is more the maximum (32678) that Minecraft allows for. You could reduce your fill region:
/fill ~-15 ~-15 ~-15 ~15 ~15 ~15 minecraft:diamond_block 0 replace minecraft:gold_block
Or, if the huge area is important, split it up into multiple commands:
/fill ~0 ~0 ~0 ~30 ~30 ~30 minecraft:diamond_block 0 replace minecraft:gold_block
/fill ~0 ~0 ~0 ~-30 ~30 ~30 minecraft:diamond_block 0 replace minecraft:gold_block
etc.
(I'd suggest not running either of these on a clock)
That should be it, but keep in mind that the command will also fail if there are no gold blocks to replace, or if you're too low-down/high-up so that the relative coordinate are selecting an area outside of the world.
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.
Best Answer
You have to use a combination of relative rotational coordinates and a scoreboard objective. The latter is to ensure that players are only rotated once per stepping above a coal block.
Fancy single objective solution
Set up your objective as:
On a 20Hz. clock, run the following commands to set the score:
This might look confusing at first, what with adding 3 and subtracting 2, but it does the trick. Basically, every tick the player is above a coal block, his score is incremented by +3-2=+1, but only to a maximum of 2 (3rd command). The moment the player steps off, the score decreases by 2 (thereby avoiding the value of 1), to a minimum of 0 (4th command).
This means that after these 4 commands are run, the score is:
All that is left is to put a command to rotate the players with a score of exactly 1:
where
<R>is the amount of degrees you want to rotate the player.Simpler 2 objective solution
If the above solution was too confusing for your taste, a more intuitive way is to use 2 objectives:
On a 20Hz. clock, run the following commands to set the score:
This achieves basically the same as above, but for
overCoalTimeinstead.