Redstone components that are (de)powered as a direct result of player actions lose 1 tick of delay.
All player actions cause this behaviour, including:
Flicking a lever on or off
Pressing a button
Stepping on a pressure plate
Activating tripwire
Placing or breaking blocks
Right clicking a note block, opening or closing (trap)doors and fence gates, changing the delay on a repeater, etc.
Executing commands
Interacting with containers (adding/removing items)
Any redstone component that has delay is affected by this behaviour, including:
Repeaters
Comparators
Redstone torches
Droppers
Dispensers
Observers
Redstone lamps when depowering
Buttons when depowering
The attached screenshot ("input_bug.png") shows a simple mechanism to showcase the behaviour.
If the lever on the purple wool block is powered, the redstone torch will lose 1 tick of its delay, which results in the red line depowering 1 tick before the green line.
If instead the lever on the blue wool block is powered, the redstone torch has its usual 2 ticks of delay, and both the red and green line depower in sync.
Code analysis
This behaviour occurs because player interaction packets sent by the client are handled before the world time is incremented. New tasks are usually scheduled after the world time is incremented, so scheduled tasks as a result of player actions skip 1 tick of delay when the world timer increments.
Incrementing the world time after all the dimensions have been ticked will fix this issue.
Linked issues
relates to 1
Attachments
Comments 10
A few more interactions that trigger this behavior includes
End platform refresh by player
Using hoe on dirt
Trampling farmland
Growing trees with bonemeal
I think it's not a bug but a game phrases execution order feature in a single gametick. The missing 1gt delay is exactly what those tiletick component should behave. This behavior has existed in a lot of versions and works quite stably. It's also useful when distinguishing player input with other type of input
I was inclined to label it a bug because it can break contraptions purely by how you power them. You could build something that works as long as you power it with a lever but it would break if you power with a repeater, or vice versa.
I understand this behaviour has its uses but I think redstone should behave the same whether you power it with a lever or a repeater.
This behavior is not just limited to players, other entities powering tripwires/pressure plates cause the 1-gt delay loss.
other entities powering tripwires/pressure plates cause the 1-gt delay loss.
Entities are processed after block events. So entity activated inputs do not cause redstone components to lose 1 tick of delay, but rather they cause pistons to gain 1 tick of delay. For a similar reason pistons appear to extend in 3 ticks (while in reality it takes 2 ticks). These two things are different behaviour than the bug described in this ticket, and I'm not too keen on having them patched (at least in the case for moving blocks).
And btw mojang never releases an official way to divide gametick between game phases,. All theories how we divide and define gametick are un-official. In my opinion you CANNOT say that mojang's code has a bug, just because your own theroy that defines the gametick with something hard to explain
For example if you use the theory that divides two different gametick with Advance gametime phase instead of the code order, everything about tiletick delay will be solved easily. TileTick component gets signal at gametick n with delay x gametick will ALWAYS execute at gametick n + x TileTick phase. And the delay of other BE / TE components can also be explained as they only execute at they phases but their phrases in this gametick has passed so they needs to wait until next gametick.
But this theory is based on in-game timings and code analysis
E.g. it's not actually a theory, but fact
imo you can say "contraptions behave differently with player input or tiletick input" a bug, but you can't say "redstone components lose 1 tick of delay from player input" is a bug, as I said above it's based on the way you explain it. These two are different things
can confirm in 1.18.1
Confirmed 20w07a