Alien Walls

by vedrit

Humanity has made many great advances, but still looks to nature for inspiration. Thanks to users ThaPear, ratchetfreak, Klonan, and TheBrain0110 for lots of help on the core of this mod. Great work!

Content
1 year, 5 months ago
0.16.51 - 1.1
1.79K
Combat

b crash on migration when installing on an existing map

5 years ago
(updated 5 years ago)

just as the subject says, the mod is crashing on migration after having installed this mod on an existing map, with the following error notice:

Error while applying migration: Alien Walls:AlienWall_0.4.0.lua
AlienWall/migrations/AlienWall_0.4.0.lua:2: attempt to index field 'alien-hybridization1' (a nil value)

I'm using quite a few mods, several of them might be affecting walls, eg Dectorio, Big Bags, AAI Programmable Vehicles, Natural Evolution Enemies, Walls Block Spitters (at least, those are the mods shown in yellow text when i hover a wall in the crafting window)

5 years ago

What version of the mod is loaded in the save currently, and what version are you trying to use? Since the message is regarding research added by my mod, those others shouldn't be involved. Even if they were, there aren't and incompatibilities that I'm aware of.

5 years ago
(updated 5 years ago)

the crash happened when i started factorio for the first time after installing your mod and loading an existing map (that had most researches sone already). thus this should have been the most recent version of the mod, and no version of it in the map yet.

just tried again and the same crash happened ...
factorio is version 0.16.51 and shows mod version 0.7.3 in its mod list

i also tried starting a new map, thus no mirgation needed and there was no crash.


ok, now i had a closer look :-)
since i am no modder and no LUA programmer this is my best guess only:

the file that caused the crash was the migration for version 0.4.0, and the problematic line was
if force.technologies["alien-hybridization1"].researched then
if there is no such technology, then checking for its ".researched" throws an error of course. you probably would need to check first whether force.technologies["alien-hybridization1"] exists or is nil, and only then test for ".researched"

and why is this old migration from 0.4.0 called at all ?
a search on google for "factorio migration" gave as first result https://lua-api.factorio.com/latest/Migrations.html which clearly states :
When adding a mod to an existing save all migration scripts for that mod will be run.

thus a new map doesn't run migrations and has no such problem.
and a savefile for an old version that has this technology and/or already has done this migration and will not run it again, and thus also not have the problem.
but adding the mod to a map will cause ALL migrations to be executed, and thus will crash because of the missing nil check.

5 years ago

I guess it makes sense that migration will run, but I thought it would only be the latest. Alright, I'll make some adjustments

5 years ago
(updated 5 years ago)

I thought it would only be the latest.

for any new version (eg v4) you would need to have one different migration depending on which is the most current version of the user (thus v1->v4, v2->v4 and v3->v4), and on your next update you would need to add four more migrations, then five on the next etc, exponentially increasing the number of files and the amount of work to keep them all current. and this doesn't even include subversions where several subversions might require the same migration (eg same for v4.0->v5, v4.1->v5, etc).

thus it makes sense to always run all migrations. and since no migration is executed twice on the same map, there also should be no problem when upgrading only from v3 to v4.

the only problem is when you do migrations for the first time (also doing eg v1->v2 and v2->v3) when you only would need to do v3->v4. I'm not sure whether it would be possible to somehow check the current version and then only do the following migrations, but since you can't be sure what the current state is (which version, maybe something was inadvertently changed in a save, etc) each migration should assume as little as possible and do any additional check whether some variable, prototype, entity, research, recipe, whatever really exists and is valid before acting on them. the additional overhead (for checks against nil etc) doesn't matter since each migration is only executed once on each different map.

usual disclaimer: I'm no modder, but this is what i gathered from readin several infos, and what would appear "logical" to me.

New response