Migration cost is not an issue at all. It's vastly more important to do things the right way then to save a few seconds on something that is only done once. Try loading a really old really big vanilla map in latest vanilla. Just the renaming of entities can take more than half a minute - but that's totally ok.
Co-relating .researched directly to .enabled is an interesting approach. But it seems my statemend was unclear: I do not lack the technical knowledge to implement *some* method to enable recipes. I have too much knowledge and so for every method i can think of i can also think of a potential mod that would break if i use it ;). So my problem is one layer higher - deciding which "potential mod" i care less about.
For example toggling the tech off and on again also re-applies recipes, but "potential mod" might break because this causes on_research_finished to be raised for a tech that supposedly was already researched (reset_technologies() has the exact same effect). But at least there *is* an event that mods can handle while directly toggling recipe.enabled happens silently.
Code: Select all
local function reresearch_technology(technology) if technology and (technology.researched == true) then -- Have you tried turning it off and on again? technology.researched = false technology.researched = true end end for _, force in pairs(game.forces) do reresearch_technology(force.technologies["plastics"]) end
Ctrl+Shift+E/F came brand new with 1.0 :D.
Well, under normal circumstances it shoul (almost) not print anything at all. Does it print alot for you?