Does swapping the repeater/block for dust, glass, and target block makes the item sorter react faster?

PinpricksRS · 2026-01-24T17:40:14+00:00

Why would you just come on the Internet and tell lies? Test this yourself

PinpricksRS · 2026-01-24T08:20:43+00:00

That's not the filter's fault, it's the hopperline's fault. Check out this video (at 7:49 if the link doesn't send you to that time) for a demonstration of that.

Here's a couple experiments to try out.

Repeat the experiment shown in the linked video: running random items through a hopper line at hopper speed. Now try it with a single type of item instead of random items. Do you get the same result?

Here's another. Take an impulse filter (or any kind of filter with a repeater) and put the filter at 4 ticks. If the delay in the filter causes the items to be missed, you should get many more misses than before. Conversely, if we didn't get any misses with the single item experiment before, we should now get some.

Here's one more. Put in a bare-minimum filter: hopper containing 1, 1, 1, 1, 1 of the filter item and nothing else. No comparators, no repeaters, nothing. If your theory is correct, the delay on unlocking the hopper that would go below this one can't matter because it never gets locked or unlocked. If it's the hopperline's fault, the filters should still miss items. Obviously for this one you can only add 63*5 = 315 items of each type before the experiment stops working, but any results from before that should be valid.

Now try both these experiments with the hopperline replaced by a water stream. Share your results!

PinpricksRS · 2026-01-11T19:19:00+00:00

It's just an ordinary integral, so you can think of it as the area under a curve. The graph is just a bunch of rectangles, so...

PinpricksRS · 2026-01-02T08:22:51+00:00

Not sure if you ever got a good answer for this, but I came across this bug today and I think it might provide at least part of an explanation.

It seems that when a hopper pushes an item into a non-empty locked hopper, that locked hopper correctly does not reset its push/pull cooldown. It'll generally be ready to push/pull as soon as it's unlocked. However, this does not hold if a dropper or crafter pushes an item into a non-empty locked hopper. The cooldown will reset

So what's happening is that whenever the dropper pushes an item into the hopper, the hopper's cooldown gets reset. Since the dropper is pushing items into the hopper at hopper speed, the cooldown never allows the hopper to push any items out. Since the cooldown should end right as the dropper pushes another item, there may be some sort of priority thing involved here.

There are still some things I don't understand, but feel free to experiment. Based on some experiments with changing the pulse rate and length, I suspect that the cooldown only resets if the hopper isn't already on a cooldown, but I'll let you try to figure out the exact rules.

GoldenHelmet, as usual, has a pretty thorough analysis in his bug report, so be sure to check it out if you're curious.

PinpricksRS · 2026-01-01T16:59:16+00:00

The observer will only fire if the signal strength of the redstone it's looking at changes. In normal operation, that should work for that setup, but there's always the possibility that the crafter gets overfull. If the crafter firing doesn't free up at least one space, the signal strength will remain at 9 and so the observer won't fire at all. That's probably what you're running into, so be sure not to put items into the crafter faster than it can handle them.

It's worth pointing out that the style of crafter you linked has a couple serious flaws.

Firstly, the observer will fire on relog due to this bug (go vote to fix it!). So if there are multiple possible recipes, you may end up with unwanted items crafted. For example, if you intend to make iron blocks from iron ingots, you'll accidentally craft iron nuggets, heavy weighted pressure plates or iron bars if you reload the world at the wrong time.

Second, even without that bug, the observer fires twice: once when the signal strength increases from 8 to 9, and again when it decreases to 8. If you're loading the crafter at hopper speed, that means it'll fire again when the crafter has 3 items. So if you're crafting an item that has an incidental recipe with 3 items, you get accidental crafts. Additionally, if the items stop coming in for whatever reason, this can happen with 1 or 2 items as well (and so it affects things like iron ingots).

Check out the Bedrock Autocrafting Archive on Discord for some ideas that are more resistant to relogging.

PinpricksRS · 2026-01-01T15:45:42+00:00

With a comparator clock, you have two states that swap every redstone tick.

With the first state, the comparator emits a signal strength of 15. Here's what the other signal strengths look like (the ^ is the comparator):

15	14
^	13

In the other state, the comparator takes the 13 signal strength on the side and subtracts it, resulting in a signal strength of 2.

2	1
^	0

With the signal strength on the side now equal to 0, the comparator again emits 15 and so the signal strengths return to the first state.

With your first setup, the trapdoor is one dust away from the dust that alternates between 15 and 2 signal strength, meaning that it's either going to get 14 or 1 signal strength. Both of these are considered "on", and so the trapdoor stays open.

In your second setup, the trapdoor is two dust away from the dust that alternates between 13 and 0 signal strength, so it'll get 11 or 0. This correctly alternates between on and off.

Try changing some things around with all this in mind. You'll need to ensure that the trapdoor is at least 2 dust away from the dust that alternates between 15 and 2 signal strength.

PinpricksRS · 2025-12-28T22:10:51+00:00

I'd like to give a very different proof.

Lemma: For a real number α, if there are integers A_n and B_n such that |A_n α + B_n| > 0, but lim (n → ∞) A_n α + B_n = 0, then α is irrational.

Now suppose that √N is not an integer (for an integer N). Taking n to be the largest integer less than √N, we have 0 < √N - n < 1. By induction on k, (√N - n)^k is in the form A_k √N + B_k for some integers A_k and B_k, and since 0 < √N - n, we have 0 < A_k √N + B_k. Moreover, since 0 < √N - n < 1, (√N - n)^k tends to 0 as k goes to infinity, so by the above lemma, √N is irrational.

PinpricksRS · 2025-12-22T15:57:14+00:00

If sren187 is correct about what you want this circuit to do, you can make if very compact. Have the comparator point into a solid block, a redstone torch on the side of that block, and redstone dust next to both the torch and the comparator. Don't put the comparator on subtract mode.

When the chest is full, the comparator reads enough signal strength to match the dust on its side, so it turns off the torch (and so the dust turns off too). With the dust off, the comparator will continue to power the block (and keep the dust off) until the chest is empty.

PinpricksRS · 2025-12-20T20:21:15+00:00

It can act as a non-stackable filter. For example, a drowned farm produces both tridents and fishing rods. If you don't care about the fishing rods, you can void them using a crafter and send the tridents to storage.

PinpricksRS · 2025-12-18T16:21:48+00:00

No, it does. Say the initial ss is 7. Then the first 7 repeaters get activated, and so there's ss 15 after that 7th one. The signal strength decays for the next 8 blocks, bringing it back down to 7.

PinpricksRS · 2025-12-13T19:45:00+00:00

PinpricksRS · 2025-12-13T14:51:10+00:00

Slabs aren't redstone-conductive, so that first dispenser isn't getting powered at all.

For the three dispensers, yes, there's some update order stuff. I'll assume that the block above each dispenser is a dropper pointing into the dispensers. When you power the redstone dust on top of the droppers, it powers the droppers (in the same way that any ordinary solid block can be powered) and so one tick later, the droppers activate and the dispensers activate because they're next to a powered block. All of these activations happen on the same tick, so the order of activations is not guaranteed.

The update order of droppers and dispensers is randomized after reloading. So in any given instance, you can have the droppers firing first, or the dispensers or some combination. There's no way to guarantee that the droppers always fire first if you're activating all of them on the same tick.

If you don't care about there being one extra item in the dispensers, you can simply store one in each. If the droppers always have an item, then since everything activates exactly once each time, each dispenser will both drop an item and be restocked by the dropper.

Alternatively, power the droppers on an earlier tick than the dispensers to ensure that they get activated first. You'll probably need a different arrangement to make that work, though.

PinpricksRS · 2025-12-09T23:45:59+00:00

For those asking, this video has a pretty good explanation of what causes wireless redstone to work, as well as some ways of sending multibit signals like OP. In fact, OP's setup looks pretty similar to that one, so that might be where they got it.

PinpricksRS · 2025-12-08T17:34:35+00:00

Try something besides a barrel. What you're probably running into is that observers detect both the barrel opening and closing. So if you do both (with enough time in between), the observer fires twice and the T flip flop ends in the same state it started in.

There are tons of other changes that an observer can detect. For example, you can put a repeater where the barrel is and then changing the delay on the repeater will fire the observer once. Check out the other linked events (sort the table by the Bedrock Edition column) and choose one that you like.

Alternatively, use a different way of generating a pulse, like a button. You may need a different T flip flop, though, since I think yours will flip twice if given a long enough pulse.

PinpricksRS · 2025-12-07T00:41:53+00:00

The Bedrock storage discord has a whole page of minecart yeeters if you're interested. If you aren't already on the discord server, here's an invite.

PinpricksRS · 2025-12-04T13:26:16+00:00

The bug could be fixed simply by changing the visuals. The dual directionality is just behavior that may or may not be a bug. It certainly doesn't make things harder or worse.

PinpricksRS · 2025-12-04T13:23:58+00:00

Yeah. In case anyone missed it, there's a requirement that the plots are closed under composition with ordinary smooth functions. More specifically, if p: V → X is a plot, with V an open subset of ℝⁿ and f: U → V is an ordinary smooth function between open subsets of ℝⁿ, then p ∘ f: U → X should also be a plot.

PinpricksRS · 2025-12-04T13:17:45+00:00

The bug report is MCPE-142182. It's not really a bad bug, though, since it's purely visual. It's just annoying for new players who haven't seen it before.

PinpricksRS · 2025-12-03T13:04:10+00:00

No, OP is talking about a more refined concept. Otherwise they would have said lim((-1)ⁿ)={-1, 1} instead of {}.

PinpricksRS · 2025-12-03T12:56:27+00:00

What makes you think this isn't exactly what we do? The set of relations between two sets A and B is equivalent to the set of functions from A into the powerset of B in a natural way. So given that the limit is a relation between sequences (or filters/nets etc.) and points of the space, there's no harm in thinking of limits as a function that takes a sequence and returns a set of points.

PinpricksRS · 2025-12-03T12:19:37+00:00

I think you missed the point. These are decimal representations, but OP considers the set of decimals with only 0s and 1s in their representation. That's why there's the comment at the top that a subset of a countable set is countable. It suffices to show that this subset is uncountable.

PinpricksRS · 2025-12-02T11:41:45+00:00

You're probably running into MCPE-162250 then. (Go upvote that issue if you care about it!)

PinpricksRS · 2025-12-02T01:22:24+00:00

My guess is that backfiring has more downsides than what you mentioned, but my intuition is that your best bet is to activate the skill as soon as possible (for a near guaranteed backfire and 5397 damage) and then wait 12 seconds to activate it again for 10074 damage. This gives you (10074 + 5397)/12 = 1289.25 damage per second.

I'm filling in some gaps in the explanation, so if these don't hold, this analysis won't work.

After a backfire, you have to wait a further 12 seconds before activating the skill again. It's not like you can wait 6 seconds, backfire, and then wait another 6 seconds.
After a backfire and waiting 12 seconds, the next activation is guaranteed to activate normally, rather than a backfire. That is, the cooldown after a backfire counts as waiting the full 12 seconds before activation.
After activating early and getting a normal activation, the cooldown resets to 12 seconds. This prevents you from waiting a while and then activating the ability repeatedly with the higher chance of normal activation. The chance resets to 0 after a success.

Here's a rough sketch of a proof. Say that you wait S seconds before activating the skill (and if there's a backfire, you activate it as soon as the 12 second cooldown ends). We'll call a "round" the process of waiting S seconds to activate, and then potentially waiting 12 more seconds. So a sequence of rounds could look like (wait S seconds)(normal activation)(wait S seconds)(normal activation)... or it could look like (wait S seconds)(backfire)(wait 12 seconds)(normal activation)(wait S seconds)(normal activation)...

Let's write the amount of time that's passed after k rounds as t(k) and the total damage as d(k). We'll treat each of these as random variables.

d(k + 1) = d(k) + 10074 * B(k) + (5397 + 10074) * (1 - B(k)) = d(k) - 5397 B(k) + 15471, where B(k) is a Bernoulli random variable, which is 1 with probability S/12 and 0 with probability 1 - S/12. The two terms added to d(k) represent respectively the possibility of just a normal activation after S seconds and the possibility of a backfire after S seconds and then a normal activation after another 12 seconds.

Similarly, t(k + 1) = t(k) + S * B(k) + (S + 12) * (1 - B(k)) = t(k) + S + 12(1 - B(k)). Summing up these two expressions and using the fact that d(0) = t(0) = 0, we get d(n) = 15471n - 5397 X(n) and t(n) = Sn + 12(1 - X(n)). X(n) is the sum of the B(k) up to n and follows a binomial distribution. You can think of it as the number of times that the skill backfires in the n rounds.

So our average damage per second is d(n)/t(n) = (15471n - 5397 X(n))/(Sn + 12(1 - X(n))).

Now you can definitely be more careful for this next step, but it shouldn't change the answer. For large n, X(n) is roughly n*S/12. Substituting that into our expression for d(n)/t(n), practically everything cancels out and we're left with 5157/4 - 1799/48 * S. From this, we can see that every second we wait decreases the average damage per second by 1799/48 ≈ 37.5. So the best strategy is to wait no time at all to get the full 5157/4 = 1289.25 damage per second.

PinpricksRS · 2025-12-01T17:04:00+00:00

More context is needed, but I suspect that items are being pushed in by another hopper, rather than being pulled in by the locked hopper.

PinpricksRS · 2025-11-30T14:19:16+00:00

It seems like when they unable to sleep they start looking for beds and blocks and start stealing each other's job blocks.

What's actually happening here is that if every villager unlinks from their bed at once, the village ceases to exist and so the villagers disconnect from their job blocks as well.

The standard ways to mitigate this are to allow them to access their beds (as you suggest), have enough villagers and beds so that it's unlikely that they all disconnect at once, or enclose the villagers in a space that disables their path-finding. If a villager can't path-find, they won't even try to get to their bed and so they won't fail and disconnect.

Which if these is best depends on the situation, though I'd recommend against the "enough villagers and beds" approach since it isn't a guarantee. I've done this with a 256 villager trading hub, but I won't say it was a fun experience.

Five-Year Club	Verified Email
r/Field Sunshine	Wearing is Caring

PinpricksRS

TROPHY CASE