Localization AsyncHandleOperation has errors and not possible to .Release()

Hello,

I’ve just noticed that the Localization package has an issue where after the LocalizedObject has been loaded - next frame the handle that’s been used to load the asset is cleared/reset/broken - making it impossible to cache the handle and virtually impossible to call the .Release() method to finally release it via addressable system.

I have tested the issue and it’s only with LocalizedAsset and other objects that have inherited from it, LocalizedAudioClip, etc…

Additionally, I did a sanity check where I did the same thing with raw AssetReference and its handle didn’t get cleared/reset/broken making it possible to call .Release() method after it has been loaded.

If the handle is intentionally cleared/reset after the load is finished, it defeats the whole purpose of Localization being built on top of the Addressables.
Since loading multiple objects must result in returning the first loaded instance since it’s tied to the handle and internal counter that keeps them loaded until the counter drops to ‘0’ - correct me if I’m missing something.

Kind rega,rds
Mario

Hello,

I would like to kindly ask you to report this issue via the bug reporter tool.

You can do so by doing the following:

  1. Open the project where the issue is reproducing
  2. Open the Bug Reporter Tool from the Tool Bar (Help → Report a Bug…)

Additionally, please add the URL to this Discussions Thread in the Description.

Thank you in advance!

1 Like

This is by design. We pool and reuse the addressable operations. The docs seem to be missing this info on that method however this one contains the info
https://docs.unity3d.com/Packages/com.unity.localization@1.4/api/UnityEngine.Localization.Settings.LocalizedAssetDatabase.html#UnityEngine_Localization_Settings_LocalizedAssetDatabase_GetLocalizedAssetAsync__1_UnityEngine_Localization_Tables_TableEntryReference_UnityEngine_Localization_Locale_UnityEngine_Localization_Settings_FallbackBehavior_

Once the Completed event has been called, during the next update, the internal operation will be returned to a pool so that it can be reused. If you do plan to keep hold of the handle after completion then you should call Acquire to prevent the operation being reused and Release(AsyncOperationHandle) to finally return the operation back to the pool.

So by default you dont need to do any releasing, this was to keep things simple for users as having to call release after every localization call would have been an easy thing to miss out and resulted in a lot of confusion and performance issues.

Holding on to the operation will let you keep the asset around, just like addressables however there is 1 additonal reference held which is in the AssetTable.
You need to tell the localization system to release it Class AssetTable | Localization | 1.4.5

The localization system will also released the assets when the table is release, such as when the language changes or when ReleaseTable is called.

1 Like

Hi Karl,

first of all, thank you for your fast and helpful response!

I can see the underlying architectural issue and approach why is that done automatically under the hood due to tables/assets being AssetReferences.

I still think that it should be mentioned when calling the .LoadAssetAsync() within the method summary.

Within our company, we have an Addressable Management System and helper classes where we load Addressable Assets and implementing LocalizedAssets just gave me a nightmare due to the work it does under the hood removing our micro-managment aside.

I would like to suggest you consider expanding the system with the possibility of Loc Tables returning AssetReferences as well.

It would be a superb option if I could manually handle language switching and determine when I want the current asset to be unloaded and load a new one and if I can still get ahold of Asset Reference so I can use the RuntimeKey for my internal feature checking.
e.g.

LocalizedAsset<T> _myLocalizedAsset = ...
AssetReference localizedAssetReference = _myLocalizedAsset.GetAssetReference(Locale);

Additionally, we updated our voiceover generation tool to be implemented with Unity Localization.
So naturally all generated voiceover clips had to be set into corresponding columns and rows within tables.
It was really odd that Localization Table takes a Object refference that is being an asset rather than being AssetReference. I know once you drag an Asset into the empty column within Localization Table it turns it into an AddressableAsset (checks the chekbox for addressables) but it’s weird that therei’s no classic drawer for addressables dropdown.

What I’m trying to say is, when accessing Tables via code, there’s no way to get the actual Addressable Assset Reference within the table, in Editor yes, in build I couldn’t find a way.

Kind regards,
Mario

I agree, ill get the docs updated.

We tried to develop localization so that users wouldnt need to learn anything about addressables and could ignore it if they choose. By default we handle all the confirguation of addresables, we dont expect you to add/remove the assets to addressables yourself.

We try to avoid having any Addressables specific features as we may want to support other systems to provide the assets in the future. The problem with AssetReference is that it needs to know the asset id, in order for us to know this we have to go through various steps during runtime (loading locales, tables (via name or guid), asset/platform variant etc) so that by the time we reach the asset there isnt any benefit to wrapping it up in a AssetReference, we already have the asset operation and additonal allocations are something we try to avoid. AssetReference itself is a wrapper around a AsyncOperationHandle. LocalizedString and LocalizedAsset were designed to be our answer to AssetReference. When an asset is loaded we store its AsyncOperationHandle in the AssetTableEntry, you can use the Address property to find the addressables key.
Localization is doing the micro-management side for you.

Theres more info on our Addressables integration here Addressables Integration | Localization | 1.5.3

1 Like

Fair enough, thank you again for clarification.
Have a good day!

Kind regards,
Mario

1 Like