search

juniordiscart / com.unity.addressables

Addressables extended with the ability to build multiple catalogs, ideal for traditional DLC purposes.
https://docs.unity3d.com/Packages/com.unity.addressables@1.17/manual/index.html
Other
76 stars 23 forks source link

'Could not find file' error during build #4

Closed Metal-666 closed 1 year ago

Metal-666 commented 1 year ago

I'm getting this error when building addressable content: image Minimal project demonstrating the issue: CouldNotFindFile.zip

Metal-666 commented 1 year ago

Removing this foreach loop seems to fix the issue: https://github.com/juniordiscart/com.unity.addressables/blob/bffdf42180ef7c3b874f458c62b8b4de418f177c/Editor/Build/DataBuilders/BuildScriptPackedMultiCatalogMode.cs#L159-L162 It looks like the purpose of this loop is to move built bundles to where their respective external catalog is located. This doesn't make much sense to me, since you need to assign a Build and Load path to each addressable group anyway, and in my case I set it to the same place where the external catalog is built, making this loop redundant and causing an error. I guess maybe the intention was to skip the process of assigning Build and Load paths to groups? If this is the case, should I set both paths to the predefined Local paths? Should I only set the Build path to the predefined Local.BuildPath? I would appreciate if someone could clarify this.

juniordiscart commented 1 year ago

Thanks! I'll have a look when I can find the time. :)

KCFindstr commented 1 year ago

Getting the same issue. Have to specify a different build path because of this.

juniordiscart commented 1 year ago

I wanted to write a small update to this issue.

I'm investigating it, but some things run quite a bit deeper than I initially thought. @Metal-666, to answer your questions:

I guess maybe the intention was to skip the process of assigning Build and Load paths to groups?

The external catalog system didn't take into account custom build and load paths on asset groups. It assumes it was set to the default Local.BuildPath and Local.LoadPath, as that generates the expected paths for it to extract the files to the external catalog. Other values just weren't considered a possibility.

If this is the case, should I set both paths to the predefined Local paths?

That's indeed the original intent, as said above, it basically comes down to undefined behaviour otherwise. I simply didn't write specific support for the scenario of custom build and load paths. That's why removing the foreach works in that case, as the bundle files are directly build to that location, instead of being extracted. But it's still necessary if the groups have the paths set to their local defaults.

In my project's situation, the external catalogs expected their content to be placed next to the catalog. But that's of course not desirable for everyone. So if it's no value to you, you can set the build and load path of your asset groups that belong to your external catalogs to their local defaults again, and it should work as intended.

I'm currently investigating to see if I can properly support both options though.

juniordiscart commented 1 year ago

This issue should be resolved now. Additionally, a fix to vanilla Addressables had to be applied as well since the <custom> build and load paths was broken.

Finally, I updated the ExternalCatalog to use ProfileValueReference for their build and load paths so it can easily reference an existing build profile. It also got updated to version 1.21.9 and supports binary catalog files.