Info

• Server version: 1.11.2-R0.1-SNAPSHOT
• OldCombatMechanics version: Newest (1.6.5)
• Server log file: There are no any errors here :/
• OldCombatMechanics config file: https://pastebin.com/kxm4mMsY

Hi,
i have problem with strength armor. With enabled: false, leather armor still changed by this values:
old-armour-strength:

This is to set armour strength values as in pre-1.9

enabled: false
worlds: [world]

The higher the armour toughness value the closer the damage done while wearing armour is to pre-1.9 values

toughness: 9999

This is to change the armour strength values if you so wish

strength:

Leather armour

LEATHER_HELMET: 3
LEATHER_CHESTPLATE: 8
LEATHER_LEGGINGS: 6
LEATHER_BOOTS: 3

So i need to repair enable: false "Old-armour-strength" mechanics. Because "false" value still work and it changes armor stats ingame (for example with enabled: false, it changes leather armor to values in config) Our armours are with custom stats and this mechanic make trouble.
Thank you very much ! :)

I am not quite sure what you mean.
Do you mean that OCM overwrote your custom Leather Armour and you want to undo that?
Do you mean that OCM shouldn't modify armour that has custom tags?

I mean OCM shouldn't modify any armour when "enabled: false". Is it possible ? :) But maybe this "Do you mean that OCM shouldn't modify armour that has custom tags" should be too good :)

double toughness = enable ? Config.getConfig().getDouble("old-armour-strength.toughness") : getDefaultToughness(is.getType());

It seems to apply the defaults when disabled. Interesting, that looks like it was deliberately added here in order to reset the armour strength to the default values. If you remove that feature the armour will keep its modified values even after it was disabled.

Sadly, as the user can enter anything in the config, there is likely no reliable way to check if you are reverting changes OCM made or if you are overwriting deliberate changes made by the user or another plugin. As a consequence "not modifying armour that has custom tags" is probably impossible.

What OCM could do is keep track of all the armour it edited (custom NBT values would be a nice way) to only reset those when the feature gets disabled. This wouldn't play amazingly well with already changed items, but that is to be expected and likely not a big deal as you can not retroactively reset them anyways.

I don't know if @rayzr522 or gvlfm78 (not tagging him as he seems busy) have any other neat ideas but that would be my two cents.

Easier alternative would be to default this option to false so that the user has to enable it and then just add a comment that reverting may not work on armor already altered. That would be the quickest temp fix until a bigger solution could be rolled out (if one would be needed).

Having said that, I switched back and forth a couple of times on 1.12.2 and did not seem to have this issue.

I would like to leave that decision to Rayzr or gvlfm, as I am not a maintainer of this project.

If you need a quick fix, I'd be happy to make a fixed version for you (probably with the toggle as you said) until they come to a decision.

We have a system for "marking" items with NBT, and I could probably just apply that to this. However, I could've sworn we already checked for only marked items... I'll have to look through the logic again.

I'm aware this is probably the most broken of all systems, but the sad truth is that we simply can't fix the biggest problem with it: you can't just iterate through every itemstack in the server to fix armor values. So then you end up with borked armor values it items are not equipped during an OCM config change.

Sounds like the only proper solution is this (though it may break for items that are already modified by OCM from older versions):

1. Check if the item has a certain NBT marking that identifies it as a piece of armor which is being modified by OCM.
2. If the marking is not present, but the armor already has some custom attributes, then exit the method. This most likely means the attributes are being handled by a non-OCM source.
3. Otherwise, add the NBT marking to the item and apply the proper armor values.

This way it should never modify a piece of armor with custom attribute data unless it is marked as being handled by OCM.

Alright, looks like this should be all patched up (1ba5095). Please try the latest dev build and let me know if OCM is still messing up your custom items. It should now have less conflicts with 3rd party plugins :D

Thank you very much, i will try it soon as possible :)) very nice support!

@revkilleri did this build fix your problem?

Awesome. I'll close this issue now.

Yes! :) My problem was fixed! Thank you very much!