In the changelog of 17w45b, it said that "Made /execute if <..> return values if used on their own".
I found that the result of the "if blocks" is 1(when source and destination regions match) or 0 (when they do not match).
But this command's "precursor" , /testforblocks , returns the number of matching blocks, not only 0 or 1.
if i want to get 0 or 1, i should use "success" mode. (this mode do not work as intended as well)
-------------------------------------
by the way,"if block" could not use on their own.
Comments 10
I can confirm 'success' always returns 1, unless part of the block detection cuboid goes outside loaded chunks.
This does happen in 1.13 prerelease 1. It would be so useful to have, too. You could then spare a masked clone command.
This bug has not been fixed yet.
If the blocks in the range match, the number of matches is returned, but if they do not match, 0 is returned.
It seems that code modification is incomplete.
This is port of `/testforblock` behavior - in 1.12 AFFECTED_BLOCKS stat was also set only on success.
It would also require some deeper changes to implement "failure with result" case.
Oh I'm sorry, I seem to had misunderstood the specification.
However, I think that it is more convenient to have specifications that can acquire the number of matches.
Why is it port of `/testforblock`, when must be `/testforblocks`? (or you just lost the letter)
Because `failure with result` was normal behavior for `/testforblocks`
Updated the summary, as this works fine for
execute if entity(giving the number found viaresult). Also confirmed! 🙂