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

[curiosity]

This has been claimed as fixed, but the bug came back. I made a new thread, since the old one seems too old, but feel free to merge them (and un-resolve) if you disagree.

Steps to reproduce:
1. Put the following into the data stage:

Code: Select all

data:extend{
    {
        type = 'item',
        name = 'fancy-new-item',
        icon = "__base__/graphics/icons/crash-site-spaceship-wreck-big-1.png",
        icon_size = 64, icon_mipmaps = 4,
        stack_size = 100,
        fuel_category = 'chemical',
        fuel_value = '4MJ',
        burnt_result = 'fancy-new-item',
    },
}

2. Smelt a stack of ore in a furnace using the item above as fuel.
3. Observe that the furnace stops with burnt inventory full and no way to clear it.

Expected behavior:
Either the furnace should not accept the item as fuel or an error should be produced in data stage.

[Rseding91]

I looked into this and it looks like there was some confusion in the past. Someone with source access made a pull request that claimed it fixed that report. When in reality it was code to fix this report 99793

A burner with no burnt_result inventory is still a "mod should fix that or don't allow that fuel category in the burner" issue.

[SoShootMe]

This has been claimed as fixed, but the bug came back.

The changelog of 1.1.37 (released a few days after Rseding's "fixed for the next release" in the linked thread) includes "Inserters can now pull from the main output and burnt result inventory of an entity." This seems to tie in with a related but different issue mentioned in that thread.

The original issue that seems to be what you describe is covered by an earlier response that (as I read it) amounts to "This is only a problem if you make it one. Use fuel categories so fuels producing a burnt result can only be used in entities with a slot for it."

[curiosity]

I looked into this and it looks like there was some confusion in the past. Someone with source access made a pull request that claimed it fixed that report. When in reality it was code to fix this report 99793

Is that the right bug? Your "fixed" declaration predates it by a month.

In any case, I don't think the original bug should then be marked as resolved, since there was no change.

[Rseding91]

I looked into this and it looks like there was some confusion in the past. Someone with source access made a pull request that claimed it fixed that report. When in reality it was code to fix this report 99793

Is that the right bug? Your "fixed" declaration predates it by a month.

In any case, I don't think the original bug should then be marked as resolved, since there was no change.

Probably not the exact one. It was just the first I found when searching. As for the resolved section: there are... many reports in there that were resolved, then later reverted, or we just removed the entire mechanic/thing/entity/item from the game at some later update. So I can't say for sure anything in the resolved section applies still.

[Loewchen]

There is also 99799.

[curiosity]

There is also 99799.

That's also a month later.

[Loewchen]

There is also 99799.

That's also a month later.

That does not mean it got picked up first, this one is referenced in the changelog.