I’ve recently upgraded the Unity Editor for a project from 2020 to 2022. I’m now finding that the addressables in the project are no longer loading. The error logs seem to indicate that Unity can’t find the addressable it has been asked to load and upon further investigation I found that the bundle at the address has a different name to what Unity is trying to load.
I’ve tried deleting the Library folder and rebuilding, to no avail. I’ve also tried rebuilding the bundles with a different naming convention, but the file name targeted by the addressable loader still doesn’t match. Interestingly, the names are consistent. Rebuilding results in the same bundle name on the drive and the path being used by the addressables loader. It’s almost as if the builder and the loader are parsing the same information in two different ways, resulting in a mismatch.
My question for the forum is this: has anyone come across this issue before and managed to solve it? A suggested fix by a colleague hasn’t worked out so I’m reaching out beyond the team for insight.
1 Like
I got a similar issue after upgrading from 2021 lts to 2022 lts
Even if i build the addressable from scratch it cant find it anymore.
Also if i use the local profile it cant find it anymore.
When i try to delete the lib folder and reopen the project there is a weird bug that keeps all editor windows white until the next restart. First addressable builds also need 10 times longer.
It does not help my addressable keep failing on load. ( also editor hosted content)
1 Like
@JohnDooley did you find a solution?
I tried:
-Rebuilding the .apk and addressables (clean builds)
-Deleting packages cache + reimport of each package
-Deleting library folder
-Changing addressable package settings
-URP material converter built in to URP for materials only
-Re-cloning of the whole project
Result:
The issue persists.
Still a persistent issue for me @DavidZobrist_1 , although I haven’t been looking into it much over the holidays. Done pretty much everything you’ve done, with the exception of the URP material converter. Don’t know about the video addressables, our videos were set up under the old asset bundle system.
Did you ever find a solution?
We did use an old working branch which was on the unity editor 2021 LTS in the end.
Than all worked fine. Now we gotta apply all the changes we have done since on this one.
So what i could suggest for you trieng is to kill it and re-clone it, so you are 100% sure there is no weird caching outside of version controll effecting your addressables.
@JohnDooley
Yeah, I’m reaching that point now. I was cross referencing with another project (Unity 2021) yesterday and accidentally rebuilt the addressables for that one. Now it’s running into the same problem, even though it hasn’t gone through any changes recently. Makes me think that there may be some setting somewhere that isn’t being pulled into local projects. Anyway, thanks for your help, David. I’ll update the post if I find any solution.
1 Like
@karl_jones Hi
Maybe you got an idea.
Version info:
Addressables 1.21.12 is in 2021.3.31.f1 LTS ( working)
Addressables 1.21.19 is in 2022 LTS ( failure)
I’m not aware of any issues with upgrading. Can you try downgrading to the same version of addressables on 2022 LTS?
The error seems to indicate it could be an issue with the path. Does the asset exist at the path it provides?
I tested it on 2021.3
2022 LTS
2023
It only found the addressables in 2021.3
And I downgraded to 2021 again so we can keep working
I noticed on some cloud build tests with the new versions that withouth changed addressable settings it just build the
Addressables_content_state.bin
I did local clean build on the app, addressables pushed to the cloud and hit clean build again.
But just to come back its not a cloud build issue, they were never found localy / Editor hosted.
Sorry, been out of office for a few days.
In answer to your question @karl_jones , the name of the archive file made by the addressable builder seems to differ from the one used by the addressable loader. End result is the loader is looking for a file name that doesn’t exist. I’ve tried changing the bundle naming mode and while the name does update, so does the filename it attempts to load. The bundle does exist at the address, but the naming mismatch means it isn’t being read.
I have observed that the name is consistent for both building and loading (the hash it tries to load for the example above is always 84e9d5… when set to ‘Filename’ bundle naming mode, so it doesn’t appear random). The mismatch made me think the builder and loader are hashing the file in two different ways, but at that point I’m speculating.
The issue seems to arise when simulating the addressables in-editor, and I haven’t gotten the project to the point where I can output a build to check if the issue persists outside of the editor environment.
we are now up to 2022 LTS but using the old addressable system that works
