The Meaning of Life, the Universe, and Everything.
In order to fix a major bug in the enchanting table, they are reverting all changes to the enchanting system. A more permanent fix will hopefully be included in 1.15, the protection changes may come back then.
Interesting, hopefully 1.15 has some good patches and I really hope that this time around it's tested a bit more to have less issues. Every new release we find has major lag issues which requires an extra two patches to make the game more playable. 1.13 and 1.14 had these issues.
Yeah, there've actually been a Fair-bit of changes, already to Villagers' and Illagers' behavior - Behavior? a lot of it, being (re- , in the Villagers' case )Changed. (Since the full Update-released) As for Armor, yeah, I couldn't even believe they'd keep it that way - just like Crossbows, some'd been all-but fearful [F] outright before - on the edge of: "oh, no! It's New!! runn!1!1!" ; which I still barely-use (well, don't yet) Months-in.
Perhaps the Villagers'll even Trade them..? you never know, could happen in a future Update... Trade - (to) us - Emeralds, for (our unwanted) Enchanted /regular Armor (no wait, they're all-about Getting-Emeralds, other than Diamonds-specifically - and except the "Nitwits" /sometime-"Unemployed" - which're already-Green or else "Undecided"). But "testing more, less issues" of course doesn't sound as interesting as "whole New, Armor, 'without "Cheat(ing)(s)"' !"
While the ability to combine protection types may have been reverted as part of removingthe new buggy changes to 1.14 enchanting, it is to be hoped the MS/Mj will see sense and keep these out.
[Among other issues, MS/Mj still appear to be hostile to farming and industrial scale trading both of which are helpful in acquiring the 1.14.0 'god-armor'; adding to the game a system that encourages the use of features one is otherwise attempting to DIScourage would seem to indicate poor planning.]
From a player perspective, the choice of protections represents a way (although a comparatively small one) in which to 'customize' one's 'character'.
Also, and particularly from the perspective of the lobbyists for various 'super-hardcore' modes, avoiding the ability to max out all the various protection factors simultaneously retains a bit of challenge without needing another tier of hostile mob opponents.
Rollback Post to RevisionRollBack
WARNING: I have an extemely "grindy" playstyle; YMMV — if this doesn't seem fun to you, mine what you can from it & bin the rest.
Anyone else remember when Infinity and Mending could both be put on the same bow? Then they changed it so they couldn't be stacked any more, even with books or merging in an anvil. Some of us kept playing for a while on old worlds where we had several such bows pre-made and they continued to work, but we couldn't make more to replace them if they were lost. I expect the armor change will be much the same, so for a while at least those of us continuing to play the same world at least won't lose the God Armor we've already made, and unless we play in Snapshots we've got a bit of warning to go grab a bunch of books and an anvil or two and head for our XP grinder.
Rollback Post to RevisionRollBack
"I think I'm starting to like this `programming' thing. It's about four times as fun as shaving." -- Notch, June 12, 2011
Formerly Known In-Game As Spectrumwars
Co-Host <*> Back2Babylon5 Podcast <*> Coming in Feb 2018!
I don't see why they had to revert this just because of the issues with the enchantment table, which is entirely separate from whether enchantments are mutually exclusive:
* Defines the type of protection of the enchantment, 0 = all, 1 = fire, 2 = fall (feather fall),
* 3 = explosion and 4 = projectile.
public final int protectionType;
* Determines if the enchantment passed can be applyied together with this enchantment.
public boolean canApplyTogether(Enchantment par1Enchantment)
if (par1Enchantment instanceof EnchantmentProtection)
EnchantmentProtection var2 = (EnchantmentProtection)par1Enchantment;
return var2.protectionType == this.protectionType ? false : this.protectionType == 2 || var2.protectionType == 2;
All Mojang did in 1.14 was change the bit of code that checks for "protectionType", which in this case (from 1.6.4) excludes itself and anything other than Feather Falling (type 2); the enchantment table code does call this but only to prevent incompatible enchantments from being applied (or duplicates of the same enchantment), while the calculations that choose enchantments are completely separate.
Also, I don't buy their reasoning for changing the enchantment table in the first place; they made some claim about making high-level enchantments most likely at level 30 instead of 26 but I see no evidence of this in online enchantment calculators, which all show enchantments peaking at level 30 (indeed, some enchantments never reach their maximum level, hence why you can't get enchantments like Sharpness V. Some, like Knockback, do reach a point where you can only get one level before level 30 but the probability of getting it still increases, and otherwise you'd only have to adjust their individual "enchantability" factors, and either way most players will just enchant at level 30):
As with mutually exclusive enchantments, the "enchantability" required to get an enchantment is also separate from the main enchantment table calculations; they can increase the transition between Knockback I and Knockback II by lowering the minimum enchantability and increasing the difference between the minimum and maximum (so the chance of getting Knockback II begins rising at a lower level but doesn't reach the maximum until level 30, or maybe even a bit past it, at least for diamond with gold reaching it at level 30):
* Returns the minimal value of enchantability needed on the enchantment level passed.
public int getMinEnchantability(int par1)
return 5 + 20 * (par1 - 1);
* Returns the maximum value of enchantability nedded on the enchantment level passed.
public int getMaxEnchantability(int par1)
return super.getMinEnchantability(par1) + 50;
* Returns the maximum level that the enchantment can have.
public int getMaxLevel()