Distinct Input Buses #451
Distinct Input Buses #451
Conversation
update required licensing information
This reverts commit 2e131db.
Remove BuildCraftAPI as its unneeded
|
This would be very helpful in automation of things that use molds, say with ae2 |
actually, this works perfectly. there is a default behavior which scans distinct first then combine |
| ITextComponent buttonText = new TextComponentTranslation("gtadditions.multiblock.universal.distinct"); | ||
| buttonText.appendText(" "); | ||
| ITextComponent button = withButton((isDistinct ? | ||
| new TextComponentTranslation("gtadditions.multiblock.universal.distinct.yes") : |
There was a problem hiding this comment.
I dont understand why I used universal instead of common -_-
|
|
||
| Tuple<Recipe, IItemHandlerModifiable> recipePerInput = itemInputs.stream() |
There was a problem hiding this comment.
you rewrite lots of code, but the only thing to change is that single line
There was a problem hiding this comment.
Its possible that it would be "functional" with a single change there, but there would be many places where the code is largely inefficient. I rewrote trySearchNewRecipe and checkRecipeInputsDirty because when the buses are treated distinctly, the caching for these methods will fail every single time. But with this change, it properly caches and will prioritize continuing with the same bus rather than swapping to other buses randomly.
Though in my testing, the separate buses feature from before was not functional, and would often use molds/shapes from other buses rather than the one in the current bus. But if I am wrong on this, and the single change in findRecipe is all that was needed to make this functional, then my code is still more efficient, as it will be able to stop in trySearchNewRecipe instead of improperly finding a recipe, and then scanning all buses again to know it has failed in findRecipe.
|
otherwise nice feature |
|
@huneau for me this seems okay and from Dan's testing seem to improve the behavior, is it okay to merge? |
First attempt
Offers much better efficiency than using stock one from AbstractRecipeLogic
This PR does 1 thing: it adds a button to the UI of a Large Multiblock (anything that extends
LargeSimpleRecipeMapMultiblockController) that toggles between "distinct" and "combined" item buses.What this means is, if the multiblock is in "combined" mode, it will behave just as it is now, treating all of the Input Buses as one large inventory for recipe matching and item consumption. If it is in "distinct" mode, each Input Bus is completely separate from others.
For example, if I have a Plate Extruder Shape in Input Bus 2 on my Large Extruder, and Steel Ingots in both Input Buses 2 and 3, then the machine will consume all of the Steel in Input Bus 2, creating Plates, and will not touch any of the Steel in Input Bus 3.
Another example. If I have a Plate Shape in Input Bus 2, and a Ring Shape in Input Bus 3, then any Steel put into Input Bus 2 will create Plates, and any Steel put into Input Bus 3 will create Rings.
The hover tooltip for the UI button:
This option is available for all Large Multiblocks, and is set to false by default to retain current behavior on update for players.