Mix-mode recipe inputs to reduce menu-page clutter and actually use compressed items more
The recipe page for assemblers is getting cluttered, due to multiple ways of making the same output ( e.g. a recipe taking 3 inputs of 4 items each, and another to take 3 inputs of single-500-item-block to produce more output of the same thing ), so I propose a way to fix that
Firstly, for brevity lets call a 500:1 compressed asset like a kindlevine block a 'macro' asset.
Right now, because you can't split macro assets ( they either exist or don't, they can't be a 400-item lesser version ) the recipes are either all-macro or all-normal.
How about auto-allowing macro versions of any input to be handled, mixed with non-macro versions. It would work like this:
Say 3 inserters are feeding assets into an assembler, and it's outputting as normal. Then the left/slot1 inserter grabs a macro asset from the belt ( it's a mixed input line ), and inserts it.
Straight away, because one of its recipe inputs is a macro item, the assembler goes into 'macro recipe mode'. <cont.>
Comments: 3
-
22 Aug
SteAt that point, the middle/slot2 inserter is still inserting items from its belt,
but now instead of the machine only needing ( say 4 ) items to count as having enough of that recipe input, it now needs 500. So it keeps inserting over and over with the non-macro assets until that's reached,
assuming the right/slot3 inserter is doing the same thing, then when enough items are input, the assemble cycle begins and the internal input-items are removed/unretreivable, as normal.
Now supposing instead that once the assembler has entered macro-mode, the middle inserter has so far input 100 non-macro recipe items but a macro item ( of the same type ) is found on its belt and it tries to insert it. <cont.> -
22 Aug
SteAt that point the devs would have one of two options. Either they just count the assembler as having 2 filled macro-input slots so far, and put the non-macro 100 assets it already had in a new 'holding' slot just below ( but that would take up valuable screen space ),
or after inserting the macro item into the assembler, the inserter would automatically be 'given' the internal non-macro 100 items and it would revert to the waiting-to-insert animation, but be holding those 100 items.
Yes, I know the inserters can't hold that many, and if you were using a non-stack inserter for some reason then at that point it would magically end up holding 100 items that would normally be impossible to do so,
but all it would have to do is hold them for a while until the assembler was ready to receive new recipe items, then it would insert them at its normal speed ( or you could take them from it as normal via a pick-up command ). <cont.> -
22 Aug
SteThis way, there's never any attempt to split-up macro assets. You could mix them on the belts if you wanted and it would all just-work. We would then get the benefit of a) much less cluttered recipe screens, since the recipe variations would be automatic, b) ability to mix input streams without being stuck with machines that are only set to build macro or non-macro recipes and can get stuck waiting, c) actually having a use for all macro items, which is currently not the case - we currently only have very limited options for using some macro-asset types, which is annoying.
Just a thought.