mrvn wrote:I think burner inserters should have 2 states: Normal and refuel.
They don't need more state. They can only take any load if they are empty and hovering over their pickup location. Whenever that is the case they can decide what to pick up depending on whether anything needs refuelling and what items are available. If they themselves or their drop target needs refuelling and some matching fuel is available, pick that up - else do, what they do now: pick up anything needed by the drop target, or if that has no special needs (like a belt or empty tile or something that does not take anything), pick up the first available item.
mrvn wrote:Setting a filter for a non-existent item should make it only pick up fuel.
Filters limit, what can be picked up. That is a sane vanilla behaviour that really makes sense and is already established also for inserters that transport fuel from belts into their drop targets.
There are no vanilla filter burner inserters. But if there where, they could rather easily be side feeded by another burner inserter (burner inserter chaining already just works with InserterFuelLeech). So i don't think, easier feeding of filter burner inserters is worth the a deviation from the well-known vanilla behaviour of filters.
mrvn wrote:I would create a priority queue (heap in an array is probably a good data structure for it). Put all inserter into the queue sorted by T. Then each tick you check the top of the heap. While T <= tick count you re-check the fuel situation of the inserter and either switch it to refuel state or normal and reinsert it into the queue.
A priority queue could indeed be the way to go. I could at least calculate the way back to the pickup position and avoid rechecking an inserter until it is expected to be near that. The game is deterministic so (in theory) i could get perfect pick ups (one tick before vanilla behaviour kicks in) that way.
I could implement it as a linked list for O(1) insert and pop.
Aeternus wrote:I've found that the rippling actually makes research inefficient, since the research packs moving through the chain of inserters shuts down research.
The labs keep researching as long as they have at least one of each required pack in stock. Feeding enough packs will keep em stocked so that removal of some packs does not dry em out as long as you do not use stack inserters for linking the labs or let more inserters take from a lab than are feeding it.
Never had problems with chains of lengths up to 5 labs in sequence.
Fuel moving out of burners however... that could create both problems and solutions. When would a burner know when not to do that?
That is an easy one: Remove fuel from a fuel inventory when the inserter itself or it's drop target needs refuelling. That is the logic implemented by InserterFuelLeech. It works just fine that way.
The only problematic case - where the player hand-feeds something that an inserter just has leeched some fuel for - is handled by the vanilla behaviour as expected: The suddenly unneeded fuel gets dropped into the drop target as soon as possible - wich could be never. It is the same behaviour you also get when force-feeding anything that is not chained.