Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. We have updated the language to the Editor Terms based on feedback from our employees and community. Learn more.
    Dismiss Notice

Question Addressables not working on build

Discussion in 'Addressables' started by Zelarm, Jun 1, 2023.

  1. Zelarm

    Zelarm

    Joined:
    May 10, 2018
    Posts:
    22
    I've been working at this for about 6 hours now and I've exhausted all the internet resources I could find without coming across a solution if anyone could please help.

    I am loading a scriptable object via addressables that holds a bunch of delegates that direct player input wherever I want it to go by registering/unregistering to those delegates.

    I have figured out that the issue is with addressables and it seems like things are not loading/referencing properly.

    In Editor if I load the SO and do a debug.log on loadedAddressableObject.GetInstanceID() from both the object loading the addressable and from the addressable itself it matches. When I compare Instance IDs for the loaded reference and from the scriptable object itself during a build I get two different Instance IDs and my functionality is not connected.

    It's as if when I load the addressable in a build it is loading some new/non existent instance of the scriptable object. The input system events are directed to the scriptable object with a direct reference in the editor and it seems to definitely be referencing the proper scriptable object but I am unable to get a reference to the same object via Addressables.LoadAssetAsync

    Please tell me someone has any ideas!
     
  2. Phan-Phantz

    Phan-Phantz

    Joined:
    Nov 11, 2015
    Posts:
    15
    Not sure if they answer your question but consider these facts.

    1. From my understanding, the GetInstanceID() is only useful in Editor since it will be different in build. The official doc says :

    'The ID changes between player runtime and Editor sessions. As such, the ID is not reliable for performing actions between the Editor and runtime sessions, for example, loading an object state from a save file.'

    2. Instead of directing with direct reference, have you tried using custom ids instead? For instance, you can have a field called 'Id' on each scriptable object then when you load them in build keep them as a list and iterate through all of them to find a target scriptable object with matching id instead of using direct reference.
     
  3. Zelarm

    Zelarm

    Joined:
    May 10, 2018
    Posts:
    22
    I'm not looking things up by Instance ID only comparing my references via Instance ID so the fact that the instance ID changes between editor and build is not the issue.

    I have 3 objects I'm trying to connect
    New Input System ----> Scriptable Object Holding Input Events <----- Player Input Registering to events

    New Input System has a reference to the SO via editor inspector
    Player Input has a reference to the SO via addressables.loadasset

    In Editor the Instance ID's are the same because they are referencing the same object and so my input works correctly.
    In Build the Instance ID's are different because Addressables is failing to load the right object (or I'm misunderstanding something)

    I guess I will just abandon these addressables and hook up a direct reference via inspector, I switched things over to Addressable ScriptableObjects so that I could keep the inspector a bit cleaner but I can't spend the rest of my life working on this trivial problem
     
  4. Zelarm

    Zelarm

    Joined:
    May 10, 2018
    Posts:
    22
    I decided to take a look at some other addressable situations to see if I could fix a simpler case and found the same issue across all my addressables.

    I have some addressable scriptable objects being used as an enum, for example a Weapon has a reference to a SO to match up equipment slots and when the character tries to equip an item it takes the weapons equipment slot reference and matches it to the equipment slot types that are loaded by addressable

    e.g.
    Weapon1 has direct reference to RangedWeaponSlot (Addressable Scriptable Object)
    Player tries to equip Weapon1
    Inventory compares Weapon1 direct reference to RangedWeaponSlot against valid equipment slots (loaded by addressables) and is unable to match them despite being the same name/referenced object

    I assume this has to do with all the stuff I don't fully understand about Addressables regarding asset bundles?

    My biggest concern surrounding this is that this is such an obvious issue to encounter that I would expect a pretty easy solution that would be built into the Addressable quick start guide. I'd also expect that anyone building their game and using addressables would quickly run into this issue unless I'm just wholly misunderstanding why/how to use addressables.
     
  5. Zelarm

    Zelarm

    Joined:
    May 10, 2018
    Posts:
    22
    Ok I fixed this issue after finding some hints in the right direction in this thread

    https://forum.unity.com/threads/scriptableobject-references-in-addressables.777155/

    What was needed was to mark my scene as Addressable and create an empty scene that loads my addressable scene on startup. I am sure this has something to do with "asset bundles" though I don't fully understand why this issue should/would exist
     
  6. spiney199

    spiney199

    Joined:
    Feb 11, 2021
    Posts:
    6,015
    Its caused by a property of asset bundles, and Addressables is just a wrapper interface around the old Asset Bundles system.

    Anything that isn't addressable but referenced in a scene or asset that is addressable will be duplicated when the asset bundles are built. So often in the case where scriptable objects are used for the purpose of transmitting data, you instead have references to multiple different instances instead of the one.

    Though if said asset is addressable, it will be built into its appropriate group, and other groups will have the appropriate dependencies. Thus no multiple instances.

    Generally this means that all your assets will need to be built into addressables groups, with just the one bootstrap scene in your build list to kick start everything.

    You can also see where assets are getting duplicated with the Analyze window.