Affects Version/s: Minecraft 1.8-pre1, Minecraft 1.8-pre2, Minecraft 1.8-pre3, Minecraft 1.8
Fix Version/s: None
Environment:Linux (Mint 16)
java version "1.7.0_55"
OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1~0.13.10.1)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)
When multiple repeaters are serially connected, and immediately adjacent (i.e., have no space between them,) several things go wrong:
1) Delayed "lock"
In version 1.7.10, the "lock" signal on a repeater locks the output with a delay of exactly one redstone tick from the point of view of the input of the laterally connected repeater. See `expected_repeater_lock_delay.png`.
In version 1.8-pre1 and 1.8-pre2, the lock signal is sometimes delayed by exactly one additional redstone tick.
This seems a lot like a bug, because it only occurs on repeaters in certain configurations, and in some configurations, only occasionally. And most importantly, it significantly reduces the set of redstone circuits with well-defined/intelligible behavior.
I have observed this only in connection with multiple serially connected, and immediately adjacent repeaters. Indeed, `expected_repeater_lock_delay.png` always looks the same, and always looks as as expected, in both version 1.7 and 1.8.
In circuits where the lock signal is synchronous, the bug appears to happen every time, and in a completely consistent way (see `bug-synchronous-1.png` and `bug-synchronous-2.png`.)
In circuits where the lock signal is produced by a manually activated switch, the bug happens roughly 1 out of 5 times. In most of those cases, the extra delay affects all but the last repeater in the adjacent series (see bug-asynchronous-1.png,) however, in roughly 1 out of 25 times, the first repeater in the adjacent series has the expected delay, i.e., is not affected by the bug (see bug-asynchronous-2.png.)
2) Loosing 1-tick off
The last repeater in a series of immediately adjacent repeaters fails to respond to a 1-tick *off* pulse even when all the repeaters are set to the minimum delay (i.e., ...1110111... becomes ...1111111...). This was not the case in version 1.7.10.