Not technically an "issue". And I also understand that the EMC code is far from finished.

==Summary==
Instead of specifying the total cost, and then specifying a map of percentages for types, that gets compounded by a percentage (applied to all types) for recovery.
Specify two maps, one for cost (EMC cost for 'buying' this) and one for sale (EMC received
for 'selling' this).

==The full verbal onslaught==
In EMCEntry (The EMC data for an object) the EMC cost is defined as: cost + breakdown (map for percentages) + recoveryPercentage.

Wouldn't it be better to specify two Map<EMCType, Float> variables, namely: Cost + Recovery.
That way you can specify the breakdown and cost per EMC type with more control.

totalCost (what you pay to 'buy' it) is then a function, summing all Cost values. And total value (what you get when you 'sell' it) is similarly a function to sum all Recovery values.

To use OMNI instead of a specific type(s), you then just check if the player has more OMNI than the value returned by the totalCost function.

==An Example==
You can make this for 1000 Essentia, and 500 Void, but you only get 900 Essentia and 0 Void back.
Or you can specify this can be made with 1000 Omni, but actually breaks down into 250 Essentia, 500 Void, and 250 Kinetic.

Currently, specifying 0.9f for recoveryPercentage would give back 900 Essentia and 450 Void.

Also, it would currently take more thinking in the above example to figure out that cost should be 1500, and the factors 0.66 and 0.33 to get 1000 Essentia and 500 Void cost.
And then apply another factor for recovery rates.

==Code==
Something like:
/**
* learnable = Can the user learn to make this?
* recoverable = Can this be converted into EMC?
*
* cost = How much of each EMC type must be paid to make this object.
* recovery = How much of each EMC type will you get if you break this down.
*/
private Map < EMCType, Float> cost;
private Map < EMCType, Float> recovery;
private boolean learnable, recoverable;

I could, if you want, attempt to code the change (with new functions, class constructors and tie-ins to other classes and code) and then submit a pull request.

Wouldn't it be better to just specify the return instead of precentages? Would be easier to just use simple numbers while programming. :)

Restructured some things, simplifies it a lot now.

Not a bad idea, let me stew on it a bit to make sure it melds (or enchances) ideas I already have for this. :)

Cool.
Just trying to help. :)

Wow I wish I thought of that. not bad. +1 from me.

something bi-directional is needed, because without that all reversible recipes must have emc exactly equal emc out, for all recipes ...

eg atm sawmill makes 6 planks from a log, but the normal (reversable w/ transmute) recipie is 4 -- that implies 2/6 loss efficiency, and could be automatically calculated from the set of available recipes ...

parse all recipes to make something; max resources needed is x, min is y; y is the cost, but breakdown inefficiency is (x-y)/y