You didn’t specify what are the issues with DQ patcher you are unsatisfied with So i’m going to make an assumption it is perhaps an issue with large memory use and excessive disk operations. Since the rather simple and intelligent way DQ patcher will handle this operation i think it’s not actually issue of the patcher. You can choose whatever patcher you find comfortable to working with, the problem will still boils down to the PAK files. If the project in question is using one single PAK file for all contents, the patching will always yield in bad results unfortunately. PAK files are literally the nemesis of any patcher tools. Here is why.
Since the modifications introduced to the PAK file can happen in random locations, offsetting will be required for the patcher to inject / reject certain parts of it, however it cannot be done on the disk because there is no hardware support for such actions.
Not to my knowledge at least. Perhaps it would be possible to exploit the fact that hard disk drives are capable of handling file fragmentations, and so the patcher would be able to reassign certain parts of the PAK files to different areas of the disk in order to mimic the offsetting, and so the patcher can add the modifications to the end of the file, then reassign the sectors to threat the affected parts. But this is purely hypothetical and require quite an effort to figure out it’s possibility. Also the outcome may result in continously increasing file size which is rather unsatisfying.
A preferred solution would be to not using PAKs at all. The reason is because it will allow the patcher to only modify those affected files which are actually being modified, and not the entire PAK file. This is a huge improvement, if not the ultimate one. The down side of not using PAKs it will result in large content folders because unreal will only Compress / Encode PAK files, and not individual files. A modification to the engine code to use compression on individual files could be a potential middleway solution here that keeps the content size small (and encrypted if neccessary), while allowing the files to be individual contents. I’d expect no differences in performance, compared to a single pak file being compressed, but maybe i’m wrong on that. Tests!
Doing this may rise some security concerns, however i find those are rather negligible since the unreal packaging system is open source, so anybody can write exploit tools to modify PAKs - therefore defeating the advantage of having the content stuffed in a single PAK. Without being open source it also cannot guarantee proper security.
Some patchers you have mentioned implements BSDIFF which is originally designed for executables (according to the original author at least ) so despite it’s common use it may not yield in good results at all. Not much better when comparing to the DQ patcher method at least. ZPatcher is a rather unfinished project and props to the author for making it, it is very promising indeed, but it lacks of many features which makes it a difficult to choose. Butler, Karazeh comes without UI as it would seem, so that’s up to the deveoloper to extend these projects with such features. Finding deveopers with understanding of Go lang can be another challenge on it’s own:) JunoPatcher may seem open source, however the core (GRF.dll) appears to be closed source so modifications to the way it works can be rather difficult if not impossible (thinking of reverse engineering which is illegal).
I think the best bet would be for you to stick to DQ patcher and try using unPAK-ed contents, hopefully it will resolve all troubles for the longer run, especially if the project in question is huge.
bsdiff - Binary diff
dq patcher doc - https://docs.google.com/document/d/1…fqTlaQCRw/edit