Steve W
- SomeOtherSteve
- JIRAUSER715372
- America/New_York
- Yes
- No
MC-36937
This report only describes that an enchantment is shown which is not available. See MC-30730, which describes the general behavior that an enchantment table may provide less than three enchantments.
The bug
When enchanting fishing rods, you are not able to apply low level enchants; the bug here is that these enchants still appear as if they could be selected. They should be greyed out.
See attached image
: The first slot, which the mouse is hovering over, does not display any promised enchant in the tooltip and clicking it does nothing, yet it's not greyed out like the middle slot.
Example
Here is an example in video: Unavailable enchants are not greyed out (fishing rod).mp4
Bug analysis
Steve W has done a detailed analysis of when the bug occurs and possible solutions in this comment.
Code analysis
The following is based on decompiled version of Minecraft 1.9 using MCP 9.24 beta. All method and class names are the names used in the decompiled version.
The reason why this happens is because the enchantment level returned by the method net.minecraft.enchantment.EnchantmentHelper.calcItemStackEnchantability(Random, int, int, ItemStack) is used. This method always returns at least 1 for the first enchantment (0 meaning no enchantment available). I am not sure if this can be fixed in this method, however what can be done is having the method net.minecraft.inventory.ContainerEnchantment.onCraftMatrixChanged(IInventory) set 0 as enchantment level if no enchantments are available.
This might not be the best solution and is only a suggestion.
After confirming that this bug still exists in 1.18.1, I investigated and discovered what was happening:
TL;DR For Fishing Rods specifically, it is possible for the enchanting table to be in a state where it has a required XP level but no enchantments.
When generating enchantments, first a required XP level is randomly generated based on bookshelf count and player enchantment seed, then a modified level is generated from that XP level for gathering possible enchantments. See this page for info on what modified levels can get you what enchantment levels (the page says that the data is from 1.14.4, but the relevant Fishing Rod enchantments are still correct for 1.18.1).
The bug occurs when the required XP level is more than 0 but the modified level is not enough to reach the above mentioned enchantment levels, leaving the enchanting table without any enchantments. This bug affects Fishing Rods specifically because they have no enchantments that can apply below a modified level of 5 (the cutoff for Unbreaking I), whereas all other enchantable items have at least one enchantment with a minimum level of 1.
To test this, I made a Fabric mod to show enchanting table info in the GUI. As can be seen in three of the four attached pictures, the required XP level is more than 0, but no enchantments are generated (shown as "-1 -1"). Even with 15 bookshelves, bad enough RNG rolls can give you a required XP level as low as 2 or 3 (both of which have this issue every time). A required XP level of 4 will usually generate an enchantment (always Unbreaking I), but it can also have this issue depending on the exact RNG rolls.
The GUI mostly doesn't check for this inconsistency between having a required XP level yet no enchantment. The only place it does check is when rendering tooltips for the enchantment hint.
Possible fixes (either or both can be implemented):
1. Lower the minimum modified enchantment level for either Fishing Rod enchantment to 1 (Lure would be the more likely candidate for this as Luck of the Sea uses the same Java class as Fortune).
2. Reset the required XP level to 0 for that slot if no enchantments are generated.
This bug affects 1.18.1 as well.
When a Minecart is moving on a Powered Rail, one of the final checks it does is to see if it will bounce off of a wall. The function it uses for this check will let the Minecart bounce off if the block in question is considered a "solid block." For most blocks, there are two requirements to be a solid block:
However, a block can be explicitly set not to be considered solid even if it otherwise meets the above requirements. Blocks set this way include:
Glass and Beacons already fail the first check of blocking light. I assume that the rest were made non-solid for use in redstone contraptions. There are also a couple of odd blocks out:
Possible fix: Modify the Minecart bounce-off check to work with full cube blocks. Replacing the check outright might make Soul Sand no longer work as it is hardcoded as solid and is not a full cube.
Possible cause: In the TNT entity's explode() function, the Y-coordinate of the explosion is calculated as 0.0625 x the entity's height. Since the TNT entity is 0.98 blocks tall, this puts the Y-coordinate at 0.06125, inside the gap in these blocks and outside of the water. I assume that the slightly smaller hitbox was done to allow TNT to fit down 1 block wide dropshafts easily.
Possible fix: Increase the Y-coordinate multiplier enough to push the result to be more than 0.0625. This will need testing to determine how the change will affect TNT explosions.