Describe the bug
Pulse formers produce incomplete pulses after reloading the world. By this I mean that some data cells receive the clock signal from the pulse former and others don't. It doesn't have a set cut off point either as sometimes only the middle cells will be affected.

To Reproduce
I haven't been able to reproduce it outside of the world I'm working in.

Expected behavior
The expected behavior is that data cells will correctly update their contents on a single tick pulse without needing to replace the pulse formers.

Crash Log
The game does not crash.

Versions

• CCL Version: 1.12.2-3.2.3.358
• FMP Version: 1.12.2-2.6.2.83
• MrTJPCore Version: 1.12.2-2.1.4.43
• ProjectRed Version: 1.12.2-4.9.4.120

Screenshots/Videos
Video of the issue
In the video you'll see how after pressing the reset button on my circuit the first set of data cells only gets partially filled and that the contents of the second set are also partially filled. After breaking and replacing the 2 pulse formers which are used to trigger the clock for them and I press the reset button you'll see that the first set of data cells properly gets filled and the second set is empty. You'll notice I place a bundled redstone cable a couple of times. I do that in order to update the a visual glitch which is probably due to me using optifine.

Wow, after all this time, this issue is still around. Was able to quickly repro it like shown below:

While the PulseFormer gate does tick for a full 2 ticks, we have a situation where tick ordering matters. And the order in which block entities are added to the world is the order in which they receive scheduled ticks. So if the pulse-former is placed after the cells, everything works. Otherwise, the pulse-former gets the tick to go low before the cells can actually "read" the input data.

Happy case where Pulse Former was added to world after the data cells:

1. Pulse former gets a redstone input change from lever
2. It immediately produces a high signal, and schedules a tick 2 ticks later (for going back low)
3. Data cell gates see the signal go high. They schedule a tick 2 ticks later to latch the input
4. Data cells get scheduled tick first. They can still see the high signal from pulse former, which triggers the data latch from back to front.
5. Pulse former gets its scheduled tick, and drops the output low.

Bad case where Pulse Former gets its tick before Data Cells:

1. Pulse former gets a redstone input change from lever
2. It immediately produces a high signal, and schedules a tick 2 ticks later (for going back low)
3. Data cell gates see the signal go high. They schedule a tick 2 ticks later to latch the input
4. Pulse former gets its tick first, and drops the output low
5. Data cells get their tick. But top wire signal is already low, so they can't do anything.

Note that this is happening with all Array gates that use their top signal to make a logical decision. Why only array gates? Because normal gates actually save their input signals to a variable, and then act on that variable during their scheduled tick instead of re-querying the world.

Also, world loading may change the ordering of the tiles in the tile list, causing this behavior to come back up during world reload even after rebuilding the pulse former gates.

I've managed to make a circuit that functions the same but doesn't have the bug. Without the repeater I found that the issue still occurred, so it might be an issue with single tick pulses in general since other single tick pulse circuits I made exhibited the same issue. It's possible that the chunk is just overloaded.

+1 This keeps happening to me, too.

I haven't actually measured it, but a one-tick repeater in traditional redstone definitely stays on longer than the pulse generators in this mod. Vanilla redstone ticks are actually 2 game ticks (1 game tick = 1/20th of a second, 1 redstone tick = 1/10th of a second), and I suspect the D latches are expecting the latter. It'd be nice if the pulse either output a 2 redstone tick pulse, or better yet, was configurable.

But I also feel like the intermittent behavior of the D latches is probably unintentional, and potentially an indication of a larger bug in its code. I searched through this codebase, but I'm unfamiliar with Scala so I couldn't find any of the logic for the pulse gate. If anyone's more familiar with this codebase, knowing where that code is would be a good place to start. For now, I've just added 2-tick repeaters in series after all my pulse generators and it seems to have fixed it.