This article is a work in progress. 

Please help in the expansion or creation of this article by expanding or improving it. The talk page may contain suggestions.

This feature is exclusive to Java Edition. 

Damage types are JSON files located in data packs that define different kinds of damage that entities can take. They control which attributes the damage has as well as which death message is used when an entity dies due to that type of damage.

Additionally, the built-in damage type tags control many aspects of how damage is applied by the game.

Custom damage types can currently only be applied using the /damage command.

File format

Damage types are stored as JSON files within a data pack, at the path data/<namespace>/damage_type/<name>.json.

For example, here is JSON for the built-in minecraft:arrow:

{
	"exhaustion": 0.1,
 	"message_id": "arrow",
	"scaling": "when_caused_by_living_non_player"
}

Scaling

Damage types control whether damage scales with difficulty.^{[more information needed]}

Possible values of  scaling:

• never: Damage is always the same.
• always: Damage always scales with difficulty.
• when_caused_by_living_non_player: Damage scales with difficulty if the attacker^{[note 1]} was a living entity^{[note 2]} and was not a player.

Effects

Damage types control how incoming damage is shown to the player.

Possible values of  effects:

• hurt (default): The default hurt sound.
• thorns: Thorns hurt sound.
• drowning: Drowning sound.
• burning: A single tick of burning sound.
• poking: Berry bush poke sound.
• freezing: Freezing tick sound.

Death messages

Damage types control the death messages displayed when players or pets die.

Possible values of  death_message_type:

• default (default): Use the standard death message logic.
• fall_variants: Use the fall damage death messages, e.g. death.fell.assist.item.
• intentional_game_design: Show the "intentional game design" death message.

Default message type

When standard death message logic is being used, messages are generated as follows, making use of the  message_id tag:

• If the killing blow was caused by an attacker^{[note 1]} and the attacker was holding a named item in their main hand at the time of death, this is categorized as an item death. A translated message is displayed using the translation key death.attack.<message_id>.item with the following insertions available:
  1. The name of the dying entity.
  2. The name of the attacker.
  3. The name of the item.
• If the killing blow was not caused by an attacker^{[note 1]}, but the dying entity had recently^{[more information needed]} taken damage that was caused by a living entity^{[note 2]}, this is categorized as an assisted death. A translated message is displayed using the translation key death.attack.<message_id>.player with the following insertions available:
  1. The name of the dying entity.
  2. The name of the recent attacker.
• If neither of the above apply, this is categorized as a normal death. A translated message is displayed using the translation key death.attack.<message_id> with the following insertions available:
  1. The name of the dying entity.
  2. The name of the attacker^{[note 1]}, if there was one.

Design

Because of how the default death messages are set up, most vanilla damage types are divided into ones that will always have an attacker^{[note 1]} and ones that will never have an attacker. Depending on whether there was an attacker, the translation for normal deaths (death.attack.<message_id>) will have either one or two available insertions. Translations have no safe way to access an insertion that may or may not be there, so the primary options are:

The death type is planned to always have an attacker.

• The translation looks like

  "death.attack.mob": "%s was slain by %s",
  "death.attack.mob.item": "%s was slain by %s using %s",
  

• The translation key death.attack.<message_id>.player is not provided, since assisted deaths are impossible.

The death type is planned to never have an attacker.

• The translation looks like

  "death.attack.drown": "%s drowned",
  "death.attack.drown.player": "%s drowned whilst trying to escape %s",
  

• The translation key death.attack.<message_id>.item is not provided, since item deaths are impossible.

The death type may or may not have an attacker.

• The translation looks like

  "death.attack.electricity": "%s was electrocuted",
  "death.attack.electricity.item": "%s was electrocuted by %s using %s",
  "death.attack.electricity.player": "%s was electrocuted whilst trying to escape %s",
  

• The translation key death.attack.<message_id> avoids using the second insertion, since it may or may not be present.
• The translation is a little awkward, since the death message when killed by a player will only mention them if they're holding a named weapon.

To avoid the awkwardness of the third option you can have two different damage types, one for use with an attacker, and one for use without an attacker:

"death.attack.active_electricity": "%s was electrocuted by %s",
"death.attack.active_electricity.item": "%s was electrocuted by %s using %s",
"death.attack.passive_electricity": "%s was electrocuted",
"death.attack.passive_electricity.player": "%s was electrocuted whilst trying to escape %s",

History

Notes