What is the point of LuaForce.reset_recipes(),reset_technologies() ?

[Adil]

I've been writing a modding guide recently and when I got to migrating, it occurred to me, that I have no idea of how to answer the following questions.

The documentation of these functions reads:

Code: Select all

Load the original version of all recipes from the prototypes.

Load the original versions of technologies from prototypes. Preserves research state of technologies.

We do know that you can't alter things at runtime. What would that actually mean?

In times of yore this used to be the function to call after you've altered prototypes of technologies. Why don't these changes propagate on their own, like alterations of any other prototype do?

Enabling recipes when a technology has been long since researched is done by modder manually. The algorithm for that process is trivial. Why hasn't it been internalized yet?

Why are these functions stored in force? In which situation would I want one force having new version of technologies and other force - the old one?

The documentation on data cycle in the chapter 5 "control.lua script.on_configuration_changed()" says:

Code: Select all

Note: this is not the place to handle things such as recipe unlocks due to research changes - that is best done through migration scripts.

Why is that?

[Rseding91]

Because you can research technologies and doing so unlocks other technologies or recipes the entirety of the prototypes for both technologies and recipes are copied and are allowed to be mutated per-force runtime.

Those functions throw out the runtime instances and re-load them from the prototypes. This is needed when you change the prototypes. The game does it automatically if it detects that mod versions or the game version changes but in other cases it has to be done manually.

It's not done every time the game is loaded because it's not a cheap operation to do. Additionally there was the plan (maybe still is) to allow changing recipes/technologies runtime (as in the costs/results).


As for why you shouldn't do tech/recipe fixes in the on configuration changed: because it's messy. The migration script runs once per save file that existed before the migration script did and never gets run again. It automatically handles version checks and doesn't clutter up the control.lua with things that it doesn't need to bother with.

[Adil]

Hm, what does `reset_technologies()` actually do?
If a new recipe is added that should be unlocked by technology, and the tech is already researched, the recipe does not become enabled.
What about other effects?
If I modify bullet damage research for example, will the damage modifier of the force be updated?

[Klonan]

Hm, what does `reset_technologies()` actually do?
If a new recipe is added that should be unlocked by technology, and the tech is already researched, the recipe does not become enabled.
What about other effects?
If I modify bullet damage research for example, will the damage modifier of the force be updated?

If you change the prototype of a technology to change it, such as its effects, prerequisites, cost etc., they won't affect any current game, so you will have to call reset_technologies() to update them

However this doesn't retroactively call their effects or anything, this just sets them to their correct values.

So for instance if i change the cost of automation-1 from 10 red packs to 50,
In a new game it will be 50 from the start,
But in older games, it will show as 10, until reset_technologies() is called for my force

[Adil]

However this doesn't retroactively call their effects or anything, this just sets them to their correct values.

Is there any reasoning for that?
As in original post: It seems highly exotic for the modder to want to keep old technology effects in action in a new version of the mod.

[Rseding91]

However this doesn't retroactively call their effects or anything, this just sets them to their correct values.

Is there any reasoning for that?
As in original post: It seems highly exotic for the modder to want to keep old technology effects in action in a new version of the mod.

Because there's no way to correctly "reverse" the old effect. It's up to the mod(s) to use migration scripts to fix up any old save files when they change.

[daniel34]

Because there's no way to correctly "reverse" the old effect. It's up to the mod(s) to use migration scripts to fix up any old save files when they change.

Didn't you mention above that these two functions are automatically called when the game/mod version changes?

Those functions throw out the runtime instances and re-load them from the prototypes. This is needed when you change the prototypes. The game does it automatically if it detects that mod versions or the game version changes but in other cases it has to be done manually.

What other cases are there, except for during development where the mod version doesn't change? Migration scripts only run when the mod version changes.

[Rseding91]

Those functions throw out the runtime instances and re-load them from the prototypes. This is needed when you change the prototypes. The game does it automatically if it detects that mod versions or the game version changes but in other cases it has to be done manually.

What other cases are there, except for during development where the mod version doesn't change? Migration scripts only run when the mod version changes.

Migration scripts run when they haven't been run before on a given save if it's not a new save file.

[sensenmann]

...
Additionally there was the plan (maybe still is) to allow changing recipes/technologies runtime (as in the costs/results).

Please make that possible, and if possible also enable changing module effects at runtime.

[Rseding91]

...
Additionally there was the plan (maybe still is) to allow changing recipes/technologies runtime (as in the costs/results).

Please make that possible, and if possible also enable changing module effects at runtime.

It's not going to happen.

[Adil]

However this doesn't retroactively call their effects or anything, this just sets them to their correct values.

Is there any reasoning for that?
As in original post: It seems highly exotic for the modder to want to keep old technology effects in action in a new version of the mod.

Because there's no way to correctly "reverse" the old effect. It's up to the mod(s) to use migration scripts to fix up any old save files when they change.

What do you mean no way? It seemed to me that there's already this functionality in game. Simply setting technology `researched` to false reverses the effects.
So, if I'd ever bother with modding and migrating technologies in lua, I'd simply slap something like the following in every such mod:

Code

Code: Select all

for fn,f in pairs(game.forces)
  local temp={}
  for n,t in pairs(f.technologies) do
    if t.researched then
      temp[n]=true
      t.researched=false
    end
  end
  f.reset_technologies()
  for n,t in pairs(f.technologies) do
    if temp[n]  then
      t.researched=true
    end
  end
end

That's assuming I get this to run before factorio automatically calls `.reset_technologies()`.
What is the reason for requiring something more complicated?

[orzelek]

However this doesn't retroactively call their effects or anything, this just sets them to their correct values.

Is there any reasoning for that?
As in original post: It seems highly exotic for the modder to want to keep old technology effects in action in a new version of the mod.

Because there's no way to correctly "reverse" the old effect. It's up to the mod(s) to use migration scripts to fix up any old save files when they change.

What do you mean no way? It seemed to me that there's already this functionality in game. Simply setting technology `researched` to false reverses the effects.
So, if I'd ever bother with modding and migrating technologies in lua, I'd simply slap something like the following in every such mod:

Code

Code: Select all

for fn,f in pairs(game.forces)
  local temp={}
  for n,t in pairs(f.technologies) do
    if t.researched then
      temp[n]=true
      t.researched=false
    end
  end
  f.reset_technologies()
  for n,t in pairs(f.technologies) do
    if temp[n]  then
      t.researched=true
    end
  end
end

That's assuming I get this to run before factorio automatically calls `.reset_technologies()`.
What is the reason for requiring something more complicated?

You are assuming that game has stored all the technology effects for technologies in save file.
If you set researched to false with new version of mod game will try to reverse updated effect attached to this technology since it's the only one it sees. It won't update the effect as it was before since it's not stored anywhere (at least thats my assumption how it works - tech costs/recipes are stored but not the actual effects).

[Adil]

Nah, I've tested it, the technologies are stored with their effects alright.

c

Code: Select all

local t= --insert some altered technology reference here
--t.researched=false
print(serpent.block(t.effects))
game.forces.player.reset_technologies()
--t.researched=true
print(serpent.block(t.effects))

The code above doesn't work, however, due to the fact that despite lua migrations are there to alter game state, you cannot alter technology research state in them.