AsyncOperation.progress <-- Not working?

So yeah, does this method work? My debug keeps showing a zero value (even though the level loads up just fine). I’m trying to make a load progress bar. My code:

void Start()
	{
		syncLevel = Application.LoadLevelAsync(levelToLoad);
		
	}
	
	void Update()
	{
		UnityEngine.Debug.Log(syncLevel.progress);
}

So I’m guessing this is a broken method then?

The value changes from 0 to 1 when AsyncOperation completes its task.

So then it is not possible to make a “progress bar” based upon any “progress” value?

Anyone? The scripting reference says this:

" Unity will completely load all assets and all objects in the scene in a background loading thread. This allows you to load new levels while still playing the current one, show a progress bar or create a completely streaming world where you constantly load and unload different parts of the world based on the player position, without any hiccups in game play. "

How do I make a progress bar? The only way I can think of is to make my progress bar increase based on some bogus value like increment the bar by 2 every second and then when progress = 1 fill up the bar. That is a pretty lame way to do it. Any thoughts here?

Dreamora is correct. Progress will never return any values between 0 and 1 in this case, so you cannot make a progress bar, you could just make an indeterminate loading bar.

This is disappointing.

How is one supposed to implement level loading screens?
Why do I need an AsyncOp at all in this case if it will never return anything but 0 when it starts and 1 after its done? I don’t.

And what does the mutex have to do with anything here? First off, locking the mutex (or Critical Section) is super cheap compared to the IO operations and caching that have to be performed during the level load.

Secondly, if you really don’t want to use mutexes you could use atomic operations on int, and increment it from 0 to 100.
Done. No mutexes and you got nice thread safe progress information.

I had the same problem with progress being only 0 or 1. This was solved by 3.5.0 release on 02/14/12.