[boskid][2.0.30] Crash editing Scenario, "loadedTargetsCount == savedTargetsCount was not true"

[eugenekay]

What did you do?
- Edit Scenario "Space Ribbons" containing my Testing factory.

What happened?

screenshot

Screenshot 2025-01-13 155616.png (76.49 KiB) Viewed 527 times

What did you expect to happen instead? It might be obvious to you, but do it anyway!
Scenario Editor would load

Does it happen always, once, or sometimes?
Every time I load the attached Scenario (SpaceRibbons). It does not happen with a previous 15-minute Autosave, which is also attached.

From the Logfile:

Code: Select all

28.080 Steam Storage Quota: 23697/23841
  76.176 Loading level.dat: 28962061 bytes.
  76.176 Info Scenario.cpp:178: Map version 2.0.30-1
Factorio crashed. Generating symbolized stacktrace, please wait ...
C:\Users\build\AppData\Local\Temp\factorio-build-Bzk7fb\src\Util\ReleaseAssert.cpp(7): ReleaseAssertFailed
C:\Users\build\AppData\Local\Temp\factorio-build-Bzk7fb\src\Map\MapDeserialiser.cpp(88): MapDeserialiser::setupLoadHelpers
C:\Users\build\AppData\Local\Temp\factorio-build-Bzk7fb\src\Map\MapSetupHelper.cpp(79): MapSetupHelper::MapSetupHelper
C:\Users\build\AppData\Local\Temp\factorio-build-Bzk7fb\src\Map\Map.cpp(828): Map::setupEntities
C:\Users\build\AppData\Local\Temp\factorio-build-Bzk7fb\src\Scenario\Scenario.cpp(331): Scenario::loadFactory
C:\Users\build\AppData\Local\Temp\factorio-build-Bzk7fb\src\Scenario\ParallelScenarioLoader.cpp(176): ParallelScenarioLoader::doLoad
C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\include\thread(56): std::thread::_Invoke<std::tuple<void (__cdecl*)(MapInterface,ParallelScenarioLoader *,MapDeserialiser *,enum InputType,InputSource *,MultiplayerManagerBase *,NamedBool<EnableReplayTag>),MapInterface,ParallelScenarioLoader *,MapDeserialiser *,enum InputType,InputSource *,MultiplayerManagerBase *,NamedBool<EnableReplayTag> >,0,1,2,3,4,5,6,7>
minkernel\crts\ucrt\src\appcrt\startup\thread.cpp(97): thread_start<unsigned int (__cdecl*)(void *),1>
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00007FFE3AD8E8D7)
00007FFE3AD8E8D7 (KERNEL32): (filename not available): BaseThreadInitThunk
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00007FFE3C8FFBCC)
00007FFE3C8FFBCC (ntdll): (filename not available): RtlUserThreadStart
Stack trace logging done
  78.500 Error TargetDeserialiser.cpp:191: loadedTargetersCount == savedTargetersCount was not true
  78.500 Error CrashHandler.cpp:643: Received 22
Logger::writeStacktrace skipped.
  78.559 Info CrashHandler.cpp:318: Executable CRC: 1157339668
  78.559 Error Util.cpp:95: Unexpected error occurred. If you're running the latest version of the game you can help us solve the problem by posting the contents of the log file on the Factorio forums.
Please also include the save file(s), any mods you may be using, and any steps you know of to reproduce the crash.
 141.300 Uploading log file
 141.382 Error CrashHandler.cpp:270: Heap validation: success.
 141.383 Creating crash dump.
 141.567 CrashDump success

" 76.176 Loading level.dat: 28962061 bytes." I was not able to locate level.dat in the "scenarios/SpaceRibbons/" folder structure. There is a "blueprint.zip" file containing "blueprint.dat", but that does not have a matching File size to the Log. This may be a Truncated file situation? I would have expected an I/O Error in that case, as in 125531.

I created "SpaceRibbons.zip" containing the folder "scenarios/SpaceRibbons/" Please let me know if there are any additional files required to reproduce!

[boskid]

Thanks for the report. I think i got into every possible trap while trying to investigate this including loading the save file first which created a working copy of this scenario for me causing some sanity to be lost trying to understand why it does not load in steam/portable release while loading fine on local builds, getting completly different amount of targeters and targetables between those builds etc, and knowing that there also exists 125908 report was not helping me take the blinds off my eye.

In the end after understanding all traps i fell into, the only thing i can say is that this scenario is corrupted.

Do you know how to create such corrupted scenario from a known good save or from scratch?

If you have no clues how to reproduce this type of corruption i may just change this assert (that forces the game to crash) into an exception that will create a nice popup saying that a scenario is corrupted which in the end will result in the same outcome (scenario not working) but at least game will not quit.

[eugenekay]

Do you know how to create such corrupted scenario from a known good save or from scratch?

Unfortunately no - it “just happened” after making some changes today. I think the most recent thing I have done was modifying some Inserters’ Pickup and Dropoff locations (using Bob’s Adjustable Inserters mod). I will do some experimentation after dinner to see if I can trigger it from the Autosave.

Reading the error message tea leaves a little bit, could it be that I did not “Tick” the simulation before saving? This might lead to a disagreement in the “Targets” count on the inserters

[Rseding91]

The error is not referring to the inserter target and is instead an internal name for part of the generic game save load logic.

[eugenekay]

Thanks, I’ll save my time with Inserters and focus upon the Save/Load and my environment.

This was an AMD Ryzen MiniPc, which mayyybe was a bit warm at the time, possibly leading to a CPU or (non-ECC) RAM issue at Savetime? Factorio is the most intensive thing this system is used for; and the Fan level was high. This system is located inside a grounded Steel Shipping Container to eliminate external EMF interference, aside from WiFi and HDMI leakage inside the box. I can’t think of anything else to cross-check…

[eugenekay]

I was able to immediately reproduce the Crash using _autosave3.zip, which I thought was in a known-good state, but is clearly not.

Reproduction Process (Video capture attached):
- From the Main Menu, navigate to Single Player --> Load Game
- Select "_autosave3", which was uploaded previously
- Press Escape to open the Game Menu
- Save as Scenario --> SpaceRibbons_Autosave3
- Exit Game back to Main Menu
- Navigate to Map Editor --> Edit Scenario
- Select "SpaceRibbons_Autosave3" which was just converted

screenshot

Screenshot 2025-01-13 201148.png (76.5 KiB) Viewed 393 times

I have not attached the new scenarios/SpaceRibbons_Autosave3/ folder; please let me know if this would be helpful or if you can create it from _autosave3.zip uploaded previously. I don't think I have made any substantial manual edits to this Scenario outside of the game - the description.json & freeplay.lua etc are all Vanilla.

For my own purposes, since the Autosave is also bugged / this was just a Test map; I think I will just abandon this world entirely and start a fresh Scenario.

Good Luck! Please let me know if I should try to reproduce on another system; I have several available.

[boskid]

Ok, i am slowly narrowing on the issue. In this specific save file it is related to this specific pipe:

01-14-2025, 10-52-15.png (262.95 KiB) Viewed 339 times

because in the extra settings, in Difficulty it was set to "Normal" -> off

01-14-2025, 10-52-51.png (38.2 KiB) Viewed 339 times

Because this pipe has this checkbox disabled, when converting a save file into a scenario it tries to append a DifficultySpecification data after the level itself was already saved, but this DifficultySpecification holds targeters which during scenario creation are trying to be loaded from the save file causing additional targeters to be requested that were not saved and so the mismatch between loadedTargetersCount and savedTargetersCount happens.

So my minimal reproduction right now is this:
1/ In main menu select Map editor -> new scenario
2/ Place a wooden chest
3/ Open it and in difficulty settings set "Normal" -> off
4/ Esc -> Save As -> "test"
5/ Exit to main menu
6/ Try starting new game from "test" scenario
7/ Crash

[eugenekay]

Wow, that's crazy!

The Pipe dialog was accidentally opened right as the previous Autosave occurred. I don't know how I clicked-off this Checkbox, but it is indeed visible plain-as-day in the Reproduction video and when loading _autosave3.zip.

The checkbox may have become un-ticked because I was clicking at the time of the Autosave dialog popping-up?

I also did some testing with my other _autosave files from the time; they seem similarly affected. I have not exhaustively checked the Map (since I am planning to Delete it after this Bug is concluded) for other Entities with these checkboxes toggled, but it seems likely that they exist. Is there a LUA script that could be run to check for such entities and remove or "Normalize" them?

[boskid]

When i was using your _autosave3 for reproduction purposes, difference of targeters was exactly 1 meaning this pipe was the only entity that was set with non default difficulty settings.

Main question right now is: since this issue remained undetected for such a long time (since 2.0 release), does it make any sense to keep the difficulty settings there at all? The only thing it does is to remove selected entities if the scenario was started with matching difficulty (it is literally just a mechanic to selectively delete entities based on selected difficulty). Scripts are a lot more flexible in doing this.

[eugenekay]

Got it, thanks!

I double-checked _autosave2 and _autosave1; they both seem to have the same Game state; only differing in Playtime. So mystery solved here.

I have never had a real usecase for Difficulty-based Entity presence in my Scenarios; as I only use the Map Editor for Testing of mechanics and throughput numbers. If anything, I do find the "<entityname> Extra Settings" panel to be obtrusive and take up space; but it is an Editor feature - not in the "Main Game" so that's not a real compaint.

It does seem like a Feature that would be welcomed for doing "serious Scenarios", like a Tower Defense mode which has more/less Turrets pre-built depending on your Difficulty. I do not know how widespread its usage is, but if this is (accidentally) causing more issues then it could be a Mis-Feature to be removed in 2.1? Or disable by default the Map Editor --> Settings --> Rendering toggle, "Show entity extra settings GUI" ?

Screenshot 2025-01-14 113014.png (141.17 KiB) Viewed 272 times

Good luck with the Bugfix!

[boskid]

Thanks for the report. This issue is now fixed for 2.0.31: your scenario provided in the first post will load just fine. This fix is bundled with a different change that was mentioned in this topic.