The behavior described here still exists in 14w21b. stat.damageTaken seems to track possible damage instead of what damage the player actually suffers. It also doesn't take account of armor or the split-second of invincibility after a suffering a hit (if you click a player twice really fast, only the first hit will damage them, but both hits will be counted by stat.damageTaken).
Yes, I hope this wasn't intended. I've been working on a mini-game that uses fake players (dummy players? I'm not sure of the correct terminology) to track team scores with names like "RedTeam". In 14w25b and before, I could add these fake players to the team so their name would show up in the sidebar with the team color. But in 14w26a & b, I can no longer add the fake player to the team, so they all show up as white in the sidebar.
This issue still exists in 14w28a. Any mods around? I'm pretty sure Mojang isn't going to fix this if they don't know about it and I can't update the list of affected versions unless I am mistaken. I can't open a new report since it would immediately (and rightly) get marked as a duplicate of this one. But this report seems to be well and truly dead.
@Jeff I'm pretty sure you didn't read the entire bug report. How do OwnerName or OwnerUUID have anything to do with creepers? The horse thing was just one example and perhaps one that is no longer relevant.
Agreed this is not a duplicate of MC-29518.
As of 14w31a, stat.damageTaken (MC-49590) is now tracked correctly, but stat.damageDealt still ignores any armor, enchantments, etc. that the other entities have. So, if you hit another player with a wooden sword, it will count as dealing 5 hp of damage even if they had full enchanted diamond armor and received no visible damage on their screen.
This still happens in 15w41b.
It's a bigger deal now because the new Elytra is only found in an item frame in a ship which is often above void. If you don't build a massive safety net under the ship, there's no way to stop the Elytra sometimes flying through the wall, off the ship, and into the void.
This problem still exists in 14w21b.
This still happens in 14w21b, although I thought it was intended.
The behavior described here still exists in 14w21b. stat.damageTaken seems to track possible damage instead of what damage the player actually suffers. It also doesn't take account of armor or the split-second of invincibility after a suffering a hit (if you click a player twice really fast, only the first hit will damage them, but both hits will be counted by stat.damageTaken).
This issue still exists in 14w26b, but it looks like the original reporter stopped updating this long ago.
This issue still exists in 14w26b.
This issue still exists in 14w26b.
Yes, I hope this wasn't intended. I've been working on a mini-game that uses fake players (dummy players? I'm not sure of the correct terminology) to track team scores with names like "RedTeam". In 14w25b and before, I could add these fake players to the team so their name would show up in the sidebar with the team color. But in 14w26a & b, I can no longer add the fake player to the team, so they all show up as white in the sidebar.
This issue still exists in 14w26c.
This issue still exists in 14w26c.
This issue still exists in 14w26c.
This issue still exists in 14w27b.
This issue still exists in 14w27b.
This issue still exists in 14w28a. Any mods around? I'm pretty sure Mojang isn't going to fix this if they don't know about it and I can't update the list of affected versions unless I am mistaken. I can't open a new report since it would immediately (and rightly) get marked as a duplicate of this one. But this report seems to be well and truly dead.
This issue still exists in 14w28a.
This issue still exists in 14w28a.
Thanks for updating it
@Jeff I'm pretty sure you didn't read the entire bug report. How do OwnerName or OwnerUUID have anything to do with creepers? The horse thing was just one example and perhaps one that is no longer relevant.
Thank you, Skylinerw. I know I tried that, but I must have had a typo somewhere that stopped it from working, which was my mistake.
This issue is no longer present in 14w31a.
Agreed this is not a duplicate of
MC-29518.As of 14w31a, stat.damageTaken (
MC-49590) is now tracked correctly, but stat.damageDealt still ignores any armor, enchantments, etc. that the other entities have. So, if you hit another player with a wooden sword, it will count as dealing 5 hp of damage even if they had full enchanted diamond armor and received no visible damage on their screen.Still present in 1.8-pre1
Still present in 1.8-pre1, but I think this is intended. All similar blocks such as flowers and tall grass cause the same effect.
This issue still exists in release 1.8
Still present in 1.8.3
This still happens in 15w41b.
It's a bigger deal now because the new Elytra is only found in an item frame in a ship which is often above void. If you don't build a massive safety net under the ship, there's no way to stop the Elytra sometimes flying through the wall, off the ship, and into the void.
I made a video showing the bug in 15w41b: https://youtu.be/r-5-ToPwDUM
Duplicate of MC-2791
...yes...what is this duplicating? There are two issues listed as related, but neither of them describe this issue at all.
This still happens in 15w42a
The title is wrong. It still affects nether portals.
Still happening in 15w44b