Why are there no synchronously LoadAsset APIs?

Came back to check in on this having looked into moving to Addressables twice now and each time finding it a painful experience. I was happy to see a Synchronous API had been added, but unless I'm misunderstanding, there is a very important flaw that has been quietly swept under the rug?

The documentation page mentions the following:

If these statements are accurate, this means I can't really leverage async to load any heavier assets, since as soon as I call a single synchronous load, all async loads are forced to complete anyway? It's not really practical to expect people not to use synchronous calls when they have any asynchronous loads running, since that is likely to be true any time you want to be using a synchronous load!

Furthermore, even ignoring the obvious architectural issues, if "the intention is for all active operations to complete synchronously" - then this is just terrible API design, since that isn't at all what is communicated by this method. If the intent is to complete all operations, it should be a static method rather than a method on the handle - which implies it will only complete that operation. This is just really insidious design that the majority of people using the method will have overlooked, since it isn't conventional.

Finally, we really shouldn't be expected to track the current operation count - at that point I am just going to roll my own wrapper, since what the hell am I really getting out of Addressables if I have to do all the book keeping it's meant to be doing for me?

I have re-read that documentation page several times now. Please tell me I've misunderstood something here, because if not, this is just yet another installation of bafflingly poor design in a series of poor designs, that have taken us several years to arrive at.

I am a little fed up hearing "due to how <Insert Limitation> are handled in the Engine".
It's your engine! I appreciate that you are all separate teams, but if between you, you can't get those limitations resolved, or you can't provide solutions that work around those limitations, then there's barely any benefit to this "first party" solution.

I don't like being inflammatory on the forums, and I appreciate I've probably reduced my chances of a thorough reply to zero, but this is beyond frustrating and frankly just astounding, and representative of the general state of Unity at the moment. We've been waiting years for a solution here, to one of -if not the- most fundamental parts of the engine - loading assets - and we're no better off than we have been for the last several years, writing our own wrappers around Asset Bundles. Tell me the documentation quote is wrong, please, I beg.

 

If we're ever asked "Why aren't your team using Addressables?", the answer can be found right there ^.

 

https://forum.unity.com/threads/nonasync-way-to-load-assets.1244701/

thought id leave that here, because i really dont wanna fill my project with unneccessary coroutines and addressable boilerplate code. Years ago I didnt care but after taking a look back, addressables invited lot of mess to my project.

wasteful cpu instructions + coroutines + delays + taking few lines visual space instead of just one
thats just recipe for disaster for bigger projects, which should be coded in clear and uncluttered manner

i was hoping maybe sync methods will be added if i wait but seems not so now im wondering what should i do..


EDIT NVM i see there waas sync func added.

 

I was using Resource.Load all over the place. Now since I want to make the game download assets on demand, I have to rewrite quite a lot of code to make things async. I wonder what is the reason to have the Addressables.LoadAsset as deperacted?

 

@userq
XML comment says:

[Obsolete("We have added Async to the name of all asynchronous methods (UnityUpgradable) -> LoadAssetAsync(*)", true)]

So, the API has been always async, but one day they decided to add a suffix.

 

Are you going to change this in the future?

 

Sync versions are already working I think.

 

I was asking about the behaviour of sync operation. Instead of completing only the handle's operation, WaitForCompletion will complete all async operations that was running too.