Zungry Ware
- ZungryWare
- JIRAUSER507604
- America/Los_Angeles
- Yes
- No
MC-190276
Unbreaking does not prevent deterioration caused by Soul Speed enchantment by amount expected.
Damage to the durability of boots caused by running on Soul Sand is not prevented by the Unbreaking enchantment at the expected rate of 75% for an Unbreaking III enchantment.
Reproduced by running along a long strip of Soul Sand with two different pairs of boots. One with Unbreaking III and Soul Speed III and one with just Soul Speed III. Then checking the durability of each.
Expected Behavior is that Unbreaking III would prevent damage caused to boots by walking on Soul Sand/Soil by about 75%. But they take about the same amount of damage.
This results in Netherite Boots with Soul Speed only lasting about 45 minutes.
Damage to the durability of boots caused by running on Soul Sand is not prevented by the Unbreaking enchantment at the expected rate of 75% for an Unbreaking III enchantment.
Reproduced by running along a 350-block-long strip of Soul Sand with two different pairs of boots. One with Unbreaking III and Soul Speed III and one with just Soul Speed III. Then checking the durability of each. Tested three times and each trial resulted in both pairs of boots being within three durability points of each other.
Expected Behavior is that Unbreaking III would prevent damage caused to boots by walking on Soul Sand/Soil by about 75%. But they take about the same amount of damage.
This results in Netherite Boots with Soul Speed only lasting about 45 minutes.
Damage to the durability of boots caused by running on Soul Sand is not prevented by the Unbreaking enchantment at the expected rate of 75% for an Unbreaking III enchantment.
Reproduced by running along a 350-block-long strip of Soul Sand with two different pairs of boots. One with Unbreaking III and Soul Speed III and one with just Soul Speed III. Then checking the durability of each. Tested three times and each trial resulted in both pairs of boots being within three durability points of each other.
Expected Behavior is that Unbreaking III would prevent damage caused to boots by walking on Soul Sand/Soil by about 75%. But they take about the same amount of damage, rather than the one without Unbreaking taking four times as much damage as the other.
This results in Netherite Boots with Soul Speed only lasting about 45 minutes.
When you unlock a new advancement tab (by completing any advancement on that page), the new tab is placed next in the list of tabs, putting the tabs in the order you unlocked them. However, whenever you reload the world (either via the /reload command or by quitting and reopening the world), the tabs get reordered into a completely arbitrary, but more or less consistent, order. Each time you reload, the order will be the same, but the order doesn't seem to be based on any information from the root.json files. It is not ordered alphabetically (by folder name or by display name), by date created, by number of advancements under the tab, by alphabetical order of the advancements under the tab, by alphabetical order of tab icon item names, by creative menu order of tab icon items,
by creation time of root.json file,or by the background image. I cannot find any rhyme or reason to the ordering I get. (The ordering I get for the default tabs is Nether, Adventure, End, Husbandry, Story.)Side note, I created a datapack on that world with a single root advancement included in it, and that advancement tab ended up between the Nether and Adventure tabs, rather than at the end like I was expecting.
Also, while this is purely circumstantial, I looked up some screenshots of the advancement menu from other players, and the screenshots all had different tab orderings. This could be because they had all just unlocked the tabs and hadn't reloaded their games, but I find that very unlikely.
What I expect to happen: For the tabs to either be permanently sorted by the order you unlock them, to be sorted alphabetically, or to have a key in the root.json file that lets the datapack maker decide a priority value.
When a purpur pillar is placed with [axis=x], the north-facing side of the texture is oriented in a way that makes the shading look incorrect. (The same happens with [axis=y] and the west face.) The shading painted into minecraft's textures generally assumes that light is coming from above, so when the purpur pillar is placed next to a purpur block,
the shading looks incorrect.How to reproduce: place some sideways purpur pillars next to some purpur blocks and look at it from the north or west side to notice the difference.
Expected behavior: For the north and west side pillar textures to be rotated by 180 degrees.
When a purpur pillar is placed with [axis=x], the north-facing side of the texture is oriented in a way that makes the shading look incorrect. (The same happens with [axis=y] and the west face.) The shading painted into minecraft's textures generally assumes that light is coming from above, so when the purpur pillar is placed next to a purpur block, it looks like light is coming from above on the purpur block and from below on the purpur pillar.
How to reproduce: place some sideways purpur pillars next to some purpur blocks and look at it from the north or west side to notice the difference.
Expected behavior: For the north and west side pillar textures to be rotated by 180 degrees.
Mending affects one item at random and only items in your main hand, off hand, or armor slots. So what might have happened is that you were not holding the item when you collected xp. And if you were, it might have gone to your armor or shield instead.
This is still in 1.16.3
Going between (custom) dimensions hides the xp amount until xp changes or the player relogs.
Still affects 1.16.5
The inability to have the option to synchronously load chunks completely
breaksdestroys tons of datapacks. Async loading would ordinarily be a good idea, but programming languages with async functionality usually have a callback function so you don't have to continuously poll to see if the task completed. What this change does is guarantee the majority of datapack makers' time will be spent ensuring their datapack doesn't run into race conditions every single time they want to interact with the world in any meaningful way. The /forceload command isn't even accurate anymore. It should be called /pleaseloadifyoufeellikeitsometimemaybe.Confirmed for 1.17.1