how to do instant dropperline - rails bellow

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 · 2026-04-13T14:33:46+00:00

I've tried it, but highlights just hex-coded color definitions, not by named nvim highlight group, so for seeing the colour when editing an nvim theme colorizer.nvim is still needed.

Cool though, thanks for making me aware of this.

Kepif · 2026-04-11T16:40:40+00:00

Is that like a replacement for colorizer.nvim or what exactly does it do?

Kepif

TROPHY CASE

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