Furnace source_inventory_size = <1

[laige]

I am requesting that the cap on the furnace source_inventory_size of 1.

This would make the furnace type more versatile for mod-makers to create unique machines. I see big benefits in using a furnace over an assembling machine. Having a machine that just goes to work crafting instead of having to pick the crafting recipe based on what items it contains.

One problem mod-makers run into is how the crafting selection area gets filled up fast. With furnace type machines it is possible to have hidden recipes that do not take up valuable gui area. So increasing the number of source_inventory_size would increase the options for hidden recipes.

In the mod I am working on right now this would be a great help. For my mod storage_cubes I would have furnace that just packs up the storage cubes. It is a box/crate mod.

How will this alter Vanilla. It wont affect vanilla.

[Rseding91]

The furnace input inventory size is limited to 1 because it if it wasn't it would have exponential complexity in recipe lookup cost on the inventory slot count. Specifically the cost to look up a recipe for the furnace would be: recipe count ^ slot count.

So say you have 15 recipes:

1 slot: 15 ^ 1 = 15 checks
2 slots: 15 ^ 2 = 225 checks
3 slots: 15 ^ 3 = 3375 checks

So I limited it to 1 slot keeping the cost at N where N is the recipe count a given furnace can accept.

[ssilk]

I have an idea to ignore that limitation:
Instead of furnaces, that can furnaces everything it would be useful to have "classes" of furnaces.

For example: Say we have a class of "iron furnaces" and assign some recipes to that. For example:

- 1 iron ore -> 1 iron plate
- 1 iron ore + 1 copper -> 2 bronze plates
- 1 iron ore + 1 coal -> 1 cast iron (works only, if furnace doesn't use burner (fuel) for electricity)
Just those three.

Only this class of furnace is able to craft that recipes. Then the number of recipes, that needs to be checked is relatively small. In this case only 3 combinations.

[daniel34]

For example: Say we have a class of "iron furnaces" and assign some recipes to that. For example:
- 1 iron ore -> 1 iron plate
- 1 iron ore + 1 copper -> 2 bronze plates
- 1 iron ore + 1 coal -> 1 cast iron (works only, if furnace doesn't use burner (fuel) for electricity)
Just those three.
Only this class of furnace is able to craft that recipes.

There's still another problem with that approach: the recipes in your example (and OPs storage cubes mod) are not prefix-free. Imagine an inserter that inserts one piece of iron ore from a belt. How would the furnace know if it should wait for additional items (copper, coal) or immediately smelt that one piece of iron ore?

This would only reliably work if the furnaces were separated by number of ingredients. One furnace would only be able to process recipes with 1 ingredient, another furnace with 2 ingredients,...). But this still wouldn't solve the performance issues Rseding91 mentioned.

So I limited it to 1 slot keeping the cost at N where N is the recipe count a given furnace can accept.

Is the cost to look up the recipe for a given item actually N? I would have assumed a hashtable with the item as key and resulting recipe as value. That way it should also be possible to make that lookup fast for recipes with several items. But, as always, I don't know the inner workings of Factorio and you seem to know what you're doing

[Rseding91]

Is the cost to look up the recipe for a given item actually N? I would have assumed a hashtable with the item as key and resulting recipe as value. That way it should also be possible to make that lookup fast for recipes with several items. But, as always, I don't know the inner workings of Factorio and you seem to know what you're doing

Hash tables are frequently slower than a simple array when the size is small. Furnaces use a lookup table that maps the categories the furnace can use to all the recipes in that category and the item ID is checked against the recipes until one is found that matches that the furnace can use.

The complexity comes from checking the furnace layout against the recipe layout. With each at a size of 1 it's O(1) time to do that comparison.

[ssilk]

Sorry, maybe I was not clear enough.

One items of that has to be "fixed". In my example it was iron.

The logic is then like so: Is there any inserter, that provides something which is NOT iron but can be used to furnace in this class of furnaces?
--> In this case copper or coal.

If yes, load that item(s), until non-iron stacks are full.

Then load the needed iron. Then craft the stuff.

You understand: The logic is not very different to the current. The trick is NOT to load the "class-item" until there is no choice anymore.

And you can do that recursively: Classes of classes. For example you have different bronze recipes. All need iron AND copper. Then you can make an iron-class which includes a copper-class which needs either nothing else (but that recipe is really slow for example), some with spit and some with leaves from a special tree that you need to plant and wait three years before you can use them.

And voillà: Furnaces with 3 ingredients...