Only execute chain block commands if the first one in the sequence succeeds

๐ŸŽ™๏ธ tryashtar ยท 1 points ยท Posted at 04:19:46 on November 12, 2015 ยท (Permalink)

Here we have a sequence of command blocks:

http://i.imgur.com/LTxsKdt.png[1]

They are running every tick just dandy. However, one of them (as indicated by the red glowing effect) is conditional.

Obviously, it will only run if the command behind it was successful.

However, I want to make it the "break point", if you will. If it fails, the line stops there and no further blocks are activated. If it succeeds, the line continues just like normal.

At first, it might seem like I could just make every block in the sequence after that red block conditional. That doesn't work for two reasons:

  1. It would turn the entire thing into a straight line instead of a compact square.

  2. If any of those commands FAIL, the entire thing will stop instead of continuing like normal.

How can I turn that conditional block into a "success = continue, failure = stop" type thing? I can insert blocks before or after it however you like.

Thanks!

[1]

wiresegal ยท 3 points ยท Posted at 06:19:59 on November 12, 2015 ยท (Permalink)

a REPEAT COND command block will act like a chain that powers a line, but only if your input frequency is 20 Hz.

brianmcn ยท 1 points ยท Posted at 13:21:29 on November 12, 2015 ยท (Permalink)

More generally, the purple and red blocks from his original could both be orange blocks (the formerly red one being conditional), and have the starting input be

blockdata former-purple-coords {auto:1b}
blockdata former-purple-coords {auto:0b}
blockdata former-red-coords {auto:1b}
blockdata former-red-coords {auto:0b}

In other words, break up the chain into two chains that both get scheduled one after the other for the same tick.

wiresegal ยท 1 points ยท Posted at 17:32:04 on November 12, 2015 ยท (Permalink)

Yes, but most people aren't as skilled in black magic as you, Dr. Lorgon. :P

๐ŸŽ™๏ธ tryashtar ยท 1 points ยท Posted at 02:58:50 on November 13, 2015 ยท (Permalink)

I tried this out, hoping I understood it correctly. Here's what I produced (the command chain is pointing in the +Z direction):

http://i.imgur.com/0QKdtQE.png

  1. <empty>

  2. blockdata ~ ~ ~-1 {auto:1b}

  3. blockdata ~ ~ ~-2 {auto:0b}

  4. blockdata ~ ~ ~3 {auto:1b}

  5. blockdata ~ ~ ~2 {auto:0b}

  6. testfor @p {OnGround:1b}

  7. say ON THE

  8. say GROUND

The result is that powering the first command block will print "ON THE GROUND" if I'm on the ground, but if I leave the ground and power it again, it will still print "ON THE GROUND."

If I power it another time while in the air, it will do nothing (as expected). It will continue to do nothing when powered until I touch the ground, at which point it will do nothing when powered the first time, but print "ON THE GROUND" on the second and subsequent times.

Basically, it "ignores" the check the first time it changes value.

Is there something I did wrong? Thanks for your help!

brianmcn ยท 1 points ยท Posted at 03:06:24 on November 13, 2015 ยท (Permalink)

The 2-5 bits are not 'part of the mechanism', they are how you invoke it.

So copy 1-5 somewhere else, in the copy change 2-3 to point to 'original 1', change 4-5 to point to 'original 7', and then in the original, change 2-5 to 'say yadda', and then power the copy block #1 to invoke the thing.

๐ŸŽ™๏ธ tryashtar ยท 1 points ยท Posted at 03:23:14 on November 13, 2015 ยท (Permalink)

I see.

http://i.imgur.com/J9WS6nW.png

I attempted this. The chain on the left is the original chain. The yellow-glowing and red-glowing blocks contain no commands.

The last three blocks on the left side contain the condition and two say commands in that order.

The chain on the right is the "activating chain". Again, the first block is blank. The second and third blocks are pointing to the yellow-glowing block, and the third and fourth are pointing to the blue-glowing block.

After making these changes, I see no difference in functionality when I power the chain on the right. Very strange behavior!

brianmcn ยท 1 points ยท Posted at 03:30:11 on November 13, 2015 ยท (Permalink)

(Let me try to replicate it)

brianmcn ยท 1 points ยท Posted at 03:34:38 on November 13, 2015 ยท (Permalink)

Ok, wow, conditional oranges also use conditionMet to 'react' one execution later. I have hardly ever tried using them. Ok, let me think about this for a sec :)

brianmcn ยท 1 points ยท Posted at 03:47:46 on November 13, 2015 ยท (Permalink)

Yeah, ok, I don't think there's any way to do this without block updates.

The techniques I usually use are either to

  • have the conditional suffix run one tick later, where the prefix ends with two conditional blockdata-the-next-orange commands, or

  • retest the success condition (or store it in the scoreboard and read the scoreboard) over and over again (to address #2 of OP), and use conditional blocks throughout the suffix (except for the repeat-tests which are unconditional)

I really need to make the final video of my command block tutorial which explains deeply the exact mechanism of how the blocks run/schedule, as I'm forgetting now myself.

๐ŸŽ™๏ธ tryashtar ยท 1 points ยท Posted at 05:38:00 on November 13, 2015 ยท (Permalink)

Heh, you really should! I normally dislike command block tutorials because the explainer always seems to either overcomplicate things or explain stuff on a really high level, but I've really liked what I've seen of yours! It's well-paced and sticks with the simple things until the complex stuff becomes really relevant, and yet you don't leave anything out! Truly great work!

To be honest, block scheduling is probably the area of commands I'm weakest in, so I wound definitely benefit from a nice explanation :)

๐ŸŽ™๏ธ tryashtar ยท 1 points ยท Posted at 17:29:45 on November 12, 2015 ยท (Permalink)

That's really it? Sweet, thanks!

๐ŸŽ™๏ธ tryashtar ยท 1 points ยท Posted at 01:49:58 on November 13, 2015 ยท (Permalink)

It works almost perfectly, but see this image:

http://i.imgur.com/lVJ5qK9.png

The commands, in order:

  1. scoreboard players add track tick 1

  2. scoreboard players test track tick 50

  3. scoreboard players set track tick 0

  4. say a

  5. say b

In theory, it should print "a" and "b" every 50 ticks, but instead it prints them both twice every 50 ticks.

Any help there?

wiresegal ยท 1 points ยท Posted at 02:27:07 on November 13, 2015 ยท (Permalink)

I have no idea, it's worked for me before... :/

brianmcn ยท 1 points ยท Posted at 03:12:06 on November 13, 2015 ยท (Permalink)

Conditional purples run their commands one tick after the condition is met (hence conditionMet). As a result, it is very hard not to run things 'at least twice' with them at 20Hz, if they are going to be 'resetting the condition'. Also, in a system with two purples, the order in which the two of them are initially powered can matter, which is confusing.

๐ŸŽ™๏ธ tryashtar ยท 1 points ยท Posted at 03:35:02 on November 13, 2015 ยท (Permalink)

Aha! Thank you for letting me know what went wrong, I totally have it solved now!

http://i.imgur.com/AamQxad.png

  1. scoreboard players add track tick 1

  2. scoreboard players test track tick 50

  3. scoreboard players set track tick 0

  4. say once every fifty ticks!

Thanks so much, both of you guys! I really appreciate it!

brianmcn ยท 1 points ยท Posted at 03:49:56 on November 13, 2015 ยท (Permalink)

Yes, but beware that the suffix is running 'one tick behind', e.g. it will be seeing tick=1 and not tick=0.

JAZEYEN ยท 1 points ยท Posted at 16:11:40 on November 16, 2015 ยท (Permalink)

Just set it from unconventional to conventional, it will then work just like a comparator without the need for one.

Cubic_Lies ยท 1 points ยท Posted at 08:58:52 on November 28, 2015 ยท (Permalink)

I use a standard command block for this...you basically introduce a branch on condition, it's not really part of the chain anymore.

So the chain block does its test, then you have a conditional chain block which does a blockdata command to set the command block's auto to 1. The command block sets its own auto back to 0, then you have a chain of blocks from the standard command block, and your original chain. Then you possibly will want to have a second test for the success/failure of the original test, so you have one branch which executes on success, one which executes on failure.

These chains extend in the +x direction in this example:
chain block:
  testfor @p[r=10]
chain block conditional on above:
  blockdata <x> <y> <z> {auto:1}
chain block:
  testforblock ~-2 ~ ~ chain_command_block -1 {SuccessCount:0}
chain block conditional on above:
  say Test not true!

Chain for true condition (at the x y z referenced above):
command block:
  blockdata ~ ~ ~ {auto:0}
chain command block:
  say Test was true!