MC-264442The "/item" command cannot replace items within campfires
Summary:
When used on a campfire block, /item replace says "Target position (x,y,z) is not a container" and does nothing
Steps to reproduce:
/setblock ~ ~ ~ campfire /item replace block ~ ~ ~ container.0 with porkchop
Observed results:
Error.
Expected results:
Porkchop is placed on campfire, just like if you right-clicked on it.
Linked Issues
MCPE-86412![[Mod] EVGENSYPERPRO](../../../data/avatars/users/92853.png){kind=small}
Created Issue:
The "/item" command cannot replace items within campfires
Summary:
When used on a campfire block, /item replace says "Target position (x,y,z) is not a container" and does nothingSteps to reproduce:
/setblock ~ ~ ~ campfire /replaceitem block ~ ~ ~ slot.container 0 porkchopObserved results:
Error.Expected results:
Porkchop is placed on campfire, just like if you right-clicked on it.
Summary:
When used on a campfire block, /item replace says "Target position (x,y,z) is not a container" and does nothingSteps to reproduce:
/setblock ~ ~ ~ campfire /replaceitemblock ~ ~ ~slot.container0porkchopObserved results:
Error.Expected results:
Porkchop is placed on campfire, just like if you right-clicked on it.Summary:
When used on a campfire block, /item replace says "Target position (x,y,z) is not a container" and does nothingSteps to reproduce:
/setblock ~ ~ ~ campfire /item replace block ~ ~ ~ container.0 with porkchopObserved results:
Error.Expected results:
Porkchop is placed on campfire, just like if you right-clicked on it.
![[Mod] Avoma](../../../data/avatars/users/86198.png){kind=small}
![[Mod] markderickson](../../../data/avatars/users/18946.svg){kind=small}
![[Mojang] Moesh](../../../data/avatars/users/10122.svg){kind=small}
Normal![[MCPE Mod] Celesian](../../../data/avatars/users/81635.png){kind=small}
relates to
Confirmed!
Campfires are not containers as stated in the error, is this not expected behavior?
Looking at the code, the four items within a campfire are stored in a list and not an inventory like the player, or a tile entity for example.
Looking at modifyBlockItem in ItemCommands.java, there is a check to see if the target is a container or not, and it throws the error you got if it is not.
/item can change item frames, jukeboxes, lecterns, etc. none of which have an inventory, just an item contained, campfires fall in the same category.
All those blocks (and item frames) not being able to be modified with /item were valid reports.
Current state of code is not a reason for WAI, or everything would be WAI.
I see, my previous comment can be disregard then.