Factorio Forums

Deadlock989 wrote: ↑Fri Dec 29, 2023 11:20 pm As far as I know I don't think this is possible with JSON migration files. But you can write Lua migration files as well, and you can conditionally run a code block if and only if a specific mod is present (game.active_mods), or test for the existence of named prototypes, etc.

if mods ["bzlead"] then
  for index, force in pairs(game.forces) do
    local technologies = force.technologies
    local recipes = force.recipes
  
    if technologies["advanced-material-processing"].researched then
      recipes["lead-dust0"].enabled = true
    end
  end
end

Error while applying migration: Extended Vanilla: Refining: ev-refining_2.1.0.lua

__ev-refining__/migrations/ev-refining_2.1.0.lua:1: attempt to index global 'mods' (a nil value)
stack traceback:

__ev-refining__/migrations/ev-refining_2.1.0.lua:1: in main chunk

Deadlock989 wrote: ↑Fri Dec 29, 2023 11:20 pm As far as I know I don't think this is possible with JSON migration files. But you can write Lua migration files as well, and you can conditionally run a code block if and only if a specific mod is present (game.active_mods), or test for the existence of named prototypes, etc.

for name in pairs(script.active_mods) do
  if name == "bzlead" then
    for index, force in pairs(game.forces) do
      local technologies = force.technologies
      local recipes = force.recipes
    
      if technologies["advanced-material-processing"].researched then
        recipes["lead-dust0"].enabled = true
      end
    end
  end
end

DiegoPro77 wrote: ↑Sat Dec 30, 2023 10:10 am But the thing that I'm realizing now is: migration files as said here are applied only once and the game knows which files were already applied and which not.
But these technology unlocks should be checked every time my mod is put together with Lead.

I mean, am I sure that these unlocks will be always applied correctly without having to copy paste the migration file for each new version of the mod?

DiegoPro77 wrote: ↑Sat Dec 30, 2023 9:52 am And what do you mean by "test the existence" of a prototype?

if game.recipe_prototypes["lead-dust0"] then
	-- do something
end

DiegoPro77 wrote: ↑Sat Dec 30, 2023 10:10 am Wait I found out a piece of code that works and applies the migrations correctly by looking at your first link: (another time, thank you)

if game.active_mods["bzlead"] and game.recipe_prototypes["lead-dust0"] then
	for _,force in pairs(game.forces) do
		force.recipes["lead-dust0"].enabled = force.technologies["advanced-material-processing"].researched
	end
end

DiegoPro77 wrote: ↑Sat Dec 30, 2023 10:10 am But the thing that I'm realizing now is: migration files as said here are applied only once and the game knows which files were already applied and which not.
But these technology unlocks should be checked every time my mod is put together with Lead.

I mean, am I sure that these unlocks will be always applied correctly without having to copy paste the migration file for each new version of the mod?

Qon wrote: ↑Sat Dec 30, 2023 10:41 am You don't have to copy paste the migration file, because which recipes are unlocked is a part of the game state, saved in the savefile. Once unlocked, always unlocked.

If the mod author of lead recipes adds new recipes in a future mod update, which you also want to unlock with a different technology than their mod specified then you would need an additional migration for that (instead of modifying the already existing migration to include the new prototypes, which would not work for users updating from a version with the old migration).

Deadlock989 wrote: ↑Sat Dec 30, 2023 12:01 pm This kind of thing is what the on_configuration_changed event is for. This event fires when a saved game is loaded and any mod has changed version (including adding a mod to an existing save that didn't have it before). This would need you to get to grips with control.lua scripting, setting up event handlers and so forth.

Deadlock989 wrote: ↑Sat Dec 30, 2023 12:01 pm You don't have to loop through every active mod, you can do this:

DiegoPro77 wrote: ↑Sat Dec 30, 2023 2:07 pm The only case where we have a problem is the one where a player:
-> Plays both mods -> Updates Ev Refining -> Deletes Lead -> Enables Lead

And well I dunno why someone would do something like that. (It would compromise the entire run.)

DiegoPro77 wrote: ↑Sat Dec 30, 2023 2:07 pm Yeah it makes sense and, at a certain degree I knew that. The thing was more about what Deadlock said in the last reply, and to work around that thing I should try to study how control.lua files work in a first place.

script.on_configuration_changed(function(event)
	if game.active_mods["bzlead"] and game.recipe_prototypes["lead-dust0"] then
		for _,force in pairs(game.forces) do
			force.recipes["lead-dust0"].enabled = force.technologies["advanced-material-processing"].researched
		end
	end
end)

https://lua-api.factorio.com/latest/classes/LuaBootstrap.html#on_configuration_changed wrote:Register a function to be run when mod configuration changes. This is called when the game version or any mod version changed, when any mod was added or removed, when a startup setting has changed, when any prototypes have been added or removed, or when a migration was applied. It allows the mod to make any changes it deems appropriate to both the data structures in its global table or to the game state through LuaGameScript.

DiegoPro77 wrote: ↑Sat Dec 30, 2023 2:07 pm

Deadlock989 wrote: ↑Sat Dec 30, 2023 12:01 pm This kind of thing is what the on_configuration_changed event is for. This event fires when a saved game is loaded and any mod has changed version (including adding a mod to an existing save that didn't have it before). This would need you to get to grips with control.lua scripting, setting up event handlers and so forth.

It really would be interesting, and useful probably, but is it really worth it for me to go this far for now?

DiegoPro77 wrote: ↑Sat Dec 30, 2023 2:07 pm And well I dunno why someone would do something like that. (It would compromise the entire run.)

Deadlock989 wrote: ↑Sat Dec 30, 2023 2:48 pm If a player can break something, at least one will. Whether it's worth handling or not it is a subjective judgement for you. There are some mods which simply aren't ever going to work out well when introduced or removed mid-game. In that case it may be massively less work for you to simply warn the punters about that.

Deadlock989 wrote: ↑Sat Dec 30, 2023 2:48 pm For mods which add only brand new recipes to brand new technologies, in general I don't feel any need to worry - the save game state keeps track of it all and if a player removes and then reinstalls the mod, there's not a great deal you can do about that.

Qon wrote: ↑Sat Dec 30, 2023 5:25 pm Maybe someone adds the mod, tries removing it to debug which mod is causing some bug, before crafting much of anything from the mods. Then adds the mods back in again. Now suddenly the recipes that worked before are now just gone! But since you have now decided to not write bugs on purpose and put the code in control.lua in the on_configuration_change handler you don't have to worry about this

Qon wrote: ↑Sat Dec 30, 2023 5:25 pm Inter-mod configuration and interaction changes is what on_configuration_changed is for. Use that. It's not hard or a lot to learn, you just name the file control.lua (directly in the mod folder, not in a sub folder) and put the code in the event handler (not technically an event like the others, so different syntax).
all you need is your idempotent (it already is so don't worry) migration in the control.lua inside the event handler

Code: Select all

script.on_configuration_changed(function(event)
	if game.active_mods["bzlead"] and game.recipe_prototypes["lead-dust0"] then
		for _,force in pairs(game.forces) do
			force.recipes["lead-dust0"].enabled = force.technologies["advanced-material-processing"].researched
		end
	end
end)

Deadlock989 wrote: ↑Sat Dec 30, 2023 2:48 pm But if you add a new recipe to a vanilla technology or arguably a technology provided by a third party mod, players are going to expect to have access to it if they already researched that technology and they add your mod later. For example this mod has a very simple on_configuration_changed script that checks to see if Optics research has already been completed and updates one specific recipe's availability, whenever the mod is added or updated.

Deadlock989 wrote: ↑Sat Dec 30, 2023 2:48 pm There is also the option of using force.reset_technology_effects() - I sometimes use this for when tricksy mod combos change and just wholesale updating every recipe availability at once. For example IR3 does this when Dectorio is added or removed.