It seems like the load/unloading mechanism of MLO is crashing the game.
The use case for this is that most MLO creators (map developers ?) do a lot of iteration while creating their maps, so fixing the load and unload of these could signicatly improve their workflow and speed up their creation.
I’m not asking you to fix any inherent game problem as MLO can be quite complicated, but some research and trial about this subject could be interesting.
I have reduced these crashes to a very simple repro version :
mlo_test.zip (7.1 KB)
I have tested this in b1604 & b2545, the following crash dumps will only be b1604.
Crash 1 :
Starting this resource while already in game and in streaming will lead to crash “orange-earth-uranus”
CfxCrashDump_2022_04_08_03_23_14.zip (1.6 MB)
Full crash dump is availaible here : c059191f-1a26-427d-94e5-de3c8b49f8e6-full.zip
This crash occurs on every start of a MLO, no matter what I tried.
Seems like they don’t like being started at runtime.
Crash 2 :
Reloading/Restarting of the MLO is also crashing the game for a different crash “zebra-high-leopard”
CfxCrashDump_2022_04_08_03_31_50.zip (1.6 MB)
Full crash dump : 14894ab3-b224-47bc-bead-813ef5980e2e-full.zip
This crash only occurs when there is dependent ytyp in manifest for the interior. Most of the time, this can occurs when calling non permanent ytyp like props to use in rooms. In this specific case, I produced the crash by putting the mlo_test_shell.ydr in a different ytyp.
(It seems like the precedent crash dump ends with a timeout, so here is a not full dump ending with the correct crash CfxCrashDump_2022_04_08_03_46_26.zip (1.6 MB))