Hello,
I’m writing a general purpose Addressables Manager Script for the community.
Questions for now:
- Can you get a list of groups by script in runtime?
- Can you get the size of each group by script in runtime?
The manager script will start with two components:
-
2 pop Queue loader:
This is for people who have tons of assets on disk, but only want X in memory(typically 2), one to be played, one to be loaded. After the one is played, it is unloaded, the one in queue becomes active, and a queue is loaded… A good example for this is music, but I also am having a news ticker always showing a tv image. This 2 pop Queue loader is a good component a for general purpose Addressables Manager Script1
-
Unexpected On demand load:
Lets say your game has thousands of items like Diablo 2, but you don’t want em all in memory. You kill a monster and an item is dropped, so unexpected On demand for load happens. The demand for load sees if it is already in memory, and if so, uses it. Otherwise loads it, Until the load happens, a temp representative gameObject is seen if necessary(if placeholder option picked). When load happens, its swaps for placeholder(if option picked) otherwise is processed to be seen by similar channels. For unloading, choose X minutes since last seen to unload, like 15-25 typically. Every time you issue an on demand for load(you use the object) or your script knows it is in use, the ‘datatype long’ timer of ‘last used’ is refreshed.
I’m sure I’ll add to this script I’ll supply the community, but I’m asking the question now is there a way to query the list of Addressable groups? And is there a way to get the size of each? Otherwise we run into clunky hand coding of indexmax for each group, and that isn’t something I’d be proud to share with the community.
,Jim
No. The concept of a ‘group’ as you know it in the Addressables Group window does not exist at runtime. A group has several settings which can split the group into different bundles, e.g. afaik, scenes and other assets cannot co-exist in the same bundle (at least, that was the case before Addressables, and I kept this separate in our Addressables setup anyway), so these are split by default, and depending on other settings on the group, a bundle per asset is created. So groups are not a concept you should be looking to use at runtime. There is information you can deduce from the contents of the catalog file, because it contains the keys that resolve to a specific location to load from. But there’s no straightforward way to get that data, unless you reverse engineer how it’s generated or check out how it’s used at runtime by the Addressables system.
If you require groups specifically, then ‘no’ is the answer here to per the first question asked. However, if the asset bundles are stored locally on disk (build and shipped with the player), then you can get the filesize of the asset bundles using C#'s System.File API. If you host your asset bundles on a web server for your game to be loaded, you generally can’t get the size of the files, unless you create some custom web API for that and query the size prior to downloading it.
However, bundle size is not really a metric to go by for memory usage. A bundle may be loaded, but that doesn’t mean all assets it contains are also loaded. Depending on the compression of a bundle, assets can be streamed in, only requiring the memory for the assets actually needed. LZ4 compression is like a zip-file: you can check out what’s in there and only extract a select few items to decompress and load without loading and decompressing the whole file. LZMA compression will require the whole bundle be loaded and decompressed in memory. So this one defacto places everything in memory. Not using any compression is similar to how it works as LZ4 (minus the file size compression of course the asset bundle file). Generally, it’s best to stick with LZ4 as it yields great results and performance. It just results in longer build times because it needs to compress the files of course, but helps in upload times because the files are smaller.
Addressables will also unload the full bundle again if no assets registered to it are loaded anymore. So this is generally nothing to really worry about doing this all yourself, and one where you already have pretty great control over on a higher level. E.g. if you have loot that gets dropped, the placeholder icon/item can be in a group that is either small, or in a bigger group with assets that’s always loaded. Your actual loot data (prefab, meshes, materials, textures etc.) can be placed in a separate group, which will be loaded the moment the loot drops, and you can replace the placeholder icon with the newly loaded data once it’s done. When it has been picked up, you can destroy and release the specific loot data, after which Addressables will unload it if no more references exist to it (provided you use the correct Addressables API calls to release). So there’s already pretty great ways to manage the memory lifetime of these assets without the need to dive deep in level of the bundle files themselves.
no… unless you reverse engineer how it’s generated or check out how it’s used at runtime by the Addressables system.
Super thanks again! This will be easy to work around, I’ll have to manually type the int for each group’s size.
I would not want to reverse engineer this, considering one role of addressables is obfuscation so you can’t steal a game’s assets .png/.wav/etc. So even if you did reverse engineer it, once it was found out, they’d change the encryption, lol, not a winning battle.
You rock my man, thank you for a freaking essay. If I make it big, just ask for the cash and you got it.