The addressables manual from version 1.17.17 mentions (though just very briefly) addressables in (custom)packages. The addressables manual from the current version 1.20.5 does not contain any mention of using/including addressable assets in packages anymore, even though addressables seems to be the recommended way to do all asset loading etc. (Even unitys own package validation suite warns when using resources inside of a package).
Is this a mistake or is there a reason this is not mentioned anymore? Also why is information on this so hard to find? There is a single forum thread that talks about including the associated asset groups and schemas in the package, but it is a year old and there seems to have been some trouble with importing asset groups if there was no manual setup of default asset groups in the project before etc.
Is this the intended way to reference assets in packages or is it not?
Hi @leutnant_kane the Addressables documentation was recently revamped, hence the difference in versions. You can mark assets in the Packages folder as addressable just like assets from the Assets folder, and they will load as expected.
There is just a slight caveat for addressable groups/schemas in packages. Since they use GUIDs which are project-specific, you will need to do some extra configuration to use them in a different project. We have a sample tool that shows how to do this called “Import Existing Group” Import Existing Group | Addressables | 1.20.5
Hi @pillakirsten thanks for the info!
Is there a change planned for this? Because this actually seems like a pretty big showstopper to me. If I understand this correctly: With the current addressable system I need to check manually after each package install,update or removal if there are/were any groups inside the package and import/update/delete them accordingly? We have around 20 projects with different maintainers that want to use internal and external packages to power them. The potential for human error seems enormous with this approach. Even if we invested the time and wrote an extension to unity that did this checking automatically each time a package is added/changed/removed, that is still a pretty sizable amount of work with lots of gotchas like resolving packages when opening unity or when the manifest was updated outside of unity etc.
Just putting package assets in the resource folder seems far more usable for production to me, but of course that is not recommended (comes with memory and performance gotchas) and would only work for packages that we control ourselves.
This entire thing also seems to me like something that does not need user interaction. If the project depends on a package and the package depends on certain assets, is there some benefit to importing and managing these package assets by myself (that I am not seeing)?