This question was created in reference to: [Patching release [Content removed]
Hello there !
I want to set up our build machines to be able to generate patches for our game, but I’d like to be able to tell UAT to go find base versions over our local network (basically specify a custom path to -createreleaseversion & -basedonreleaseversion parameters).
At this end, I found the mentionned above [Content removed] where the user asked pretty much the same question.
You guys seemed to say that there was not such a feature, but since the thread is quite old now, I was wondering if the situation was still the same ?
If there is any other new solution to this issue, I’d be glad
I don’t think anything has changed in that regard, all the patching and DLC logic has seen very little development in the recent years.
However, it seems that there are additional parameters to also set a root directory for these two options and they have been in the code for almost as long as the other options:
-basedonreleaseversionroot=… and -createreleaseversionroot=….
You could try setting these to a custom location and see if they work.
Given the age of that code and them only being used for saving the AssetRegistry they might not work at all, but it’s worth a try.
It works if you specify -basedonreleaseversionroot to a remote folder over our network, so we should be able to work with this process :). At least for PS5 update package generation.
Though it seems that the cook process absolutely needs the AssetRegistry.bin file inside the root folder alongside the package in order to perform the patch generation. I was wondering if there was a way to bypass that ?
On our previous project it seems that we didn’t need to have this file to generate a patch for PS5.
Also, my wondering is based on the last answer of [this [Content removed] were your colleague from Epic seems to tell that the generic-platform pak-based method may be not relevant anymore
> Also, my wondering is based on the last answer of [this [Content removed] were your colleague from Epic seems to tell that the generic-platform pak-based method may be not relevant anymore
I think I need to clarify some of the nomenclature here, since I was assuming you were doing something different.
On the Unreal side what we call a patch (or platform agnostic/independent patching)is the usage of the “-generatepatch” command line and the corresponding creation of “patch paks”, as in pak files that only contain the difference from the last release (e.g. new/updated assets and info on deleted ones) and are postfixed “_P” in the file name. These pak files are then copied into an existing release to apply the patch.
This process is what the other thread mentioned as not relevant anymore.
Nowadays all the platforms have good delta patching tools that just take two regular releases and then create binary patches based on the pak files from the old release.
So from the UE nomenclature you are just creating multiple regular releases, each with their independent complete pak/iostore files. The PS5 tools then take those two releases and create the platform specific patches.
> Though it seems that the cook process absolutely needs the AssetRegistry.bin file inside the root folder alongside the package in order to perform the patch generation. I was wondering if there was a way to bypass that ?
Could you post the error message you’re getting when the AR is missing?
I’m only aware of the one stating “Unable to find AssetRegistry results from cook of previous version” and this one should be an ensure, so it should not prevent the cook from proceeding.
I don’t think there’s an official way to skip it, but based on my understanding the AR should only be a requirement when building a patch.
I’m unfortunately not familiar with the PS5 process, there’s a chance this would work without using “create/basedonreleaseversion” and just backing up each of your releases manually. I’ll need to sync with a colleague more familiar with the console platforms.
There is no way to bypass the missing registry when creating a new release, it is necessary when using the “createreleaseversion” parameter.
Just to double check, is the path mentioned in the error message the correct path you’ve specificied via basedonreleaseversionroot?
Looking at the code this should be respecting the basedonreleaseversionroot parameter.
If the path is correct then the question is why your release folder does not contain the AssetRegistry.bin, which should be stored automatically in the Releases/<ReleaseName> folder, or whatever folder you’ve specified as createreleaseversionroot when creating the base release.
Could you give an example of the build command, the folders involved and the contents of your release directory, for both the base and the new release?
It feels like one of these is not not set up correctly currently.
Just for context, the basedonreleaseversionroot should be pointing at the “Releases” folder containing your releases (not the packaged output/archivedirectory of your Release).
Indeed there is no AssetRegistry.bin in the folder, that’s why I get this message.
The reason is because we never packaged any of our versions with the “-createteleaseversion” commandline.
I understand that the assetregistry.bin file is created during cook. And it’s copied into the Release/ folder during the packaging when using -createreleaseversion command.
Since we want to patch from older version that were not built with the createreleaseversion commandline, we’re kinda stuck right ?
We’re currently trying to rebuild those versions with the commandline so that we can get back the assetregistry.bin, and go through the normal process
Since the regular AssetRegistry.bin (not DevelopmentAssetRegistry.bin, which is also saved by the cooker but not part of the package) is a copy of the one shipped inside the pak file you should be able to extract the AssetRegistry.bin from the pak files of your release and copy it into the Releases/<version>/ dir.
However, if you did not use “createreleaseversion” you are also missing the other files places in the Releases/<version>/ folder that is expected as an input here. I think the AR might be the only thing required for a patch, so restoring the AR.bin might already be enough in that case.
