Marking this off so I don't forget to do it. Useful, for example, for Tinkers' Construct smelteries (which can drain multiple types of liquid) or compacting complex fluid systems.

I got permission from Flow86 to use ABO's existing implementations, but I think they should be looked into and seen whether they can't be made better:

< asie > oh, hey Flow86!
< asie > i wanted to have a talk with you about ABO
< asie > as I'm helping out with BuildCraft in recent days, will you be mad if I use some ideas from ABO as inspiration?
< asie > (no copying, not even assets... just inspiration)
< asie > (and not all, more like 2 or 3 things)
< Flow86 > you can even copy it if its integrated into vanilla buildcraft

How did you get a hold of Flow86? I've rather thoroughly and unofficially taken over development on my fork. I've fixed and improved and added a lot of things, and he (or she, I haven't a clue and don't really care other than convenience of reference) has replied to his (assuming male for convenience) thread or github regarding my updates in quite a while.

It might make sense to hold off on this for now. I'm currently doing a few things with fluid pipes that make substantial changes to some of the underlying code (like PipeTransportFluids). Also, there was a fair bit of discussion on whether such a pipe should even exist and it didn't result in any kind of consensus (e.g., http://mod-buildcraft.com/forums/index.php?topic=101.0).

I usually agree with the "don't put two liquids in one pipe" standpoint, but having these as a way to filter unwanted liquids out of a pump or similar scenario is justification enough in my eyes.

@da3dsoul - TCon smelteries and filtering there is one valid use.

@RufusStark - hold off with that, a pipe redesign/overhaul is planned soon.

There wasn't anything to hold - it was already done. I just had to track down one little bug before submitting the PR. (Apparently I don't understand git that well - I thought I was creating a separate PR, but it just combined it with #2011.) In any case, it doesn't make sense to delay those features while redesigning the whole pipe system. Those can go in right now (everything in that PR has been pretty thoroughly tested), but presumably a complete redesign of the pipe system won't happen before the next release.

And correcting my earlier comment... As far as I can tell, none of the changes I've made to PipeTransport should interfere with implementing a Diamond Fluid Pipe. That said, I still don't think it's necessary - you can always use Emerald Fluid Pipes to selectively extract liquids.

@RufusStark - No, the extraction hack is a bit of a hack, and part of the redesign is feature parity and consistency across all pipes as much as possible.

@asiekierka - I don't understand what you mean by extraction hack. The emerald pipe is designed to selectively extract fluids. The same is true for the emerald item pipe. Do you mean the implementation in code is a hack?

I honestly don't have a strong opinion against a diamond fluid pipe; my concern is the complexity of coding it. I think right now, if a fluid comes into a pipe, it cannot move into the central part of the pipe if a different fluid is already there. To use a diamond pipe, that behavior would have to change for all fluids pipes, right? Fluid pipes are already somewhat laggy - adding more logic to keep track of different fluids in every section of every fluid pipe will only make that worse.

Emerald Fluid Pipes does not filter fluids. Or have they?

Done.