Ahem, if i write a recipe-reading code capable of calculating costs based on recipes, why don't i just use same one for the basic IC recipes as well? Redundancy much.
Wouldn't work, however, because any sort of refillable item would instantly cause a lockup.
Yep, but that honestly wouldn't be much of a problem. For example, if you use BC to pump items into the top a generator, they just have to be extracted from the generator. So if anyone has a problem with that, then...
I picture this more as a copy machine that just needs an item to be copied placed in one slot. Then UUM in another slot, and a final slot for the copied item (And maybe one for paper, just to be silly). Attach a button and it will copy the item once per button press. Put a switch and it will just keep going until it runs out of UUM.
As for item cost of UUM, the complex way is to analyze the recepies for the amount and rarity of their base components. This would work for if there are other mods installed. I might suggest having it check when Minecraft loads for any new mods added. If it detects a new mod, then it would check the recipies. It would store the cost in UUM in a file that could be read each time after that. Like assigning the block ID of an item the UUM value required. I figure that would make it load relatively faster after the first time loading a mod. A problem arises for materials that are added by other mods, because their rarity needs to be discovered.
The other way set it up is to assign general values for different items. Any items from other mods would require the mod owners to assign the item a value themselves. If an item is not assigned a value, then the machine will not copy it. So pretty much only the IC2 items would work with it at first, but those are the main ones that give me trouble with the BC automatic table due to not stacking some items.
Thank you for taking the time to consider my suggestions, I hope they are helpful.
I don't see your refillable item lockup case; refillable items only get more full; it might branch out a bit finding the cheapest cost, but at worst it's just a large number of paths that all have endpoints. Caching the cost at each recipe would also help a lot in these cases (and calculating the set before hand implicitly does that).
The idea is that iterating over a potentially vast number of recipes (such as the ones RP2 adds for block manipulations) may be excessively time consuming.
Scanning all the recipes only has to take action on minecrafts startup or if you enter a world/start a server.
Also there are not that much recipes in minecraft, even not with RedPower 2 + (BTW + BC2 + other mods), so the runtime for that script should be rather short. (below one second)
It's less a performance issue than a balance and programming issue, because:
there are other problems.
how do you prevent endless loops in this script.
something like 9 copper -> copper block -> 9 copper -> copper block
if you do that often enough your MC crashes/freezes -> Stack overflow
A common problem in recursive algorithms.
also, there are variable EU costs in smelting, for example. (induction furnace)
so which one to use?
the lowest?
but an I-Furnace needs EU's to heat up and you can't calculate them by just following recipe trees.
The only way to solve this would be to add a multiplier, which adds about 10% to the final cost.
This would also balance the machine, since it's very overpowered to just bypass all construction effort you actually put in said items.
Using a reference item, btw, should be better. Every machine needs at least a "blueprint". A dropdown list sounds kinda OP, too.
That would balance it even more.
That's it with my brainjuice...
Yep, but that honestly wouldn't be much of a problem. For example, if you use BC to pump items into the top a generator, they just have to be extracted from the generator. So if anyone has a problem with that, then...
I think Alb was talking about items with a recursion loop mechanic. For example, you can macerate ingots back to dust, and then heat it up to get the ingots back. In code, the "backwards" cost of an ingot would get stuck in an endless loop trying to negotiate the cost. There aren't many items that have recursions, and this was the most basic....but others include almost ALL of RP2 (especially the panels and subblocks).
However, EE already contains a "cost" of materials, so why not do the following:
1. Create a database with API hooks so that items could be added to the list (with an associated cost) and can be retrieved at any time
2. Ask Eloraam/SpaceToad to include it into Forge
3. Use it, and any items not in the list, cannot be a "valid" target for UU creation (maybe have a green/red light to show acceptance). So it leaves it up to the mod developers to add their items to the price list (which also relieves the burden on IC2 of checking if specific other mods are installed).
Also, when putting UUM into the "input" slot, the machine should accept it as added energy directly (the amount required to make UUM in the first place). Although UUM is not required (the machine _is_ creating matter), it helps in the same manner scrap does in a normal fab. However, this now makes this machine idea a Mass Copier....but I think it's one of the turned down machine ideas, can't remember.
The item pricing database could be general enough to allow mods that already have a pricing guide institute it without wasting memory on duplicate listings (Tale of Kingdoms and EqEx for example already do item prices). If created, there should be a cfg file so that the prices of the vMC items can be located and altered if player/admin feels the need to. Obviously there would be a conversion multiplier between the price of an item and the EU cost to fabricate it, but I figured it didn't need to be said...prices should just be basic values.
However, EE already contains a "cost" of materials, so why not do the following.
Just as long as you're not advocating actually using EE's "prices"... Honestly, they're ridiculous. It's one thing to turn 64 coal, 8 flint and 4 clay into a diamond (via a process that requires at least 4 steps and the requisite energy), it's another thing to trade in cobble for diamonds.
Personally, I don't use EE for that very reason. With all the cobble I get from a quarry, I'd be living in a house made of diamond blocks. At that point, I might as well just use TMI instead.
I like 
