Non async version

What is there to load if it's already in RAM?
What do you mean by "in memory"? Disk or RAM?

 

Have you looked at the Addressables Samples on Github? There is a SyncAddressables example, I think it shows how to do exactly what you want. If you call LoadAssetAsync() on an asset that was already loaded by the same call from a different place, AsyncOperationHandle will point to a cached AsyncOperation that already has Result set. So you can access it immediately in a sync manner.

 

1, maybe the naming 'load' I used is ambiguous, should be 'get' to be more specific.
2, RAM.

 

thanks for your info. I'll try to look into that example project.

However, as I've tried code running, it does not work that way, i.e., cannot "access it immediately in a sync manner".
Example:
step 1, preload assets (by Addressables.LoadAssetsAsync<object>) with a label, which actually load a bunch of assets, e.g. "apple" "banana" "cat" with label "default".
step 2, wait until it's `Succeeded` from callback. (observed: the loaded assets are ready in the handle.Result property)
step 3, do not unload, i.e., do not call Addressables.Release().
step 4, do another call of LoadAssetAsync() from a different place for a single asset loaded (e.g., the "apple"), and immediately look into the returned handle object in sync code.
Observed: the returned handle will have the `Result` of `null` and `Status` of `None`, i.e., I'll still have to write async code (by `async` `await`, or by `delegate` `+=` `-=`) for it.

 

Yes, I think it's because in this case there was no cached operation for retrieving single asset, so it needs another frame to complete the new operation.

The approach I'd use for having sync assets is to pre-load stuff that I need synchronously during loading, place it somewhere and then access normally during game play.

 

Would be nice to have split things into two packages: one for the async loading and one to sort out the problems inherent with the Resources approach (which could be used directly by those using sync loading).

 

Having a sync load function (even if it stalls and whatnot) would have been really helpful for learning Addressables.
Right now I first had to learn async and only then I was able to actually use Addressables.

Also, the documentation sucks. Dependencies are huge and important, yet you can't find anything about them.

 

Without a sync option, addressables have proven to be a huge mistake for me to use. Now every class I make has this unneeded async complexity. All I wanted was to reduce patch sizes for console, but the dogmatic "async only" api adds so much extra work and potential for bugs. I regret trying out addressables. I've burned so much time, that I should have spent just use asset bundles.

Which, as other people point out, is the backbone of addressables, and it has a sync api. So from a technical standpoint we know the system supports it already, but the developers have this dogmatic belief of "async only"

And by the way, Unity's async all runs on the same thread anyway, and isn't any faster.
You are forced to use their async in a "sync" manner because you can't actually load multiple async things at once. If you load multiple scenes async from addressables and then try to activate them all at once, they will block each other unless you activate them in the order they are loaded.

So with addressables you can get the bad stick of both the async and sync worlds!

 

There is an example of Sync API in Addressable Examples repo. How hard it is to adopt it and use it if you don't want to mess with async stuff? Just pre-load remote stuff in bulk using labels during loading screens and then use sync interface in all of your code to get assets from bundles. What's the issue?

 

Any news? We need sync addressables

 

For anyone else looking for that, there is a preview version already: https://forum.unity.com/threads/release-announcements-and-notes.543537/#post-6776828