Double Powering: A Powerful Technique | Minecraft 1.16+

quantum redstone in minecraft! the line is both on and off at the same time!

You've shown quite a bit of interesting behavior in this video! A lot of it relies on the update order of scheduled ticks, which I definitely recommend you look into, as it will make a lot of other behavior make a lot more sense. The 'double powering' is an example of that. Using a single observer doesn't power a torch because it schedules itself to depower before updating the torch, so when the torch tries to depower, the observer is already off again. Using a second observer guarantees the torch is still receiving power when it tries to depower, and it will successfully pulse. The comparator trick you showed at 11:20 works because the comparator is facing into a repeater. It works the same for repeaters, as well, and it's the reason repeater lock monostables have been reliable since 1.8. If a repeater or comparator is facing into the side or back of another repeater/comparator they will update slightly earlier, and in this case, that guarantees that the comparator tries to power on before the observer depowers.

Oh, I love these obscure Redstone quarks that not even the minecraft developers know about, but can come in so handy when compacting down a circuit. Amazing stuff really!

gt0: - observer 1 sched ON - observer 2 sched ON gt2: - observer 1 turns ON -> sched OFF - comp sched ON - observer 2 turns ON -> sched OFF gt4: - observer 1 turns OFF - comp checks if it should be powered, "oh, observer 2 is still powering me, i should turn ON" - observer 2 turns OFF It is based on tile tick priority order.

Interesting stuff. This reminds me of the time I tried to make an "inverted" instant 0-tick repeater which basically just turns off for 0 ticks

2:30 this one is definitely redstone update order related. I've recently been watching some Rays Works videos (3 Easy Ways to Break Bedrock) where they go into redstone update order and why it's important, even if things seem to be happening at the same time.

That's some cool stuff! Thanks for sharing.

Alguém para esse homem, ele é bom demais!!! Keep it up, Cass!

I remember Methodz mentioning an "extended 2gt pulse" in one of the "Dissecting Minecraft" episodes by LogicalGeekBoy (mild cringe alert :P), a signal that would be able to propagate through a torch tower, yet still make a sticky piston spit out its block. (The concept is different, since it is based on powering a comparator using a moved redstone block, but the effect seems interestingly similar.) I assume your effect would be caused by multiple block updates in the same tick, causing the redstone torch (or comparator, I guess) receiving an update a bit sooner than expected, causing it to change state when it normally wouldn't necessarily do that yet.

Torches and Comparators not responding to 2-gametick pulses is a general rule that applies most of the time, but sometimes they can. Normally they don't because they aren't updated in the right order/at the right time, but in some cases they are. Sending 2-gametick pulses up torch towers is one example of this behavior that is used in contraptions from time to time.

You are doing great work, I learnt a lot. Keep it up!

Wonderful work! Sorry it took so long to find you again, but quite an amazing discovery. Time for me to test it against ancient versions for the hope of finding positive results.

Love your content!

As for the weird behaviour with rails + minecarts... There is an update order, let's just simplify it talking about the parts we are interested in (inside a gametick): - TT: tiletick gets processed - Block Events: we will just ignore this, just mention because is in the middle - Entity: Entities get processed You are sending a 0 tick, specifically one that starts and ends in the TT phase. What that means is that the minecart won't be able to "read" that update just because the minecart is an entity. The update has started AND ended in the TT phase(let's say of the gt 1), so there is no difference between the gt 0 and the gt 1 from the minecart perspective (that is reading from the rail in the Entity phase). gt0 - TT: does nothing - E: minecart gets processed gt1 - TT.1: turns OFF signal - TT.2: turns ON signal - E: minecart gets processed As you can see that pulse does NOT affect the E phase ~~I hope this makes any sense~~

This is mind blowing

"Hoje vou dormir cedo" Uma e meia da manhã: "Meu cérebro tá fritando"

i belive ilmango made a video on this kinda behaviour a long time ago and at the time he called them extended 2 tick pulses but the way he made them isn't nearly as nice as these

That is nuttz dude.

If you place a chest next to a comparator for some reason the comparator gets updated every game tick. This way the comparator can detect 2 gt pulses.

This is interesting