[Rseding] [0.18.8] Burning a fuel with burnt_result in a burner with no result slots locks up burner

[calcwizard]

What did you do?

Placing a fuel item with a burnt_result into an entity with a burner source that has a burnt_inventory_size of 0 causes the item to burn as expected until the heat runs out (when the burnt_result would be created), at which point the burner locks up. The burner won't burn any more fuel (even a different type of fuel) and there is no way to remove the burnt_result to unclog it. The only way to fix it is to remove the entity.

What did you expect to happen instead?

Either the burnt_result would be discarded so the entity can keep working or for the entity to not allow that item to burn in the first place.

[darkfrei]

> What did you expect to happen instead?

1. You cannot insert fuel with burnt_result to entities, that have no burnt_result_inventory.

2. (Alternative) The game changes all prototypes and set up the burnt_result_inventory if any fuel with burnt_result is acceptable for this entity.

3. (Alternative) The burnt_result_inventory will be enabled for all entities, but hidden until the fuel with burnt_result will be inserted to the fuel slot and hidden again when no fuel or no fuel with burnt_result.

[Rseding91]

I could change this, but I kind of see it as not a real problem. If a mod defines a fuel as having a burnable result then it should make sure it has a fuel category that works with what ever burners it's compatible with.

For example: the base game doesn't let you put nuclear fuel cells into the furnace by using different fuel categories. And the reactor has a burnt result output slot which it is compatible with.

[Mylon]

What if the game failed to launch if it found an incompatability? Store a flag for each fuel-category that contains a burnt-result among the items and check each entity with a burner if it uses that fuel category and has no output slot, it throws a startup error.

[Deadlock989]

What if the game failed to launch if it found an incompatability? Store a flag for each fuel-category that contains a burnt-result among the items and check each entity with a burner if it uses that fuel category and has no output slot, it throws a startup error.

This would be pretty useful in debugging. But it's not just not having an output slot - "burner assemblers" can't ever work properly with fuels that have a burnt result unless you take brute force scripting measures to empty their burnt result slots, because inserters will always ignore the burnt result slots in favour of the recipe output slots. If burnt result fuels were only ever intended for use in generators, reactors and vehicles (the single fuel in vanilla that uses it can only be used in reactors), maybe they should be restricted to those entities. Yes, it's the mod creators' responsibility to make all that work, but it's far from obvious what the full range of consequences are of giving fuels a burnt result.

[darkfrei]

You can just add to the mod the dependency to https://mods.factorio.com/mod/BurntExtractor or any another if it exists.

[Deadlock989]

You can just add to the mod the dependency to https://mods.factorio.com/mod/BurntExtractor or any another if it exists.

No, that's my worst nightmare. If a problem requires you to store thousands or tens of thousands of entities in a global table and poll every single one of them every single tick, something is clearly very wrong.

[darkfrei]

You can just add to the mod the dependency to https://mods.factorio.com/mod/BurntExtractor or any another if it exists.

No, that's my worst nightmare. If a problem requires you to store thousands or tens of thousands of entities in a global table and poll every single one of them every single tick, something is clearly very wrong.

Not thousands of entities, but just only special inserters, and only if the entity has burnt_result.
Not thousands of entities per tick, but just only one/several entities per tick. The fuel burns not too fast and it will be nice to extract it as whole stack.

[Deadlock989]

Not thousands of entities, but just only special inserters, and only if the entity has burnt_result.
Not thousands of entities per tick, but just only one/several entities per tick. The fuel burns not too fast and it will be nice to extract it as whole stack.

I don't want to make players use "special" inserters to access a simple game feature.

I don't want having 60 inserters in the world to result in a delay of up to one second for any one of them to work. 120 inserters, 2 seconds. 1000 inserters, 16.67 seconds.

I respect your personal choices but this is not a workable solution for me. My view is that if burnt result fuels break assembler functionality without brute force scripting intervention then perhaps assemblers shouldn't be able to use them.

[darkfrei]

I don't want to make players use "special" inserters to access a simple game feature.

I don't want having 60 inserters in the world to result in a delay of up to one second for any one of them to work. 120 inserters, 2 seconds. 1000 inserters, 16.67 seconds.

I respect your personal choices but this is not a workable solution for me. My view is that if burnt result fuels break assembler functionality without brute force scripting intervention then perhaps assemblers shouldn't be able to use them.

I know, it will be much better if vanilla inserters can grab from any (result) inventory. The can grab fishes, why not burnt result?

Right now the special inserter (extractor or burnt result extractor) is the only way how to solve this problem.
After some amount, for example when the player has more than 600 extractors, the script can calculate two of them per tick and the delay will be 300 ticks.
5 seconds delay is actually is not a problem when the burnt result has big stack size and this extractor has big stack too. This inserter doesn't need to be very fast, one motion with period some less than 300 ticks will be ok.

[Rseding91]

Thanks for the report. It's now fixed for the next release.