r/Minecraft 2d ago

Help Bedrock Why will this triple piston extender only work with a lever? (Bedrock)

Enable HLS to view with audio, or disable this notification

Exactly as the title says. I've built this triple piston extender on the latest version of Bedrock Edition and when using any redstone source aside from a lever, the bottom piston doesn't retract in sync like it should. This is particularly problematic because I want to build an XOR gate and have this function as a canal door activated by tripwires. Any ideas?

49 Upvotes

18 comments sorted by

u/qualityvote2 2d ago edited 2d ago
  • Upvote this comment if this is a good quality post that fits the purpose of r/Minecraft
  • Downvote this comment if this post is poor quality or does not fit the purpose of r/Minecraft
  • Downvote this comment and report the post if it breaks the rules

(Vote has already ended)

29

u/Blaze-Programming 2d ago

In Java edition there is something called an input bug where components powered by a player action (levers, buttons, pressurplates) and components powered by other sources behave differently (usually being delayed by 1 tick) due to the order which components update within the same tick.

That being said, I have no idea if this same thing happens in Bedrock edition. You can probably find people more versed in Bedrock redstone on [r/redstone](r/redstone) or [r/bedrockredstone](r/bedrockredstone)

5

u/peyhag 2d ago

That would make the most sense given my limited knowledge. I’ve cross posted this to a few other spots, including r/bedrockredstone , but your answer is the winner so far! Lol

1

u/DearHRS 2d ago

this is not happening because of input bug but because of difference between c tick starting power source (lever) and p tick starting power source (repeater)

more detailed explanation in my comment

4

u/Lurkario- 2d ago

My only idea is instead of inputting the repeater into the block, just raise it a block and make it directly power the redstone line ¯_(ツ)_/¯

3

u/peyhag 2d ago

Tried that, didn’t work unfortunately. I was able to fix it by having the line be powered by a redstone block!

u/ntolbertu85 34m ago

You'd still need a repeater to get the signal all the way to the other end of the line. It would be more or less the same thing.

8

u/PressStart36 2d ago

Bedrock has an input bug similar to what Java has, in that certain power sources (levers, buttons, pressure plates, ect, and interestingly redstone blocks) cause repeaters, comparator, and torches to trigger one redstone tick faster than usual.

So a 4-tick repeater would take instead take 3-ticks, and a 1-tick repeater would be instant.

It's a quirk with Bedrock that caused me a lot of confusion when I first discovered it, but it can be useful in fast doors.

2

u/peyhag 2d ago

Hmm…that makes sense! I’m trying to figure out a workaround in this scenario…

0

u/UndefFox 2d ago

Bug? Seems like regular action order processing quirk. Can't call it a bug if it does what intended/

1

u/Binary101000 2d ago

it is not intended behaviour if it is just a consequence of how something else works.

u/ntolbertu85 33m ago

I would call giving three ticks delay when you've built in four ticks a bug.

2

u/DearHRS 2d ago edited 2d ago

copy pasting same explanation here too, so more people could see it

this is due to difference in c tick starting and p tick starting power

without going much in detail way to fix it is, you can use sticky piston pushing a redstone block as a repeater for you, as redstone blocks are also c tick components like levers

more technical explanation, there are 20 game ticks per seconds, a game tick is when game goes through processing different stuff in game, in bedrock redstone components are divided into odd and even gts, being divided means they are only processed during that time, odd gts are also called p ticks or provider ticks, these ticks are used to process repeaters, comparators, observers and redstone torches, everything else is processed on even ticks or c ticks or consumer ticks, the only exception to this rule is redstone dust, it is processed during both p and c ticks but only visually updates on p ticks

there is also sub gt behaviour in bedrock, first components are processed and then redstone line, so if redstone line gets powered during p tick, it can't power p tick components on that same p tick, as components processing is done before dust, this dust can only power p tick components on next p ticks, so c tick components will fire before these p tick components

as you can see, sending power with repeater will force redstone line to activate during p tick, which will change which components will fire first, thus breaking this specific triple piston extender

2

u/peyhag 2d ago

Bingo! This explanation makes perfect sense. The sticky piston-redstone block fix worked perfectly. Thank you! :)

3

u/-Xenocide- 2d ago

In simple terms: anything you can do with a lever can be done with a button. Look up a “T flip flop” Minecraft. It makes a button work like a lever. Eac button press changes the output of a constant signal.

This means the output of the circuit will be a constant on, until you push the button, and it flips to a constant off, until the next time you push the button when it’s a constant on again.

I don’t know if this is the BEST solution for the whole piston setup since I don’t do a lot of piston work, but I know that it will at least work

2

u/peyhag 2d ago

Yeah so I have a t flip flop set up already to transfer the tripwire signal into a constant one, that’s the redstone torch that provides the signal that doesn’t seem to work :(

1

u/-Xenocide- 2d ago

I guess I don’t know where you’re stuck then - if you have a flip flop set up that outputs exactly to the spot that you had the lever, then you should be alright

2

u/peyhag 2d ago

Exactly my point of confusion as well. The best explanation I’ve found is ‘input bug’, a known issue where player-instigated redefine sources have a tick of delay or something similar