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.
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 