Download progress fix for 1.1.5

It seems I've managed to fix progress reporting in SceneProvider.cs Can't say if it is convinient way of measuring progress, but it works! All you need to do is to override Progress property in SceneOp class in SceneProvider.cs file and measure progress of all its dependency operations (which is usualy only one - UnityWebRequestAsyncOperation )

Spoiler: Code

Code (CSharp):

1.  
2. protected override float Progress
3. {
4.     get
5.     {
6.         float progress = base.Progress;
7.      
8.         if (m_Inst.m_Operation != null)
9.         {
10.             //Progress of unpacking downloaded bundle
11.             progress = m_Inst.m_Operation.progress;
12.         }
13.         else
14.         {
15.             //Progress of downloading
16.             var deps = new List<AsyncOperationHandle>();
17.             GetDependencies(deps);
18.             foreach (var dep in deps)
19.             {
20.                 progress += dep.PercentComplete / deps.Count;
21.             }
22.         }
23.         return progress;
24.     }
25. }
26.  

 

fixed in 1.1.something. 1.1.7 i think. Not exactly the way you suggest, but should work.

 

@unity_bill I'm still seeing progress issues with downloading asset bundles. I'm using

var downloadHandle = Addressables.DownloadDependenciesAsync(_assetRef);

and when I use the downloadHandle.Progress it prints out like .0039, .8333, then jumps to .91666 for the remainder of the loading.

I'm using my own AssetBundleProvider class which is a copy/paste of the 1.1.7 version of AssetBundleProvider and in the PercentComplete() function the m_RequestOperation.progress actually seems correct. So the downloadHandle up at the top is not properly accounting for all of its dependencies or something.

Is there a class I could override myself to get this to work for now? I tried to follow the DownloadDependenciesAsync() function and got lost on where the Progress is coming from...

 

Others have reported this. It would seem we're not getting the real-time status properly out of the actual web request. We haven't had a chance to look into it in depth yet, but it is on the list.

Thanks for the report.