MC-18676Comparator/hopper chaos
I am confused by this machine. Seriously. Hoppers, comparators, or repeaters seem to work differently depending on the position. (Not quite sure which thing's fault this is)
I encountered at this specific position, on a bukkit server, with a optifine client. However, I can reproduce in single player on a vanilla client.
I haven't yet tested in the snapshot build, but it is likely this will still exist then.
It may very on position, but I built the two devices on my case at specific places, with the back quartz block that at the given coordinates, the block behind that the lever, and the rest of the machine infront, from f=0 (SOUTH).
Coordinates of #1: x: 3134.5 // c:195 (14) y: 34.0 z: 6278.5 // c: 392 (6) Coordinates of #2 x: 3130.5 // c: 195 (10) y: 34.0 z: 6278.5 // c: 392 (6)
Weirdly, if you break and replace the hopper, the problem may disappear or reappear on the other side.
Probably some hash order thing.
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
Created Issue:
Comparator/hopper chaos
I am confused by this machine. Seriously. Hoppers, comparators, or repeaters seem to work differently depending on the position. (Not quite sure which thing's fault this is)
I encountered at this specific position, on a bukkit server, with a optifine client. However, I can reproduce in single player on a vanilla client.
I haven't yet tested in the snapshot build, but it is likely this will still exist then.
It may very on position, but I built the two devices on my case at specific places, with the back quartz block that at the given coordinates, the block behind that the lever, and the rest of the machine infront, from f=0 (SOUTH).Coordinates of #1: x: 3134.5 // c:195 (14) y: 34.0 z: 6278.5 // c: 392 (6) Coordinates of #2 x: 3130.5 // c: 195 (10) y: 34.0 z: 6278.5 // c: 392 (6)Weirdly, if you break and replace the hopper, the problem may disappear or reappear on the other side.
Probably some hash order thing.
Attachments2
- Unresolved
- Open
- Unconfirmed
- Creative
- comparator hash hopper hopper_clock redstone repeater weird
- 1.5.2
I wouldn't call that "chaos":
They are on the same delay. It doesn't always do it.
Could it be that the items are moving from one hopper to another and back again in the same tick, depending on update order? My impression of the relevant underlying mechanics is that in the course of one tick, all "pull" operations are done in one pass, then comparators check the inventories, then all "push" operations are done. What's unclear is whether they just perform the individual operations in sequence, or if they went to the extra work to simulate simultaneity. Probably the former, considering things like the existence of the south-east rule.
I'm also not too clear on the 8-tick-per-item mechanic. Does it actually take 8 ticks to move an item, or does the item move in one tick, and then there's a 7 tick delay before the next one moves? I think it's the latter, considering comparator behavior. But I don't know if hoppers are synchronized globally, or if the individual hoppers could be out of sync.
They are on the same delay, one flashes while the other doesn't.
It is confusing, and unreliable. Thus, it is a bug.
Is this still a concern in the current Minecraft version? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
It is "fixed" in the weird way of them staying on for 1 cycle, then off the next, but it is somewhat stable. I will probably make a new ticket to describe this other effect, close this one.