I took my time and read through the whole thread for the TE status and somewhere in the middle of that thread was a discussion about a universal API for powerhandling.
While reading that I thought of an interessting and somewhat even more useful implementation of that and was going to post this when I would have read through the whole thread, but sadly that thread is closed by now.
So here is my idea:
There are some requirements for that API that I imagine would be needed:
- Provide a framework that you can implement/extend/customize as you wish.
- Don't force every registered ressource to work with everything else.
What this API would do is that:
- Every mod could register it's resources (not only Energy but also Fluids, Items and everything you could imagine)
- Every Block can implement a standardized (and ISided) attribute for showing that it accepts/provides a resource.
The process of registering would work as follows:
A mod registers a type of resource in a sort of tree of types as a subclass to another type with "RESSOURCE" as root and optionally a unit conversion method to the parent type.
It could register that a Ressource is convertable into or from another (needed to give a conversion function, when two mods create conversions between the same type, the mod which adds the type that it's converted to is prioritized)
Ressources that use the same type are considered "equal" and are freely exchangable,
Ressources with the same parent are considered "equivalent" and may be consumed as if they were equal.
Ressources that have a conversion method to another ressource advise a mod that implements a way to do this conversion on what that converson needs and which ratio would be ideal. This is optional but should be used.
Ideally Resources like "WATER" could be registered with multiple parents ("FLUID-COOLANT" & "FLUID-CARPENTER")
A example tree could look like this:
http://pastebin.com/Yq2tFRnF
This list would be automatically filled by the LiquidDictionary and OreDictionary (I don't where things like burn time in a furnace are registered) and there may be subtypes for items/fluids that exist but are not registered in that tree,
but I think it would be too much to register every item in the game automatically under "ITEMS".
The server should calculate all possible conversion methods that can be calculated through existing conversions in advance to save performance later on.
The use of this API is that any block could show what it needs or offers (a special subtype or something general as "ENERGY" or "ITEMS-FUEL")
and every other block that handles ressources in any way could know if it can provide/handle that and therefore this decides if those connect and transmit their resources.
Conduits/Pipes/Cables theoretically are handled the same es Consumers but there should be a way to prevent "equivalent" ressources to be changed into each other.
Use Cases:
Furnce registers: bottom: Input:"ITEMS-FUEL", top: Input:"ITEMS-BURNABLE", right: Output:"ITEMS"
SolidFueledBoiler registers: Input:"ITEMS-FUEL", "WATER"
ForestryCarpenter registers: Input: "ITEMS", "CARPENTER", "ENERGY" Output: "ITEMS"
StrlingEngine registers: Input:"ITEMS-FUEL", Output: "ENERGY-MECHANICAL"
EnergyConduits registers: Input: "ENERGY", Output: "ENERGY"
The intension here is that:
you could power for example:
- BC Machines with RotoryCraft power
- IC2 Machines with UE Power
- TE Machines with BC Power
- TE Machines with IC2 Power
BUT: you could not connect BC with IC2 cables/pipes.
you could easily (standardized) register types of ressources like Liquid Fuel.
you could easily implement new types of Conduits to connect to new types of Inventorys.
you could easily register Blocks that use Thaumcraft essentia or provide it.
you could easily set up blocks to filter what they accept.
FINALLY: The internal way of transporting a resource in a network of blocks who are programmed to become a network together could still work the same (TE Conduits form one giant tube, AE, etc...) but the interaction with machines and other mods would be easier.
I hope you can understand the Idea behind this post, and I hope Forge or even the MC-Modding API will implement something like this.