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 ()

  1. 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.

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.