Brian McNamara

Might also be related to MC-124686

This is WAI

Here is a repro without teleport:

/scoreboard objectives add TEMP dummy
/scoreboard objectives setdisplay sidebar TEMP
/scoreboard players set @p TEMP 1
/execute at @e[limit=2] as @p at @s[scores={TEMP=1}] run scoreboard players add @s TEMP 1

EXPECTED: final score of 2

ACTUAL: final score of 3

This demonstrates that the second 'at' is evaluating @s only once at the start, rather than in each iteration of the outer limit=2 loop.

This is all WAI.

OP's expectation is wrong, tildes never care about anchoring.

once upon a time, I recall that doing entitydata on a ThrownPotion to change the potion details would cause the potion item in my inventory to also change, which sounds like a similar thing (have not tried to repro now)

It seems to be that is makes the most sense for the game to load everything at once (to avoid blocking on disk I/O during gameplay at a later point in time), but I acknowledge that there are possible space-versus-time trade-offs here.

As per my comment on MC-124491, I think it's fine if this is WAI or WontFix (for efficiency reasons), but it would be good to get an 'official ruling'.

I cannot reproduce this in 1.13,

/execute as @e[type=pig,sort=nearest,limit=1] at @s run tp @p ~ ~ ~ ~ ~

give me the pig's location and facing direction properly.

This error is 'fatal' to command logic and should be treated specially; silently continuing from a broken program state with no hope of debuggability is a poor choice. This is a foolish "consistency".

As per my comment on MC-96926, I think it makes most sense for trigger to autocomplete all objectives of type trigger, regardless of their current 'enabled' state.

This is trivial to reproduce:

Give yourself a lava bucket. As you spin around (move mouse) standing on a flat plain, repeatedly try to put down and pick up the lava in the bucket. About 1 in 10 times, the client and server desync (e.g. I see the lava on the ground, and also in my bucket, until I use the bucket again or move it in my inventory; or I see no lava on the ground and my inventory displays the bucket as empty, but I actually still have lava and can place it).

(I just reproduced in in 18w02a)

From a 'user scenario' point of view, I don't think there is a compelling scenario to write two `store`s in a single line of code. So either WontFix or "add a check to make multiple `store`s be a syntax error" are both valid resolutions, in my opinion.

After poking through the decompiled code, I think the problem is that various 'scoreholder contexts' for entity selectors are throwing exceptions, rather than simply returning empy collections and failure results. Exceptions should not be used for 'expected failures' such as 'selector that targets no entities', as it breaks the overall control flow through an execute subcommand loop. It might be non-trivial to find all such exception-sources in the source code via inspection, however an appropriate exception handler at the 'root' of commands (e.g. whatever existing handler is printing out the red "No entity was found" message in chat) that logs the stack traces of these caught-exceptions could be used to help find all the call stacks which throw exceptions inappropriately, so they may be fixed over time.

Here are the repro steps for the 'score' version of the bug:

/summon armor_stand ~ ~ ~ {NoGravity:1b,Marker:1b,Tags:[A],CustomName:"\"A1\""}
/execute at @e[tag=A] run summon armor_stand ~ ~ ~1 {NoGravity:1b,Marker:1b,Tags:[A],CustomName:"\"A2\""}
/scoreboard objectives add X dummy
/scoreboard objectives setdisplay sidebar X
/scoreboard players set @e[tag=A] X 1
/execute as @e[tag=A] at @s positioned ~ ~ ~1 run say @e[distance=..0.1]
/execute as @e[tag=A] at @s positioned ~ ~ ~1 if entity @e[tag=A,distance=..0.1,limit=1] run say hi
/execute as @e[tag=A] at @s positioned ~ ~ ~1 if score @e[tag=A,distance=..0.1,limit=1] X = @s X run say hi

The third to last line is just to ensure the setup is correct, expected (and actual) output is

[A1] A2
[A2]

The second to last line is to demonstrate that 'execute..as..at..if entity' works with a particular selector, it correctly outputs "[A1] hi".

The final line fails "No entity found". It should succeed exactly as the previous line does, since the scores match (all are 1).

WAI; this is floating-point. If you want to perform a 'round upwards', you can do it yourself; one way is by changing 10000 to 20000, adding 1, and dividing by 2 the result.

Here are repro steps:

/summon minecraft:pig ~ ~ ~ {NoAI:1b,Tags:["foo","A"]}
/summon minecraft:pig ~ ~ ~ {NoAI:1b,Tags:["foo","B"]}
/scoreboard objectives add X dummy
/scoreboard objectives setdisplay sidebar X
/scoreboard players set @e[tag=foo] X 42
/execute as @e[tag=foo] at @s store result score @s[tag=A] X run say hi
/execute as @e[tag=foo] at @s store result score @s[tag=B] X run say hi
/execute as @e[tag=foo] at @s store result score @s[tag=foo] X run say hi

In the last 3 lines, EXPECT the A and B to update score of each respective pig only, and final foo line to update both. ACTUAL is that A and B lines fail, but final line does update both scores.

I cannot repro this in 18w02a

Still occurs in 18w02a

still present in 18w01a

this still seems broken to me in 18w01a, reopen?