First off... I love this mod. As an engineer, I'm drawn to technical Minecraft, but I'm not a fan of large bulky circuits. RedPower (and later Project Red) was my favorite mod because it allowed me to create super compact circuits and focus on functionality rather than puzzling out how to make something work within vanilla redstone oddities. Tiny-Redstone once again allows me to create extremely compact circuits while still managing to stay true to vanilla. Kudos on an excellent mod!

I noticed that redstone signals don't always propagate reliably across adjacent panels. I created a simple circuit shown below to illustrate the issue:

With these three parallel lines, each operates fine individually. However, if I first turn on the right one followed by the middle one, the middle one doesn't propagate past the first panel:

Likewise, the left line also doesn't propagate.

However, if I turn off the left circuit again, the middle one updates properly.

Adding repeaters to the panel edge helps somewhat, but the propagation is still unreliable. In the example below, the middle circuit "blocks" the falling edge of the right circuit from propagating (sometimes):

As I mentioned, sometimes the above circuit works, and sometimes it doesn't. It seems a little random. There are a lot of other permutations, but I think you get the idea.

If I place repeaters on both panels (one launching and one receiving), then it seems to work reliably.

For this test, I'm using Tiny Redstone 1.16.5-1.7.0 with Forge 36.1.0.

I hope this helps.
Dave

Small update: If I use 0-tick super repeaters on the panel edges, the problems return.

Thanks for reporting this and for helping test the new alpha! The is likely related to the overhaul of the methods for updating neighbor cells. I should be able to have a fix for this later tonight.

Fixed in 1.16.5-1.7.1b.

I personally think the yield is fine. As with most things Minecraft, it may seem a little expensive early game, but eventually, you always end up with a surplus of everything. Most Tiny Redstone components never seemed overly expensive to me.

That said, the super repeaters may be a bit on the expensive side (5 iron for 4 repeaters). I see myself using a lot of super repeaters due to the 0-tick delay functionality (which is quite powerful). One thing that I've been thinking is that the range of the Tiny Redstone dust is a bit short. Tiny Redstone dust still has a range of 16 like normal redstone, but it is reduced by a factor of 8 due to the small size. Effectively, Tiny Redstone has a range of only 2 blocks compared to 16 blocks for normal redstone. I would use super repeaters to make up for that difference without incurring huge delays. I don't necessarily think that Tiny Redstone dust should have the same range as normal redstone... the power of 'tiny' does seem like it should come at some cost, but the factor of 8 seems a bit much. One thing that I was thinking is that perhaps Tiny Redstone dust range could be increased by a factor of 2 or 4. That could be accomplished by having Tiny Redstone dust drop off at some fractional amount per block. For example, say you wanted to increase the Tiny Redstone dust range to 8 instead of 2, you'd make the dust drop by 1/4 strength per tiny block (effectively giving it 64 levels of strength). I was thinking of submitting this idea as a feature request/suggestion... but I haven't completely thought it through...

BTW, I'm trying the new version out now. So far, so good. I'll continue trying to 'break' it. Kudos again on an awesome mod.

It's much more reliable in 1.7.1b, but unfortunately, I can still break it by flipping the switches quickly:

I also had to increase the length of the circuit. It didn't seem to fail with the original 2 panel circuit. You can see the failure quite readily if you connect an observer clock to the input. Clock pulses definitely get lost.

If I add 0-tick super repeater at the point of failure in the above circuit, things improve, but I can still cause it to fail as shown below:

However, things break down if I add one more 0-tick repeater in series. In the circuit shown below, the far right lamp rarely changes state as the switch is flipped.

The problem becomes much less pronounced if I set the repeaters to 1 instead of 0 ticks. However, it still seems to occur on occasion (though it's been difficult to get a screenshot of it). Should I open a new bug for this issue or continue with this one?

(Incidentally, the original intent of the above circuit was to create a sort of 'bundled cable' with multiple redstone lines traveling through each block spanning multiple blocks.)

As I mentioned, a good way to see the behavior is to connect the input to an observer clock.

The far right lamp (connected to the clock line) rarely toggles.

The strange thing is that if I turn off the middle line, the lamp toggles most of the time (but not always).

Again, this circuit is using 0-tick super repeaters. If I change them to 1-tick, the frequency of the problem drops off (but not to 0).

@DaveJWalker I have a somewhat unrelated question for you. Based on your screenshot, it looks like you're playing in survival and have crafted a lot of tiny components. Care to share your thoughts on the cost of components? I'm considering increasing the yield of some recipes, because I'm concerned that the current recipes may get too cumbersome for larger redstone builds.

@dannydjdk It doesn't seem like you've seen my responses since I didn't reference you and the ticket is closed. I think this ticket should be reopened or a new one created since the issue isn't entirely resolved.

I'm having trouble reproducing this with the exact set up. I'll continue troubleshooting, but I wanted to mention something in case you weren't aware. This is a visual sync bug and should have no affect on the actual output, other than the light output of the tiny redstone lamps. It's still an important bug to fix, and I very much appreciate your troubleshooting help. But, this shouldn't stop your bundle cable from working. The output of those signals into external blocks should still work as expected. Of course, that statement is subject to further testing, but my testing so far has supported this.

Update has been released to Curseforge as 1.16.5-1.7.2b.
This should fix the issues related to long lines by increasing the max zero tick line and making that max configurable. It will also provide feedback if the max tick is exceeded.
Hopefully, this fixes all the issues you're experiencing, but I'm still wondering about some of the more intermittent issues, so I'll keep this open until you get a chance to test your circuits. There may be some residual issues after the update. If so, just remove and replace a few components where the issue is happening, and it should fix itself.

@dannydjdk Yeah, I think I implied that the problem was now due to multiple series 0-tick repeaters, but I probably didn't explicitly state that. I wasn't aware of the visual sync bug, however, so now I'm testing the circuit with both tiny and full-sized redstone lamps. As far as I can tell, the problems are now fixed in 1.7.2b.

Did you see my response to your question regarding component expense? In that response, I mentioned the reason why I was using 0-tick repeaters in series was due to the short range of the tiny redstone dust when compared to vanilla redstone. Right now, the range differs by a factor of 8 which seems a bit high to me. I'm curious what you think of the idea of increasing the range by giving the tiny redstone dust more levels of strength. Should I open a feature request for that idea?

EDIT: Actually, I see in your code that the number of series 0-tick super repeaters should allow for tiny redstone dust ranges of 16 blocks. Given that, it seems like increasing the range of tiny redstone dust isn't really needed.

Ok. I reproduced it, and you can ignore my last comment, because this problem is actually different than the original one. With very long strings of zero tick repeaters, the redstone updates are iterating many, many times within the same tick. (This is the reason that zero tick repeaters don't exist in vanilla.) I have a cap on the number of times signals can iterate within a tick in order to prevent stack overflow conditions. That cap needs to be raised in order to accommodate this scenario. I have to make a decision about how far I want to let these go. For instance, a 100 block length of redstone that is pulsating frequently could potentially lag out a server. But, I should be able significantly increase it from where it is now without much consequence.

That's good news! Yeah, the first issue you raised was actually caused by a sync bug. At first, I thought I hadn't fixed it entirely since you were still finding issues, but it turns out, it was a completely different issue.

I did see your response on component expense. Thanks for the feedback! I'm not likely to change the signal strength behavior of the redstone dust, because a lot of vanilla circuits rely on it, and I think fractional drops might be confusing to some users. However, I did double the yield of component recipes, including super repeaters, so that should help in addition to the range increase you mentioned.
Also, I am considering plans for an add-on mod that includes a lossless redstone wire (along with colored wires and bundles). I have no ETA for this yet, as I want to get the API settled and have a few other plans I want to do first.

I'm going to close this again, hopefully for the last time. ;) Feel free to open another issue if you want to discuss other feature ideas or problems.