Recent developments and experiences brought me to the point where I think it might be possible to create a true pipe API that doesn't require you to compile against Core code.

The proposed API would consist of two primary classes: PipeDefinition and PipeBehavior.

PipeDefinition would be global similar to Block and Item, it would provide things like the unique tag, localized name, icon registration, pipe type, PipeBehavior object construction, etc...

PipeBehavior would be a glorified per pipe event handler object, it would catch PipeEvents as its primary purpose. PipeEvents would allow you to modify the behavior of the pipe in a loosely coupled manner, replacing the current IItemTravelingHook and IPipeTransportItemsHook interfaces as well as many Pipe methods. PipeBehavior would also be home to many of the current basic Pipe methods like getIcon, readNBT, writeNBT, activateBlock, etc....

Additionally, Pipe, PipeTransportItems, PipeTransportFluids, etc.. would become final classes in an effort to promote using the API (and requesting expansions to the API instead of hacking in easily broken workarounds).

TravelingItem would likely get an interface with the basic methods to allow easy interaction.

Buildcraft itself would as a design constraint be required to define pipes via the new API as well.

Would this be dependent on BuildCraft being installed?

sounds good, that way alot of mods would be able to add there own pipes to improve compatibility

@makerimages no buildcraft, no pipe, but you won't be required to compile against core code like now, increasing compatibility and decreasing complexity.

i think it would also decrease lagg as it doesn't has to load the basic code for each pipe multiple times over and over again

@AEnterprise uh....no, that statement doesn't make any sense.

@AEnterprise Not only does it not make sense, Java doesn't work like that.

@CovertJaguar I love the sound of this, and forcing the use of an API is something that should certainly be encouraged.

I think this has been fully implemented in 7.99.x, however I haven't done any addon testing yet to ensure that everything is possible with just the API

@asiekierka since I didn't catch you in IRC, I just want to comment on the TransportLayer thing. Its probably fine, but only if the subclasses are final. The base class can be extended, but not the sublclasses. I ran into way to many cases of people extending the existing transport layers to hack strange behavior into specific pipes implementations (instead of requesting new API features). And every time time we changed even the smallest thing in the transport layer subclasses, all those mods would explode and cause hard to trace bugs. It was quite painful at the time.

Just some words of wisdom from someone's who been there.

@CovertJaguar - that's fine by me.

Anyway, the idea I had for making PipeBehaviour work uniformly across multiple TransportLayers is... a lot of the Behaviours deal with either larger or smaller capacity of the pipe (this can be done with a multiplier) or routing directions (a list of open inputs and outputs could do that fine).

Here's the general split of responsibilites:

• PipeBehaviour reacts to events (such as the pipe being wrenched, a TravellingObject passing the pipe, etc.).
• PipeTransportLayer sends the events out and receives information from the pipe's tile entity and/or other in-world representation.
• PipeDefinition defines the material of the pipe and hooks the proper Behaviour and TransportLayer to it, creating a unique pipe item.

@asiekierka @CovertJaguar
The separation of concerns here is beautiful, It's good to see life back in this issue, it almost looked dead, who knows, this could even be pulled in on the anniversary of it's creation if implemented within 18 days.

I'll stay subscribed here, looking forward to the progress.
Regards, Josh.

@nevercast - The reason it was dead is because SpaceToad had other priorities, but now that he's not here (and I'm not creative enough to invent new things a lot), I can work on it.

But forget about 18 days. That's far too short, and this needs complex rewriting and bugtesting. In addition, many other optimizations are planned. This will take quite a while.

@asiekierka What hours GMT 0 are you typically on IRC?

@nevercast - I don't know, 8 AM-9 PM? Usually in the more afternoony part, though, except on weekends.

Now sounds good, will be on shortly if you're available.