search

Shadows-of-Fire / Shadows-of-Greg

An addon for GregTech Community Edition with the goal of making it much more complicated and realistic through the use of GregTech 5 Unofficial and GregTech 6 features.
GNU General Public License v3.0
16 stars 30 forks source link

Processing array Batches #171

Closed Gammelkebab closed 3 months ago

Gammelkebab commented 2 years ago

Im having issues with electrolyzer PAs. They will always take the recipes they took before, regardless of the amount of batches that would be. So a 16 machine electrolyzer PA will run full time on single batches of 3 silicon dioxide, while theres full 16x batches of (80) granite dust waiting to be processed, effectively wasting 15/16 machines and a ton of energy. This is likely not limited to electrolyzers but all machines that you continuously give several inputs to. My idea for that: Have the PA look for largest possible number of batches or at least prefer full batches, instead of preferring the previous recipe. Alternatively: Make PA processing time scale with batches, as in "You process M batches, it will take M/N (with N being the number of machines, and M being the number of batches) of the time". That way the PA MIGHT look for other recipes before that singular batch of silicon dioxide is coming back in.

Exaxxion commented 2 years ago

While I've run into a similar issue as you have, I solved it by having separate electrolyzers dedicated to processing the constantly appearing stone dusts. What you're proposing sounds like a useful feature, but has major flaws in practice.

Recipe lookups are the most expensive operation the PA does. Caching was added specifically to reduce the amount of time it spends doing that. The absolute worst case scenario for performance is when the recipe being processed changes every time.

Your proposal would necessitate that the current caching be discarded. Recipe lookups would not only need to occur every time the current recipe finishes, but the search would also need to produce an exhaustive set of matching recipes rather than stopping on the first matching recipe. In addition, another step would need to be performed by the algorithm in which the result set is sorted to determine which recipe utilizes the most machines, ultimately selecting the top recipe.

To say that this would be devastating to performance would be an understatement. The way recipes are implemented in GTCE is far from optimized for searching. One must iterate over a machine's entire recipe set, checking if it can be run.

Gammelkebab commented 2 years ago

Okay, heres another idea that would solve at least half of the issue. If I Electrolyze 16 batches of bauxite I am happy with that. meanwhile, other dusts are coming in and taking up the slots of the stacks of bauxite that were consumed in one batch. This means, since the electrolyzer will take that recipe again and again, it will no longer use full batches, even though enough would be available. Solely, because only one stack fits in the input bus. So my idea for that: Give us a way to make input buses with increased stack sizes. Make it possible to fit 16 stacks in one slot so that this cant happen.

Exaxxion commented 2 years ago

If the PA is processing bauxite, due to recipe caching it will continue to try to do so each time the prior batch completes until there is a check where there is insufficient bauxite to run the recipe at all. At that time it will look for the first recipe that can be run at all, which in your case happens to be whatever small quantity of some other thing is being drip-fed at just the right rate to keep it running one craft per batch.

The PA is working as intended. Your particular problem is solved by making better use of filtering (like keeping undesirable stuff out of that PA's input bus) or moving larger quantities of ingredients at a time into the input bus so it doesn't have the opportunity to run only a single craft.

Gammelkebab commented 2 years ago

I'd rather not brainstorm in here, but I couldn't find a channel to PM you over. What about making the PA behave like the Multismelter. If a batch is started that is less than the capability of the Multismelter, it is done faster. So the PA can do 16 batches, finds only one. Is done in 1/16th of the time.

Another way to make it good: give smart item filters in robot arms a counter to set the number of batches. So one could set it to only move N of the same electrolyzer recipe at once.

Exaxxion commented 2 years ago

Modifications to smart item filters would require changes be made to them in GTCE, which seems unlikely at this time.

It's an interesting idea, dividing the properties of the scaled-up recipe by the number of machines or something. I'll take it under consideration.

Exaxxion commented 3 months ago

This issue is resolved by GregTech Nomifactory Edition's Robot Arm and Smart Filter enhancements which allow for specifying a multiple of the base recipe ingredients to move at a time.

You can specify for example Supply Exact 16 and it will move 16 crafts worth of ingredient items for that machine (if possible for that tier of Robot Arm and the input can hold that many items), ensuring it won't recipe-latch smaller batches like when ingredients are drip-fed into the input bus of a PA.