Item movement priority is pseudorandom

[gniftygnome]

This is the best vanilla-friendly hopper mod I have ever seen. THANK YOU!

When moving items horizontally via hopper, if there is a hopper with room below the horizontal line of hoppers, it will take priority and remove items from the hopper chain (allowing things like sorters). The ducts mod often but not always moves the item on to the next duct before the hopper below is allowed to acquire it. This means sorters must still be 100% hopper-based. In our testing, ducts greatly outperform hoppers for lag so we want to avoid using hoppers wherever we can. Therefore it would be great if ducts could be made to have a stable behavior similar to that of hoppers in this situation.

[gniftygnome]

We spent a while trying to create a simple reproduction case but from a gameplay standpoint this is a really complicated issue. However, we do understand it a bit better now. Here are some things we've learned from experimenting:

• When you first place a line of ducts over some hoppers, the game will most likely fill the hopper beneath the most recently placed duct. In order to see this, it is helpful to cover the hoppers with blocks, then one at a time break a block and replace it with a duct. This places the ducts in the opposite order from how you would naturally place them from the terminus back.

• Whatever hopper receives items after you have created the system will continue to receive the items until the chunk is unloaded (we think). If you teleport away and back, it can change.

• Once the chunk has been unloaded and loaded, all future loads of the chunk will show stable behavior (unless you modify the system again). What hopper receives items appears pseudorandom (but stable). We suspect it is an artifact of how the chunk is loaded/initialized.

• The above leads us to think there is an ordered list of ducts somewhere and the order of the list (rather than the position of the ducts relative to the hoppers) is what is determining which hopper can pick up an item.

[gniftygnome]

See the pull request but i think I've found a solution to the problem. I've tried to replicate vanilla behavior by setting the cooldown in the target duct to 8 ticks. This stabilizes the behavior by making it less dependent on the order the ducts tick. It also gives the hopper below time to acquire the item, so it appears to restore the behavior people rely on for sorters.

Note that setting the target cooldown to any less than 8 ticks will probably break sorters in the event the ducts are moving items continuously because they may move items more rapidly than the hoppers below can acquire them.

[gniftygnome]

I've had some time to research and as far as I can tell this is as technically correct a solution as seems to be available in Fabric mods to date. For example, it turns out Flytre's Hopper+ mod does basically the same thing (currently line 126 of HopperPlusBlockEntity.java). I have updated the pull request to make this behavior configurable. Please let me know if there is anything else I need to do in order to get this change accepted.