Such as the title。
Do you mean that it’s always 0 ? Because I noticed this too.
No,the progress is not continuous，for example：0→0.3333→0.6667→1,Only few numbers。
This is probably due to your op having 3 dependencies that are all either done or not. So initially none of the dependencies are done, then as the first finishes, your overall % jumps to 0.3333.
For the individual dependencies, we are at the mercy of the progress that the Unity engine itself reports to us. For downloads, this should be active progress. For many other things it’s either 0% or 100% due to what the engine exposes. If you have a specific example that you think should be more granular, but isn’t, please let us know.
What scenario are you seeing this?
I used Addressables.DownloadDependenciesAsync(),the progress will stay a lot of frames between two numbers.
we’ll take a look at it.
I also have this problem, when download a large bundle,maybe 30M, with low network speed(200K/s), the progress will keep a number for long time until download complete.
1 Like
Same issue here, it is stuck at a progress completion for a very long time.
I can see that this isn’t really being taken seriously, but it could cause an app to be reject by Apple App Store review.
We are seriously investigating whether we should make our own downloader and dependency resolution just to get proper feedback on the download progress. This is an indicator that the Addressable developers are dropping the ball on this.
App Store review requires that we present proper feedback for user. It’s absolutely unacceptable to download several gigabytes, provide zero feedback, and suddenly jump to 100% at the end. It’s so unacceptable that I don’t see this passing App Store review.
What could possibly be the problem? I can see in your code that you know exactly the number of bytes passing through. Instead, you choose to count the number of open processes, which remain open all the way to the end. This is a bizarrely poor design, and @unity_bill seems to keep rationalizing this as somehow OK.
It’s OBVIOUS that the only thing that’s acceptable is a fluid download progress from 0% to 100%. Every other app in the world is capable of doing this. You have access to the byte-for-byte progress in your code. The only thing that’s stopping you is not realizing that this is important. Important enough that apps can get rejected over extremely lousy feedback during downloads.
Check this in version 1.14.2 “Added GetDownloadStatus method to AsyncOperationHandle. The DownloadStatus struct returned will contain the total number of bytes needed to be downloaded and the current number of bytes already downloaded. Cached AssetBundles will not be included in the count and if everything is cached, the values in the struct will be zero.”
I saw this function in the source code, but it’s not available on the AsyncOperationHandle we get from downloading. Is there a special version of the handle for downloading? It somehow keeps eluding me. I was close to forking the Addressables source just to put a “public” in front of the function they call internally.
private IEnumerator DownloadAssetBundles()
{
var opSize = Addressables.GetDownloadSizeAsync(ADDRESSABLE_DOWNLOAD_KEYS);
yield return opSize;
Debug.LogWarning(opSize.Result);
var _downloadOperation = Addressables.DownloadDependenciesAsync(ADDRESSABLE_DOWNLOAD_KEYS, Addressables.MergeMode.Union, false);
while(!_downloadOperation.IsDone)
{
// Refresh Progress bar of Updating...
Debug.LogWarning(_downloadOperation.GetDownloadStatus().DownloadedBytes);
yield return null;
}
}
1 Like
Hmm, it compiles, even though intellisense isn’t picking it up.
Exactly. It appears then that the problem is actually solved. It was just fooling me that (a) it isn’t mentioned in API docs, and (b) Intellisense shows the method as non-existing.
Thank you very much for insisting, and for the code sample. I need to rebuild intellisense.
A simple restart of VS Code, and it picked it up. I guess my computer doesn’t crash enough! Damn you, Windows 
It’s definitely still broken, though, and follows the same weird pattern as PercentTotal, that it hangs at a low number, and races at the end. I’ll make a separate post.
I posted a thread about GetDownloadStatus not performing any better than PercentComplete:
This isn’t just a cosmetic thing. Without an actual, good faith download progress, users will have no idea how the download is going or whether it’s even happening, and an Apple App Store reviewer will simply see a hanging app, and reject the app.
Anyone ever figure a solution? DownloadStatus always return 0 and PercentComplete jump in 3 step because I have 3 assets 