Question [Solved] Unable to load catalogue with dynamic path

Hello,

I wrote a mod system built on top of the addressables package and just recently found out that at least v1.19.19 breaks a very important feature of my system which is the ability to rename folder mods aka catalogues are located in.

I have a system that syncs the load path for the bundle that is saved in the catalogue file. This sync happens before the catalogue is loaded to make sure it has the correct folder name if it was changed. In v1.19.19 (potentially even before) anything loaded from a catalogue that had it's folder name changed will throw a bunch of errors that relate to the system seemingly trying to access the old path.

The loading of the actual addressable works and the catalogue is indeed loaded but throws 5 errors whenever I access any addressable renders the entire approach useless.

This appears to all be related to the requirement of having a load path specified. It looks to me that internally the addressables package wants to always load the addressable from the previously defined path and not the path in the catalogue. It will therefore throw those errors if the path is different from the original one.

Example:
I have the following specified in the 'Default Local Group' Asset


If I now change the folder name to anything but Mod1 the errors will occur even though the catalogue gets successfully loaded from the new folder name and the bundle file also appears to be loaded just fine as I get the addressable returned correctly if I request it via its address.

My question here is if there is some way I am not aware of that would solve this issue or force the addressable system to ignore the load path? If there is a way to have the load path be relative to the catalogue which is always the same folder would help immensely. Also, is the path specified in the editor potentially in the bundle file too which would cause this behaviour?

What I essentially need is a way to ignore the original path and have it instead only use the path specified in the catalogue.

Thanks for reading and any help that can be provided

 

I believe to have figured out what is the issue.

The behaviour described in my previous post occurs when I try to load assets via and addressable label. The problematic call is when I attempt to load the addressable with Addressables.LoadAssetAsync<T>(location) with the location provided by Addressables.LoadResourceLocationsAsync(label). If I instead get the location manually by using the key from location.PrimaryKey and checking the available IResourceLocators with locator.Locate for the location and call Addressables.LoadAssetAsync<T>(location) with that location instead it will work as intended and not throw the errors. What's odd is that both locations printed out are the same.

What I do to work around this is simply get the location via locator.Locate and use that in the Addressables.LoadAssetAsync<T>(location) call instead of using the key directly in Addressables.LoadAssetAsync<T>(key).

I might file a bug report cause I currently do believe that it is but will give it some more thought before doing so.

In the meantime maybe this post can help someone else that runs into this issue.