[Resolved] Loading addressables exported from a separate project

I've been watching a few tutorials on Addressables, and I still can't quite figure out whether this should currently be supported given the new features these tutorials hammer mostly on. That is, do Addressables allow you to pack bundles in a project different from the main application? It's currently possible with Assetbundles, and I keep seeing it tossed around that Addressables are built on top of the Assetbundle API, so to me that sorta implies that anything you can do with Assetbundles, you'll be able to do Addressables.
But all the examples I've seen so far use one project to build both the asset bundle and the application. So it seems less geared towards the type of use I have in mind, which is to build the application once, and create and export assets from a separate project.

 

Awesome, thanks!
I should have phrased this better. It's still in preview so it's a bit silly to expect full coverage of the entire feature set out just yet. I'm glad it's being considered. Aside from the script constraint you mentioned, I was beginning to wonder if this use case was a sort of "you can technically do it now with Assetbundles, but probably shouldn't if you can avoid it" kind of thing.

 

Thanks for expanding.

 

We do this successfully, with Addressables version 0.6.8 in Unity 2018.3. The key parts are:

• Build asset bundles in project A normally. Copy asset bundles to server, copy link.xml to Project B, and catalog.json must be renamed and copied to project B
• Project B has its own (potentially empty) addressable configuration, which is built as normal.
• Project B calls this:
  var asyncOperation = Addressables.LoadContentCatalog(catalogPath);
  ... wait for the asyncOperation
  Addressables.ResourceLocators.Add(asyncOperation.Result);

Be sure to not load the same catalog twice, as that will result in an error stating that the asset bundle is already loaded.

 

@EirikWahl : Could you please elaborate more on link.xml? When I build player content, I got three files: .json, .hash and .bundle. I did not get any .xml file.

 

Our project shares the same concerns as the OP. We have an assetbundle solution working without any catalogs running on the previous assetbundle way of things. If we stay with our current assetbundle code-base, will this break with future Unity releases or should we migrate to the new code base?

It seems addressables is not the way we need to go where there are multiple users creating content, uploading to a server, using a centralized database/web service, and dynamically loading into the scene at runtime. Or are we missing something?

 

If you have used another version of Addressables, this may have changed. It is the file describing what classes/methods should NOT be stripped away when building the Unity project and "Managed stripping level" is set different from "Disabled" in player settings. Some classes (for example custom asset providers) do not have direct code references, but are only referenced in JSON/XML files, and the compiler must be informed to not "optimize" the build by removing these seemingly unused classes.

In other words: Try to find that file. If you can't find it, a workaround is to ensure you have turned off stripping. Good luck with your project!

 

Thanks @EirikWahl : With some struggle, I am able to create Addressable Asset bundle and it is working fine. Thanks once again for your valuable feedback

 

Why a copy of the catalog.json is needed?
Should be copied every time a new asset is built into the catalog from the project A?
Or is it just a sort of "first" deploy, to know where to take the asset?

 

I do a fully automated Addressables build from external projects as part of my SDK for my game. It is open source so y'all can get inspiration from it. Basically, I allow my players to create their own game worlds, package them and upload them to my servers. I setup addressables fully automated in the background and build for all supported platforms.

• setup settings
• create groups and profiles
• build per group
• rename catalog files
• upload

https://github.com/WetzoldStudios/traVRsal-sdk/blob/master/Editor/PublishUI.cs#L371

 

So let me get it straight - it's been 3+ years of this project existence, it is out of preview and all we have is this shacky, hacky and unstable way to do something they were claiming to be one of the important features and were proudly boasting about here:
https://invidious.snopyta.org/watch?v=iauWgEXjkEY

Never change Unity.

Are you talking about copying it into the output build folder?
What if Project A has a mix of local and remote bundles and not just all remote like in your example?

 

@ImpossibleRobert on the client project, do you share (by copy) some file or settings with the builder project? and or, do you need to have an addressable settings (even empty) also?

 

I share common artifacts inside my SDK, like Shaders, common C# scripts so they can be referenced without including them in the bundle etc. AddressableSettings are created programmatically on the fly.

 

How any of this even work that way? You cant include scripts/logic into asset bundle/addressable bundle, it never was possible and if you reference a shader it will be packed into a bundle on client side (because different project) which means it will be a duplicate data.

 

You can reference scripts if they exist in the producing and consuming project. This is why Unity components work always. I put all my custom components into an SDK that all projects simply reference which creates a common base for reuse. Some only consist of an empty stub for configuration which will be extended at runtime. Of course the C# scripts will not be included (it is technically possible though, but doesn't reliably work on all platforms, which is why I went for a visual scripting approach at runtime for dynamic logic).

Including custom shaders is important in my case since I dynamically switch shaders at runtime, making them not always visible to the shader stripping feature of Unity and which will lead to missing shader variants.

 

So, I did a quick look through the project. I see you ship Editor tooling with it and some Runtime stuff, including your aforementioned shaders and some 3rd party tools.
So, how does the custom code work? Is it serialized into SO with xNode and then just shipped as part of the project instead of Assemblies? Okay, but how would runtime playtest work? When player fetches base game bundles from your remote server - he still needs Assembly data to run the test play mode, or the nodes available will be limited to predefined set and the rest of the logic will not work.

 

Yes, the nodes are limited to the predefined set. This is why they are very flexible and rather low level. I actually support two flows, my custom xnode nodes and the full feature set of FlowCanvas.

 

This approach sounds super interesting to me, as we are trying to build something similar for an AR app. Is the code you're using to build the addressables on server-side open source as well? That would be super helpful.

 

Building addressables is all client side and in the SDK Server just hosts! So that can be any file share, e.g. S3