Using PAK signing when making patch builds

We have been trying to enable PAK signing for our patched builds, and finally I found a way. It’s quite messy though, so I would like to know whether there’s a better way.

First off - after enabling PAK signing for our patched builds, the base build works just fine but any patched build refuses to start, giving an error saying something like “Unable to find descriptor file for game.uproject”.

The thing I noticed is that in the base build there are .sig files for each of the PAKs, in the Game/Content/Paks folder that we distribute as the game build. These .sig files are not included in the Game/Releases/BaseVersionName folder for the same build, so they are not present in the workspace when building the patch. The patch builds without issue, but the patched build will not start. The Paks folder of the patched build contains the .sig files for the _P PAK files, but not for the base PAK files. By copying the base .sig files over into that folder, I can get the build working.

What I’ve done in our build scripts is to add a copy step to get the base .sig files into the Game/Releases/BaseVersionName folder, so they get copied to our build storage and then into the workspace when creating a patch for that base build. I’ve also had to add a copy step to get the base .sig files from that folder into the final build folder for the patched build (where the other base PAK files are already being copied without my interference). (We do not use Horde.)

Is there a better way?

Steps to Reproduce

Hey Markus,

apologies for the late response.

This is likely an oversight and most users just worked around it by copying the files from a previous release (or just by copying the patch paks/containers into their latest packaged release).

I agree that the output from the patch build should be able to run standalone and the .sig files should be copied alongside the original paks/containers.

I’ve created a bug report, as this also has been reported by another licensee recently.

We’re tracking it as UE-295497.

Since the workaround is pretty straightforward it’s likely this will be considered low priority.

You can follow the status once it gets mirrored to the public issue tracker.

Kind Regards,

Sebastian