Altering core tech requirements?

[Forien]

Hello. Lot questions by me recently, sorry for that

I need (or more precisely I want) to alter some base tech's prerequisites. I've tried to do it with this in my tech.lua:

Code: Select all

data.raw["technology"]["solar-energy"].prerequisites = {"optics", "advanced-electronics", "my-new-uber-tech"}

In game it shows mod dependency "base->MyMod", but still works like before, and does not need my new tech.

[FreeER]

You'll need to call game.player.force.resettechnologies() in the control.lua afterwards (if you put it in the game.oninit event it'd run when your mod is first added to a game), you can do so from the console if you've already made a save with your mod active (~ to open the console). If you ever change recipes you'll need to run game.player.force.resetrecipes(). Factorio saves a copy of the recipes and technologies with the save game (to eventually allow modification during run-time) so that's why you have to run commands to manually reset them, those commands can also be placed in a lua migration file (though migrations are really only used after you've released a mod and need to run commands to migrate player saves automatically from older mod versions to a newer one).

[Forien]

Oh, thanks!

That worked. But I've now created new game (without adding "game.player.force.resettechnologies()" to control.lua yet) and tech worked fine. In old save I had to make console call.

But you say it's better to call "game.player.force.resettechnologies()" in control.lua on init event?

[FreeER]

and tech worked fine

It works fine in new games because there is no save with the old prototypes for a new game

But you say it's better to call "game.player.force.resettechnologies()" in control.lua on init event?

If you're going to release the mod to other people, and want to allow people to use it with already started games without having to run the command in the console theirselves, then you can place it in the oninit event so that it is ran automatically for them. If you don't plan to release the mod then there's no real reason to place it in oninit (since any new game you make will not have the issue, as you've noticed).

[Forien]

Ok, thanks for help

I hope to release my mod soon, so any hints about things to do when releasing are welcome!

[FreeER]

I hope to release my mod soon, so any hints about things to do when releasing are welcome!

Then I'll also mention that if you added recipe unlocks (or removed them) then you'll also need to check in oninit whether the save already had those technologies unlocked using if game.player.force.technologies["technology-name"].researched then ... end and if so make sure you unlock the added recipes using game.player.force.recipes["recipe-name"].enabled = true inside of that if statement (and enabled=false for any recipes that you've removed from that tech). I've also seen it done using code like the following which sets each recipe to be enabled if the technology was researched, and not enabled if it wasn't researched, if there's only one recipe then you don't need the local var (it can be assigned directly) but it saves some (probably insignificant) lookup time if there are multiple

Code: Select all

local techname = game.player.force.technologies["tech-name"].researched
game.player.force.recipes["recipe-name"].enabled = techname

[Nova]

The migration system was already mentioned, and I think it would fit nicely here. The migration file gets called every time you start an old save with a new mod. Writing the resettechnologies (or recipes) inside this file should solve the problem.

Create a "migrations" folder inside your mod folder. Now create a new .lua file inside this folder, the name doesn't matter. Now write anything inside this file what should be done at the loading of an old save with a new mod, something like:

Code: Select all

game.player.force.resetrecipes()
game.player.force.resettechnologies()

[FreeER]

The migration file gets called every time you start an old save with a new mod

Do they? I assumed that they wouldn't run for a new mod since they were intended for mod updates. From my understanding migrations are only run if they were added after the save was created (they're also 'saved' in the save, though by name only).

a quick test shows that it indeed does work, learn something new everyday I suppose, thanks Nova
So, you could do it in a migration script (same code) as Nova has suggested and it would prevent 'cluttering' your code with something that's mostly unrelated to it.

[Nova]

Every save saves which migration file it already has processed. If you now add a new mod with a new migration file, the save sees "yes, that's a new migration file, i run that."

Migration files are (as far as i know) not run if you start a new map with some mods.

[Forien]

Good to know.

But please tell me. Does the game recognizes mod version in some way, or is it just for people? And if I add new stuff to mod, is there need for including that in migration stuff, or only need for changes (like changed item name) and research dependency unlock (like new recipe should be unlocked if someone already has the tech)?

[Nova]

I... don't know how the game recognizes the migration files. :/


You need the migration file only if you change something in the mod which was saved with the save. Recipes and technologies get saved with the save, so you have to use a migration file if you want to change them. You don't need it if you just add new technologies or buildings.

[FreeER]

Every save saves which migration file it already has processed. If you now add a new mod with a new migration file, the save sees "yes, that's a new migration file, i run that."
Migration files are (as far as i know) not run if you start a new map with some mods.

All true Nova, I just didn't realize that saves would recognize the migration files of a new mod as something that they should run since there is nothing from that mod yet to need migration. So, I thought that it'd need to be done during the initialization of the mod

Does the game recognizes mod version in some way

It does to an extent...mostly, I think, for dependencies (on other mods). If I recall correctly, not with migration files, it's based entirely on the name of the migration files. So when you release a new mod version and need to update something, by which I mean a change not new additions which should work fine without a migration, from the older version you just add a new migration file with a different name, if you look at data\base\migrations you'll see that the devs name theirs based on the date and mod version. For names of items changing you can use a .json migration file and the game will automatically change all of them (rather than you doing your best attempt and finding all of the items with lua and replacing them), you can see the format by opening the base game's migrations or (hopefully) reading this post I made about migrations some time ago.

If you wanted to see what's in the save (in a somewhat limited way), just open the level.dat (and maybe level-init.dat) in a hex editor (I'm using Notepad++ with this plugin) alot is unreadable, but there's a decent about that's written as regular text for instance at the bottom is likely something like this (not all spaces are actually spaces, but control codes instead)

Code: Select all

base    2013-04-30_Factorio_0..4.0.lua    base    2013-05-30_Factorio_0..5.0.lua    base    2013-08-06_Factorio_0.6.0.lua    base    2013-09-05_Factorio_0.7.0.lua    base    2013-10-05_Factorio_0.7.1

which if you look inside the data\base\migrations folder, looks pretty similar no?

[Dark]

I didn't used migration files, I presume there is nothing complex in how they work.
At start of new game engine does not run any migration, it just saves the list to the save file.
When engine loads a save file it mindlessly runs any migrations that was not in the saved list (ordered by filename), even if new migration comes from a mod which was not present before.

So, AFAIK, there is no way to know which version of mod was used in the particular save file from inside the migration file.
For migration that recognizes version you have to use the control script, save mod's version in the "glob.version" and handle migration in onload handler in the same way as you would do in migration file.