Lua migration script is run before a game is loaded

[Pi-C]

While trying to update a mod for Factorio 1.1, I've got an error in a Lua migration script before I even tried to load a saved game or start a new game:

migration.png (49.36 KiB) Viewed 3620 times

Here's a peek at the log file:

Code: Select all

  22.727 Sprites loaded
  22.769 Generated mipmaps (4) for atlas [3] of size 16384x5600   
  22.774 Generated mipmaps (3) for atlas [4] of size 8192x4208   
  22.987 Generated mipmaps (3) for atlas [5] of size 16384x6064   
  23.012 Generated mipmaps (3) for atlas [6] of size 4096x3216   
  23.031 Generated mipmaps (3) for atlas [7] of size 4096x1840   
  23.070 Generated mipmaps (3) for atlas [8] of size 4096x3088   
  23.144 Generated mipmaps (5) for atlas [9] of size 8192x2256   
  23.152 Generated mipmaps (3) for atlas [12] of size 8192x2352   
  23.199 Custom mipmaps uploaded.
  23.369 Generated mipmaps for virtual atlas of size 8192x16384
  23.369 Verbose AtlasSystem.cpp:942: Virtual atlas mipmaps generated in 0.169579 seconds.
  23.369 Verbose AtlasSystem.cpp:945: Atlas memory size: 1014.03MB; 136.50MB (virtual)
  23.369 Verbose AtlasSystem.cpp:946: Size of sprites outside of atlas: 0.13MB
  23.409 Custom inputs active: 1
  23.441 Info PrototypeMigrationList.cpp:194: Activating migration WaterTurret/0.18.02.json
  23.441 Info PrototypeMigrationList.cpp:194: Activating migration WaterTurret/1.0.2.json
  23.502 Applying migration: Water Turret☂.☔: 0.18.02.lua
  23.506 Applying migration: Water Turret☂.☔: 1.0.0.lua
  23.507 Script @__WaterTurret__/migrations/1.0.0.lua:1: Entered migration script "1.0.0.lua"
  23.588 Factorio initialised

Has it always been this way? Seems kind of strange …

[Deadlock989]

It's because the new "menu simulation" is literally a bunch of saved games, so any mods that are running migrations have them applied to the menu simulations as well. Any other kind of control script error in a mod results in the same kind of black screen of death instead of the main menu background now.

[Pi-C]

Thanks for the info! Yes, that makes sense. Looks like I'll have to fix a lot of migration scripts!

[eradicator]

Ehwhat, that almost sounds like a bug. Migrations shouldn't run on savegames or scenarios that never had the mod installed in the first place. Otherwise all migrations have to include if/then garbage for possibly being loaded into a world that never had the to-be-migrated mod data in the first place.

(Assuming that @Pi-C's problem happens with the vanilla simulations and not a custom one.)

[Edit: See my next post]

[Deadlock989]

Apparently it was changed in 1.1.1 so that migrations don't run in simulations any more. viewtopic.php?f=11&t=91675&p=522713&hil ... ns#p522713

[eradicator]

For the record: Checked the API Doc and i was wrong apparently:

When adding a mod to an existing save all migration scripts for that mod will be run.

_____

Apparently it was changed in 1.1.1 so that migrations don't run in simulations any more. viewtopic.php?f=11&t=91675&p=522713&hil ... ns#p522713

Did he just say that simulations don't run control.lua? That is weird shit that completely excludes script-focused mods from using simulations at all. >_>

[Deadlock989]

He does appear to say that but I thought I saw a control script error when messing around, I may misremember.

Simulations do have "init" and "update" scripts of their own, so you can do initial set up and then something that appears to run every tick if you want to do complex camera panning or introduce keyframed stuff etc.

Code: Select all

return {
    simulation_1 = {
        checkboard = false,
        save = "__IndustrialRevolution__/menu-simulations/menu-simulation-1.zip",
        length = 60 * 60 * 60,
        init =
        [[
		local logo = game.surfaces.nauvis.find_entities_filtered{name = "decorative-logo", limit = 1}[1]
		game.camera_position = {logo.position.x, logo.position.y+11}
		game.camera_zoom = 1
		game.tick_paused = false
		game.surfaces.nauvis.daytime = 0.5
	]],
        update =
        [[
	]]
    }
}

menu.jpg (592.78 KiB) Viewed 3520 times

[eradicator]

Simulations do have "init" and "update" scripts of their own

Thanks for the info, but...text blocks? Seriously? Doesn't seem worth bothering to try and get normal control scripts working with that.

[Deadlock989]

YMMV, I'm quite interested in it. My plan is to have just one simulation that loads in random blueprints for the four quadrants of the screen, so 1 simulation = a lot of combinations.

What's weirder is that the camera scale changes with GUI scale so you have to be careful about what you're hiding off screen because someone could pull their scale down to 75% and eyeball all your dirty laundry.

[Bilka]

Thanks for the info, but...text blocks? Seriously? Doesn't seem worth bothering to try and get normal control scripts working with that.

You can also use init_file and update_file with a https://wiki.factorio.com/Types/FileName that points to a Lua file, so that you can at least have syntax highlighting in that file. Probably doesn't make things much better, but it's something. I haven't looked into this much yet since I haven't documented it yet, so I am not sure what capabilities the file version has - from what I can see at a quick glance it has the same capabilities as the text block version.

[eradicator]

YMMV, I'm quite interested in it.

Sure it looks interesting. But as far as i know your buildings don't need scripts to run. While for example for my Stockpiles mod i'd have to c/p the whole control.lua in there for it to have any visuals at all (LuaRendering). And that's only a simple mod that doesn't use require or even cross-mod require. Or compound entities, etcpp...

from what I can see at a quick glance it has the same capabilities as the text block version.

Which i assume means no use of require (according to some other forum post)? [Edit: this post]

More than the main menu i'm worried that this means it's also impossible to make tips'n'tricks/tutorial simulations for any scripted entities.

[Bilka]

from what I can see at a quick glance it has the same capabilities as the text block version.

Which i assume means no use of require (according to some other forum post)?

No idea... I'd honestly love if someone tested these things and reported back what works, it would make it faster to get through this particular documentation task in my pile of around 100 :)

[Deadlock989]

Yeah that's not ideal. (Require in the utility constant simulation definition's init text block.)

[eradicator]

At that point i really start wondering why they bothered to invent a completely new type of "map" instead of just having it load a standard savegame...

[Bilka]

Speaking of map... do scenario scripts in the save files work? It wouldn't be ideal, but in those you can have requires loading your mod files and use events etc.

[Deadlock989]

Requires don't work in init_file either ...

I have zero experience of scenarios so can't test.

[Bilka]

I had a go at testing it myself. Scenario scripts work. So from what I can see, you can just make a custom scenario with a control.lua that just does require("__my-mod__/control"), make all your simulation (and tips&tricks) maps using that custom scenario and your mod's control scripts will work as expected.

Note for the above: Obviously, that means that the freeplay scenario goes poof (is replaced by your own custom scenario). Furthermore, if you instead decide to just edit the freeplay.lua inside the save file, keep in mind that anything calling reload_script() will then mean your custom scenario code is then just replaced with plain old freeplay. For example, this will happen if you use a <= 1.1.0 savefile (level.dat), since 1.1.1 calls reload_script() on those.

[eradicator]

I had a go at testing it myself. Scenario scripts work. So from what I can see, you can just make a custom scenario with a control.lua that just does require("__my-mod__/control"), make all your simulation (and tips&tricks) maps using that custom scenario and your control scripts will work as expected.

Good news, thanks for testing!