ME Export Bus - Use the whitelist as a priority in Schedule Mode/Add Blocking Mode.
Slaymeister opened this issue ยท 3 comments
Not sure if the first half of this suggestion is a bug or a feature. If not, I'm am submitting this as a single feature request, so I am submitting one post. I can break this into two if that is preferred.
When using an export bus with expansion cards in schedule mode, an ME Export Bus appears to begin on the top-leftmost item to send first. Once that item is depleted, it checks items left to right, then top to bottom.
However, once an item is no longer sending, it does not appear to reset the list until it has sent all following items in the whitelist. My suggestion is to restart the list after failing to send so that it becomes a priority.
Example, if an export bus was configured to send viable fuels to a single stack inventory. The player prefers to send by priority Charcoal Blocks, Coal Blocks, Charcoal, then Coal. With the current behavior, if it ran out of Charcoal Blocks, it would continue sending Coal Blocks until there were no more Coal Blocks even if Charcoal Blocks subsequently became available. This change would have it go back to preferring Charcoal Blocks every time they became available.
Not sure if it is already expected to work that way. It will naturally get "stuck" if it is topping off a single stack inventory, but I've tested this with single item/quantity 1 inventories such as pedestals. These are empty every time an item is removed, and export buses will continue sending the same item rather than resetting to an available top-left item.
The Add Blocking Mode portion of the suggestion is definitely not existing behavior. This suggestion is to implement a blocking mode option similar to the ME Interface. Selected in the GUI, if items exist in the inventory, do not send. Because of the nature of Export Buses, this would have the impact of sending a single item at a time even if multiple item types were "whitelisted".
These behaviors could be attached to a prioritizing upgrade card to avoid disrupting existing setups.
Reasons why it should be considered
This provides considerable additional flexibility in AE export flexibility in certain situations that cannot be accomplished by adding other mods. Combined, they enable users to control a preference where many interchangeable items will work but are not equally desirable.
This includes combustibles as fuel sources, for furnaces, generators, reactors, etc. A consumable item would be supplied to an inventory, removed, then the next item supplied would consider the prioritized available item types before sending. For example, a user of a nuclear reactor would not have the AE2 network crafting all of their uranium ore into low grade nuclear material when they have higher grade post-fission products available. Another scenario would be to keep using renewables like charcoal blocks rather than using up all available coal ore if the supply of logs ran low momentarily. The combination also provides the switching mechanism by preventing a send operation until the receiving inventory is cleared (ie., avoids adding to an existing stack.)
Minecraft 1.12.2
AE2 rv6-stable-7
ModPack ATM3 5.12.3
Blocks/Parts in AE2 are not designed to solve everything by themself. In terms of the export bus, just export stuff. But not handle stockkeeping, reactor control and what not.
These goals can be achieved by simply combining different parts together. This certainly requires more space, yet again this was never a design goal to stuff everything into a single block. Especially as the minecraft world is pretty much infinite.
In terms of priority, an export bus will always start with the top left item. Except if put into (semi) round robin or random mode. These should be pretty self explanatory. Of course it is also limited by the target inventory. In case the inventory is full and cannot accept the first item, it will try every other item until it checked all or found one being accepted. This might run into some race conditions. E.g. the export bus always exporting before the inventory is free, thus being forced into exporting some random item instead of the first one. However these things can be solved by controlling the export bus, e.g. only operate once the target inventory is empty.
In that case, this is a bug. Once a slot is exporting, the code doesn't reset back to the first slot until the network is empty of that item. If it never empties of that item, it will not go back to the first (highest priority) item. The easiest way to see this is a single item inventory such as a pedestal. Once the item is taken, the inventory is open and can accept the highest priority item, but it will continue with whatever item it was on.
I created a fix in PartExportBus.java that resets the priority. My testing is showing it allows the slot to reset during exports.
A couple more things, one is that the priority is not top-left to bottom-right, but is closer to the order the slots are enabled by expansion cards. So middle, then a cross, then the corners. The top-left slot is about priority 6 of 9.
Also, my fix may disrupt tick acceleration for repeated successful exports since it forces the bus back to slot 0 after an export success to see if there is a higher priority item that is valid to send for the next item. I haven't dug into that section of the code to be sure, I just wanted to put that out there before I sign off for the night.