Inserter Fuel Leech


In addition to normal behaviour, all Inserters take fuel from entities containing a burner when they or their drop target have no fuel left.

Tweaks
2 years ago
0.16 - 1.1
67.1K
Logistics

a Working on 2.0 and UPS improvements

2 months ago

I am working on a full rewrite improving UPS load and it will be compatible with 2.0 Vanilla and Space Age.

2 months ago

Yay!

2 months ago

Can't wait! Didn't even realize this mod wasn't vanilla, I've gotten so used to building my steel smelters a certain way :) Take your time, of course

a month ago

Any progress? This is kind of a must have QoL mod for me..

a month ago

I got it working and can currently play on a map with a few hundred inserters that need to leech fuel for themselves/targets and 2k inserters that don't need to leech with mostly 60 UPS.
But there are nasty UPS/lag spikes caused by my naive scheduling logic for half a second every few seconds. I have to fix those before I dare to release it to the public. I also have to reduce the overhead for non-leeching inserters a bit more to allow players to just use less leeching inserters instead of having to fully remove the mod when they reach endgame (still no mega base support planned though).

I keep working on it on weekends until it's done.

a month ago

Awesome news. Is there any chance you can update the github repo with what you have now? I've been meaning to get back into modding again and I would love to try and help.

a month ago

I'll update the repo when I work on the mod again. That's likely this weekend.

a month ago
(updated a month ago)

BTW, why this mod needs ANY logic? It already sets the flag allow_burner_leech for all burner inserter prototypes in data-final-fixes.

a month ago

It needs the logic to implement refueling of inserters from the drop target, refueling of the drop target from the fuel inventory of the pickup target and cheat-refueling inserters when already out of fuel from the pickup or drop target.
allow_burner_leech only implements refueling inserters from the pickup target and this sadly is just ¼ of what I want my mod to do.

The mod has to look at each inserter periodically and find out whether it or it's target needs fuel and where to get it from. Then it predicts when the inserter is in position and looks again at the inserter at that tick. It moves items directly from the source into the inserters hand to make it deliver it or refuel itself.
There is always a chance that this fails due to timing or logic imperfections. So if an inserter actually does run dry, it gets one fuel item from it's hand, pickup or drop directly teleported into its fuel inventory.
I know that sounds simple. But it's surprisingly tricky to do in a UPS-friendly way for thousands of inserters.
The implementation in development is built around a ring buffer of tables that hold all the inserters to be updated in one of 3600 ticks (that's a minute worth of ticks). I am currently testing, how long I can make the time between checks of inserters before it gets too noticeable that inserters don't immediately react to changes in their environment.
The prediction of when an inserter will likely hover over something are also subtly diffuse as inserters don't always need to go over the center of an entity to pick something from them.

a month ago
(updated a month ago)

allow_burner_leech :: bool
Default: false
Whether this burner inserter can fuel itself from the fuel inventory of the entity it is picking up items from.

  1. Picking up fuel from the pickup target inventory is how the burner inserters work in game; there's no additional logic need on that (allow_burner_leech is false for the burner inserters)
  2. Picking up fuel from the pickup target fuel inventory is what's allow_burner_leach stands for
  3. Pickup up fuel from the drop target fuel or normal inventory is questionable and counter-intuitive
  4. Cheat-fueling inserters is the only OK thing

For the most use-cases, allow_burner_leach=true should be enough.
Maybe keep other two UPS-hangry things as opt-in, not opt-out?

Maybe we should request an event on_burner_out_of_fuel?

a month ago
(updated a month ago)

If you just want allow_burner_leach=true, that is a trivial mod to do and very likely has been done multiple times by others already. Just use one of those.
on_burner_out_of_fuel would be great to have for cheat refuel. But it needs to fire earlier than actually running out of fuel to make it viable for the remaining two use cases.

Wube in general has a high resistance against adding events relating inserter behavior for performance reasons (and I definitely understand that the vanilla use case is way more important than my niche-of-a-niche mod).
I suggested some event and extra priority filters or pickup preferences (to be used by mods exclusively and further limiting the user-set filter) on inserters in the past.

a month ago

If you just want allow_burner_leach=true, that is a trivial mod to do and very likely has been done multiple times by others already. Just use one of those.
on_burner_out_of_fuel would be great to have for cheat refuel. But it needs to fire earlier than actually running out of fuel to make it viable for the remaining two use cases.

Wube in general has a high resistance against adding events relating inserter behavior for performance reasons (and I definitely understand that the vanilla use case is way more important than my niche-of-a-niche mod).
I suggested some event and extra priority filters or pickup preferences (to be used by mods exclusively and further limiting the user-set filter) on inserters in the past.

Even though I agree, this very mod is part of the official SE modpack, that's why i vote for the simplest solution which covers 99.9% use cases, especially for 2.0 where you can issue construction robots to fix stuff remotely.

a month ago

Okay, you actually have a point there.
I add default-on NoLogic/LeechFromPickup/LeechFromPickupAndDrop options for solid-fuel burner inserters and other inserters (just electric in vanilla. but there are mods adding some powered by fluids). That also fixes the megabase (or potato CPU) case that will never be good otherwise no matter how much I optimize it.

New response