I've recently done a build where I wanted to provide a number of blocks with redstone signals at the same time to turn them on or off. For this purpose I used a cobblestone structure pipe with red pipe wire, and attached iron gates with the setting "red pipe signal -> redstone signal". I noticed that, when I turned off the assembly, the pipe wire would flicker on and off erratically for 4-5 seconds afterwards, and the gates obviously did as well (responding to the pipe wire). However, on further testing, it seems like it's the gates that are causing the pipe wire to flicker.

I have reproduced an example assembly in a test world: https://dl.dropboxusercontent.com/u/44754370/2013-12-06_11.58.04.png

The effect happens in situations like this, where there are gates at the top and the bottom. If I turn off the conditional in the gates on either side, the effect disappears (turning off one of the two gates on a side makes it weaker). This is despite that fact that none of the gates in question output a pipe wire signal, they only watch for it.

One would think: "Well, obviously the gates are outputting a redstone signal, this is through some method causing the pipe wire to light up again". But, they should not. Only the gate on the bottom right next to the lever, many blocks removed, is set to "redstone signal -> red pipe signal". No signal from the other gates can possibly reach it. You can actually build this as close or as far away as you want, it does not matter.

This was observed using Buildcraft-A-1.6.2-4.1.2 on Minecraft 1.6.4 with Forge 937.

is there anybody working on this? It is not fixed yet (http://mod-buildcraft.com/forums/index.php?topic=98.0;topicseen)

I'll take a look at it.

Thanks for your help @Humungus! I've put you in the external collaborator list to assign this to you, and tentatively allocating for 5.0.x branch.

@Humungus, did you find anything on this one?

@SpaceToad Frankly, not yet. From what I have seen it looks like some kind of a logic hazard, but I hadn't much time to look into it yet. This weekend looks promising though.

Thanks @Humungus! I'm looking forwards to it. We'll need to get a bugfix on 5.0.x soon, it would be nice to have that one in.

Seriously, the more I am going through the code, the more I don't understand what exactly and why is causing the problem. Is there a way to run MC in debugging mode so I can set up breakpoints and step through the code?

@Humungus if you're using the Eclipse forge environment, it's all setup for debug.

a very complete bug report, nice work, most people don't write there reports so in depth :)

Odd...

I see the same problem, a simple build like this reproduces it so some extend:

LA---------B-

L = lever.
A = pipe with gate, red wire and redstone -> red wire gate rule.
B = pipe with gate, red wire and red wire -> redstone gate rule.

• = pipe with red wire.

when flipping the lever off, I see the red wire signal "bounch" back from the B gate. This only happens when there is a bit of pipe with red pipe wire after the B gate.

Interesting. I've had setups like that in Buildcraft 3.5.3 back in the day (a single line of pipe wire with multiple gates in a row) that did not show this effect, but I can now replicate it in 1.6.4 versions. The effect is actually quite nice to look at :D

I wonder if it was caused by increasing the frequency of Gate updates. Not sure why that would affect wires though.

Any news on this one?

@dmillerw Fine with me. The signal updating is in updateSignalState and readNearbyPipesSignal methods of Pipe, to save you some time searching.

I wish. Sorry, I'm a bit tied up at the moment, but I will try to reserve more space for this.

I also found a peculiar behaviour with the wires, although I'm not sure there is a way to do it better. Imagine you have a longer wire, with three gates on it with some space between them, and one of the outer two and the center one are emitting a wire signal. The signal strengths are then something like this:
(G is an emitting gate, g is a non-emitting gate and each number is pipe block, with the number meaning the signal strength. '...' is just some more wire)
G 254 253 252 253 254 G 254 253 252 ... ... g
The signal strength between the two leftmost gates forms sort of a dip.
Now, if you turn off the middle gate, what happens is that the signal turns to 0, starting with the middle gate, until it hits the stronger signal from the left gate:
G 254 253 252 0 0 g 0 0 0 ... ... g
And only after that the signal from the left gate ripples back:
G 254 253 252 251 250 g 248 247 246 ... ... g
The side-effect of this is that the right gate receives one additional falling and rising edge, although (if based on real-world behaviour) it should just receive the weaker signal, without the 0 signal strength state.

Problem is, fixing this would require reworking the whole signal system, probably require looking around on the wires for stronger signals and thus result in higher resource consumption.
Thanks to this, I'm not sure whether to even post it on the forum. Your opinion?

I can take a quick look at this. Got some time to kill.

What may have to be done is something similar to vanilla redstone, where updates are disabled while the signal propagates throughout the entire line, with the stronger signals taking over weaker ones.

Note that that sounds more and more like a functional behavior change, not desirable on 5.0.x branch that should now only contain simple stability fixes. I'm moving this to the 5.1.x branch. That could be on NextGen as well if easier.

Sent a pull request: #1770
I would be glad if someone could test it in case I missed something.

To summarize: In the 'before' version, when the wire signal travels, hits a gate and changes its redstone output, the pipe the gate is on will schedule a neighbour change on itself and its neighbours. This causes problems because when it's turning off, the original wire signal is turned off already, but the pipe's neighbour still has the signal. Due to neighbour change process, it will grab the neighbouring signal, even though it shouldn't. In the next update, since the pipe's gate isn't ouputting a signal, it will turn off, and so on and on until the signal strength reaches 0.

The fix just turns off the scheduled neighbour change on pipes, if it would be caused only by the change in the redstone ouput.

This one is ripe for closing then.

Yes indeed!