Rafael Lucas

The Bedrock Edition has a critical issue regarding how villagers link to beds and workstations, as they bind to them randomly rather than to the nearest ones.

A villager's detection range is 17x7x17, measured from their feet, due to this mechanic, the process is practically unfeasible. You would have to locate the specific bed and workstation they are actually linked to if it isn't the closest one by repeatedly breaking and replacing the blocks until the villager emits the particles confirming the link.

From what I gathered while trying to build an iron farm using villagers, the problem seems to lie in the golem-spawning algorithm. It doesn't actually scan the available range to find a valid spot; it simply attempts to spawn one within that area. If the point it selects turns out to be invalid for spawning, it simply registers the attempt as "spawned," forcing you to wait for the next cycle for it to try again at a valid location.

Nowadays, I think the only farms that work well are the ones that cover the entire spawning area, or a large area with water to ensure that spawning actually occurs. Unfortunately, the smaller the area, the less efficient the farm will be...

I think the leader randomly and occasionally changing is a mechanic, but the bell would be much more useful if that didn't happen. Any farm you build should take into account that anyone can be a leader.

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.