This is technically not how we should do this. In theory we should
"overlay" the delta manifest over the proper one and simply add/replace
the chunk/file list entries with the one from the delta manifest.
However simply not deleting files also works for the time being since files
are rarely deleted anyways.
This may result in less-optimal situations since
it effectively also disables patching. But it does
allow us to re-use the resume file mechanisms for
repairing broken installs.
With some titles such as Metro Exodus there is
even more duplication across files. While this
change does not manage to reduce the limit to
below the default 1 GiB limit, it does bring
it down by about 512 MiB.
This is an optimization that aims to fix issues with some titles
such as World War Z that have lots of duplicated files resulting
in a very high runtime cache requirement.
The basic idea is to group files that share lots of chunks together
so the data can be removed from the cache sooner.
For most games this has little to no effect. For some titles with heavy
duplication it can reduce the RAM usage significantly however. For
instance the RAM requirements for World War Z are reduced from 5.3 GiB
to 499 MiB.
Partially fixes#17
Also adds tsv option for list-files and fixes
no_install not being set with --exclude.
Install tags are only present in some titles, I'm not
entirely sure how EGL uses them. Perhaps to allow one
manifest to be used on different platforms? Or to only
download extra assets when the user wants to?
Either way, it's another filtering feature that may be
useful, though for now it's mostly another toy to explore
EPIC's distribution system with.
Useful to exclude unnecessary files such as redistributables.
Can be used together with --prefix to exclude files that would
still match the specified --prefix.
This is a change to something that was so massively stupid and
overcomplicated that I feel like I need to explain and justify myself:
After figuring out the format for manifests and spending countless
hours staring at IDA/Ghidra I kinda was sick of that, so I decided to
figure out what to do with the manifest myself by playing around with
it, which was also a lot more fun than looking through disassembly.
When looking at the chunks and files it quickly became obvious that the
way they're created is by concatenating all files into 1 MiB chunks that
can be downloaded and reassmebled (mostly) sequentially. What I did not
know was how the order of files in this "stream" was determined.
In playing around with it I came up with the old method: essentially
forming a chain of files, because each file's end generally pointed to
the start of the next file. And it worked great! At least until now...
Yesterday somebody alerted me to a game where this failed and it took me
a bit to figure out. Essentially the chaining had failed because
multiple files started at the same offset, but some of them would follow
another chain that never went back to the chunk it started at,
effectively skipping those files. This was rather annoying to deal with,
I came up with a workaround but it wasn't pretty. So I decided to jump
back into IDA/Ghidra and find out how Epic does it for real.
Well it took me a while, but thanks to symbols (yay macOS!) and a decent
decompiler in Ghidra even a noob like me was able to find it eventually.
The answer is as simple as it can be: the files are sorted alphabetically
(case-insensitive).
So really all I ever had to do was to sort files alphabetically and then
run through them to create the list of tasks.
I feel so stupid.
P.S.: I tested a few games and for the most part the resulting file
processing order is identical between the old and the new method. The
cases where it differs is when there's heavy de-duplication happening
(e.g. Diabotical's small model files) but the runtime cache size remains
the same so both methods are equally efficient, the old one just can't
handle certain cases.
