static Dictionary<int, DelMonsterBrain> cache;
public static Dictionary<int, DelMonsterBrain> dict {
get {
// not loaded yet?
if(cache == null)
{
DelMonsterBrain[] monsters = Resources.LoadAll<DelMonsterBrain>("");
}
return cache;
}
}
So as u can see, it’s just a lazy load singleton dictionary. The important points are:
I have like 6 other patterns (for items, skills, npc, etc), and they never caused this problem
The script is a ScriptableObject
Between when this error happens and last i checked before it starts, i didnt even change this script (DelMonsterBrain)
The only changes i made were related to Jobs system, completely elsewhere in the codebase
This only happens in build (Windows 64bit, Development build, Script debugging)
For a quick test, i did Debug.Log(DelMonsterBrain.dict.Count); at Start. These 3 errors pops up, but the log prints just fine. So, it’s not actually causing any real harm (even tested the build as server, and everything seems to work properly)
I dont use any #ifdef in this script, nor in any members of this script, also no [SerializeField] here either
What is serialization layout anyways? I tried adding more members in this script to test, but the offending byte doesn’t change (40, expected 140). Also tried adding variables inside the member classes of this script, no difference
Bump, I am dealing with the same issue. I recently restructured my ecs project to use Scriptable Objects and Addressables. Editor works fine, but when I execute a build it crashes with:
.“…has a different serialization layout when loading. (Read 32 bytes but expected 92 bytes)
Did you #ifdef UNITY_EDITOR a section of your serialized properties in any of your scripts?”
Yep, the same in Unity2019.4.4f1
Errors going along this line:
A scripted object (probably MagicInk.Managers.Bootstrap?) has a different serialization layout when loading. (Read 32 bytes but expected 36 bytes)
Did you #ifdef UNITY_EDITOR a section of your serialized properties in any of your scripts?
(Filename: C:\buildslave\unity\build\Runtime/Serialize/SerializedFile.cpp Line: 2324)
I was able to solve such a bug with simple solution - added required assets under sub directory.
So that Resources.LoadAll(“”) has transformed into Resources.LoadAll(“SomeSubdirectory”).
Why it solved the issue? Well, let me tell you my guess.
When you build your project, Unity merges all the Resources folders into one internal format that is similar to asset bundle. So every folder basically becomes one.
Therefore, when you put your assets into root of any Resources folder, it will later share the directory path will all the other assets that are also placed into the root of any other Resources folder.
In my case, I was loading some prefabs that were initially put into one folder. And the other had some broken assets with invalid serialization layout.
When Resources system is issued a load request, it most probably iterates over all the possible assets in the specified directory and then check whether it has required component type or not. When it was checking my Resources root, it eventually stumbled upon broken asset and it generated the error, moving on to the next one.
After I placed my prefabs into sub directory and specified it in LoadAll method - the system started to check only that folder, and completely ignored the broken assets.
I had the same problem, it turned out there was a problem with scriptable objects (I named my class with a typo). Check your scriptable objects, if the script is “none”, then the problem is probably there (see screenshots)
I’m providing a solution since here since this is the first post when I google this ‘bug’.
I encounter this problem using Addressables. I also wrap some serialized fields with UNITY_EDITOR, which it claims to change the serialization layout.
What I did is to add another define symbol and use it to wrap around the fields that i need in the editor but not runtime, such as ENABLE_ADDITIONAL_SERIALIZED_FIELDS, not UNITY_EDITOR.
When I build the player, I remove this symbol manually and then build Addressables. It solved the issue.
I don’t if removing symbols before building can be automated. Did not try it since I don’t use CI/CD at the present, but if it can, it would be much greater.
This could be user error, but it’s also 100% a Unity bug that can happen. I had a project that was building just fine. Then, without any changes at all, it started happening and there’s no way to fix it. It’s just Unity deciding to randomly break your project, which is common.
