I have found an interesting bug about Addressables. If I load a scene and an addressable object at the same time asynchronously, the scene is loaded but the addressable object stops loading or gets stuck. Nothing throws error.
Here’s an example code. The scene is not in the addressable build:
private AsyncOperation SceneLoader;
[SerializeField] private AssetReference AddressableObject;
private AsyncOperationHandle<Sprite>? AddressableHandler;
// It doesn't matter when they are called. If they are called at the same time, the bug happens. For this example, they are called in Start function
private void Start()
{
// If you remove LoadSceneAsync from the code, the addressable object loads
SceneLoader = SceneManager.LoadSceneAsync("TestScene");
SceneLoader.allowSceneActivation = false;
AddressableHandler = Addressables.LoadAssetAsync<Sprite>(AddressableObject);
AddressableHandler.Value.Completed += (handler) =>
{
// This line is never executed, because the addressable never loads
Debug.Log("Addressable is loaded");
};
}
private void Update()
{
if (SceneLoader == null)
{
Debug.Log("Scene loader is null");
}
else
{
// Since 'allowSceneActivation' is false, the progress stops at 0.9 (90%) as expected. When the boolean is true, it loads the scene automatically when it's done
Debug.Log("Scene is loading... Percent: " + SceneLoader.progress);
}
if (!AddressableHandler.HasValue)
{
Debug.Log("Addressable handler is null");
}
else
{
// You will see that the addressable object never loads
Debug.Log("Addressable task status: " + AddressableHandler.Value.Task.Status + " - Adressable status: " + AddressableHandler.Value.Status + " - Addressable percent: " + AddressableHandler.Value.PercentComplete + " - Addressable is done: " + AddressableHandler.Value.IsDone);
}
}
Interestingly, everything works with “Fast Mode”. They don’t affect each other, but if I switch it to “Packed Play Mode”, LoadSceneAsync gets Addressable Build corrupted. I never tried it on Windows build, but this bug happens on Android build too.
In “Use Asset Database (fastest)” everything works, but when I switch it to “Use Existing Build (requires built groups)”, it does the same thing, doesn’t work.
No, it’s not related. In fact, I can load around 10 addressable objects at the same time without any issues. (I didn’t know the label thing when I started coding my game. After learning that, I didn’t want to change it either since there is no issue). The thing about this bug is that a different async function affects the addressable build, which is LoadSceneAsync function.
As unity use just one background worker to execut async operation in one quene,
when you use “allowSceneActivation = false”,it must corrupted not only addressable api but also any other asnyc opration such as Resources.LoadAsync and so on.
you’d better await SceneLoader and then call Addressable api.
in other words, at this moment, you should call Addressable api after scene have already loaded into player.
When I came across this bug, I didn’t know it was the LoadSceneAsync function. I changed some of my code to the Resources.LoadAsync function see if it’s related to the Addressable feature, and it worked. By going more deep into this issue, I found that LoadSceneAsync function causes the issue. So, LoadSceneAsync only affects the Addressables from my experience. They might be using something similar under the hood. (I also heard that Resources.LoadAsync doesn’t work like a async function but like a sync function. Maybe that’s why I didn’t have any issues when I tried it with Resources.LoadAsync.)
Currently, I’m loading the Addressable objects first. Once they finish loading, I start loading the scene. The other way around doesn’t work because with “allowSceneActivation = false”, LoadSceneAsync function holds the line. It stops at 90%, which I need to make a “Press any key” intro type.
So, as for the original issue posted, I noticed you have allow scene activation set to false. This is why your other async loads are getting stuck. It has to do with how the engines PersistentManager handles async operations.
So there isn’t anything we can do about that, unfortunately.
That said, this is likely the same reason that kicking off several regular async asset loads can have unintended behavior, which I know some of you have run into. There may be something we can do about that. We haven’t started investigating that yet but will in the future. Hopefully when our synchronous APIs are released that will mitigate some of the issues ya’ll are running into with things like that.