Arqade is a question and answer site for passionate videogamers on all platforms. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a setup like this:

enter image description here

In which the yellow command blocks are a standard 20Hz /fill clock, and the blue is a command such as, for example:

/spreadplayers ~ ~ 10 20 false @p[r=5]

My problem, which has cropped up for me quite a few times, is that I want to get some kind of redstone pulse or output when the blue command block succeeds. The obvious solution is a comparator, but that does not work for this as the command executes once and then fails on the next tick, resetting its successcount before the comparator can detect it.

Ideally this output detection should also be pretty fast, although it doesn't have to work at the same frequency as the fill clock. The solution needs to actually be testing for if the command succeeded.

I have tried some things with /blockdata and /testforblock, but no success as of yet.

Edit: Again, the solution needs to actually test for the block succeeding. It cannot just test for, say, the players location, because the command block will not always do something that can be tested for. Imagine that instead it is a /say, relative /fill, or /clear item command.

share|improve this question
I'm pretty the Comparator will still detect it. You could try using a command block next to the Comparator, that tracks a dummy variable. – Aaron128l Jun 23 '14 at 19:21
A comparator does not detect it, you can try it out with the command I gave. A comparator is too slow to detect a 1 tick success. – colorfusion Jun 23 '14 at 19:22
Use a 10Hz clock instead? That seems to be the obvious solution to me. – MBraedley Jun 27 '14 at 10:30
I cannot slow the command down. The /spreadplayers command was just an example. – colorfusion Jun 27 '14 at 12:40
  • /execute @p[rm=6] ~ ~ ~ /say The command worked
  • /execute @p[r=5] ~ ~ ~ /say The command did not work

(both after the /spreadplayers command). The only problem with that is that it will still act as if the command didn't work if a player gets positioned inside the 5 Blocks radius.

EDIT: It is now completely possible with the CommandStat Data Tag:

/blockdataCommand Block Coordinates{CommandStats:{SuccessCountName:"Fake Player Name / Entity / whatever you're gonna use",SuccessCountObjective:"Scoreboard Objective Name"}}

Basically, you can make the SuccessCount output to a scoreboard. See the video below for more info!


EDIT 2: Maybe I should mention that you can then do some sort of execute on the entity if it has a score of at least 1. Also, you should set the score back to 0 at the end of every tick (/cycle of the clock).

share|improve this answer

Dummy Objective Workaround

  • Make a dummy objective, let's call it isNotSpread
  • Hook a command block to the clock that sets it to 1 for @p[r=5]
  • /testfor players with score_isNotSpread_min=1
  • Comparator that into two command blocks to /spreadplayers players with score_isNotSpread_min=1 and reset their isNotSpread objective to 0.

Since the score is not set to 0 before a comparator detects it at 1, this will detect

I'm not too sure, but I believe most of Sethbling's works use this or a similar method.

share|improve this answer
I still need the /spread command block to work at the same speed, otherwise I would just put it on a slower clock and it'd all be fine. Using this method it would take about 4 times as long to execute the command with an additional pause at the end before it can work again. – colorfusion Jun 24 '14 at 11:32

Use a comparator. Here is a picture of a possible system. System Pic.

The command block on the left is the one that is being tested. If the command succeeds, then the comparator is activated, and thus activates the command block on the right, with a /say or /tell command inside. Make sure that the comparator is facing directly away from the tested command block.

share|improve this answer
"The obvious solution is a comparator, but that does not work for this as the command executes once and then fails on the next tick, resetting its successcount before the comparator can detect it." – Skylinerw Dec 6 '15 at 14:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.