Description
Adding or removing fields on types marked [Serializable] may cause runtime crashes if they already been baked into the game’s assets files. This will be accompanied with a misleading “file corrupted” error, despite the asset file itself being intact and the crash being triggered by a field‑layout mismatch.
Reproduction Steps
- Start with any of 114 existing serialized classes in any of the game's assemblies. Using
[Assembly-CSharp]Scripts.Data.GameDataInfo is a good example because it's confirmed to be present in resources.assets, and also loads early on, confirming a crash within first seconds of the game running. This is its base code.
using System;
using Engine.Source.Connections;
namespace Scripts.Data {
[Serializable]
public class GameDataInfo {
public string Name;
public string GameName;
public SceneAssetLink Scene;
public IWeatherSnapshotSerializable WeatherSnapshot;
public TimeSpanField SolarTime;
public float SkyRotation = 145f;
public int LoadingWindowGameDay;
public bool HideLoadingWindow = true;
}
}
- Create a mod that adds or removes a field on this class. For example, add:
-
Observe Unity crash on startup with:
The file '.../Pathologic_Data/resources.assets' is corrupted! Remove it and launch unity again!
[Position out of bounds!]
…
[CachedReader.cpp line 214]
Actual Behavior
- Unity crashes and reports the resources.assets file as corrupted, even though file integrity checks pass
- dnSpy exhibits the same crash when attempting to load the asset with the modified class, confirming the root cause is serialization field‑layout mismatch, not specific P2ModLoader logic
Expected Behavior
- P2ModLoader should prevent mods from adding/removing fields on
[Serializable] classes
-- What about potential serializable classes that are not actually serialized and instances of them do not exist in the game's assets files? Should they be disabled as well? How to check if it's the case?
-- Are any other attributes causing this?
Workaround
Mods must not add or remove fields on any [Serializable] types that is already present in the game’s assets files and should instead store any extra data outside of the original types.
Description
Adding or removing fields on types marked [Serializable] may cause runtime crashes if they already been baked into the game’s assets files. This will be accompanied with a misleading “file corrupted” error, despite the asset file itself being intact and the crash being triggered by a field‑layout mismatch.
Reproduction Steps
[Assembly-CSharp]Scripts.Data.GameDataInfois a good example because it's confirmed to be present in resources.assets, and also loads early on, confirming a crash within first seconds of the game running. This is its base code.Observe Unity crash on startup with:
The file '.../Pathologic_Data/resources.assets' is corrupted! Remove it and launch unity again!
[Position out of bounds!]
…
[CachedReader.cpp line 214]
Actual Behavior
Expected Behavior
[Serializable]classes-- What about potential serializable classes that are not actually serialized and instances of them do not exist in the game's assets files? Should they be disabled as well? How to check if it's the case?
-- Are any other attributes causing this?
Workaround
Mods must not add or remove fields on any [Serializable] types that is already present in the game’s assets files and should instead store any extra data outside of the original types.