Search Unity

Resolved Unable to read header from archive file

Discussion in 'Scripting' started by EmberWorks, Aug 20, 2020.

  1. EmberWorks

    EmberWorks

    Joined:
    Apr 21, 2020
    Posts:
    28
    Hi all,

    I'm loading scenes in the following way:

    Code (CSharp):
    1. using System.Collections;
    2. using System.Collections.Generic;
    3. using UnityEngine;
    4. using UnityEngine.SceneManagement;
    5.  
    6. public class PlayMainMenu : MonoBehaviour
    7. {
    8.     private AssetBundle myLoadedAssetBundle;
    9.     private string[] scenePaths;
    10.  
    11.     // Start is called before the first frame update
    12.     void Start()
    13.     {
    14.  
    15.     myLoadedAssetBundle =
    16.     AssetBundle.LoadFromFile("Assets/Scenes");
    17.      
    18.     }
    19.  
    20.     // Update is called once per frame
    21.     void Update()
    22.     {
    23.      
    24.     }
    25.  
    26.     public void OnMouseDown()
    27.  
    28.     {
    29.  
    30.     SceneManager.LoadScene("SampleScene");
    31.  
    32.  
    33.     }
    However the following error fires:
    Unable to read header from archive file: Assets/Scenes
    UnityEngine.AssetBundle:LoadFromFile(String)
    PlayMainMenu:Start() (at Assets/PlayMainMenu.cs:22)

    This doesn't seem to cause any problems but is it something I should look to fix?
     
  2. RakNet

    RakNet

    Joined:
    Oct 9, 2013
    Posts:
    315
    EmberWorks and PraetorBlue like this.
  3. EmberWorks

    EmberWorks

    Joined:
    Apr 21, 2020
    Posts:
    28
    Thanks for the help, error is sorted now.
     
  4. vlad1p

    vlad1p

    Joined:
    Nov 12, 2021
    Posts:
    4
    The upgrade to 21.3.16f helped me
     
  5. DaveA_VR

    DaveA_VR

    Joined:
    May 26, 2022
    Posts:
    35
    I've seen this error when the bundles were built with a newer version of Unity than what is trying to load them
     
    vlab22 likes this.
  6. Kurt-Dekker

    Kurt-Dekker

    Joined:
    Mar 16, 2013
    Posts:
    38,745
    This makes sense given how software data versioning works, but I've never seen it called out anywhere.

    For safety it is always best to make the bundles with the same version that you make the binaries.

    For practicality that may not always be reasonable, such as if you have a game that has accumulated five years of daily content creation by a 256-person diligently-working overseas content team and you may not even have the original artwork anymore, or be able to requalify and revalidate it. :)

    So as a second option, always consume the built content with an equal or later version of Unity.

    And of course whenever you upgrade Unity, going back for a "smoke test" over your built data might be a good idea, perhaps spot-checking over a wide range of time and versions and or used internal features of the bundles.

    Here's my upgrade blurb:

    ISSUES RELATED TO UPGRADING PROJECTS (eg, changing to a higher Unity version)

    Upgrading to a later version of Unity is a one-way process. Any project that has been updated should NEVER be reverted to an earlier version of Unity because this is expressly not supported by Unity. Doing so exposes your project to internal inconsistencies and breakage that may actually be impossible to repair.

    If you want to upgrade to a newer version of Unity, do not even consider it until you have placed your project fully under proper source control. This goes double or triple for non-LTS (Tech Stream) versions of Unity3D, which can be extremely unstable compared with LTS.

    Once you have source-controlled your project then you may attempt a Unity upgrade. Immediately after any attempted upgrade you should try to view as much of your project as possible, with a mind to looking for broken animations or materials or any other scripting errors or runtime issues.

    After an upgrade you should ALWAYS build to all targets you contemplate supporting: iOS and Android can be particularly finicky, and of course any third party libraries you use must also "play nice" with the new version of Unity. Since you didn't write the third party library, it is up to you to vet it against the new version to make sure it still works.

    If there are issues in your testing after upgrading Unity, ABANDON the upgrade, revert your project in source control and be back where you were pre-upgrade with the earlier version of Unity.

    Obviously the less you test after the upgrade the more chance you will have of an undiscovered critical issue.

    This risk of upgrading is entirely on you and must be considered whenever you contemplate a Unity version upgrade.

    Do not upgrade "just for fun" or you may become very unhappy.