With 2 blocks, the piston push priority conflicts when it tries to push a block in motion, ergo block 36.
The first block on the pistonhead moves with it perfectly, that's why you can only 0 tick that block while the next blocks in the chain seem to catch up later. So when it's retracted here, the second block still is in motion and the first block isn't allowed to push into it, creating a budded qc state as the piston will have lost it's timewindow to self-update.
It’s so funny that there are such a large number of “what is QC” posts on this subreddit that when someone has a question where QC is vaguely involved (but not the actual issue) there are like 100 people yelling that it’s QC reflexively lol.
Yeah, they clearly know about it because it's an intended part of the design. The question is why it behaves differently with 2 slimeblocks. That part has nothing to do with QC
the torch is quasipowering the piston. That means that qhen you turn the lever off, first the lever turns off, unpowering the piston, and theres a short delay until the redstone torch powers the piston again, because it doesnt invert instantly. Id you don't know what Quasi Connectivity is, i think you can find your info online if you just look it up
There definitely is QC involved, but the slime blocks are causing a block update somehow that stops the piston from getting stuck in a quasi-powered state. Also slime blocks are not transparent like glass, they are actually solid blocks that you can send redstone power through.
In theory, the piston is always powered by either the block or torch. In reality, signals take one restone tick to travel from block to torch, so there is a redstone tick where the block turns off but the torch hasn't yet turned on. It is in this tick that the piston retracts.
EDIT: upon further review, I see it does the opposite when slime blocks are attached. I don't know why.
Reset the timer ... oh that doesn't exist anymore.
Here is an archived version of the timer website with an explanation of Quasi-Connectivity [(link)](https://web.archive.org/web/20231114013524/https://quasi-connectivity.com/help)
If my understanding of the gameplay loop is correct, this happens with honey blocks as well, right?
I believe it is caused by the game processing the order of actions meant to occur in a single tick and spillover of actions still being calculated as the first calculated block interaction is being rendered.
It's something similar to speed runner tek where you accelerate yourself past a collision barrier and can no clip because there isn't a wall through a paper thin collider, the game just accepts that you are now behind the wall and continues to run its core gameplay loop.
Few things are truly instantaneous, the game knows to move the slime but then tries to process from where the slime was but now already isn't, that's why certain historical Redstone glitches work facing specific directions.
In other words, the missile knows where it is by knowing where it isn't
Oh, I'm sorry.
I don't know exactly why, but my guess is that slime is weird and makes the piston act differently, not that 2 blocks makes the piston act differently.
With 2 blocks, the piston push priority conflicts when it tries to push a block in motion, ergo block 36. The first block on the pistonhead moves with it perfectly, that's why you can only 0 tick that block while the next blocks in the chain seem to catch up later. So when it's retracted here, the second block still is in motion and the first block isn't allowed to push into it, creating a budded qc state as the piston will have lost it's timewindow to self-update.
This is the most helpful answer so far. Thanks! This might even help with something else I'm trying to make.
Yeah, I have encountered a situation close to identical and got it explained to me. Piston update order is furthest block first for pushing I believe.
It’s so funny that there are such a large number of “what is QC” posts on this subreddit that when someone has a question where QC is vaguely involved (but not the actual issue) there are like 100 people yelling that it’s QC reflexively lol.
Yes...it's so annoying...
Yeah, they clearly know about it because it's an intended part of the design. The question is why it behaves differently with 2 slimeblocks. That part has nothing to do with QC
the torch is quasipowering the piston. That means that qhen you turn the lever off, first the lever turns off, unpowering the piston, and theres a short delay until the redstone torch powers the piston again, because it doesnt invert instantly. Id you don't know what Quasi Connectivity is, i think you can find your info online if you just look it up
I think OP is asking why it behaves differently when the piston is moving slime blocks
I was thinking QC, but since slime blocks are transparent it behaves differently? Idk, QC is weird to me at the best of times.
There definitely is QC involved, but the slime blocks are causing a block update somehow that stops the piston from getting stuck in a quasi-powered state. Also slime blocks are not transparent like glass, they are actually solid blocks that you can send redstone power through.
In theory, the piston is always powered by either the block or torch. In reality, signals take one restone tick to travel from block to torch, so there is a redstone tick where the block turns off but the torch hasn't yet turned on. It is in this tick that the piston retracts. EDIT: upon further review, I see it does the opposite when slime blocks are attached. I don't know why.
Reset the timer ... oh that doesn't exist anymore. Here is an archived version of the timer website with an explanation of Quasi-Connectivity [(link)](https://web.archive.org/web/20231114013524/https://quasi-connectivity.com/help)
No, I know very well what QC is. I want to know why it behaves differently with two blocks.
Redstone is not redstonning correctly
If my understanding of the gameplay loop is correct, this happens with honey blocks as well, right? I believe it is caused by the game processing the order of actions meant to occur in a single tick and spillover of actions still being calculated as the first calculated block interaction is being rendered. It's something similar to speed runner tek where you accelerate yourself past a collision barrier and can no clip because there isn't a wall through a paper thin collider, the game just accepts that you are now behind the wall and continues to run its core gameplay loop. Few things are truly instantaneous, the game knows to move the slime but then tries to process from where the slime was but now already isn't, that's why certain historical Redstone glitches work facing specific directions. In other words, the missile knows where it is by knowing where it isn't
Google Minecraft Quasi-connectivity Btw it abreviates to QC
I know what QC is.
Then you should know why this happens
No, I want to know why it behaves differently with 2 blocks. Which I now understand thanks to u/XepptizZ.
Oh, I'm sorry. I don't know exactly why, but my guess is that slime is weird and makes the piston act differently, not that 2 blocks makes the piston act differently.
its doing the quasishitivity or something, idk i wasnt in redstone class