Rafael Lucas

One small observation about the case that I forgot to mention. The comparator signal relative to the direct Sculk signal is asynchronous, and this could complicate verifications with false-true returns if someone use this signals together without adjusting the ticks

Yes, it can be understood as improvised solutions to deal with the situation, all related designs, which could be easily resolved with a few lines of code.

affects 26.1

Apparently it has already been fixed. It's working normally on v26.0+.

This is a normal function of the target block. What's happening is that it's not visually cutting the redstone dust, giving the wrong impression. It's just a visual bug.

So would this be more of an improvement suggestion?

It doesn't make much sense for the lower funnel to pull items from an upper funnel that isn't directly connected to it, even if its generic programming dictates that it should do the same.

Being able to control its connection more intelligently would allow for even more compact routes and detours, without the need to maintain a block of distance between them.

I apologize as well, I didn't read your message to the end and went to see the old post first.

It's illogical for an upper funnel that isn't directly connected to the lower funnel to suck in items, even if its generic function is programmed to do so. Being able to control their connection would allow for even more compact routes and detours without needing to maintain a block of distance between them.

It's working normally here. Apparently fixed in version 26.0+.

Or stretching it with repeaters, and finally a sticky piston with an observer. Even so, it still takes up a lot of space and wouldn't reduce the tick speed.

What happens is that for some reason the game is loading the hopper first, before the redstone signals. Since it's not powered, it ends up pulling the item from the chest at the beginning. Just place a signal near where you're going to put the hopper, below the chest, and when you place the hopper you'll also see that it will pull an item even though the area is already powered.

It would be interesting if the jars emitted light or became slightly clearer when fermenting, or if they matched the jars that are actually on the brewing stand.

I don't know how you managed to fit 64 in one slot, but if you attach a funnel to the side, you can actually pass empty bottles through the brewing stand.

And currently, the only way to add delay to the ticks is by stacking repeaters without adjusting the delay, since they naturally add 1 tick without interfering with the signal, but consume more space and resources unnecessarily.

Another reason that would reinforce the idea of ​​a new feature is that this delay in repeaters isn't bad. It's quite useful in looping situations where you want continuous output, but only a continuous signal, such as in brewing stands.

Perhaps a new object that could slow down a fast tick or speed up a slow tick would help solve many of the problems related to this, but of course, it wouldn't rule out the future need to correct observer inconsistency. As you can see in this other video, it's not even possible to slightly delay a fast tick with the current tools.