If we are at it. Please also the same for Electrolyzer Target Storageblocks, like the isTeleporterCompatible, but for the Electrolyzer.
And here its with a few better Parameters:
addElectrolyzerRecipe(ItemStack aInput, ItemStack aOutput, int aEnergyCost, boolean aReversedSlots)
aReversedSlots just says, that it goes form the Outputside to the Inputside, as your Direction is not really needed if you can simply add another Recipe for doing the same thing.
the point of using an int instead of a boolean is for conciseness
The reverse Recipe has another EU-Cost than the original one, so you need to seperatly add the reverse Edition anyways.
different item id's is obsolete since NBT implementation.
it shoud register:
itemstack usable
method ontick
method oncomplete
Method registration will allow to do anything, not only templates predefined inside API.
different item id's is obsolete since NBT implementation.
it shoud register:
itemstack usable
method ontick
method oncomplete
Method registration will allow to do anything, not only templates predefined inside API.
Then every Item has to implement that Interface, and what is if the Item is of another Mod or Vanilla-MC? And you should really work on your understandability. I almost didnt get what you wanted to say.
every Item registered as iElectrolizable shoud implement iElectrolizable interface, pretty obvious.
entire implementation of methods shoud be included inside item specific class.
this already done for reactor components.
every Item registered as iElectrolizable shoud implement iElectrolizable interface, pretty obvious.
entire implementation of methods shoud be included inside item specific class.
this already done for reactor components.
Again, what do you do if the Item is not accessible (IC² or part of vanilla)? I dont want to have to make a special electrolyzable Item for every single Case, and if I have MetaValue based Items, then this Interface would be complete fail at all the non-Electrolyzable Items.
