http://www.youtube.com/watch?feature=player_embedded&v=z7835xUuHqQ

that would be awesome in vanilla bc :)

https://github.com/BuildCraft/BuildCraft/blob/master/common/buildcraft/transport/pipes/PipeItemsLapis.java

The author could probably make a good case for getting it merged in if they wanted to, but thats up to them.

Diamond pipes are still better in my opinion.

I suggested Transportation Crates some time back, but after testing the new item coloring features I realize that both my own idea and the coloring of items we now have are unnecessary. It doesn't give BuildCraft any new abilities. Just a new way of doing almost exactly the same as it already does.

I am the author of said mod, but sadly I have no idea, how to make a pull request to get it added to vanilla BC.

Google is your friend. Its very easy

Shortly:

1. "git clone" BuildCraft source.
2. edit source to add your stuff.
3. create patch or submit pull request via GitHub directly.

2013/9/17 Jeffrey Kog [email protected]

Google is your friend. Its very easy

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1208#issuecomment-24606691
.

This does look like a great addition to Buildcraft, but I'd almost prefer it not to be included, if what I consider a bug is fixed.

Popping a gate on your lapis pipe lets you add a trigger on item passing through, filtered on certain items, and then change the colour dynamically, however the gate is too slow applying the action and half the time the item has already passed. A similar problem occurs with a gate on a daizuli pipe, attempting to change the output direction based on selected items passing through doesn't work.

If the lapis/gate combination could be fixed item wouldn't be that necessary (though would allow far more items to be sorted at once than the 8 a diamond gate allows). If the lapis/gate issue doesn't get fixed, this item definitely needs to be included as without it lapis/daizuli pipes are very very limited.

Probably not fixable without rewriting the Trigger system entirely. @Krapht or @Flow86 would know more.

I admit never even considering such a use.

Ok, its a pity if it requires a rewrite.
I lodged a new issue discussing gates/lapis/daizuli, but then got carried away and started discussing this colouring machine too...

Mostly its purpose is to get items from Point A to Point B, through a shared pipe network, without regards to what type of item it is. You can't do that with just Diamond Pipes.

I still consider item coloring to be an unnecessary feature in BuildCraft. I've still not seen any real use where it's more powerful than regular diamond pipes.

I claim that the purpose isn't real. Being able to transport items from Point A to Point B without regard to what type of item it is, isn't a mechanic we need. If an item is transported, it is because the item is needed somewhere and at that point you know what type of item it is. And that is were the diamond pipe excel.

If you have a logistics system with actual logic. As in; item supply based on demand. The limit you'll hit is actually at 4 because there are only 4 wires. Only 4 unique signals. This limit isn't lessened with the help of item coloring.

I'm not saying I want more wires. I see the limit as an interesting challenge.

There is currently nothing in BuildCraft that let you use that. You can't decode it reliably or prevent the signals from polluting each other. Let's say a gate receives a red and a blue signal. Is that (3) and (5) or is it (10)?

4 signals are usually enough when it comes to having unique signals between two systems. The challenges comes when you have a larger logistic system with many producers(suppliers) and consumers that are signaling each other in the same network.

However! I never considered that limit for a massive problem. I don't want it to change. I brought it up, because; with long and complex piping networks you will run into that limitation before you run into any limitation with the diamond pipe or filtered buffer.

Let's say a gate receives a red and a blue signal. Is that (3) and (5) or is it (10)?

3 would be Red on Blue,Green,Yellow off on an and gate etc.

@SandGrainOne

If you are able to use only Buildcraft, then the pointy on logic is more
then for. You actually have:

01: No signal
02: Green
03: Red
04: Yellow
05: Blue
06: Green & Red
07: Green & Yellow
08: Green & Blue
09: Red & Yellow
10: Red & Blue
11: Yellow & Blue
12: Green, Red & Yellow
13: Green, Red & Blue
14: Red, Yellow & Blue
15: Green, Red, Yellow & Blue

This is just for basic "turn on/off a signal". If you start to include
basic vanilla Redstone mechanics, that number jumps considerably.

I really see no reason to add more. Can you give am example on how that
would not be enough?
On Oct 7, 2013 10:43 PM, "SandGrainOne" [email protected] wrote:

I claim that the purpose isn't real. Being able to transport items from
Point A to Point B without regard to what type of item it is, isn't a
mechanic we need. If an item is transported, it is because the item is
needed somewhere and at that point you know what type of item it is. And
that is were the diamond pipe excel.

If you have a logistics system with actual logic. As in; item supply based
on demand. The limit you'll hit is actually at 4 because there are only 4
wires. Only 4 unique signals. This limit isn't lessened with the help of
item coloring.

I'm not saying I want more wires. I see the limit as an interesting
challenge.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1208#issuecomment-25866184
.

We can easily decode the meaning of a 4-wires signal from one gate to another, but we have no way of preventing corruption from other gates. If you have a simple network with 2-3 nodes you might be able to set it up properly, but in that case you probably don't need more than 4 signals to begin with.

Anyway, let's not stray to far away from the topic.