Sprunkles

Still in effect as of 1.21.50. max_distance being an integer still silently fails.

Yes, still an issue as of 1.21.60.21. Behavior remains the same; y-axis (green channel) is flipped. New attached image shows cobblestone (left, 2x2) with affected rendering, and end stone (right, 2x2) with expected rendering.

Also comes into effect when transitioning from any menu (vis. Settings, Marketplace, Dressing Room, Profile, Member permissions, profile screen) to the pause screen.

As of preview 1.20.50.22, the x-axis appears to be correct, but the y-axis rendering is still flipped. Attached is the new behavior.

This appears to have been fixed by now, perhaps since the rotation arguments were reintroduced (preview 1.19.70.23?).

The developers are likely already aware, but just for the record: This was supposedly marked as fixed in Preview 1.19.60.25 according to the changelog, but the bug can still be reproduced.

I can reproduce in 1.19.50. It seems to occur when I schedule a function from tick.json too? If I don't select any entities before calling /schedule. At least, that is what it appears to be ...

I like to think this is an unintended side effect to an intentional change. This is the consequences of the backwards compatibility system implemented for command blocks.

When the new /execute syntax was being developed under experimental, the command blocks were versioned for 1.19.10 (probably in that 21-24 version range) such that old command blocks would continue to use the old syntax, while new or updated command blocks would use the new syntax. Similarly, when the new /execute syntax released into stable, the command blocks were versioned yet again for 1.19.50 (version 25); this once again marked those command blocks as "old" and they began to use the old syntax again.

/execute as does not apply any changes to the rotation context of the command. You must use /execute at or /execute rotated as to supply a change to the rotation. These are both valid implementations, although I recommend the former.

/execute as @a at @s run setblock ^ ^1 ^3 light_block 9 keep

/execute as @a positioned as @s rotated as @s run setblock ^ ^1 ^3 light_block 9 keep

The minimum engine version for the new syntax has been updated to 1.19.50. Please make sure that your behavior pack's minimum engine version is up to date: "min_engine_version": [1, 19, 50]

The reason for this is the 'rightitem' bone responsible for binding attachables is a child of the 'rightarm' bone. Changing the position of the arm changes the position of the item in this manner.

I can reproduce in preview 1.19.50.20. Just about any /execute command argument followed by "entity" will induce a crash. What an odd bug ...

Affects version 1.19.31, as well as preview 1.19.50.20. The bug also affects the engine behind the new /execute syntax too.

Adding these tags as a comment to keep the body of the report clean.

fast faster quick quickly quicker spam spamming click clicking left hold holding button mouse single

Affects release 1.19.31

As of preview 1.19.40.21 the /execute align command exists. For those who look up to this bug as intended behavior, /execute align fulfills this role and should be used in practice instead.

@Ch39 You may experience a few differences in the command engine as the minimum engine version increases. The notable one here is that the new /execute syntax is enabled for functions by setting it to 1.19.10 or greater, replacing the old syntax in the process. You will not be able to use the old syntax upon upgrading, but you can always set the min engine version to an older version (like the 1.16.0 you have it at now).

This seems related to MCPE-161257, as both commands behave similarly. It could be a duplicate for that very reason however, as a different means to the same end.

Note that the new /execute command syntax is behind the Upcoming Creator Features experimental toggle, so you will need to enable that too to see results.

It is also worth noting that, in this case, @s has nobody to target; the block cannot execute as itself because it is not an entity.

Using the new /execute command syntax in behavior packs is dependent on two factors:

• Having the Upcoming Creator Features experiment enabled (which you have done here)

• Setting the pack's *minimum engine version* to 1.19.10 or greater.

{
  "format_version": 2,
  "header": {
    // ...
    "min_engine_version": [1, 19, 30]
}

Are both of these true?