Space Walker

Here is a simple reproduction case. Flicking the lever off causes the top wire to depower entirely, while it should reduce its strength to 14 instead.

The issue is in `ExperimentalRedstoneWireEvaluator#propagateChangeToNeighbors`. After the top wire depowers, it tries to enqueue neighboring wires, but since the block below it is not a conductor, it skips over the wire diagonally below it. This in turn means the top wire is never enqueued for turning on again. You want to make sure a wire enqueues neighbors it can provide power to, as well as neighbors it can receive power from. Removing that skip will fix this bug.

Hi all,

Like a few before me I have attempted to fix some of the issues with the current implementation of redstone dust. It is both laggy and unpredictable, making it a pain to work with, and leading to it being the most avoided redstone component in the game. Before I get to my solution to these issues, though, I want to acknowledge the work done by @unknown and @unknown, as both have been an inspiration in one way or another.

My implementation is mainly developed as a Fabric mod but has also been implemented into Paper.

Like the other two implementations, mine does not solely address the lag issue. It is a complete re-write of the power propagation code, fixing MC-11193 in the process. It is not a re-write of redstone as a whole, however. I attempted to keep existing behaviors as much as possible while fixing the lag of and inconsistencies with redstone dust that make it hard to rely on. To be more specific, it addresses the following issues:

1. Redstone wire does unnecessarily many calculations. Each wire in a network may calculate and update its power level over half a dozen times before settling on its final value. Moreover, each time it does so, it updates itself six times, doing even more completely redundant calculations.
2. Redstone wire emits unnecessarily many shape and block updates. This is, of course, related to the previous point, as a wire updates all neighboring blocks (and itself) each time it updates its power level. However, even if only the previous point is fixed, there would be many redundant shape and block updates that can be removed.
3. Redstone wire behaves unpredictably. The order in which a wire updates neighboring blocks is dependent on the location of the wire. Combined with the chaotic nature of the brute-force algorithm with which it updates, this makes it nigh impossible to predict and rely on how a wire network behaves.

I have designed a wire handler that addresses these issues in the following ways:

• When a wire is updated, a breadth-first search through the network identifies all wires that require power changes, and finds any power sources around the network. 

• If a wire is found to be unsupported, its removal and subsequent effects on power propagation are integrated into the search.

• Power is spread from the power sources outward to give each wire its new power level.

• Wires are updated in order of power level, from highest to lowest. This ensures power is spread most efficiently and makes the update order very predictable and intuitive.

• Each wire emits shape updates as it updates its block state, in the standard { west, east, north south, below, above } order.

• Shape updates to neighboring wires are avoided, as they are redundant.

• Each wire emits block updates in an order dependent on the local direction of power flow. This leaves the update order nearly completely consistent across all locations and all orientations. All credit goes to @unknown for this idea. Unlike RedstoneWireTurbo, however, my implementation exibits directional rather than random behavior in the cases where the direction of power flow is ambiguous, though this is trivial to change.

• Block updates to neighboring wires are avoided, as they are redundant.

• While Vanilla parity is not 100% preserved, by far the biggest change is that contraptions that are locational in Vanilla work either everywhere or nowhere with this implementation. Beyond that parity issues appear to be rare.

• The number of shape and block updates emitted is reduced by ~20x.

• The MSPT contributions of redstone dust are reduced by up to ~20x.

Sorry if I wasn't clear in the report. The bug occurs when sending power through the repeater, not when toggling the delay on the repeater.

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).

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. 

The observer is not providing constant power. The piston is powered by the redstone wire on top of the observer due to MC-108.

It's just block 36. 

This does not occur in 1.11 or 1.12. 

MC-109799 is not the same issue. My issue arises regardless of how the sticky piston is powered. 

This behavior has been in the game for a very long time. Redstone dust is not redirected if it goes up a slab. It looks redirected, but that's just a visual glitch. It's actually very useful behavior.