When you use a /clear command to delete Stone from an inventory, it not only deletes Stone but also Granite, Polished Granite, Diorite, Polished Diorite, Andesite, and Polished Andesite. When you use a /fill command to replace Stone, it also replaces these other blocks. And when you use /testforblock to detect Stone, it detects the other blocks as if they were Stone.
A similar thing happens when you use these commands on Prismarine: They recognize Prismarine Bricks and Dark Prismarine as if they were Prismarine.
Steps to reproduce:
Download the attached world "Replace 'stone'.mcworld" and open it.
You are on the first of 3 stations. Note that your hotbar contains stacks of Stone, Granite, Polished Granite, etc.
In front of you is a command block labeled "/clear test". Press the button on it to execute the command /clear @p stone.
Note that all the blocks in your hotbar were cleared.
Move to the next station. Press the button on the command block labeled "/fill test" to execute the command /fill 4 71 2 4 73 5 air replace stone. Note that all the blocks were replaced, not just the Stone blocks.
Move to the next station. Press the button on the command block labeled "/testforblk tst" to execute the command /testforblock 2 71 7 prismarine. Note that the "Successfully found..." message appears in chat, despite the block actually being Dark Prismarine.
Expected results:
The commands should only detect/affect the blocks with the specified names, 'stone' and 'prismarine'.
Observed results:
The commands detect/affect blocks with additional names. With 'stone', the commands include 'granite', 'polished_granite', 'diorite', 'polished diorite', 'andesite', and 'polished andesite'. With 'prismarine', the commands include 'prismarine_bricks' and 'dark_prismarine'.
Additional information:
Since this bug report was written, additional sets of blocks with variants have been flattened. For those like ‘stone’ and ‘prismarine’ which retained the variant 0 name for one of the blocks in the set, this problem has been inherited. To be specific, when one of the specified commands is given a base name from the following table and the <data> parameter is omitted, the command actually acts on blocks or items having the additional names shown.
Base Name | Additional Names |
|---|---|
anvil | chipped_anvil, damaged_anvil, deprecated_anvil |
quartz_block | chiseled_quartz_block, quartz_pillar, smooth_quartz |
red_sandstone | chiseled_red_sandstone, cut_red_sandstone, smooth_red_sandstone |
dirt | coarse_dirt |
sand | red_sand |
purpur_block | purpur_pillar |
sandstone | chiseled_sandstone, cut_sandstone, smooth_sandsstone |
sponge | wet_sponge |
cobblestone_wall | mossy_cobblestone_wall, granite_wall, diorite_wall, andesite_wall, sandstone_wall, brick_wall, stone_brick_wall, mossy_stone_brick_wall, end_stone_brick_wall, nether_brick_wall, prismarine_wall, red_sandstone_wall, red_nether_brick_wall |
See my comments below for a discussion of why this problem is happening, why it's probably intended, and why I believe it's going to become a bigger problem if it's left this way.
Attachments
Comments 3
migrated
Discussion:
Obviously, what's happening here is that these commands are interpreting these block names the same way they always have: as the name of a family of similar blocks or items that share a common name and are distinguished by a variant number (often called a "data value" or "DV"). The combination of name and DV used to be the only way to identify specific members of a family in a command. For example, the command to give a block of Diorite to a player had to be written /give <player> stone <count> 3 where 'stone' was the family name and '3' was the data value.
Beginning with release 1.16.100, Mojang has been gradually been replacing these combinations by giving discrete names to each variant in a family. This means that instead of the previous syntax, a player can use the command /give <player> diorite <count>, which is easier for players to understand and which regularizes the command syntax because this form is identical to that used for names that were never grouped into families. This simplified syntax also matches that of the corresponding commands in Java Edition (which I think is Mojang's real motivation for doing it). Within changelogs, these changes are described in terms like "splitting a block or item into discrete instances"; in the community they're often referred to as "flattening names". The 'stone' block family was flattened in 1.20.50; the 'prismarine' block family in 1.21.10.22 Preview.
Flattening simplifies writing commands, but it also has a downside: Because it changes the syntax of commands, it could cause commands that use the earlier syntax to fail. Such commands might be found in worlds updated from an earlier release, where they were stored in command blocks or functions. Mojang makes it a priority not to break updated worlds, so to preserve the functioning of those commands, Mojang retains the deprecated "family + DV" references, calling them "aliases" of the discrete names. Aliases are not shown to players while they compose commands in the chat window because Mojang doesn't want players to use them going forward.
The problem described in this report happens when an alias is used in these three commands. It only happens in these commands because they make a special exception for aliases when no DV is provided: Whereas all other commands default the DV to 0, these commands instead trigger special logic that matches on the family name only, disregarding the DV. In other words specifying 'stone' with data value 3 in a command matches only Diorite, but specifying 'stone' with no data value matches everything in the 'stone' family. This is what causes the unexpected behavior, because now that 'stone' has been flattened, the name 'stone' should only apply to the Stone block. And the reason it doesn't is for backward compatibility with stored commands in updated worlds, as explained in the previous paragraph.
Lots of block and item families have already been flattened: 'planks' in 1.20.50 (with 'stone'), 'bucket', 'coal', 'dye', 'wool', 'log', 'carpet', 'coral', 'concrete', and many more even earlier. But the problem doesn't happen with any of these family aliases, so let me explain why only 'stone', 'prismarine', and the five families flattened in the new Preview release are affected.
There are 2 crucial prerequisites for this problem to happen: First, only block families are affected. For whatever reason, the /clear command doesn't delete other kinds of buckets (Milk, Bucket of Cod, etc.) when you give it the item name 'bucket', nor does it delete Charcoal when you give it 'coal'. The /fill and /testforblock commands only accept block aliases, so this doesn't apply to them.
Second, the flattening must have persisted the family name as the discrete name of variant number 0. To give a clearer example, the 'stone' family's variant number 0 was given the discrete name 'stone', and 'anvil' variant 0 was given the discrete name 'anvil'. It is this fact that triggers the problem, because it makes the name 'stone' or 'anvil' ambiguous: It can be interpreted as either a discrete block name or an alias family name, and when no DV is provided it's impossible to know which is meant. In point of fact, these commands always interpret it as an alias family name in this case, for reasons of backward compatibility, and it triggers their special matching logic, which is what causes the error.
It is possible for a player to code a command in a way that gets around the problem: For the /clear command, you can simply provide a <data> parameter specifying the intended DV. It's a little harder for /fill and /testforblock, which no longer accept a <data> parameter; for these you have to include a block state parameter. But these tricks are just workarounds: Newer players won't understand what they mean or why they're necessary, because to them the block name uniquely identifies the block.
In the final analysis, the hard problem I'm describing in this report is that backward compatibility is considered very, very important, but when it comes to these commands, preserving it conflicts with Mojang's intention that players should regard blocks as independent objects with discrete names. And the conflict grows more visible with each block that gets flattened. So the design team and the devs will have to come up with some way to fix this, but I don't think it's going to be easy or smooth.
