MC-123362SuccessCount of command blocks use the "result" return value of a command instead of "success"
The bug
In 1.12, when a command block runs a command, its SuccessCount will (typically) be dependent on the number of targets affected, otherwise a simple 1 for success and 0 for failure.
Now in 1.13, SuccessCount will be the "result" return value rather than a simple 1 or 0 of "success". I'm assuming that a separate return value based on the number of affected targets is not feasible, but result behaves much differently than the old SuccessCount equivalent.
This has some obscure consequences depending on the command being run, particularly when it comes to the "conditional" setting of a command block, which relies on the previous command's SuccessCount being 1+. Such conditional command blocks will fail to run if the command block behind them succeeded, but had a "result" return value of 0.
Reproduction
/scoreboard players set will provide a "result" value of playerCount * score. If score was 0, the return value for "result" will be 0. At the same time, the return value of "success" will be 1 since the command did succeed. But a conditional command block will fail due to the use of "result".
Some example commands to put into an unconditional command block that prevents a conditional command block from running, despite being successful:
At all times (standard score reset):
/scoreboard players set @a[scores={OBJ=1..}] OBJ 0
At all times:
/weather clear 0
Only if it's day 0:
/time query day
Only if it's Peaceful difficulty:
/difficulty
Only if the player is in the Overworld:
/execute as @p[distance=..3] store result score @s OBJ run data get entity @s Dimension
Linked Issues
is duplicated by3
![[Mod] Skylinerw](../../../data/assets/gravatar/skylinerw.png){kind=small}
![[Mojang] Bartosz Bok](../../../data/avatars/users/10122.svg){kind=small}
Created Issue:
SuccessCount of command blocks use the "result" return value of a command instead of "success"
The bug
In 1.12, when a command block runs a command, its SuccessCount will (typically) be dependent on the number of targets affected, otherwise a simple 1 for success and 0 for failure.
Now in 1.13, SuccessCount will be the "result" return value rather than a simple 1 or 0 of "success". I'm assuming that a separate return value based on the number of affected targets is not feasible, but result behaves much differently than the old SuccessCount equivalent.
This has some obscure consequences depending on the command being run, particularly when it comes to the "conditional" setting of a command block, which relies on the previous command's SuccessCount being 1+. Such conditional command blocks will fail to run if the command block behind them succeeded, but had a "result" return value of 0.
Reproduction
/scoreboard players set will provide a "result" value of playerCount * score. If score was 0, the return value for "result" will be 0. At the same time, the return value of "success" will be 1 since the command did succeed. But a conditional command block will fail due to the use of "result".
Some example commands to put into an unconditional command block that prevents a conditional command block from running, despite being successful:
At all times (standard score reset):
/scoreboard players set @a[scores={OBJ=1..}] OBJ 0Only if it's day 0:
/time query dayOnly if it's Peaceful difficulty:
/difficultyOnly if the player is in the Overworld:
/execute as @a[distance=..3] store result score @s OBJ run data get entity @s DimensionAt all times:
/weather clear 0
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
is duplicated by
is duplicated by
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
[Mojang] Nathan Adamsis duplicated by
The bug
In 1.12, when a command block runs a command, its SuccessCount will (typically) be dependent on the number of targets affected, otherwise a simple 1 for success and 0 for failure.
Now in 1.13, SuccessCount will be the "result" return value rather than a simple 1 or 0 of "success". I'm assuming that a separate return value based on the number of affected targets is not feasible, but result behaves much differently than the old SuccessCount equivalent.
This has some obscure consequences depending on the command being run, particularly when it comes to the "conditional" setting of a command block, which relies on the previous command's SuccessCount being 1+. Such conditional command blocks will fail to run if the command block behind them succeeded, but had a "result" return value of 0.
Reproduction
/scoreboard players set will provide a "result" value of playerCount * score. If score was 0, the return value for "result" will be 0. At the same time, the return value of "success" will be 1 since the command did succeed. But a conditional command block will fail due to the use of "result".
Some example commands to put into an unconditional command block that prevents a conditional command block from running, despite being successful:
At all times (standard score reset):
/scoreboard players set @a[scores={OBJ=1..}] OBJ 0
Only if it's day 0:/time query dayOnly if it's
Peaceful difficulty:/difficultyOnly if
the player is in the Overworld:/execute as @a[distance=..3] store result score @s OBJ run data get entity @s DimensionAt all times:
/weather clear 0The bug
In 1.12, when a command block runs a command, its SuccessCount will (typically) be dependent on the number of targets affected, otherwise a simple 1 for success and 0 for failure.
Now in 1.13, SuccessCount will be the "result" return value rather than a simple 1 or 0 of "success". I'm assuming that a separate return value based on the number of affected targets is not feasible, but result behaves much differently than the old SuccessCount equivalent.
This has some obscure consequences depending on the command being run, particularly when it comes to the "conditional" setting of a command block, which relies on the previous command's SuccessCount being 1+. Such conditional command blocks will fail to run if the command block behind them succeeded, but had a "result" return value of 0.
Reproduction
/scoreboard players set will provide a "result" value of playerCount * score. If score was 0, the return value for "result" will be 0. At the same time, the return value of "success" will be 1 since the command did succeed. But a conditional command block will fail due to the use of "result".
Some example commands to put into an unconditional command block that prevents a conditional command block from running, despite being successful:
At all times (standard score reset):
/scoreboard players set @a[scores={OBJ=1..}] OBJ 0At all times:
/weather clear 0Only if it's day 0:
/time query dayOnly if it's Peaceful difficulty:
/difficultyOnly if the player is in the Overworld:
/data get entity @s Dimension
The bug
In 1.12, when a command block runs a command, its SuccessCount will (typically) be dependent on the number of targets affected, otherwise a simple 1 for success and 0 for failure.
Now in 1.13, SuccessCount will be the "result" return value rather than a simple 1 or 0 of "success". I'm assuming that a separate return value based on the number of affected targets is not feasible, but result behaves much differently than the old SuccessCount equivalent.
This has some obscure consequences depending on the command being run, particularly when it comes to the "conditional" setting of a command block, which relies on the previous command's SuccessCount being 1+. Such conditional command blocks will fail to run if the command block behind them succeeded, but had a "result" return value of 0.
Reproduction
/scoreboard players set will provide a "result" value of playerCount * score. If score was 0, the return value for "result" will be 0. At the same time, the return value of "success" will be 1 since the command did succeed. But a conditional command block will fail due to the use of "result".
Some example commands to put into an unconditional command block that prevents a conditional command block from running, despite being successful:
At all times (standard score reset):
/scoreboard players set @a[scores={OBJ=1..}] OBJ 0At all times:
/weather clear 0Only if it's day 0:
/time query dayOnly if it's Peaceful difficulty:
/difficultyOnly if the player is in the Overworld:
/execute as @p[distance=..3] store result score @s OBJ run data get entity @s Dimension
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
relates to
in pre-release 6 I am still experiencing this bug.
This is in its purest form a duplicate of MC-123362, however the interesting issue is that /scoreboard objectives setdisplay always returns 0 for result regardless of success.
So if my understanding is correct, the issue is that conditional command blocks are still checking for the outdated SuccessCount value, now "result", rather than checking for the new success value. It sounds like just a simple oversight on the dev's part. I would assume this should be a pretty easy fix once it gets attention.
Is it possible to get something with a success of 0 but a result that isn't 0? I'm guessing this isn't possible but it would determine whether or not the success value is actually read by conditional command blocks, which it likely isn't(given the case of success=1,result=0 not triggering the conditional command block).
FV: these are run in a command block directly; cannot use @s for the root selector.
Oh, right, whoops.