Put the summary of the bug you're having here
What I expected to happen was the comparator would continue working when I reloaded or download a map and opened it
What actually happened was the comparator was stuck on it's previous state when I open a map I downloaded and also reloaded a map on my server
Describe what happened here
Steps to Reproduce:
1. Put two hoppers facing each other
2. Put a comparator on one of the hoppers
3.Put a item in one of the hoppers
4. Restart you world of server with the map and check the comparator
Linked issues
is duplicated by 2
Attachments
Comments 29
Because when I was ma king a map and had my friend down load my world i had two hoppers and a comparitor concted and had a bunch of command blocks and they didnt work so I changed them out for a comand block that had the command "say test" and it dint say test but the item in the hoppers was moving. When I added a new conparitor on ther other hopper it worked. Then I replaced the original comparator and it worked.
The bug in this particular case was that the two neighboring hoppers would get almost exactly the same cooldown tick. This meant that instead of hopping the item every ~4 ticks, the item would stay in either hopper 7 or 8 ticks and in the other one 1 or 0 ticks. The comparator is not updated frequently enough to notice this, so it looked stuck.
I've fixed this issue by aligning all hopper ticks to the level's game tick, at a rate equal to half of the hopper's interval (i.e. 4 ticks). Obviously this may have new side effects that I'm sure the community will discover. Especially if a redstone contraption relies on hoppers to update more frequently than every 4 ticks.
@unknown I've seen a few fix notes by now from you (also on Reddit), not only I do very much appreciate these, thank you very much!
Although it steals a few minutes of your time, I know from own experience that in some bugfixcases the community was asking themself what exactly was the issue now, or how it was fixed/what to expect now as new behaviour, which is also a good thing to know how the game is supposed to work from Mojang's view, so we can look out for anything out of the normal (= bugs).
Thank you again }=)
@unknown Thank you a lot for the fix notes! Really helpful 🙂
As you said there are a few side effects with aligning hoppers with the game tick.
Since hoppers can interact with components that can change in every tick, hoppers will appear to have a bit more or less delay dependent on the time they were triggered.
Many designs that use hoppers for timing will now have 5,6,7 or 8 ticks delay at random and considering random factors in redstone designs is always tricky for the player.
@_Eta740_ pointed out some of these cases on Twitter: https://twitter.com/_Eta740_/status/763452453303967745
The issue comes from the way the hoppers cooldown is reset when another hopper places an item in it.
It only resets the cooldown if it was ready to transfer items already. If the cooldown was almost done before it stays there.
Which can lead to neighbouring hoppers having almost the same cooldown (see Jeb's comment).
Resetting the cooldown each time an item is placed inside the hopper is not really an option, because then hoppers that get fed from two sides would just not transfer anything out.
Potentially an alternative hack-solution for this issue could be to also reset the cooldown to 4 if the hopper was empty before and the cooldown was not done yet.
It's such a specific case that it probably wouldn't affect too many other cases (even though it probably would allow for some kind of "super charged hopper line").
More generally I think that the cooldown is used for two things here:
1. Limiting the hopper to one action every 8 ticks
2. Making sure each item stays for some ticks inside the hopper
Handling the second case on a per stack basis instead would make the timings more predictable (e.g. when a stack was added to an empty slot it can't be moved out for 4 ticks).
Tricky as always with redstone changes.
Thanks again for the fix notes! 🙂
I kindly attached the repercussions of alligning hopper cooldown with global clock (see the attached 1.10 and 1.11 images), This causes, as Panda4994 indicated - dependency of comparator response based on when a hopper receives an item, thus making hopper response time unreliable.
Another possibility I could suggest to solve the issue mentioned in this bug report would be to allign the cooldown of hoppers on chunk load, and then leave them be. This should fix the reported bug, as all hoppers will be loaded aligned to the same central clock when chunks are loaded (in any order), but would keep their response with 1-tick resolution.
Duplicate of MC-16716