Allow furnaces' recipe to be reset using .set_recipe(nil)

[nullium21]

Basically what the title says.
Tried to do this and got an error:


The entity is a furnace, which, according to prototype wiki, is a crafting machine:

[boskid]

I see there is a documentation error. As for 1.1.41, LuaEntity::set_recipe() is incorrectly documented saying it can be used with CraftingMachine while it should say it can only be used with AssemblingMachine. LuaEntity::get_recipe() is correct saying it works on CraftingMachine.

[nullium21]

I see there is a documentation error. As for 1.1.41, LuaEntity::set_recipe() is incorrectly documented saying it can be used with CraftingMachine while it should say it can only be used with AssemblingMachine. LuaEntity::get_recipe() is correct saying it works on CraftingMachine.

Is there a reason for why it can't be used with other crafting machine types? Or, maybe, a workaround to clear the recipe?

[boskid]

Is there a reason for why it can't be used with other crafting machine types?

Yes of course there is a reason. LuaEntity::set_recipe() works by calling AssemblingMachine::setupForCrafting() on the c++ side which is only available on entities that can be casted to AssemblingMachine class. Furnaces have completly different recipe changing routine which looks at first item from source inventory or first fluid in the input fluid box.

[nullium21]

LuaEntity::set_recipe() works by calling AssemblingMachine::setupForCrafting() on the c++ side which is only available on entities that can be casted to AssemblingMachine class. Furnaces have completly different recipe changing routine which looks at first item from source inventory or first fluid in the input fluid box.

And what about clearing the recipe (.set_recipe(nil))?

Also, just noticed, the alt-view looks like the furnace keeps the recipe, but debug info says "Recipe: <none>". Is it a bug?

[boskid]

Clearing recipe on assembling machine is done through AssemblingMachine::reset which is also available only on AssemblingMachine. AssemblingMachine::setupForCrafting internally calls the AssemblingMachine::reset when it is given a RecipeID of "no recipe".

Furnaces have a "previous recipe id" which is used in certain cases (showing recipes on map, showing recipe in alt mode when furnace is not working). Value of the "previous recipe id" is accessible through LuaEntity::previous_recipe [R] which only works for Furnaces. It has no effects on furnace working state, its just a visualisation stuff due to how furnaces work: when a furnace finishes crafting, its recipe is automatically cleared and thats why the debug info says "Recipe: <none>" - debug stuff shows furnace's true current recipe without any layers of hiding them using previous recipe id.

[ownlyme]

so the only way to reset the recipe is destroying it and respawning it?

wanted to add modules to RealisticReactors

[Rseding91]

This sounds like a case of an AB error. What are you actually trying to do that you want to "reset" a recipe on a furnace?

[ownlyme]

it has a few applications in RealisticReactors:
When the reactor was scrammed or fails starting, the fuel cell is lost and the the remaining fuel gets deleted (formerly done by setting currently_burning = nil in burner)
anyway. i made a workaround now.. though it's not pretty at all...

Code: Select all

function respawn_furnace(reactor)
	local surface = reactor.furnace.surface
	local name = reactor.furnace.name
	local position = reactor.furnace.position
	local force = reactor.furnace.force
	local quality = reactor.furnace.quality
	local input = reactor.furnace.get_inventory(defines.inventory.furnace_source)
	local output = reactor.furnace.get_output_inventory()
	local input1 = nil
	if input[1] and input[1].valid_for_read then
		input1 = {name = input[1].name, count = input[1].count, quality = input[1].quality}
	end
	local output1 = nil
	local output2 = nil
	if output[1] and output[1].valid_for_read then
		output1 = {name = output[1].name, count = output[1].count, quality = output[1].quality}
	end
	if output[2] and output[2].valid_for_read then
		output2 = {name = output[2].name, count = output[2].count, quality = output[2].quality}
	end
	reactor.furnace.destroy()
	reactor.furnace = surface.create_entity{name = name, position = position, force = force, quality = quality}
	reactor.furnace.active = false
	if input1 then
		reactor.furnace.get_inventory(defines.inventory.furnace_source).insert(input1)
	end
	if output1 then
		reactor.furnace.get_output_inventory().insert(output1)
	end
	if output2 then
		reactor.furnace.get_output_inventory().insert(output2)
	end
end

[Rseding91]

I still don't understand why you want to set_recipe(nil) on a furnace.

[ownlyme]

because its not a furnace, its a nuclear reactor that just happens to use the furnace prototype to make it able to carry modules

[ownlyme]

whatever, it's fine. doesnt happen too often anyway so my workaround wont impact performance too much
can we at least have viewtopic.php?f=28&t=125010&p=655078#p655078 useful output_slots >1

[Rseding91]

So you want to stop it from crafting? You can do that with either .active = false or by setting crafting_progress = 0 which will reset the in-progress craft and require it to consume more items for the next craft.

[ownlyme]

active = false; crafting_progress = 0 doesnt set the recipe to nil and doesn't allow inserters to insert a different fuel cell (the latter is critical)
it does consume the input resource though, which is an interesting quirk i didn't expect

[curiosity]

and doesn't allow inserters to insert a different fuel cell (the latter is critical)

It's a furnace. Accepting every possible input at all times is its defining feature.

[ownlyme]

another issue is that the furnace is only willing to accept a different ingredient when it finished crafting the current product and not already when the input inventory is empty (which is slightly suboptimal for a reactor)

I also discovered an issue with inserters. they seem to be "linked" to an entity and even if that entity receives an "no-automated-item-insertion" and "no-automated-item-removal" flag after configuration changed, they still remain linked
you'll probably say this is not a bug or you can't be bothered to fix it, so i won't bother making a thread for that