When/how is the active profile used when running in the editor?

My current understanding of the Addressables system is that the active profile is only used when doing a content build. I initially had assumed that the active profile was being used at runtime as well, e.g. if I'm running in the editor with the "Use Existing Build" play mode script I thought I needed to have the appropriate profile set. But in practice it looks like all of the information in the profile is baked into the built asset catalog, and so after you do the asset build the active profile doesn't matter.

Am I understanding the situation correctly? Is the active profile used in the editor at any time other than when making a content build? One case I can think of is that perhaps the local hosting service references the active profile to determine the remote build directory?

For context, this is coming up because the active profile is stored in the

AddressableAssetSettings

asset, which results in semi-regular merge conflicts when different members of the team are doing tests with different profiles. I'm trying to understand why that value needs to be stored in the asset, and whether it's better to address this issue through a workflow change or some kind of technical change in Addressables itself.

 

It's there so that if you use the LoadContentCatalogAsync API directly to load a separate catalog, all the paths are there already. So if you build your content in a separate project, you don't necessarily have to keep the profiles in sync with the main project.

 

I'm not sure what you mean by this What paths are needed when you try to load a separate catalog? You provide the path to the catalog itself, and then wouldn't the catalog have the paths to any resource locations it specifies? Sorry if I'm missing something obvious, I'm not using

LoadContentCatalogAsync()

in my project so I haven't looked closely at that API yet.

 

You can customize the load paths on any group, bypassing the profile. Those custom paths need to be available at runtime, and groups don't exist at runtime.

 

Ah, I see what you mean now! I think that information gets baked out into the content catalog, though? As far as I understand it, profiles don't actually exist at runtime, either. The actual profile configuration is stored in an editor-only asset (the

AddressableAssetSettings

asset), and isn't included in the built player or content catalog anywhere as far as I can tell. It seems like any runtime variables (the ones curly braces, like

{UnityEngine.AddressableAssets.Addressables.RuntimePath}

) end up getting baked directly into the asset location information in the content catalog:



So I don't think the full profile info is needed to resolve the location of an asset, even when loading a new catalog with

LoadContentCatalogAsync()

.