I ran into the same issue and was like yup, I’m just gonna stick with an old version again. Disheartening to see that it does that on a very simple basic assetgroup.
The “Won’t fix” status is a little misleading, this actually should be fixed in 1.19.11. It was fixed as part of a different ticket, both related to build/load paths. After updating you have to set the custom build and load paths or it will fail similarly. Let me know if after that you’re still seeing this problem in 1.19.11 or later
hey @unity_krista , I’ve updated the Addressables package to version 1.19.18 and I’m still seeing this issue when trying to build content.
I saw you mentioned setting the custom build & load paths. I’m not sure if we’re using them correctly, they’re set as follows:
LocalBuildPath: [UnityEngine.AddressableAssets.Addressables.BuildPath]/[BuildTarget]
LocalLoadPath: {UnityEngine.AddressableAssets.Addressables.RuntimePath}/[BuildTarget]
We’ve successfully been using addressables with these values on version 1.18.19 for a while now. Please let me know if I’m doing something dumb or if these paths need to be changed for the new version, thanks
Edit: I think we may be experiencing a different issue. As previously stated, we’re running 1.18.19 which has worked fine until I created some new addressable groups today. All the groups & schemas seem to match existing settings. Now when I attempt to build, we get the following message logged twice:
Could not find a part of the path ""
UnityEditor.GenericMenu:CatchMenu (object,string[],int)
followed by the Addressable content build failure (duration : 0:00:00) error message.
I meant you may have to re-enter them in the settings after updating, because the options changed a little in the inspector. That is strange. All the paths look right in the top level settings and group settings and profile settings?
@unity_krista
Apologies, I’m sure now that this is another bug. The problem only arises when I do the following:
Create a new addressables group
Set the group to Pack Separately
Add one particular texture that I’ve determined was causing the issue
Some notes:
If I set the group to Pack Together instead of separately, the build completes without failure.
Reimporting the problematic texture doesn’t help, and there’s nothing strange about its import settings. Even diffing the meta file to another working texture’s meta file shows nothing weird.
Removing all other groups in our main project (so the one problematic texture asset is the only addressable asset in the project) does not work either.
I’m unable to create a minimum reproduction project - copying the problematic texture + meta, and the entire AddressableAssetsData folder to a new project doesn’t reproduce the error; instead it builds as expected.
I’ll continue trying to reproduce this error in another project so I can submit a bug report. In the mean time, do you know if this sounds like any known issues?
I’m getting the exact same issue. Other members in my team aren’t getting the same problem, the only difference I can think of is that I’m on windows 11 and they are on windows 10.
Also they have cache server enabled where as I don’t.
Regarding the content build failure, I get this error quite often, but only if I have been working on other things prior to doing a build.
As a work around, I simply restart Unity and immediately try again. This works for me every time.
So it seems that there may be some corruption in the memory that develops while using Unity that prevents building addressables that can only be cleared by restarting the editor.
Addressable content build failure (duration : 0:00:00) still happens on Unity 6.0.23 (Addressables 2.2.2)
I have to restart Unity whenever I need to build. Switching platforms leads to the same error on the next platform build, and I have to restart. It has been super annoying to deal with this for at least three years.
Why do I use variables?
I only use variables in Addressable Groups stored in custom packages. The reason is due to the Addressable Profiles, which can get different GUIDs for the various variables there. So, using the build and load paths as a string on the custom packages makes it safer.
This works perfectly, but only when you open the Editor and have not triggered a Domain Reload (as clicking the Play button). This issue got fixed at some point and I was able to confirm it as you can see here.
Since I’m suffering with this issue again, I give up using variables for now and will use the built-in paths instead, even when one of the projects using my custom package would have different GUIDs. When that happens, I will see what to do.