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
a month ago
0.16 - 2.0
88.1K
Logistics

b A crash in the newest version

a month ago
(updated a month ago)

When attempting to remove any entity in the map editor, the following error appears:


Error while running event InserterFuelLeech::on_object_destroyed (ID 178)
InserterFuelLeech/inserterRepo.lua:164: attempt to index upvalue 'state' (a nil value)
stack traceback:
InserterFuelLeech/inserterRepo.lua:164: in function 'forgetInserter'
InserterFuelLeech/control.lua:99: in function <InserterFuelLeech/control.lua:97>


a month ago

This can only happen when on_load happens without a state present in storage which implies that the mod didn't run for a single tick before. That's a pretty odd scenario. But I never used or read about the map editor before. So maybe that's how it's supposed to be...
I'll investigate further and probably fix the bug during the weekend.

a month ago

I fixed a bug which could lead to that error when loading a game with a pre-1.0.0 mod state. And I removed the on_object_destroyed handler and event registration because it's not needed and exposed the only event entry point without automatic state initialization.
While I couldn't reproduce the reported error, this should fix it.

But if you know how to reproduce the error in old v1.0.3 I would be interested in step-by-step instructions so I can check what actually has gone wrong.

a month ago

Thanks for the investigation. So here's some additional information:

  • Now the issue seems to cease to happen even though I still have 1.0.3, so this is probably a joint issue caused by another mod I was testing back then (which is later discovered to contain a bug that set surface_properties of some planet prototypes to empty tables)

  • Before I post this thread, I tested twice: I removed a tree on Nauvis (after doing something else) for the first time, and a chimney on Vulcanus (the first thing after the map is loaded) for the second; both actions immediately trigger the error.

The actual cause may be a bit complicated with limited information, but it seems safe to assume that this issue won't bother us now as long as everythings else are correctly set up.

a month ago
(updated a month ago)

Two things needed to happen for the reported error:

  • There needs to be no state in storage when an load event happens. By documentation, the load event only happens when the mod was in the save before. I changed storage format in v1.0.0. So loading of an older mod state would actually lead to this scenario.
    My load event handler didn't check for nil before copying the state from storage to a local variable for efficiency (I fixed that).
    The tick event handler does check for nil of the local state and just reinitializes it to self-heal though. That is probably why I didn't get reports from people continuing old saves from Factorio 1 on Factorio 2 (v1.0.0 is the first compatible version).

  • The object_destroyed event handler didn't check the local state for nil (I fixed that by removing the handler). So if after loading an old save an object_destroyed event happened before my mod's tick event handler in the first tick of the loaded game, the reported error is exactly what would happen.
    This event is documented to always fire at the end of the tick. But it looks like it still can happen before the tick event regardless.

This is definitely an edge case highlighting the need for always doing at least a quick sanity check when dealing with storage.
If you loaded a save with a pre-v1.0.0 Inserter Fuel Leech the case is somewhat explainable. Maybe, the tick event doesn't happen in editor mode and object_destroyed events happen on destruction rather than at the end of the tick (which could be far off in the future when editing a map). Another mod could have somehow registered every entity on the map to trigger an object_destroyed event.

If you didn't load a save with a pre-v1.0.0 Inserter Fuel Leech, it's a case for the X files because in that case the local state is a dummy which is a full functioning state with an invalid version field. It couldn't be nil in the object_destroyed event handler because the only write of an unknown value was in the load event handler.

New response