UASSET on a server (download on demand)


Is there a way to store .uasset on a server and download it/them when needed?

The idea is to ship the game with the minimum number of assets (and thus keep the filesize small) and only download the new assets when necessary.
Also I would like to state that the player would be required to download the asset in order to use it and not run it on the server.

If anyone has any direction I should look into it, this would be much appreciated.

You can mount PAKs at runtime and instantiate the uassets from there. The same thing should also work with .uassets(PAK are nothing more than containers for uassets.).
Direct guides are sparse on this topic but I found some examples on the answerhub:…t-runtime.html
The overall idea is quite simple. Load the pak, find the asset you want to load and then instantiate it.

As for the download of the uassets/paks theres another really nice answerhub post:…le-online.html

I quoted the guide here if the answerhub is down for whatever reason.

by the way depending on your game you can start downloading the files when the player has reached a specific point ingame(like level X or when he reached a transition zone.). Thats how we did it for our unity game. The user never notices that he has to download more.

@TriNityGER Most of these entries are quite old and no longer compatible with recent versions of engine (begins with 4.19 or so). There is also a distinction has to be made between static and dynamic (eg blueprint classes) contents that require different methods to get access to them. The issue goes beyond this, when you are running the same code from PIE and Cooked game, where asynchronous loading must access the classes differently. While this may not related to PAKs in general, it still is an important piece of the puzzle to be dealing with. In fact, mounting PAKs in editor is not really work out nicely - for the most part it is causing further issues with file system handlers. Tho it could be avoided with careful implementation and usage.

Once mounting a PAK the code has to load the actual asset registry, and it may be packaged (in PAK) at least two different ways (depending on the folder structure and other circumstances when cooking the PAK), which the method should be accounting for. Unfortunately the post you are linked here does not seem to be dealing with any of these issues i have described above, and as such they are very much incomplete. I do agree on that the documentations are quite rare in this matter.

Mounting pak’s are game boot time only, which is the only officially supported way so far. Doing this in runtime require quite an effort to pull it off.

Since you were kind to share many references here, would you please also give a general overview of your experiences with said workarounds in recent versions of the engine?

Hmm that sucks. tbh I only experimented with it years ago and barely remember things. Kinda weird all this is so undocumented and/or difficult to pull of as Unity’s asset bundles work fairly straight forward…

Yes i have only heard about the ease of use with Unity asset distributions in this matter, but i am affraid unreal does not support this idea out of the box.
With much work and trial-and-errors i have been finally managed to make this work in 4.17 and tested in 4.19p5 for the final time, but i had to go thru many steps most of them does not even revealed on any sites.

In order to get the asset registry to load, i had to decypher the DLCs pak file structure, and find both cases of where the asset registry container may be stored, then extract it manually by implementing the decryption and decompression in my class, and finally then i could load it up so it will work. Not a nice thing to do and only one step of the many. It shouldn’t be this difficult. What did i miss?

Thanks for the replies!

It is interesting that such a simple task should be so convoluted to implement.
I will give it a shot and post any updates…

Hello knotff, I found myself in the same situation as you! Did you have any luck? Thanks in advance.