MC-11449Repeaters update very differently
There is a problem when a timer is run and repeaters are placed in different directions and chunks, but to the same wire.
Linked Issues
Low
Created Issue:
Repeaters update very differently
There is a problem when a timer is run and repeaters are placed in different directions and chunks, but to the same wire.
relates to
![[Bot] Arisa](../../../data/assets/gravatar/mustek2.png){kind=small}
13w11a: 36 fps main screen, 1500~1700 fps world selection screen, 180~200 fps pause menu, 40~110 fps ingame (SSP), 30~45 fps and slight movement lag ingame near these clocks (suferflat CSP), 5-10 fps and heavy movement lag when you move 10 chunks away from the said clock lanes' far end
13w12~: 36 fps main screen, 1400~1600 fps world selection screen, 200~220 fps pause menu, 50~130 fps ingame (SSP), 55~70 fps and very slight movement lag ingame near clocks (CSP), game freezes completely when you move 10 chunks away from the said clock lanes' far end
13w12~ reupload: 36 fps main screen, 1500~1600 fps world selection screen, 210~220 fps pause menu, 70~140 fps ingame (SSP), 90~120 fps and still a very slight movement lag ingame near clocks (CSP), game still freezes when you move 10 chunks away from the clock (definitely should re-report this separately)
Environment: win7sp1 x64, java 1.7.0_17, Intel Q9300 @ 2,50 GHz, 4Gb RAM, Geforce GTX280 v.314.07 @ 1024x768
Apologies, I can't keep up the good work of bug reports, I forgot my Jira
account and want to unsubscribe from updates. Thanks.
On Sun, Dec 6, 2015 at 12:01 PM, [Mod] Kumasasa (JIRA) <bugs@mojang.com>
wrote:
> [Mod] Kumasasa
> <https://bugs.mojang.com/secure/ViewProfile.jspa?name=kumasasa> resolved
> an issue as Awaiting Response
>
> Is this still an issue in the current Minecraft Snapshot 15w49b or
> later? If so, please update the affected versions in order to best aid
> Mojang ensuring bugs are still valid in the latest releases/pre-releases.
> Minecraft <https://bugs.mojang.com/browse/MC> / [image: Bug]
> <https://bugs.mojang.com/browse/MC-11449> MC-11449
> <https://bugs.mojang.com/browse/MC-11449> Repeaters update very
> differently <https://bugs.mojang.com/browse/MC-11449> Change By: [Mod]
> Kumasasa <https://bugs.mojang.com/secure/ViewProfile.jspa?name=kumasasa> Resolution:
> Awaiting Response Status: Reopened Resolved [image: Add Comment]
> <https://bugs.mojang.com/browse/MC-11449#add-comment> Add Comment
> <https://bugs.mojang.com/browse/MC-11449#add-comment> This message was
> sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c) [image: Atlassian logo]
>
Confirmed.
Came up with this clock oscilliscope setup while testing this report. Everything described below is valid as of 1.5.2pre. Fun facts:
0) This seemingly orientation-independent device consists of a simple repeater clock and 8 oscilliscope lanes (3 test lanes and 1 for control purposes on each side).
1) Each test lane in this device oscillates (almost) as expected when its respective controlling repeater (which are on gold blocks) has a delay that is lower than the clock has.
2) When lane's controlling repeater has a delay greater than the clock has, it should oscillate only when one delay is divisible by another, otherwise the lane should become locked. However, this does not happen to 1st and 3rd test lanes (repeater->block->payload and repeater->payload) when clock is set to 2 and repeaters are set to 3. Instead these lanes output a stable 3/5 signal. When toggled manually from 2 to 3, these repeaters are likely to lock their lanes. When toggled again to 4 in this locked state, they don't unlock the lane (like it happens on the reporter's video).
3) When lane's controlling repeater is delayed as much as the clock is, 1st and/or 3rd test lanes may output a 3x/x pulse instead of expected x/x (for instance, 6/2 where 2/2 was expected). This depends largely on redstone wiring (e.g. which exact quartz block is used to support the wire which transports signal to the lanes).
4) When all delays are set to 1, every lane (including control lane) outputs either 1/1 or 3/1 pulse. This also depends on wiring. Generally, if 2-clock pulse passing over some exact quartz block does generate 6/2 strobes on 1st and 3rd lanes, then 1-clock pulse passing over that block will give a 3/1 strobe on every lane.
5) Set the clock delay to 1. If you swap your controlling repeaters for comparators, they will lock test lanes in low state. If instead you swap first receiving repeaters of each lane for comparators, you'll get to see that either all four lanes are down, or 1st and 3rd test lanes are locked up, or even all the test lanes are up. This, surprisingly, depends on timings: you have a chance to get each outcome out of these three after reconnecting the redstone through any quartz block you like in the exact wrong moment.
6) I have built two similar devices: one 2 chunks east and one east-oriented a dozen chunks southeast. They had to be wired through some other quartz blocks to output the same doughnutlike patterns as this device does without comparators.
This seems to behave differently depending on position in world, perhaps related to the order of redstone updates in a wire? like MC-11193?
I really want both of these fixed >.<
wowowowowowowowow awesome I love it
The first 3 repeaters in your video seem to follow the same cycle, however to moment of placing might have given the offset of the phase.
However I do have a video in which the a similar phenomenon in demonstrated at the beginning: in certain positions 50% of the off-pulses get ignored.
@fibonatic
Glad you confirmed this. It also highly depends on how the signal is transported off the clock and - at higher delays - on how the payload (if any) is connected to a repeater.
No progress made here since back then, I guess.
It is still happening:
http://youtu.be/jgwoGZUOEFY
Issues start at around 1:40
On second thought, is this really a bug?
Since the delays are not in alignment, it sounds more like an aliasing effect, which is also an issue in the real world.
I guess the repeaters which are supposedly "out of sync", are just doing their sampling (checking their input) at different points of time, resulting in a different output sequence.
Changing that behavior to something else would probably lead to a lot of other issues and is probably hard to code in a satisfying way.
Yep, it is. Also, it might be related to MC-11193.
Reopened, thanks
Still present in 1.8.3
Is this still an issue in the current Minecraft Snapshot 15w49b or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
Reporter's device (see vid in description) easily reproduced on latest snapshot (15w49b).
Is this still an issue in the most recent versions (i.e. 1.10.2, or 16w42a) of Minecraft?
No. Tested the build of the YouTube video linked in the description with 16w43a.
When loading a save file, an already running clock still had that problem.
When resetting the clock however, I was not able to reproduce the problem anymore.
Apologies, I can't keep up the good work of bug reports, I forgot my Jira
account and want to unsubscribe from updates. Thanks.
On Sun, Dec 6, 2015 at 12:01 PM, [Mod] Kumasasa (JIRA) <bugs@mojang.com>
wrote:
> [Mod] Kumasasa
> <https://bugs.mojang.com/secure/ViewProfile.jspa?name=kumasasa> resolved
> an issue as Awaiting Response
>
> Is this still an issue in the current Minecraft Snapshot 15w49b or
> later? If so, please update the affected versions in order to best aid
> Mojang ensuring bugs are still valid in the latest releases/pre-releases.
> Minecraft <https://bugs.mojang.com/browse/MC> / [image: Bug]
> <https://bugs.mojang.com/browse/MC-11449>
MC-11449> <https://bugs.mojang.com/browse/MC-11449> Repeaters update very
> differently <https://bugs.mojang.com/browse/MC-11449> Change By: [Mod]
> Kumasasa <https://bugs.mojang.com/secure/ViewProfile.jspa?name=kumasasa> Resolution:
> Awaiting Response Status: Reopened Resolved [image: Add Comment]
> <https://bugs.mojang.com/browse/MC-11449#add-comment> Add Comment
> <https://bugs.mojang.com/browse/MC-11449#add-comment> This message was
> sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c) [image: Atlassian logo]
>