MC-122216/execute if blocks only returning 1/0 for "result"
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.
Created Issue:
returns wrong values when i am using /execute if <..> on their own
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 commands "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.
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.
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
returns wrong values when i am using /execute if <..> on their own/execute if blocks only returning 1/0 for "result"
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
[Mojang] Nathan Adams![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
image-2018-07-18-12-54-17-399.png
And that is covered in MC-122216 
Updated the summary, as this works fine for execute if entity (giving the number found via result). Also confirmed!
I can confirm 'success' always returns 1, unless part of the block detection cuboid goes outside loaded chunks.
Ooccurs in 18w15a
Affects 18w22c
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`
I mean `/testforblock*s*`. And code has not changed for 4 years - if there was `commands.compare.failed` message ("Source and destination are not identical"), then result was not updated.