Fuzs
- Fusseel
- fusseel
- Europe/Stockholm
- Yes
- No
MC-267943![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
I recently experienced the issue, too, in my 1.8.1 world. It was also my horse that got duplicated. But as far as I know, the early versions of 1.8 had a lot of problems with disappearing and duplicated entities, but that got fixed in 1.8.3 or a later version of 1.8. I do not have any reference, that is just from what I remember from back then, but the issue is definitely fixed in 1.9.
Here is just a screenshot to prove that everything is fine when moving the max dig height beyond y=120. Bedrock isn't removed. (This screenshot was taken in a modded environment)
2018-07-27_23.44.46.png
A couple of enchantments couldn't be obtained from enchanting tables previously, but if you had an enchanted book with such an enchantment, you could still apply it at an anvil.
- All armor pieces can now get Thorns at enchanting tables, previously only chest plates were able to get it
- Axes can now get Sharpness / Smite / Bane of Arthropods at enchanting tables
Specifically for axes this really clutters the available enchantment pool and makes it harder to get tool enchantments such as Efficiency / Unbreaking / Silk Touch / Fortune which most people probably want.
This issue comes from EnchantmentHelper::getAvailableEnchantmentResults (the method responsible for picking enchanting table results) now calling Enchantment::canEnchant (for deciding if an enchantment is compatible with an item), when it was previously calling the now replaced EnchantmentCategory::canEnchant which didn't include the additional items from per enchantment Enchantment::canEnchant overrides.
Also on another note, while it's really great to have this new flexibility for controlling enchantment application via tags, why stick with the old enchantment category concept?
Like if I want e.g. tridents to accept Looting I can do that now, by adding minecraft:trident to #enchantable/sword, which is great, but it will also allow tridents to accept e.g. Fire Aspect at the same time which might not be something I want.
Why not just allow for one tag per enchantment?
The bug
Ever since the beginning of 1.14 snapshots, mobs wouldn't get knocked back when a player is blocking with a shield.
Here are some screenshots from the current version (1.13.2) and current snapshot (19w14b)
1.13.2:
- Vindicators
- Piglin (New Mob in 1.16.x)
- Zombie Pigman/Zombified Piglin (renamed in 1.16.x)
- Zombie Villager
- Zombie
- Husk
- Drowned
- Wolf
- Wither Skeleton
- Enderman
- Spider & Cave Spider
- Silverfish
- Slime and Magma Cube
These mobs do knockback when you're blocking.
19w14a & b and beyond of 1.14 - 1.16:
The mobs I said above don't do knockback in the current version(s).
However, this doesn't affect to Creeper/TNT explosions, as you still do knockback from it. And arrows from Skeletons/Strays will still bounce of the shield.
Code analysis
Code analysis by Maity & Fuzs can be found in this comment and this comment.
Issue still exists up to latest version, Minecraft 1.9.1-pre3.
I do not quiet understand the reason that was given by Marcono1234. It was working in 1.8 and prior versions, why does it only occur since the 1.9 snapshots? Clients are using an internal server since 1.3, so the issue should have appeared back then already, but it did not. So why now in 1.9?
Can confirm, too. I was testing out the XP and Gold Farm by Snocrash (https://www.youtube.com/watch?v=aBLEbJ9ozRA), it was really obvious there. Since 15w49a all the Zombie Pigmen walk very stutteringly, even up to 1.9.1-pre3. I have noticed that it has become a bit better, but the issue still is not solved. In 15w47c, any snapshot before and all of the 1.8 versions they were just walking smooth like butter.
Still a problem in 1.9.1-pre3.
Also still present in 1.9.2.
Still not fixed in 16w15a.
Still present in 1.9.3-pre2.
The issue is fixed. Not sure when exactly, but I wasn't able to reproduce it in 1.12. I ran a second test in 1.7.5 with the same world under the same circumstances and the game crashed as mentioned by the reporter. So really is about this issue.
Still an issue in 1.12, just saying...
Invalid ticket. Polar bears do spawn even after the initial world generation on grass blocks as intended. They are just 10 times as rare as rabbits. Tested in 1.12 with the given super flat preset.
Ticket is invalid. Parrot spawning works as intended, even after the initial world generation. They spawn on grass blocks as well as logs. Using a super flat world that only contains blocks in the first sub-chunk of every chunk helps a lot when testing mob spawning (no block higher than Y=15).
1.12 is affected
1.13 is affected
Still an issue in 1.13.
The cave and ravine generators (even in the overworld) have a max height value specified up to which they can remove blocks. For nether structures this is y=120 (y=248 for the overworld) and the cause of this bug.
This was probably added to prevent the generators from reaching the bedrock layer and possibly removing it, but since they are unable to remove bedrock blocks this isn't actually necessary, or at least it could be set to y=128.
This bug is actually a lot older when it comes to nether caves. I've tracked it back up to release 1.6 (from 2013), but it has probably been a thing since the introduction of nether caves in alpha 1.2.
Confirmed for 19w14b. Really hoping this is fixed soon since a lot of related bugs were taken care of very recently.
Issue of this ticket has been resolved perfectly.
About the "not able to scroll while sneaking issue": This is not related to sneaking, but to pressing any shift button. And it only occurs when scrolling using a mouse wheel, not when using a trackpad though.
Since I just stumbled across the code responsible for this bug anyways, here is a quick analysis. MCP mappings in use are 20200225-1.15.1.
This issue stems from introducing the ravager entity with its special behaviour towards shields into the game.
Where does this bug occur?
When a LivingEntity (defender) successfully blocks an attack by another LivingEntity (attacker) using a shield, LivingEntity::blockUsingShield is called for the defender, taking the attacker as a single argument for it to be knocked back.
Before Minecraft 1.14 LivingEntity::blockUsingShield would directly call LivingEntity::knockBack on the attacker, passing on the defender as the argument.
Now LivingEntity::blockUsingShield calls a new method, LivingEntity::constructKnockBackVector on the attacker, providing the defender as the argument. This method does exactly what LivingEntity::blockUsingShield did previously, so this is where the problem comes from: Defender and attacker are switched twice. In the end LivingEntity::knockBack is called on the defender when it should be called on the attacker.
(Why is the defender not knocked back in game now? Not relevant here, basically there's another call to LivingEntity::knockBack later and both cancel each other out. The second call won't be a problem when this bug is fixed, it's always been there.)
Why was this split made in the first place?
As mentioned ravager entities behave special when it comes to shields. This is achieved by overwriting the new LivingEntity::constructKnockBackVector method in RavagerEntity. The overwritten method expects both entities to be switched, therefor it behaves as intended.
How to fix?
Simply switch defender and attacker in LivingEntity::constructKnockBackVector, meaning
turns into
.
Note that LivingEntity::constructKnockBackVector is used nowhere else, so there won't be any side effects.
Yeah this would be a great opportunity for turning Enchantment::isTreasureOnly, Enchantment::isCurse, Enchantment::isTradeable, and Enchantment::isDiscoverable into enchantment tags (with the behavior of the latter two ideally being inverted functionality wise).