Protection enchantment nerf #274
ACGaming
started this conversation in
Tweak Suggestions
Replies: 1 comment
-
Haiku here. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
From abadhaiku (https://discord.com/channels/932680710815350834/1091539781722320916/1145409281185820784):
Ok looks like it sums those values up to a max of 20, which is then divided by 25, for a max of 75% damage reduction. If you want to tweak those values more effectively, you need to do the following:
n
to increase the precision by,25.0f
and20.0F
innet.minecraft.util.CombatRules#getDamageAfterMagicAbsorb
by your scale,EnchantmentProtection#calcModifierDamage
and apply your changes to the vanilla values, andnet.minecraft.enchantment.EnchantmentHelper.ModifierDamage#calculateModifier > calcModiferDamage
to multiply it by the scale if the enchantment isn‘t vanilla protection, so the total percentage stays the same for protection enchantments that don‘t use the modifiable enchantment API you‘re creatingidk why they implemented it the way they did. enchantmenthelper is queued to use floats, but the protection values use int.
honestly it might even be easier to just overwrite the method and use your own protection implementation with
float
values.I remember something on the Mixin wiki about the JVM allowing methods that otherwise have the same signature but have different return values. I wonder if you could migrate the
ModifierDamage.damageModifer
type tofloat
instead ofint
and changeEnchantmentProtection#calcModiferDamage
to return afloat
too, since the calculation inModifierDamage#calculateModifier
uses a+
operator which works with any primitive number type.Might just be easier to just inject your own implementation into
EntityLivingBase
and make it read non-vanilla enchantments normallyBeta Was this translation helpful? Give feedback.
All reactions