Search Issue Tracker
Won't Fix
Votes
0
Found in
2021.3.11f1
Issue ID
UUM-16478
Regression
Yes
[2021.3] Can't build the project after it was built with specific versions
How to reproduce:
1. Open the user-attached project “Il2CppTest”
2. Build it on a reproducible version of Unity
3. Open the project in any other version of Unity, for example, 2021.3.5f1
4. Build the project to the same folder as the first build
Expected result: Project is successfully built
Actual result: Errors are logged in the Console
Reproducible with: 2021.3.8f1, 2021.3.11f1
Not reproducible with: 2020.3.40f1, 2021.3.7f1, 2022.1.17f1, 2022.0b8, 2023.1.0a10
Reproduced on: Windows 11 Pro
Note:
-The issue is reproducible both in Mono and IL2CPP builds
-The issue is also reproducible if you then build a project to the new folder, but even though the errors occur, the build is successful
- The failure comes when enlighten cache was generated using a newer version of Unity, then moving back to a slightly older version which expects older version of the Archive file format (prior to SERIAL-732/UUM-493 backport)
The errors:
Unable to read header from archive file: memarchive0
UnityEditor.BuildPlayerWindow:BuildPlayerAndRun ()
Mounting archive file system for lighting data asset failed\!
UnityEditor.BuildPlayerWindow:BuildPlayerAndRun ()
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- [Android] Soft keyboard is missing the "OK" button on Android
- The Profiler ignores a modified targetFrameRate when profiling Edit mode
- [General] Package manager takes 15 minutes to load
- Asset's Inspector information is no longer displayed when docking the Search Window
- Crash on Object::GetCachedScriptingObject when entering Play Mode
Resolution Note:
The Light Transport team has decided to close this as Won't Fix, despite a patch being available. Here is our reasoning:
The problem statement is that we do not support the workflow of downgrading a project and building it if the LightingData was created with a later version of the archiving system. It is fair enough to say that backwards compatibility should be supported for most of the Editor, especially when the consequences are such a major blocker.
However, we cannot retroactively fix the backwards compatibility that was built into this archiving system upgrade (and how it affected the LDA). The only thing we can do is add to the latest/upcoming version of 2021.3. Thus, any fix would require the users to upgrade to the latest 2021.3 release, which would then defeat the entire purpose of the fix.
The question then comes to whether we would like to support this workflow in the future. The patch provided fixes the "Auto Generate Lighting" mode, but does not affect the LightingDataAsset that is produced when one uses On-Demand bakes (eg. clicking the Generate Lighting button). If we changed the behavior of one, we would have to change the behavior of the other and that is a much more involved change which will have side-effects and may introduce issues.
After much back-and-forth we decided that it does not make sense to support this workflow at this moment. Making this change (no matter how small it may seem) would by design trigger unnecessary bakes on upgrade of the archiving system, as well as desynchronize the auto-mode and on-demand LDAs. We hope that you can understand why we are hesitant to introduce this change, both in Long-Term-Support products as well as the future releases.
We would recommend that at any given time teams use a fixed version of the Editor and upgrade (if needed) concurrently to mitigate errors caused by downgrading due to mismatched Editor versions.