The minium stone loses its EMC value After opening the its pocket crafting table

It's probably because once the GUI is opened the item stack is given a NBTTagCompound
But the ItemStack used to register the minim stone didn't have one.

I hope this gets a fix soon because I have many items in my mods that have NBT but I'd like them all to have the same EMC (in other words... just ignore their NBT data completely when assigning them values)

The solution I have in mind is that if the item being checked for an EMC value has an NBT, it checks first for an entry for that item with it's NBT. If it can't find anything, it should check for an EmcValue for that item WITHOUT the stack.

Thoughts?

A nice way to fix this would be with an interface IEMCValueContainer (or something like that, I'm terrible at naming) that would have a method "float getEMCValue(ItemStack itemStack)". The EMC for that stack would be gathered from that method instead of the registry which would allow for specific items to manipulate their values with a bit more flexibility

What do you think @pahimar ?

That is also a good solution.
But the interface would be nice for other situations as well I think :)

Yes, I also see the need for allowing mods to specifying values for an item in a context sensitive way (ie, you want to set the EmcValue for the item at full durability, and then control the value as it's durability changes)

I'll have to think of a nice way to do that - I'm still trying to avoid having API files that people require and an interface would seal the deal on that one

Giving it a quick thought... came up with these solutions, maybe they'll inspire you to do something better:

1- You could determine a tag name that would contain the EMC value. So any mod authors could set EMC values by simply manipulating the NBT compound.
When searching for the EMC value it would look-up on the NTB and if it has a tag with that name it gets the value from there. Probably not the best solution though...

2- You could allow mods to send a static method (that would take an ItemStack as a parameter) name via IMC. EE3 would keep those methods in a registry, and call them whenever searching for an EMC value. It's a bit hacky, and I don't know if it would be efficient, but it would work and would require no API

I might just have to have the interface and suck it up - oh well!

Sounds fine to me! 😄

just for argument sack can you think of a more complex test case?

(this is just so pahimar can avoid the API depends)

Well if you take into account NBT tags, anything is possible since you don't know what information will go in there and what that information means.

Thaumcraft for example... the essitia inside the phials are determined by NBT. Azanor might want to give different values to each essentia.
Still on the Thaumcraft example... the wands charge is also NBT, the EMC could be increased based on how much charge the wand has. That's also something EE3 can't do on its own.

Tinker's Construct tools... the parts that compose a tool are all store in NBT.

There's your example which is also valid.

The examples are endless really... That's why I like the API idea. Giving the modders the ability to control what the EMC value of their items is would be a nice thing.

My suggestion would use a text file that the mod author would provide, so they have full control over the EMC values based on NBT data.

I'm not seeing an advantage to the API with regards to NBT sensitivity, only possibility I can think of is world time, or current dimension

Text files would be overcomplicating a simple problem. Not to mention the author would have to write on that file every single possibility for every single item....
You'd have to end up providing an API anyway otherwise you can't ensure that the files will all be created on the same standard, and those text files could get potentially huge, increasing the loading time unnecessarily.

And apart from that, where would those text files be saved? How are you going to make sure they won't be messed with by the user?

A simple interface with a method that has the item stack as a parameter and returns the dmc value (as I described on my second post) would resolve the problem. The mod authors would have absolute control over the value.

Could there be a way to add ranked match system where a mod can specify in a config a preferred order of matches and then use fuzzy NBT Tag equals logic (example available) to walk down the ranks for a given Item?

for example

EsscenceBucket NBT(Fill:100,LiquidType: water) = 50
EsscenceBucket NBT(Fill:100,LiquidType: lava) = 100
EsscenceBucket NBT(Fill:100,LiquidType: LiquidEsscence) =500
EsscenceBucket NBT(Fill:100) = 50
EsscenceBucket = 1

To be evaluated in order so the esscence buct filled with any un recognized liquid will have a value of 50 but will have a higher value if filled with esscence

It would be up to the mod author to ensure the order is specified correctly

That sounds like a very specific condition.I think the best solution to it would be the API.

very valid points

With the addition of https://github.com/pahimar/Equivalent-Exchange-3/blob/master/src/main/java/com/pahimar/ee3/api/IEnergyValueProvider.java this should be resolved