[2.0.76] Loading specific save from 2.0.60 causes bulk inserters to be replaced by stack inserters

[JohnAlekseyev]

Hi there, we are facing a weird issue.

Last time my friend and I continued our save was about 8 months ago, on 2.0.60. I usually hosted (and saved the games), but that last time, it was my friend who saved the game. So when we wanted to continue today, he sent me that last save file. Upon loading it, I am greeted with the following screen:

migrated inserters.png (488.42 KiB) Viewed 147 times

We have not set foot on Gleba thus far. All our green bulk inserters were changed to white stack inserters, and instead of having the green-inserter-tech researched, we now have the white-inserter-tech researched, and could re-research the one for green inserters. This however also raised the hand capacity of bulk/stack inserters by yet another +1. On the other hand, while the white inserters are auto researched, the belts did not receive the +1 stacking capacity.
All assembling machines also had their recipe moved from bulk to stack inserters, halting all production of the former.

Now due to not wanting to make my friend with his limited free time wait, we just played on with it, but now I am wondering if I can still fix the situation for the next time. It feels wrong to already have stack inserters, and it is annoying that most production is thrown off by it (waiting for full hand every time...), but most importantly, it seems that the hand capacity and belt stack size are permanently screwed up. Any idea why this happened in the first place, and how to undo all these accidental changes? I have attached both the save we loaded (30), and the one we have after the current session (31), with the inserters properly messed up. The migration reproducibly triggers every time the save 30 is loaded.

Edit: Meant to post this in Bug Reports, but I guess Technical Help isn't far off I, sorry if this is the wrong place!

[boskid]

From a quick look, "Server-30Levi" save file has only 6 migrations applied:

Code: Select all

aquilo-tilesets.json (space-age)
biolab.json (space-age)
internal.json (space-age)
jelly-yum-rename.json (space-age)
shattered-planet.json (space-age)
tungsten-belt-rename.json (space-age)

while the "Server-31" save has 13 migrations applied:

Code: Select all

1.1.0.json (base)
1.2.0 stack inserter rename.json (base)
2.0.0-biter-egg.json (base)
2.0.0-internal.json (base)
2.0.0-internal2.json (base)
2.0.0-internal3.json (base)
2.0.0.json (base)
aquilo-tilesets.json (space-age)
biolab.json (space-age)
internal.json (space-age)
jelly-yum-rename.json (space-age)
shattered-planet.json (space-age)
tungsten-belt-rename.json (space-age)

This looks like whoever created a "Server-30Levi" save file had its installation corrupted by not having any of the required migration files inside of the `factorio/data/base/migrations` directory or there was possibly some other type of corruption - loading a save on a corrupted installation will remove info about applied migrations from a save file and then when a save file is loaded again on a working installation, migrations are applied again. Without knowing what is the state of this directory on the corrupted installation, nor knowing if its a standalone or steam release, nor having any logs there is not much that can be done.

For a workaround to reapply that migration, if you have the "1.2.0 stack inserter rename.json" migration file you can create a copy of it (migrations are identified by their file name), add its name to migrations.txt, run game, load your save (this will cause them to swap again) and then delete this file and restore previous migrations.txt file.

[JohnAlekseyev]

Thanks a lot, I will try that!

Is there a way, via command or anything, to also un-research the Gleba inserter tech and undo the twice applied bonus from the twice researched classic bulk inserters?

I will also see if I can get any logs. From when would these ideally be?

As for other information, he is using the Steam version on a linux machine afaik, I am running the standalone on Win10 LTSC.