Serializing Addressable Asset References at Runtime?

We have addressable Item assets (ScriptableObject/Prefabs) and need to serialize the player's inventory at runtime. Is there a way to lookup an AssetReference (or its id) from an Item/ScriptableObject and then serialize it to json/etc?

Or is the 'best practice' to make an AssetReferenceItem and store that in the inventory? It appears AssetReference has an "Asset" property that we would then be able to cast to "Item".

 

AssetReference only knows RuntimeKey (the guid string) and Asset (the loaded asset object). If you want to serialize it at play time, you have to stick with RuntimeKey, and deserialize with new AssetReference(guid).LoadAsset.

However guid stores in .meta file which is pretty much hidden thing. Not to mention if you delete .meta by accident, which will generate new guid, you may ignore it until some mysterious bugs happens in the client side. But it's up to you to take the risk.

I think serialize primary key (name/path) of addressables will be more reliable. But you can not create AssetReference with primary key at this moment. You need to use Addressables.LoadAssetAsync and manage reference counting yourself.

@unity_bill is this a good idea to add AssetReference.PrimaryKey and AssetReference(string primaryKey) APIs?

 

I would think that since the addressable system has to use the asset guid to reference the file (in case you move it or rename it), then the GUID is the most "stable" thing to use. If you delete an assets meta file I would assume that it breaks its addressable setup. (Looking at an AssetGroup file, the address is stored there as a "guid,address" pair. The address is not actually stored with the asset.)

I was mostly just hoping for a way to do something like:

Code (csharp):

1. var guid = Addressables.GetGUID( myAddressableScriptableObject );

to serialize it at runtime and then be able to properly de-serialize it later. I personally don't want/intend to rely on the "address" of an addressable as that seems less "stable" than its GUID should someone rename an asset and want its address to match. I'd personally prefer that they be completely optional and only used for things that we know we need to load using a string name (which is actually nothing), but they seem to be forced for some reason right now despite the syncing issues.

 

You've made the point. I have a little different case that I store information outside unity using database/googlesheet, I need a way to link the outside record with unity asset using some kind id. A human readable string (either it's addressables name or path) is better than asset guid. Because guid is not very readable, and need open the meta file to find it.