In newest IC2 mod LZH condensators does not use "damage", they use nbt tag advDmg instead
So fuzzy upgrade cannot extract them correctly
Please make this upgrade compatible, or at least make settings to do so, there is no more nuclear automatization now

• Minecraft Version: 1.12.2
• AE2 Version: rv5-stable-5
• Forge Version: 14.23.1.2604
• IC2: 2.8.45-ex112

Sorry, but no. Damage is a vanilla core feature and if some mod decide to avoid it, it is their decision. But there will not be any special handling for them.

Its like half of the world decided to use cryptocurrency and you will not even look at it. Ok, fine.

So what I'm trying to do now is recompile Applied-Energistics-2-rv5-1.12 with this fix, as I understand I need to rewrite src\main\java\appeng\util\item\AESharedItemStack.java, functions getLowerBound and getUpperBound, am I right?
I dont want to publish this editing, so I decided it would be easier to rewrite code itself then override it somehow.

because "real" money is the default, ask IC2 back why they don't implement the vanilla damage system then :)
other mods use internal damage system and project it on the vanilla system so otehr mods can deal with it like a vanilla item without bothering about compat modules

You know what the most funny thing is?
You have to add just few lines of code, because you already using getDurabilityForDisplay() function, that IC2 is overriding, you just need to alter getItem().isDamageable() check (it is for ImportBus, for ExportBus you have to add similar getDurabilityForDisplay-try combination)
2 files to alter, and you can get compatibility with not only lzh/rzh reactor condensators, but all ic2 items, like armor and everything...

The reason why IC2 isn't using the vanilla damage system is because our damage can exceed the range of a short. ItemStacks only save the lower 16 bit of the damage (see ItemStack.writeToNBT()), a ItemStack exceeding that damage is also considered to be empty (see ItemStack.isEmpty()). We only use our own damage system for items, that might exceed that short value range.
That being said, there are blocks in IC2 that do exactly what you atre looking for. The reactor coolant injectors allow you to recharge condensers in reactors. You'd only have to keep enough lapis/redstone in them.

Ok, I will try to use those, but for the reference - it CAN be fixed in AE2 as I show in this video:
https://youtu.be/VB0lgmBu0pI
I have altered only
src\main\java\appeng\util\item\AESharedItemStack.java
src\main\java\appeng\util\item\AEItemStack.java
(both for export to work, getItemDamage, setItemDamage, getMaxDamage override)
src\main\java\appeng\util\helpers\ItemComparisonHelper.java
(for import to work, isDamageable in line that starts with if( a.getItem() != Items.AIR && b.getItem() != Items.AIR &&... override)

That is plain wrong.

Item damage is backed by a full int. Which gives plenty of room to use. With Integer.MAX_VALUE being practically infinite, even when using 1 durability each tick it would least nearly 70 years. But even if you had to exceed an int, it would be perfectly fine to normalize it to an int range for external users.

However if you choose to truncate it to a short or use it incorrectly, then it will cause issues. But in no way is it the fault of minecraft.

And no there won't be any fix for this. Contrary I am actually reworking the current implementation as it actually handles it incorrectly around the threshold for 99%. Which should split into undamaged or damaged, but not undamaged or < 0.001% damaged and whatever remains.

no, the variable itself is an int, but it gets saved as a short (please look at the code I referenced in my previous post), so yes, if you want to exceed the short limits, you have to make damage yourself.

Still wrong. You feel for the common misconception that damage is the same as metadata. Which it simply is not. It is just coincidence (or convenience) that vanilla provides a default implementation for damage using metadata. And if you choose to back damage by something else, but only implement half of it, it is not our problem.

That's actually true. My bad. All of this will be resolved in 1.13 anyways, when metadata is gone...

It can already be resolved by overridding methods like Item#getDamage(), Item#getMaxDamage(), Item#setDamage(), Item#isDamaged() and so on. For us only the the first two are important and as long as they return something we can deal with it. But if they still point to metadata and only a few related methods are overridden for nbt based damaged, there is nothing we can do about it. And it will be necessary for 1.13 as you said.

In some cases we use Item#getDurabilityForDisplay() but that is plain wrong for our use case and will be removed.

i would like to know why Item#getDurabilityForDisplay() is wrong? i used this in conjunction with openmods and computercraft to build my own version of the wireless interface using the open mods computer googles because i could not read any other information about damaged items through the CC LUA API XD

The obvious one being ...forDisplay(). And it just waits for someone having the great idea of inverting it because it looks nicer.

The other one being that it is a normalized float, but we need a fixed point between completely undamaged or any damage. Currently it uses a threshold of 0.001 which basically means once an item has more than 1000 uses and depending on the usual float issues, it could considered damaged items as undamaged. Using the full range of a short it would need a threshold of 0.00003 or lower. Full int is like 4.65e-10. Don't even think about long or double internally,