I created a bucket on google coud platform, and uploaded my addressables there. Now, every time I try to load them, I get this error.
using the provided http link in the remote load path:
I get this error:
Exception encountered in operation Resource(textures_assets_all_063acc97ff2462d06d00fb8dc239a3f8.bundle): RemoteAssetBundleProvider unable to load from url https:/storage/browser/MYGAME/Android/textures_assets_all_063acc97ff2462d06d00fb8dc239a3f8.bundle, result=‘Cannot resolve destination host’.
UnityEngine.AsyncOperation:InvokeCompletionEvent()
if I instead use th gs link in the remote load path:
gs://MYGAME_addressables_assets_001/[BuildTarget]
i got this error instead:
Curl error 1: Protocol “gs” not supported or disabled in libcurl
Build Remote Catalog is turned on on the AddressableAssetSettings object and you are uploading your remote catalog as well.
Try updating to 1.12.0 and see if your issue persists
The issue may be something specific to GCP. If neither of those options are relevant to you/don’t work then please feel free to file a bug report and we’ll look into it.
Do Unity officially support (or have a plan to) “gs://” protocol at Addressables?
I had a same problem of Curl error at “gs” protocol, Using Unity ver 2019.4.4f1 and Addressable 1.12.0.
Go to the https://console.cloud.google.com/ and open the Permissions tab of Bucket,
and add a new member as “allUsers” with permitted role to read Storage Object.
This make the Bucket public to Internet.
With this, I made it to download the bundle from Google Cloud Storage (which Bucket was Generated by Firebase).
I hope it helps someone.
If you want to use the Firebase API to automatically get the right url that also supports User Authentication I wrote a small Plugin to resolve the gs:// urls to https:// urls using Firebase API integrated into the Addressables Groups/Providers:
As far as I am aware, UnityWebRequest doesn’t support “gs://”, which means for now we do not. Long term we are going to write a new downloading & caching layer, but for now we have what we have.
The two workarounds:
(more robust, but more annoying) - make a custom provider that does the google call to find out the actual URL then loads that.
(less robust but easier) - I was under the impression that for a given play session, you’d be locked into one root URL for all your content. Which means you can set the load path to “{MyRuntimeVar}/whatever”, and at startup, before doing Addressables.InitializeAsync(), find out the root URL, and set it into your MyRuntimeVar. See the syntax notes for profiles here: Addressable Assets Profiles | Addressables | 1.16.19
Option 2 seems to have worked for other customers I’ve chatted with who were using addressables and gcp, but i’m no expert on gcp and do not know if that’s an all-scenario solution.
Hi, guys (sorry, for copying my question from other thread, but it is related to this one as well). Just want to add some input in this thread over 1.16.1 from Unity 2019 LTS. As I have tried the last couple of days to get this Addressables thing to work with simplest task (remote content update) I can tell you that either is documentation is not up to date or I am doing some stupid things each time.
The problem is when I try to update the remote content on the existing build (created with previous addressables content) it Is not getting updated.
var locations = await Addressables.LoadResourceLocationsAsync(label).Task;
foreach (var location in locations)
await Addressables.InstantiateAsync(location).Task;
This code always returns an old data and not the new one on the cloud.
Want to know if there are any issues with Update previous build command as it doesn’t seem like to be as stable as Build new content command.
On Mac even the first remote interaction fails due to 403 web error. After Unity restart and rebuild it gets fixed. None of the platform worked for me (Mac, Windows, Android, iOS).
Also prior to Firebase and 'gs://" it gives me the same error as the author mentioned. For the regular “https” it works OK, but seems like its caching the catalog once and never gets the latest from remote.
THIS GOT SOLVED.
Problem was outside of the Addressables package. As far as I used Google Cloud storage with public access.
Their docs says that each object is getting cached for 3600seconds by default and thus you will receive it once you uploaded them for the next hour (even if you removed them from bucket or updated by another files).
Got solved by running cloud shell command: