Hardcoded item properties (Java Edition)

Hardcoded item properties are aspects of items which are tied to the IDs and cannot be customized fully via the use of commands or data packs.

Many of the properties associated with items in the game have been made controllable with the newly-introduced data component format; this intends to track things that are not currently controllable via components, item tags, recipes, advancements, enchantments and trades (though may be in future).

Most item instances in the game are through item stacks. An item stack is defined by its id, count and components.

The count of an item is the easiest to control, and can largely be controlled even in Survival mode. Changing commands and components gives you more freedom to control it, although items with a count higher than their max_stack_size have some side effects and it is not possible, even with commands, to exceed a count of 99 or be less than 1.

However, the count is rarely used to affect the property of an item stack. Exceptions include the weight of the item in a bundle to test if it is full, the weight of the item in a container to be used by comparators, and using the item in trades. It is possible to control the quantity of items needed for a trade by commands and datapacks, the weight of the item in container is partially controlled by max_stack_size, and in bundles, in addition to being partially controlled by max_stack_size, it is also by bees and by bundle_contents. Furthermore, most uses of item stacks that do not depend on their count cannot be controlled to have to need it.

Some components are partially controlled by changes made to the item in Survival mode. All components are strongly controlled by commands, although not entirely, as valid data is still required.

It is also possible to control the components of future item instances via datapacks, such as controlling the components of items in a loot table, the components of the result of many recipes (but not all, especially when the recipe result depends on the ingredient components), the components of the gives in villager trade, or the components of items that are in structures but are not part of a loot table (such as some chests in secret rooms of the woodland mansion).

However, there are origins of items that are not controlled by datapacks or commands, thus making it impossible to control the initial components of these items without mods (although it is possible to test when these items are originated and change their components later using datapacks).

Changes to an item's stack properties, depending on whether or not a certain component has it, can vary considerably. In some cases, the component affects all items that possess it and is highly customizable. In other cases, the component only affects stack items with certain IDs, or the component doesn't have much customizable data. Furthermore, some components affect more than one item property, making it impossible to activate only some of them.

Sometimes, properties that can be controlled by components have a lower priority than properties that depend on the item's ID, to the point that being used on certain items partially or completely loses its effect.

Default components

Default components are components that are defined for each item ID. If an item stack does not have a component defined in the component field, but has it as its default component, it will consider the value of its default component. If it has the component in the component field, it will consider the value of the component field.

With commands and datapacks, this control only extends to additional components, not default components. Default components depend solely on the item's ID and cannot be customized.

It is possible to remove a component of an item stack with ![component name]. However, this will modify the item's data, adding a new component that serves to remove the previous one. This can impact, for example, comparisons of item data via commands, or picking up a block with a mouse click (since the block is only selected from your inventory if it doesn't have additional components).

Furthermore, some aspects of the items depend on their default component. For example, knowing which spawn egg will be picked up when clicking on an entity, or the villager controlling the number of items in the inventory to know whether to drop it.

Often, an item's stack property depends on its ID. Sometimes it depends only on its ID, and other times it depends on both its ID and its components or count. The main objective of this article is to describe the item properties that depend on their ID; however, not all will be covered, as some item properties that depend on their ID are actually controlled by data packs and not hardcoded.

Note that all these properties, being controlled by ID and not by component, cannot be made so that only some item stacks possess them, because when adding an ID, all item stacks with the same ID will share it. Thus, customizing properties by component instead of ID is more powerful. Due to this and the impossibility of registering new IDs, it is possible that data pack projects will not be viable because they do not have enough items to define properties with different IDs.

Item tags

Many of an item's properties depend exclusively on it belonging to a certain item tag. Sometimes an item tag is used to describe a property that can also be changed at another time; for example, using a tag in a vanilla datapack file would allow you to directly use the item IDs there. However, there are item properties that can only be manipulated without mods by adding them to a tag. See item tag.

Recipes

Recipes can control the properties of items to be used in the manufacture of others. Although largely customizable, there are still some limitations, especially when considering the components of the ingredients for the final result. See recipes.

Enchantment definition

When defining an enchantment, it is necessary to define the items in supported_items and primary_items to specify which items can be crafted at the anvil and the enchanting table, respectively. See enchantment definition.

Some properties may depend on the item's id, component, and count. Below is a list of these properties that can be controlled by data packs or commands.

Trade

Trade can be controlled either by commands (with /data, editing villager data) or by villager trade definition. With them, you define the properties of an item stack, which can be trade for another by the villagers.

Item predicate

The item predicate is a subpredicate of predicates. Predicates can be used to test if a certain item satisfies a certain condition, and if so, contribute to the activation a certain loot table or advancement trigger. Loot tables are used to obtain items at various times. Advancement triggers, in addition to being used to receive advancements, are also used to unlock recipes.

Predicates are even more important for customizations, being used in commands or in advancement triggers to activate functions. Some commands like /execute (if|unless) items ... are also very important in testing items and have an effect. Although we can use such commands to simulate a hardcoded item property or inhibit properties of certain items, this will hardly be done in a completely similar way, and the hardcoded properties will continue to exist, only being inhibited or copied.

There are at least three ways in which the game code describes the properties of an item associated with its ID.

In class Item.Properties, the game defines a series of functions that can be applied to an item and change its properties. However, the vast majority of these properties ultimately only modify the item's default data components.

A complete list of default components in 1.21.11 can be seen at misode/mcmeta. The list for 26.3 Snapshot 1 can be found here.

A notable exception is the craftRemainder property, which defines which item will remain in a recipe when using the item as a recipe. See below for a list of all craft reminders:

All craft remainder can also be used in custom recipes via data packs. In code is also used in the craft display item, however it apparently hasn't been implemented in the game​^{[more information needed]}.

Adding some tags, such as #wooden_trapdoors, to one of the items above, allow to use it as fuel and have the crafting remainder after. In the book and banner cloning recipe, the cloned item remains if it doesn't have a craft remainder^{[note 2]}; if it does have a crafting remainder, the crafting remainder takes priority. Therefore, when placing one of the above items with a source in the book cloning recipe, instead of keeping the item, it will keep its crafting remainder.

Another exception is the item descriptionId, which can be minecraft.item.<id> or minecraft.block.<id>. Although its primary use is for the item name, the item_name default component, this description id is also used for other things, such as potion names and disc fragment descreipition.

The last exception is the requiredFeatures propertie, although it's not important in the current version. It serves to list which experiments must be active to use a certain item in many cases. Currently, no item is exclusive to any experiment; thus, all have this property with its default value VANILLA_SET.

Most of the Item.Properties applied to items are applied from the item's registered in Items.

In the item package, there are many classes that define properties for a certain item or a certain set of items; these classes extend the Item class. A large part of the hardcoded item properties come from here.

These classes have [something]Item as their name, such as DyeItem, HoeItem, and NameTagItem.

In many cases, when an item is registered in Items, it is already created as a new instance of one of these classes.

Some of them are abstract classes, not having any item that is restricted as a new instance of that class; however, these classes are extended by other classes, and so on until reaching a class that is at least one item, which is then restricted as a new instance of the class.

Most of the properties of an item defined as belonging to a specific subclass are defined within the subclass itself. However, sometimes in other classes, instanceof is used to test if a certain item is an item of that class, and thus new properties can be defined for the item.

The table below shows the classes that extend Item and the IDs of the items that are restricted as instances of them (in Items).

See § Item subclasses for details.

In many parts of the game's code, within many contexts, direct access to an item's restricted area is used, by Items member access, allowing to determine a property of that item.

In certain cases, this item call only serves to create the vanilla datapack, for example by creating item tags, recipes, loot tables and trades. Therefore, this is a property that can be fully controlled by datapacks. However, it's worth noting that many of these properties that we can fully control through data packs (and not through components) can only be controlled by the item's ID, not by its components.

Furthermore, in some cases, it creates a new instance of the item. This could be due to an item origin not controlled by a loot table (such as equipment or wither flowers), a visual effect (such as using items in a GUI), or some other use (such as a mob using an item as a projectile). In these cases, we are not strictly talking about an item property, as we are not discussing how a pre-existing item modifies the game.^{[note 3]}

The table below shows all the classes that has a Items memmber access, and the number of uses in each class. According to the code of 26.1.

Legend：

• red The background indicates that all items within that class are used only for generating the vanilla datapack/resourepack.
• yellowThe background indicates that all items within them are a new instance, representing an item's origin, visual use, etc., and not a property of a pre-existing item.

See § Items member access, for details of the classes without note

Empty, for most items, it doesn't add any properties. However, it can add properties with its implementations, see below.

Uses tree

• Item.onUseTick(...)
  • ItemStack.onUseTick(...): Calls the method implemented in the item stack as item, after properties relating to consumable and kinetic_waapon components.
    • LivingEntity.updateUsingItem(...): Called at the beginning, in the ServerPlayer implementation after activating using_item tiger criteria.
      • LivingEntity.updatingUsingItem(): Calls if the item stack used remains in the same hand of the entity.
        • LivingEntity.tick(): Called at the beginning after super.tick() (i.e., activated in each ticks after the common updates of all entities but before the other specific updates of living entity).
        • LivingEntity.releaseUsingItem(): Called only if the useItem.useOnRelease(). It only affects crossbow, see § useOnRelease(...).

Implementations

• 👁 Image
  BrushItem
• 👁 Image
  BundleItem
• 👁 Image
  CrossbowItem

Used for items to drop their contents to be destroyed. By default, nothing happens, having an effect only on instances of classes that implement it, see below.

Uses tree

• Item.onDestroyed(...)
  • ItemStack.onDestroyed(...): This method simply calls onDestroyed(...) implemented in the item stack as item.
    • ItemEntity.hurtServer(...): Only called when the hurt is not ignored and the item's health is less than or equal to zero after reviewing the hurt.

Implementations

• 👁 Image
  BlockItem
• 👁 Image
  BundleItem

Retrona false iff the user is a player in the creation (has instabuild) and the item has the tool component with can_destroy_blocks_in_creative false.

Note that this method depends exclusively on the component and is not hardcoded. However, the method still has an implementation.

Uses tree

• Item.canDestroyBlock(...)
  • ItemStack.canDestroyBlock(...): This method simply calls canDestroyBlock(...) implemented in the item stack as item.
    • ServerPlayerGameMode.destroyBlock(...): Initially, it returns false if the player cannot destroy the block in that position. However, it is still possible for it to return false later in other situations. If it does not return false, the player destroys the block, in addition to some other possible effects (such as dropping).

Implementations

• 👁 Image
  DebugStickItem

It only returns the interaction result PASS. However, in implementations, in addition to the side effects (the core of the method), it can return interaction results such as FAIL and SUCCESS. These returns can have some subsequent effect as shown in the tree below.

Uses tree

• Item.useOn(...)
  • ItemStack.useOn(...): See below.
    • ServerPlayerGameMode.useItemOn(...): See below.
      • ServerGamePacketListenerImpl.handleUseItemOn(...): See below.
    • GameTestHelper.useBlock(...) and placeAt(...): Used in GameTest.
  • PlaceOnWaterBlockItem.use(...): See § PlaceOnWaterBlockItem.

Description of the methods:

• ItemStack.useOn(...): If the player is in adventure mode and the item stack does not have the can_place_on component corresponding to the clicked block, it returns fail.

Otherwise, call the method implemented in the item stack as item. If the method returns SUCCESS increases the item used statistic by one. Returns the return value of the called method.

• ServerPlayerGameMode.useItemOn(...): Returns falls if the block being hit is exclusive of a unenabled experiment. The current version 1.21.11 does not have such blocks in the game.

If the player is in the spectator mode: if the block has a menu, open the menu and return CONSUME, otherwise return PASS.

If the player is not sneaking or doesn't have items in either hand:

• The player will attempt to use the item, or the empty hand, on the block. However, for this use, the previous method will not be used, but rather state.useItemOn(...), which is a method controlled by the block (state). Sometimes this method will give different results depending on the item used; see § Items member access for details.
• If the interaction returns any success, item_used_on_block is activated and the method is completed, returning the same result.
• If the interaction returns TRY_WITH_EMPTY_HAND and the interacting hand is the mainhand, the player attempts to interact with the block using the state.useWithoutItem(...) method.
  • If the interaction returns any success, default_block_use is activated the method is completed, returning the same result.
• If neither state.useItemOn(...) nor state.useWithoutItem(...) returns success, the method continues.

If the item stack is empty or in cooldown, return PASS.

Finally, the ItemStack.useOn(...) method is called. If the player is in creative mode, the stack item quantity is restored, preventing any loss due to the called method. If the return is successful, the item_used_on_block is activated. Returns the return of the called method.

In DemoMode, output demo reminder and return PASS, if demo timer has end. Otherwise, it calls the supermethod, so the method will proceed normally.

• ServerGamePacketListenerImpl.handleUseItemOn: Initially, it tests if the interaction is allowed, if positive, call the method. If the return of the called method is successful, the any_block_use is activated.

If the interaction is unsuccessful, the interaction direction is up, the interacted block is at its maximum height, and the item is a § BlockItem or § BucketItem instance with non-empty fluid and is not on cooldown, then send the system error message in action bar with the translation of build.tooHigh with the maximum height value of the dimension.

If the return of the called method is SUCCESS or SUCCESS_SERVER, the player swings the hand used.

Implementations

* The implementation uses a supermethod, calling that method.

Only subsections marked with an asterisk (*) aren't empty.

{
 "title": "AirItem",
 "rows": [
 {
 "field": "AirItem",
 "label": "Class"
 },
 {
 "field": "<div class=\"hlist \" >\n*<span class=\"nowrap\"><span class=\"sprite-file\" style=\"\">(link to File:BlockSprite air.png article, displayed as 16x16px|link=Air|alt=|class=pixel-image|)</span>(link to Air article, displayed as <span class=\"sprite-text\">Air</span>)</span>\n</div>",
 "label": "Items"
 }
 ],
 "invimages": [],
 "images": []
}

Air has a block descriptionId, meaning its translation key is minecraft.block.air. However, unlike other items with this descriptionId, aor is not an instance of BlockItem, because AirItem does not extend BlockItem.

getName(...)

Defined ignoring the item stack components, therefore, it is always a translation of minecraft.block.air regardless of the component item_name.

This has an effect on stacked items that are treated as if they were air (for example, items with a count of 0).

Note that many other properties of the air item are defined elsewhere in the code. See § Items member access.

{
 "title": "ArmorStandItem",
 "rows": [
 {
 "field": "ArmorStandItem",
 "label": "Class"
 },
 {
 "field": "<div class=\"hlist \" >\n*<span class=\"nowrap\"><span class=\"sprite-file\" style=\"\">(link to File:ItemSprite armor-stand.png article, displayed as 16x16px|link=Armor Stand|alt=|class=pixel-image|)</span>(link to Armor Stand article, displayed as <span class=\"sprite-text\">Armor Stand</span>)</span>\n</div>",
 "label": "Items"
 }
 ],
 "invimages": [],
 "images": []
}

useOn(...)

If the interaction involves clicking on the dowm side of a block, it fails.

The target position for placing the armor stand is the bottom center of the block next to the interacted block, in the direction of the interacted face. The game simulates the hitbox of an armor stand in this position; if the hitbox collides with a block or intersects with an (no spectator) entity hitbox, the interaction fails.

The game attempts to obtain the armor stand, based on the item's components custom_name, custom_data, and entity_data. If it cannot be generated, the interaction fails.

In case of the armor stand is generated, apply in the following order:

• the armor stand rotates 202.5° according to the player's rotation, but rounds its rotation down to some multiple of 45°;
• the sound event armor stand place (entity.armor_stand.place) is played;
• produce the game event entity_place;
• shrink one item of the item stack.

The interaction returns success given no aforementioned fails occur.

{
 "title": "ArmorStandItem",
 "rows": [
 {
 "field": "ArmorStandItem",
 "label": "Class"
 },
 {
 "field": "<div class=\"hlist \" >\n*<span class=\"nowrap\"><span class=\"sprite-file\" style=\"\">(link to File:ItemSprite beds.png article, displayed as 16x16px|link=Beds|alt=|class=pixel-image|)</span>(link to Beds article, displayed as <span class=\"sprite-text\">Beds</span>)</span>\n</div>",
 "label": "Items"
 }
 ],
 "invimages": [],
 "images": []
}

placeBlock(...)

Set the block with update flags of 26 instead of 11.

{
 "title": "BlockItem",
 "rows": [
 {
 "field": "BlockItem",
 "label": "Class"
 },
 {
 "field": "(values exceeds 1000 characters...)",
 "label": "Items"
 },
 {
 "field": "(values exceeds 1000 characters...)",
 "label": "Implementations"
 }
 ],
 "invimages": [],
 "images": []
}

Each item in this class is associated with a block, defined in Items. With few exceptions, the item has the same id as the associated block and minecraft.block.<id> is the item's descriptionId.

useOn(...)

Try placing the block with place(...) (see § Place for details).

If the result of place is any success and the item does not have the component consumable, return that result from place. Otherwise, use the item (see § use(...)) and return the result of use.

shouldPrintOpWarning(...)

If the player has Permission level gamemaster (level 2) and the item has the component block_entity_data, it returns true if the block entity id is command_block, lectern, sign, hanging_sing, mob_spawner, or trial_spawner. Otherwise, it returns false.

canFitInsideContainerItems()

Returns false if the associated block is an instance of ShulkerBoxBlock, in other words, one of the 17 shulker boxes.

onDestroyed(...)

Set the container component of the entity item to empty. If the component existed previously, drop all the item stacks it contained at the entity item's position.

There are two methods in BlockItem related to associating the item with its associated block and vice-versa:

• getBlock(): Returns the block this.block, defined when registering the item in Items.
• registerBlocks(...): Put the pair (this.getBlock(), item) in map. Used only with the Item.BY_BLOCK map.

In Items, ItemBlocks are registered using either the registerBlock(...) method or the createBlockItemWithCustomItemName(...) method.

In registerBlock() given a block, an item is created with the same id, and with the block description id, after that registerBlocks is used to save the block and item in Item.BY_BLOCK. There are some variations, which can be summarized as: adding default components to the item (by § Item.Properties), making the item a different class, a subclass of ItemBlock and put alternative blocks in Item.BY_BLOCK.

Only two items have alternate blocks:

• 👁 Image
  Big Dripleaf: has the 👁 Image
  Big Dripleaf Stem as an alternate block,

• 👁 Image
  Cauldron: has 👁 Image
  Water Cauldron, 👁 Image
  Lava Cauldron, and 👁 Image
  Powder Snow Cauldron as alternate blocks.

However, in § StandingAndWallBlockItem, there is an override of registerBlocks(...), adding the wallblock corresponding to each item in the list.

In createBlockItemWithCustomItemName(...) the item's ID is defined separately and uses the item's description ID. Items can have other default components, but it is always a BlockItem and not a subclass. Below is the complete list of items registered with this method:

Resin clump and nether wart has the same ID but it still has different ID descriptions.

The method registerBlocks(...) is only used in Items, however getBLock() has many more uses.

[...]

The Item.BY_BLOCK map is used in the Item.byBlock(...) method, where for each block it searches for its associated item, and if it doesn't exist, it associates it with the air item. This method is used only in Block.asItem() which returns the item associated with the block. The Block.asItem() method, however, has multiple uses.

[...]

{
 "title": "DiscFragmentItem",
 "rows": [
 {
 "field": "DiscFragmentItem",
 "label": "Class"
 },
 {
 "field": "<div class=\"hlist \" >\n*<span class=\"nowrap\"><span class=\"sprite-file\" style=\"\">(link to File:ItemSprite disc-fragment.png article, displayed as 16x16px|link=Disc Fragment|alt=|class=pixel-image|)</span>(link to Disc Fragment article, displayed as <span class=\"sprite-text\">Disc Fragment</span>)</span>\n</div>",
 "label": "Items"
 }
 ],
 "invimages": [],
 "images": []
}

appendHoverText(...)

Define the first line of the tooltip as the translation of item.minecraft.disc_fragment.desc in gray (
 #AAAAAA).

This line cannot be hidden by the tooltip_display component, except to completely hide the tooltip with hide_tooltip set to true.

{
 "title": "DyeItem",
 "rows": [
 {
 "field": "DyeItem",
 "label": "Class"
 },
 {
 "field": "(values exceeds 1000 characters...)",
 "label": "Items"
 },
 {
 "field": "<div class=\"hlist \" ><code>SignApplicator</code>\n</div>",
 "label": "Implements"
 }
 ],
 "invimages": [],
 "images": []
}

Each item has a default dye component, defined in Items.

When two sheep, cats, or dogs breed, take the color of each parent (the color of the wool or the color of the collar) and search all items that have the component dye of that color as a default and try to create the first recipe for each pair. If the result of some of these recipes is an item with the component dye, that color will be used for the offspring; otherwise, a random color from the parents is added.

Thus, the color of these animals depends on the hardcoded property of the dyes, and the color can only be edited along with the item's recipes. Only dyes have the component dye by default, and each value of the component exists in exactly one dye.

interactLivingEntity(...)

The interaction is only successful, instead of pass, when the interacting entity is a non-sheared live sheep of a different color than the dye component and the item stack has a dye component.

In case of success, the sound dye use is played, set the sheep color and shrink the item stack by one.

tryApplyToSign(...)

If the stack item does not contain the dye component, it returns false.

Try changing the text color on the sign, on the side being interacted with, to the color of the dye.

In case of success, the dye used sound is played and returns true. Otherwise, returns false.

{
 "title": "NameTagItem",
 "rows": [
 {
 "field": "NameTagItem",
 "label": "Class"
 },
 {
 "field": "<div class=\"hlist \" >\n*<span class=\"nowrap\"><span class=\"sprite-file\" style=\"\">(link to File:ItemSprite name-tag.png article, displayed as 16x16px|link=Name Tag|alt=|class=pixel-image|)</span>(link to Name Tag article, displayed as <span class=\"sprite-text\">Name Tag</span>)</span>\n</div>",
 "label": "Items"
 }
 ],
 "invimages": [],
 "images": []
}

interactLivingEntity(...)

The interaction will only be successful, instead of pass, when:

• the item has a custom_name component, and
• the entity isn't a player, leash knot, lightning bolt, or fishing bobber.

If the entity is alive, sets its CustomName to be the same as the name tag. If the entity is a mob, also sets PersistenceRequired true. Shrink the item stack of the item by one.

Note: This method is only called for living entities, so it ends up being a redundant under certain conditions. Even though the ender dragon is a living entity, this method is never called by it because when trying to interact with it, the EnderDragonPart is actually being interacted, which is not a living entity.

{
 "title": "PotionItem",
 "rows": [
 {
 "field": "PotionItem",
 "label": "Class"
 },
 {
 "field": "<div class=\"hlist \" >\n*<span class=\"nowrap\"><span class=\"sprite-file\" style=\"\">(link to File:ItemSprite potion.png article, displayed as 16x16px|link=Potion|alt=|class=pixel-image|)</span>(link to Potion article, displayed as <span class=\"sprite-text\">Potion</span>)</span>\n*<span class=\"nowrap\"><span class=\"sprite-file\" style=\"\">(link to File:ItemSprite splash-potion.png article, displayed as 16x16px|link=Splash Potion|alt=|class=pixel-image|)</span>(link to Splash Potion article, displayed as <span class=\"sprite-text\">Splash Potion</span>)</span>\n*<span class=\"nowrap\"><span class=\"sprite-file\" style=\"\">(link to File:ItemSprite lingering-potion.png article, displayed as 16x16px|link=Lingering Potion|alt=|class=pixel-image|)</span>(link to Lingering Potion article, displayed as <span class=\"sprite-text\">Lingering Potion</span>)</span>\n</div>",
 "label": "Items"
 },
 {
 "field": "<div class=\"hlist \" >\n* <code>SplashPotionItem</code>\n* <code>ThrowablePotionItem</code>\n* <code>LingeringPotionItem</code>\n</div>",
 "label": "Implementations"
 }
 ],
 "invimages": [],
 "images": []
}

useOn(...)

The interaction will only be successful, instead of pass, when:

• the face of the interacted block was not directed downward,
• the block is in the #convertable_to_mud tag, and
• the potion's content is water.

In case of success, apply in the following order:

1. Play the generic splash sound event (entity.generic.splash),
2. Set glass bottle in hand,
3. Send splash particles,
4. Play the bottle empty sound event (item.bottle.empty),
5. Produce the game event fluid_place,
6. Convert the block to mud.

getName(...)

If the item has the component potion_contents, the name name is defined from it. The item uses the translation key item.minecraft.<item type>.effect.<potion name>, where <potion name> is the custom name of the potion contents, if available, and otherwise is the name of the potion in potion contents (see Potion § Item data), if available. If nether is available, is "empty".

This name will replace the name defined by item_name. However, it can still be replaced by the custom_name, if available.

The class PotionItem has one instanceof usage. This usage occurs in PotionBrewing.expectPotion(...) to validate the method that adds container recipes.

In vanilla, this method adds the brewing recipes that transform potions into splash potions and splash potions into lingering potions. If the source item or the destination item is not an instance of PotionItem, it throws an IllegalArgumentException, immediately aborting the method and logging the error Expected a potion, got: <item ID>.

However, currently, this doesn't affect the vanilla game at all, because besides the vanilla container recipes already being potions, it's not possible to customize them. Although this may affect mods and possible future customizations (as already exists in Bedrock Edition).

{
 "title": "ShieldItem",
 "rows": [
 {
 "field": "ShieldItem",
 "label": "Class"
 },
 {
 "field": "<div class=\"hlist \" >\n*<span class=\"nowrap\"><span class=\"sprite-file\" style=\"\">(link to File:ItemSprite shield.png article, displayed as 16x16px|link=Shield|alt=|class=pixel-image|)</span>(link to Shield article, displayed as <span class=\"sprite-text\">Shield</span>)</span>\n</div>",
 "label": "Items"
 }
 ],
 "invimages": [],
 "images": []
}

getName(...)

If the item has the component base_color, the name is defined from it. The item uses the translation key item.minecraft.shield.<color>.

This name will replace the name defined by item_name component. However, it can still be replaced by the custom_name component, if available.

{
 "title": "SmithingTemplateItem",
 "rows": [
 {
 "field": "SmithingTemplateItem",
 "label": "Class"
 },
 {
 "field": "(values exceeds 1000 characters...)",
 "label": "Items"
 }
 ],
 "invimages": [],
 "images": []
}

Each instance of SmithingTemplateItem has a series of class-specific attributes, which are defined by SmithingTemplateItem(...). However, these attributes are not defined separately for each item; instead, they are defined by the createNetheriteUpgradeTemplate(...) and createArmorTrimTemplate(...) methods, where respectively defines the attributes of netherite upgrade and of all armor trims. In Items, only the item components are defined (by § Item.Properties, which in this case is only the rarity component).

These methods use the createTrimmableArmorIconList(), createTrimmableMaterialIconList(), createNetheriteUpgradeIconList(), and createNetheriteUpgradeMaterialList() auxiliary methods, and many auxiliary constants to create these attributes. Below is the complete table of these attributes:

Asset ID refers to textures file path in /assets/minecraft/textures/gui/sprites/.

public void appendHoverText(...)

Add the following lines to the beginning of the item's tooltip, in order:

• "Smithing Template" (
   Gray)
  • {"translate":"item.minecraft.smithing_template",color:"gray"}
• Empty line
  • {"text":""}
• "Applies to:" (
   Gray)
  • {"translate":"item.minecraft.smithing_template.applies_to",color:"gray"}
• Space append to appliesTo
  • [{"text":" "},appliesTo]
• "Ingredients:" (
   Gray)
  • {"translate":"item.minecraft.smithing_template.ingredients",color:"gray"}
• Space append to ingredients
  • [{"text":" "},ingredients]

There are 4 methods that always give the assigned values ​​of the sprint items, namely getBaseSlotDescription(), getAdditionSlotDescription(), getBaseSlotEmptyIcons(), and getAdditionalSlotEmptyIcons(). All of them are used only in the SmithingScreen class. This class defines the behavior of the menu slots in the smithing table, controlling both the sprint that appears in empty slots and the tooltip when hovering the mouse over an empty slot. Furthermore, this class uses two instanceof of SmithingTemplateItem (and in no other class of the code is it used instanceof of SmithingTemplateItem).

Slot background

Slots 0, 1, and 2 of the menu use a rendering of their variable background given by a list of identifiers (asset IDs), defined by the class CyclingSlotBackground. With each tick update:

• If the icons list is different from the old icons list, update the icons list and reset the index of the list to zero.
• If the current list is not empty:
  • Increase the tick count by one.
  • If the tick count is a multiple of 30, increase the index of the identifier by one; return to zero if it exceeds the limit of the list.

And when render the slot background:

• If the list is empty or the slot is not empty: do nothing.
• If the tick count is greater than 30 and fewer than t + a < 4.0, where t is how many ticks have passed the last multiple of 30: render the previous icon (one index lower or the last one in the list if the index is zero) with 1–(t+a)/4.0 transparency.​^{[more information needed]}
• Renderize the current index with (t+a)/4.0 of transparency.

Note that in this way each icon occupies the slot for 30 ticks and has a smooth transition of 4 ticks.

In SmithingScreen, each tick updates the tick of CyclingSlotBackground, from slots 0, 1, and 2, with a list that may vary:

• For slot 0, a list of two elements is always used; these are: container/slot/smithing_template_armor_trim and container/slot/smithing_template_netherite_upgrade.
  • • 👁 Image
      
    • 👁 Image
      

• For slot 1, if there is no instance of SmithingTemplateItem in slot 0, the list is empty. If there is, it is the baseSlotEmptyIcons of the item.
• For slot 2, if there is no instance of SmithingTemplateItem in slot 0, the list is empty. If there is, it is the additionalSlotEmptyIcons of the item.

Boarding Tooltips

Depending on the mouse position, among other factors, the switcher table menu renders a tooltip.

• Mouse over a rectangular area around the arrow: if the recipe has an error (has items in slots 0, 1, and 3 but no result): "Item can't be upgraded this way" (
   White)
  • {"translate":"container.upgrade.error_tooltip"}
  • When there is a recipe error, it also renders a red X above the arrow:
    • 👁 Image
      container/smithing/error
• If the mouse is in slot 0 and it is empty: "Add Smithing Template" (
   White)
  • {"translate":"container.upgrade.missing_template_tooltip"}
• If the mouse is in slot 1, it is not empty, and slot 0 has an instance of SmithingTemplateItem: the baseSlotDescription from item in slot 0.
• If the mouse is in slot 2, it is not empty, and slot 0 has an instance of SmithingTemplateItem: the additionsSlotDescription from item in slot 0.
• In any other case: it does not render a menu tooltip (although it continues to render item tooltips normally).

{
 "title": "WritableBookItem",
 "rows": [
 {
 "field": "WritableBookItem",
 "label": "Class"
 },
 {
 "field": "<div class=\"hlist \" >\n*<span class=\"nowrap\"><span class=\"sprite-file\" style=\"\">(link to File:ItemSprite book-and-quill.png article, displayed as 16x16px|link=Book and Quill|alt=|class=pixel-image|)</span>(link to Book and Quill article, displayed as <span class=\"sprite-text\">Book and Quill</span>)</span>\n</div>",
 "label": "Items"
 }
 ],
 "invimages": [],
 "images": []
}

use(...)

Open item GUI and increases the used statistic by one. Always returns successful.

Note:

The item GUI depends on the components writable_book_content and written_book_content. Therefore:

• If the item does not have either component: nothing is opened, but there is still an increase in statistics and usage animation.
• If the item has only one of these components: the corresponding GUI opens.
• If both components are present: both GUIs open, but the written book content GUI completely overlays the writable book content GUI, which the player can see briefly on the screen.

Therefore, the GUI are entirely dependent on the components and independent of the item ID. However, it is only possible to open them with the book and quill and written book, since only these items attempt to open the GUI.

{
 "title": "WrittenBookItem",
 "rows": [
 {
 "field": "WrittenBookItem",
 "label": "Class"
 },
 {
 "field": "<div class=\"hlist \" >\n*<span class=\"nowrap\"><span class=\"sprite-file\" style=\"\">(link to File:ItemSprite written-book.png article, displayed as 16x16px|link=Written Book|alt=|class=pixel-image|)</span>(link to Written Book article, displayed as <span class=\"sprite-text\">Written Book</span>)</span>\n</div>",
 "label": "Items"
 }
 ],
 "invimages": [],
 "images": []
}

use(...)

Completely identical to WritableBookItem; see the § WritableBookItem.

Blocks