Level Maintainer fulfills requests in a round robin pattern. #187
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes GTNewHorizons/GT-New-Horizons-Modpack#15253.
Previously, the ME Level Maintainer (LM) iterated over all requested items in order, and stopped if it found an item it could schedule or request. This results in items earlier in the list being checked more often, and items later in the list only when every item before them is already being requested.
The new behavior always checks every request in the maintainer and updates its status; this only uses constant-time lookups and does not query the ME crafting system. Further, at most one item is chosen to begin either calculating a plan for or actually crafting, and at most one of the two begins with every operation. Finally, the check begins from the next index with every operation, so that the maintainer tries to fulfill all requests in a round robin fashion.
The easiest way to demonstrate the difference is by video. All patterns shown are crafting patterns of the form White Wool + Dye --> colored Wool. The ME system has an interface with all the patterns adjacent to a Molecular Assembler.
Case 1:
There are no items stored in the system: all crafting requests will fail.
Old behavior:
old-missing.mp4
Items are being requested in an erratic order, crafts that are not possible to fulfill are stuck in the "Crafting" state for a long time.
New behavior:
new-missing.mp4
Crafts are requested in a round robin order, failed crafts report as such immediately.
Case 2:
The system now contains a supply of white wool and all colors of dye, so that all the requests can be fulfilled.
Old behavior:
old-crafting.mp4
Only the first requested item (orange wool) gets crafted, until the maximum amount is reached.
New behavior:
new-crafting.mp4
All items are crafted one after another in a round robin pattern.
To reiterate, there are no more requests (whether calculation or crafting) being made than in the previous implementation. At most one request is ever made in every operating cycle of the LM. The only thing this changes is which item is requested in each cycle.
Currently, the "starting index" where the LM begins making requests in each work cycle is not being persisted in NBT data. This means that after world/server restart, the LM starts by requesting the first item again. This could possibly be implemented so that a LM will always keep crafting the same items in equal amounts, even through world reloads.