Triton365

Let me put this in a programming perspective. What would be the value of f in the following code?

float f = 8.0;
f = 1.1;

According to the IEEE 754 standard, the value of f must be exactly 1.10000002384185791015625, which is the closest representable number to "1.1". It should never result in 1.099999904632568359375(“1.0999999“) or 1.1000003814697265625(“1.1000004”). This is exactly what I am pointing out as a bug in this report.

Also, this is a simple assignment. The previous value 8.0 should have absolutely no influence on the subsequent assignment. Another key point of this report is that the entity's previous rotation is incorrectly bleeding into the new value during a /rotate command, which should behave as a clean assignment of the target coordinate.

Furthermore, it is important to note that this is a regression first observed in snapshot 25w32a. It worked correctly in previous versions, proving this is an issue with the game's implementation rather than an inherent limitation of the IEEE 754 standard.

Fixed in 25w32a update.

This was discovered while testing the bug MC-277661. That issue appears to have been fixed in 25w32a (although it's not mentioned in the changelog), and this behavior is occurring instead.

Huh… this is too weird to be WAI.

A possible explanation for this issue is that the both the first creation of the execution context and the as subcommand did a shallow copy when copying player’s position, which was affected by the subsequent teleportation, but is this really the official opinion of Mojang? It's very strange that the developers would expect the user to understand this distinction between shallow and deep copies that occur internally in each subcommand.

I was a bit confused after reading that report, but I think I understand the difference between these bugs, so let me clarify.

It seems like MC-270134 is describing that set_count function does not allow overstacked items, and my report (MC-277803) is describing that set_components function does not allow overstacked items. The commands in MC-270134 are actually working fine in current release (1.21.3), so the set_count issue is fixed now, but the same issue is still present in set_components function.

I see that changing the order of the functions fixes this as well, but there are cases where you can't change the order, like this command.

/loot give @s loot {pools:[{rolls:1,entries:[{type:loot_table,value:"blocks/redstone_ore",functions:[{function:set_components,components:{max_stack_size:1}}]}]}]}

So I think this could be considered a valid bug.

You can reproduce it with just the commands in the description, the loot tables are defined inline.

Open a singleplayer world with cheats allowed and run the commands in chat. When you run the latter command, you'll see the set_components function fail to apply (expected to get 2 stacks of 32 snowballs, but instead got 4 stacks of 16 snowballs) and the error in the log.

/rotate command also seems to have this issue. If you run /rotate @s ~30 ~ while riding something, the horizontal rotation is interpolated.

I think this issue should be considered more important than before, especially since the main reason /rotate was added to the game was to rotate while riding.

Does not occur in 1.21.1. It seems it was fixed somewhere between 1.20.4 and 1.21.1

Also here are the commands for recent versions.

/give @s shield[custom_data={Cap:1b}]
/execute if predicate {condition:entity_properties,entity:this,predicate:{equipment:{mainhand:{predicates:{custom_data:{Cap:1b}}}}}}

Changed the command from 400 armor stands to 1000 item displays, to make the lag more visible.

Also attached a video of reproducing the bug.

MC-276312

Scores still get lost on zombie-drowned conversion. Still not fixed in 24w36a

This issue is different from MCPE-165278. I know that depth-first/breadth-first order can change the logic of a command, but that doesn't explain how the forked branches are changing their execution position even though there is no position-related subcommands. You can see that the commands in my report don't have `at @p`, which means that there is no means to re-capture the player's position.

Additionally, I would like to mention that this does not happen when running from a command block.

It seems that this bug has been fixed. I can't reproduce it in 1.20.5

Uh wait... I apologize, it appears that only the AttributeModifier tag is lost, not the entire item. I wrote them incorrectly at first.

Still happens in 1.19.4. Player now teleports to the correct dimension, but still does not "/spectate" the specified entity. (Also F3+N doesn't work after this teleport. I had to run the /gamemode command myself.)

(Workaround)

This does not occur in predicate's distance detection. Use that instead.