When a mob spawns (either spawners, naturally or eggs) it is missing the generic.max_health attribute.
To reproduce:
Create a new world
Find a mob (either monster or peaceful)
Run the command (I did this with a sheep)
/data get entity @e[type=minecraft:sheep,limit=1,sort=nearest] Attributes
As you can see only the follow_range and movement_speed attributes are present, max_health is missing.
Related issues
relates to
Attachments
Comments
migrated
migrated
I can confirm this issue is still present in 1.16.3. So far the best way i've come across to fix it in-game is to summon mobs with their max health attribute in the command; like /summon minecraft:sheep ~ ~ ~ {Attributes:[{Base:8.0f,Name:"generic.max_health"}]} then if you get its data the max health will show in the data command output
Avoma
I can confirm 20w46a.
MMK21
Affects 1.18. Cows seem to only have minecraft:generic.movement_speed
MMK21
Affects 1.18.1
migrated
Can confirm still an issue in 1.20. From a quick check using some NBT decoding tools on this world, there's 254 living mobs in the 4 generated regions, and none of them have a `generic.max_health` attribute.
[media]
clamlol
Affects 23w31a, and affects players both initially and after respawn
clamlol
Actually, this seems like a duplicate of MC-188667.
migrated
@clamlol MC-188667 implies the `/data` command is broken (not showing unmodified attributes) rather than the attributes not being there but I've used other tools (e.g. `fastnbt` and Minutor) to examine the entities and they are still missing. It would be a bit weird if two unconnected codebases had the exact same bug as the Java client.
migrated
I'd suggest marking as related instead.
clamlol
@zimpenfish MC-188667 is badly worded because the reporter assumed the problem was with the data command rather than with the existence of the NBT itself. Since Mojang resolved it as WF, either they made a mistake or they realized that the data command was working as intended and said the core issue was WF; it seems highly unlikely that they thought a serious flaw in an important command wasn't worth fixing. Given the general incidence of misresolved reports on this Jira I think a misresolution on that ticket is possible but quite unlikely, and it seems safe to assume they don't want to bother fixing inconsistencies like this where a workaround (the attribute command) exists.
migrated
@clam lol The workaround (/attribute) doesn't work if you want the attribute actually in the NBT though - which is the case for offline tools that report / map / whatever - because whilst `/attribute @e[type=pig,sort=nearest,limit=1] generic.max_health get` does return a number (I'm guessing it does a lookup on the entity type), that attribute still doesn't exist on the found entity in the NBT files on disk.
But that would probably be a different bug than this one and I'm assuming will also be WONTFIX (probably they want to save a few bytes by optimising out common attributes to a lookup table.)
clamlol
You can use the attribute command to populate the NBT like this:
/execute as <entities> run attribute @s minecraft:generic.max_health modifier add 11111111-1111-1111-1111-111111111111 temp 0.0 add
/execute as <entities> run attribute @s minecraft:generic.max_health modifier remove 11111111-1111-1111-1111-111111111111Obviously it's annoying to have to do this (especially if you want all applicable attributes in the NBT of every entity in the world with no excess, in which case you'll probably want to call a function) but it should work just fine.