Aloi

@Felix Jones What exactly is this new BlockTag? The statement:

if we discover other blocks with the same vertical surface Cushion placement issue, we will be adding them to the BlockTag

seems to be something broader (possibly using a "if it's in the tag, the placement mechanics are different" approach in the positioning).

But in reality, this only affects blocks that have an InteractionShape (called an "auxiliary interaction box" on the Minecraft Wiki). This behavior occurs precisely because the clicked face can be considered "up" due to the InteractionShape, even if the clicked position isn't (since that's defined by the Shape).

So, naturally, blocks in this tag would consider the click direction in Shape instead of the InteractionShape direction (this secondary direction would have to be saved in the UseOnContextfor that). Therefore, the only blocks that would have any additional effect on the tag, besides those mentioned, are scaffolding blocks. They wouldn't be able to discover new blocks simply because all the others have an empty InteractionShape.

In this case, it would be important to add scaffolding to the tag to ignore the InteractionShape in order to resolve MC-309858.

Bug fixed in 26.3 snap 1, with the addition of registerWall(...) in net.minecraft.world.level.block.Blocks (thus adding forceSolidOn() to the resin brick wall).

I also tested it in the game.

Based on the code analysis, it's only possible if:

• The villager is sleeping

• The villager is making is trading

• Or, the item is a villager_spawn_egg

It's also necessary that the item doesn't have any other effect when interacting with the villager. For example, if it's a villager spawn egg by default, it will summon a baby villager, but it's possible to remove minecraft:entity_data.

Try using, for example:

/give @s minecraft:villager_spawn_egg[minecraft:equippable={equip_on_interact:true,slot:head,swappable:false},!minecraft:entity_data,minecraft:item_model=big_dripleaf,minecraft:item_name={translate: "block.minecraft.big_dripleaf"}] 1

Can confirm in 26.1 snap9

Code analysis

In SimpleContainer has:

public ItemStack removeItem(final int slot, final int count) {
		ItemStack result = ContainerHelper.removeItem(this.items, slot, count);
		if (!result.isEmpty()) {
			this.setChanged();
		}

		return result;
	}

And in HopperBlockEntity

private static boolean tryTakeInItemFromSlot(final Hopper hopper, final Container container, final int slot, final Direction direction) {
    ItemStack itemStack = container.getItem(slot);
    if (!itemStack.isEmpty() && canTakeItemFromContainer(hopper, container, itemStack, slot, direction)) {
       int originalCount = itemStack.getCount();
       ItemStack result = addItem(container, hopper, container.removeItem(slot, 1), null);
       if (result.isEmpty()) {
	       container.setChanged();
	       return true;
       }

Even if addItem(...) fails, simply calling it ends up calling removeItem(...) which calls this.setChanged().

The setChanged() empties the composter (in ComposterBlock.OutputContainer):

public void setChanged() {
    ComposterBlock.empty(null, this.state, this.level, this.pos);
    this.changed = true;
}

If the hopper is full (inventoryFull()), this doesn't happen because tryTakeInItemFromSlot(...)is not called.

Fixed link: https://minecraft.wiki/w/Item_tag_(Java_Edition)#panda_eats_from_ground

The same thing happens when feeding a panda an item that is not in #panda_eats_from_ground. This significantly affects data packs with items in #panda_food that are not in #panda_eats_from_ground.

See https://minecraft.wiki/w/Item_tag_(Java_Edition)#panda_eats_from_ground%5D for a detailed explanation of the behavior.

This could be solved simply by removing the tag's condition from Panda.handleEating() on the line:

if (this.getEatCounter() > 100 && this.getItemBySlot(EquipmentSlot.MAINHAND).is(ItemTags.PANDA_EATS_FROM_GROUND)) {