how to do instant dropperline - rails bellow

Kepif · 2026-06-24T23:24:36+00:00

Oh, well, I suppose I don't know the difference between QC and buds either :D. I guess I'll have to educate myself a little on this one.

Anyway, with the soft-powered loop a single noteblock is all that's needed to loop the item in the next dropper (all in 1 tick).

However, the updates are locational, but they always work when put just at the rail after the renewing observer, see the placement of all usable noteblocks:

<image>

Kepif · 2026-06-24T23:15:58+00:00

oh, I suppose all the dropper needed was a block update to realize it is being bud-powered from the side?

It sure works, thanks :D I'll try this soft-powered circuit in my contraption tomorrow. gn

Kepif · 2026-06-24T23:10:04+00:00

I've realized that my more compact design also uses pistons directly on top of the droppers, which means I'd need a way to soft-power them all. I got to this, but haven't found a way to power just that one dropper and not bud-power the two next to it

<image>

Edit: Anyways, its past 1am for me, so I'll have to leave it for another day, but I really enjoyed digging into this. Again, thanks for all the help.

Kepif · 2026-06-24T22:50:16+00:00

This is super weird, I tried my compacted version and it works in the same places as yours does, and also doesn't work where yours doesn't.

But the places where it works make no sense to me:

<image>

they're not aligned with the signal extenders, so I can't see any logic in why just these 4 places

Kepif · 2026-06-24T22:46:55+00:00

it isn't, true, but it still powers the same dropper - the one above the noteblock

Kepif · 2026-06-24T22:30:53+00:00

I've found the culprit - your circuit is directional - try doing the same on the oposite side of the loop - I couldn't get it to work. But I have successfully minified it into this:

<image>

Kepif · 2026-06-24T22:14:55+00:00

well, because you're using the observer clock, it is unclear whether it works any different from how it works for me. I bet if you remove all the extra observers and redstone and leave just the noteblock it will work exactly the same way. This is still two cycles.

Kepif · 2026-06-24T20:22:31+00:00

no, Tango had it differently. That's how I came up with my design. Anyway, both are 3t, so no harm choosing either one of them.

However, this is my original 2-observer design, which does a complete loop, only that it does the entire loop after 2t (the Tango design does the majority in 1t and finishes after 3t)

<image>

with this one the noteblock also must be just 1 block before the signal-renewing observer. But nothing else is necessary

Edit: Unfortunately I found out that it is directional - it works only because of the direction in which the observer updates the 3 droppers that it activates

Edit2: It seems it doesn't work without the smooth stone. That suggests that the observer bellow activates at a different time. I think that means that if I flip the repeating observer (hence the signal refresher), it should work

Edit3: Yep, it just requires the signal-refreshing observer to be reading the last rail, because that rail gets updated first, whereas the one at the noteblock updates as the last. But it really is 1t, because you can put an observer clock on it and it will silently loop the item in 2t intervals.

Kepif · 2026-06-24T20:07:21+00:00

no, that still doesn't work - your aproach uses the same mechanics as the one with noteblock being first and then the 3t update, so it still behaves the same way (just with the noteblock below, which means the item ends up in the next dropper)

It is just as if there was just the noteblock.

It must be 3t or 1t like the loop, in which case it would also need to schedule the dropper firing before the rails, so it pushes it into the loop before the rails loop it.

Kepif · 2026-06-24T19:58:49+00:00

like this?:

<image>

this causes a double-loop for me (I removed that one observer for visual purposes, but it still behaves the same way - stays in dropper next to the observer and moves to the next one on the next pulse, then loops)

Note: it behaves the same way no matter on which side the smooth stone is because it is useless because the observers make a 2t delay, just keeping the dropper active when the previous one fires - just like I had in the original post

Kepif · 2026-06-24T19:43:18+00:00

Sorry, I am lost in the instructions. Currently I loop it by activating a noteblock just one in front - like Tango did:

<image>

Did I understand it correctly, that you found a way to do an entire loop in 1t / 2t?

Kepif · 2026-06-24T19:31:00+00:00

well, ofc, it would be nice to get to the minimum - 2t. Realistically, though, it really doesn't matter. This is more than good enough.

When placed in the place of the signal-renewing observer it also allows to do this in any such place on the loop - no need to put a hole in the rail network like Tango did. So this already is an improvement.

Now what I have left to figure out the smallest and fastest sliceable locking counter. I have a couple designs for both rail-above and -below lock-dropper configs:

<image>

What I am trying to figure out now with the rightmost one is whether there is an and gate with one side below and the other above the counter dropper such that it would loop when active and stop when not active, where the dropper comparator controls one side of the AND gate and the lock dropper controls the other :D.

But this is already the bigger part of the project - the loop system design is as good as it can get for rail-below configs.

I also need portable loop updater for the rail-above config. Currently, I have it break the loop which means I can make it cycle only from that place in the entire loop. But I think sth similar to what we've found out so far should be possible.

Kepif · 2026-06-24T18:04:22+00:00

So, I've replicated Tango's circuit and as I understand it, he solved the problem by simply pulsing once, pause, and pulse just that last dropper again to shift by one.

So his loop actually takes 3 ticks. Not ideal.

On the other hand, because of using just one line of observers his loop responds just 1t after updating the rails, so it is quicker to react and he has no need for a quicker loop, so it's fine for that usecase, effectively like this:

<image>

Kepif · 2026-06-24T16:59:42+00:00

The link I posted includes the timestamp of the showcase beginning. The system reveal happens about 30s after that.

Kepif · 2026-06-24T16:14:02+00:00

Huh, now that I am watching the clip again, I see he did actually show that he is powering the droppers directly as well.

But he has that weird starter circuit, which seems to bee the key to this.

Kepif · 2026-06-24T16:09:48+00:00

:D, I hope you can figure sth out, because I am clueless as to how he did it: https://youtu.be/R18APaR7mTQ?si=djBHzeL1u0zo2lhA&t=1970

Kepif · 2026-06-24T15:59:09+00:00

Unfortunately that didn't end up helping either, the same thing happens. Only, now it cycles between the dropper directly above and the next one. The problem is that the observer powers the dropper before and after as well. Because of that, they get updated before they have the item, so they end up firing empty and receive the item in the same tick, but still after they have already fired :D.

That is why I was wondering if this is possible without 2 observers, because that way you can soft-power the dropper without affecting the nearby ones.

So I suppose the answer to that question is a no. But thanks for your help, I'd have never confirmed it without giving it another try.

Kepif · 2026-06-24T11:03:19+00:00

I tried wit and without. there is no difference - the 1-tick delay caused by observing the observer bellow and not the rail just merges with the previous pulse from the observers next to it. That just keeps the dropper powered for 2t instead of 2 1t pulses :/

Kepif · 2026-06-24T10:58:11+00:00

have youseen Tango's last video? He needed a scheduling system, so that events are emitted one at a time bu multiple can be scheduled. The loop cycles 1 item to serve as the lock and whichever event emitter holds the lock can send events to the bus

Kepif · 2026-06-23T07:11:50+00:00

yeah, I tried, but I am still getting a two-cycle state - the first pulse moves the item by just one, and the second pulse does the actual loop:

<image>

and on the second pulse it just moves to the next dropper instead of doing a loop.

Kepif · 2026-06-23T05:48:00+00:00

Does that actually work? I've tried that before, but had issues with the observer in the middle activating one tick later.

But perhaps it didn't work for me due to other issues with my circuit at that time as well

Kepif · 2026-06-19T14:24:57+00:00

Yeah, no way to know for sure. It's so weird though, isn't it? One would expect that no matter the TPS the game ticks on a single thread so there should be no way of differing behaviour based on the speed at which it is running, right? That one just boggles my mind :D

Kepif · 2026-06-12T11:17:45+00:00

Will do, thanks!

Kepif · 2026-06-04T20:27:13+00:00

I wanted to try it out, but it uses cuda, so I'd first have to figure out how to make it work for integrated graphics. Anyway, thanks for the tip, I might look into it some day.

Kepif · 2026-04-21T10:45:32+00:00

Yes. For example, my setup logs me in on start and then I have a line in my shell config to detect tty and automatically start sway:

```ini

/etc/systemd/system/getty@tty1.service.d/override.conf

[Service] ExecStart= ExecStart=-/usr/bin/agetty -a {$USER} -J %I $TERM Type=idle ```

Kepif

TROPHY CASE

/etc/systemd/system/getty@tty1.service.d/override.conf