undiscovered piston BUD? (at even signal strengths) minecraft 1.20
Вставка
- Опубліковано 20 сер 2023
- help me understand this.
UPDATE 1: in certain chunks it does not work if the redstone power is going towards west or north (if the most powered redstone dust is east or south of the redstone dust above the piston)
when the signal above the piston is 15, it work as expected, but when it's a multiple of 2, like 14, or 12, etc. it acts as a BUD switch (most of the time).
i could not get them to work properly in certain chunks, unless i extended the signal backwards.
at the end i show that moving a switch one block horizontal or vertical it starts working.
if this is a new discovery i want it to be called a "vlad piston bud" - Ігри
this is fascinating, Im not entirely sure what could cause this.
Dust locationality. In that specific location, the redstone dust directly above the piston is processed before the one diagonally above it, so the piston stays extended despite the redstone dust turning off at the same time. But if you moved the entire thing 1 block in any direction, then the piston might be fine. It all depends on the coordinates of the redstone dust. This isn't properly documented anywhere, but it's been known for many many years. There's 3 ways to fix it:
- Place the redstone dust directly above the piston on top of a note block
OR
- Place the redstone dust diagonally above the piston on top of a transparent block like glass or a slab
OR
- Install the "alternate current" mod by Spacewalker, which rewrites part of the redstone dust code to make it more efficient and less locational
So two things are happening here:
- Pistons (and also droppers/dispensers) have a property called quasi-connectivity (QC), which allows them to be powered from blocks not directly adjacent to them. Block updates only propagate through adjacent (not diagonal) blocks, so depowering the redstone doesn't update it and the piston will remain extended until it receives another update and realizes it isn't powered.
- The order of block updates from redstone dust is locational, meaning that the updates propagate in a different order depending on both where the dust is and where the power source is. This is because the block positions to update are collected in a hashset.
When the dust directly above the piston depowers first, the piston is still being powered by the block diagonal to it through QC, so it doesn't contract. The rest of the dust depowering doesn't cause a block update that reaches the piston, so it stays BUDed. If the updates happen to occur in the other order, then the piston depowers normally.
i don't think that explains why the press at 0:30 makes it contract, and why the press at 0:32 makes it stay extended. i don't think i understand why at 0:52 the yellow block (second block) doesn't work until the redstone is extended at 1:00.
at 2:14, it doesn't stay extended, but when i move the thing one block horizontally it does stay extended.
i get QC, but i don't think it's the main cause here. or?
@@vladde This is caused by dust locationality, and the piston is demonstrating that locationality is occurring because of its QC. The only thing that specifically matters here is the update order between the dusts above and diagonal to the piston during the depowering, which changes based on position of the dust and power source (the button), as I mentioned. 0:52 is a case where the update order changes because (to simplify it) the amount of updates change, as it propagates down the other side away from the piston.
There is no pattern, at least not any that's actually useful to anything. The only reason it is at all consistent at the same position and setup is because block positions are hashed based on their coordinates, and the positions are always added based on the order of the Direction enum (down up north south west east). I recommend Earthcomputer's (almost 30 minute) video on redstone dust update order as the most in-depth source.
thanks for the explanation and video recommendation, just watched it! going to sit down and figure out how this affects my bud :)
It is very weird but It would be cool to use in a contraption... Somehow...
Genuinely first time seeing something like this, i think mumbo jumbo has to help us out with this one...
literally was watching mumbo's old video about BUDs to see if this was touched on 😅
this isn't new, redstone dust locationality has always been a thing and changes in weird ways across updates. I've had to deal with this myself when making certain doors. The way it is usually dealt with is either putting the dust on a transparent block or moving it to a spot further from the piston or thing it's affecting
do you know if this is documented somewhere? i couldn't find anything in the wiki, or in any videos about piston buds. not really sure what to search for though
@@vladde idk it's just kinda common sense among more hardcore redstoners lol. Door ppl know the most about update order and locationality
Dust locationality woohoooooooooooo
?
Might be related to you as a player activating the redstone line by pressing a button, if I recall correctly some orders/rules are different for player activated redstone. Try to activate the same thing though for example a repeater and see if the issue remains
Time to science the hell outta this
This is such a cool find bravo
I assume this is because the block update order when powering/depowering redstone is based on which order the blocks come in a hashset, which is somewhat random, but still based on something, so I guess in small hashsets with the (probably) standard Java implementation, the even numbers are more likely to be earlier maybe, or is it the opposite maybe, idk, but it is obviously also based on where the input source is, so I don't really get how that works
Like, if the dust above the piston gets updated before the dust one away, the piston will receive an update, but notices it is powered by QC by the second dust, so it stays extended, and when the second dust gets updated, the block update does not reach the piston, because that's how QC works.
hmmm....
Я не знал этого...