Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Suggestion] Prevent parallel machines from getting stuck on the same recipe #16

Open
Doniazade opened this issue Jul 27, 2022 · 2 comments

Comments

@Doniazade
Copy link

The problem: With parallel machines it's more efficient to craft recipes in larger batches since it results in higher throughput. However, machines will keep crafting the same recipe as long as ingredients are available. This means that if there are streams of several items coming in one item will keep being processed in small batches until the others build up enough to block the input bus, slowing down throughput and causing significant delay before ordered items are done.

This is especially apparent with the bulk blast chiller, which can easily be blocked by a constant stream of hot ingots from something like the naqline or rutile processing.

Suggestion: Add some mechanism for breaking this soft lock, for example by having the machine periodically reevaluate whether to switch recipe.

Thanks for a great set of mods!

@ALongStringOfNumbers
Copy link
Contributor

This behavior is due to the recipe lookup for both singleblock and multiblock machines favoring the previous recipe used, if one exists and the inputs for the recipe are present, for performance reasons.

Favoring the previous recipe allows for avoiding doing constant recipe lookups every time the machine finishes a recipe.

As for a method to avoid this, you can use a Robot Arm to move items into the input buses. This would allow you to use the "Keep Exact" function of the Robot Arm to ensure that there are always enough inputs in the input bus to run recipes in large batches, rather than trickling in small batches. For example, if you have a multiblock that can do 16 parallels, you could have a robot arm that inserts inputs in sets of 16, so that as many parallels will be run as possible. Of course, the Transfer Rate on the Robot Arm does need to be high enough for this.

@Doniazade
Copy link
Author

Fair enough, I know the standard behavior is necessary for performance and I was just suggesting a separate periodic check, say every 5-10 sec, to break this kind of getting stuck. But I'll just use a robot armed buffer for problematic inputs then, good suggestion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants