Teşekkürler güzel yorumun için 😊

Thanks :)

You can use the fillAmount of the Image! After or before apply the value of progressValue to the LoadingBarFill, you can save the value in a string variable and set it in a text object on the UI.

you can make the text variable and reference it, and give write this code in the while loop: myText.text = $"{progressValue * 100:F2}%"

If there are few objects in your scene, it loads fast.

I am not sure about it but I think it's bcz , that the loading take .9 percent to change the scene out of 1.

It depends on what you are trying to achieve. If you want your users to se the loading screen for at least 1 or 2 seconds after the scene loaded just add a: yield return new WaitForSeconds(seconds); And then a: loadingScreen.SetActive(false); All of this after the while loop in the coroutine. Take in mind that the canvas GameObject of the loading screen gets deleted when the new scene loads so use a: DontDestroyOnLoad(loadingScreen); and DontDestroyOnLoad(this.gameObject); at the start of the coroutine. Then use a Destroy(loadingScreen); and Destroy(this.gameObject) after the: loadingScreen.SetActive(false) you added before

@@tony_almanzor9760 Wow thank you so much! Also, you have to make sure the object that DontDestroyOnLoad is not a child so it can actually be called.

Yes it works.

@@SoloGameDev thank you! and if its not to late to ask, why is it giving me a CS0642 warning: *Possible mistaken empty statement* in line 24?

@@dcry1003 show your code?

You probably got the calculation part wrong.

@@SoloGameDev How to fix it

@@thefauron742 The answer to that, if you did write the proper read on the Operation.progress, could varies depending on what's in your previous and next scenes as well as how your code refers to the UI element. For examples... ...if you scenes are huge and complex, the switch of scene using LoadSceneAsync process can take a lot longer than what is returned by the .progress as it doesn't count the time it takes for the Garbage Collector (deletion of unused memory blocks) to clean up the memory buffer. So while the next scene might be loaded into the memory, the old scene data might takes time to be "digested" and that's why there might be a hold-up in-between the time when the .progress makes the slider full and when the next scene actually appears on the screen. If you want the player to be able to play while you stealthy unload a previous level (instead of just waiting in limbo as the old scene is digested by the Garbage Collector) with scene heavy in data, you'll have to think of a custom way using the LoadSceneMode.Additive mode so that you add and remove in your current scene instead of switching scene (which requires a memory clean-up every time.) Side Note: Remember that changing scene in the Editor is different than changing scene in a build as Unity's Editor uses a sort of sandbox environment, but can't avoid adding a lot of data onto the actual scene data because it has to update the Inspectors and Hierarchy and other Editor tools live. ...if the scene does load and you can see the switch of scene, but the Loading screen remain full, that's another kind of problem which should be related to how you set up the Loading screen. For example, if the loading screen is set on a DontDestroyOnLoad() game object, you'll have to set the loading screen to Inactive once the loading is done. This can be done by adding a "LoadingScreen.SetActive(false)" in the code after the "while()" in the code above. (That requires that the LoadingScreen Object is referred in persistent way. There are various ways of doing it.)

When you create an image, the canvas is created automatically. You can think of Canvas as the parent of images.

Just make one?

@@SoloGameDev the loading image?

Agree. Would be nice to see not only how to code but how to prepare progress bar

Did you not watch the first 30 seconds of the video?