I ended up wrapping the raw data in a `BundleFile` twice.
I also made '--compile' the default, as it should be much less often
that raw data needs to be inserted. Even files that are essentially raw
binary blobs, like `.wwise_event`, still have some custom fields that
need to be accounted for.
The second compression method found in the game's code seems to be Zlib,
but it doesn't seem to be used in the game files. What does get used is
a compression type of `0`, which appears to be uncompressed data.
For DDS formats, all the ones that are currently used by in the game
files can be emitted as is. Though for some of them, other tools might
not be able to display them.
Decompiling the game binary shows a rather elaborate algorithm to load
DDS images from binary. Though comparing it to Microsoft's documentation
on DDS, most of it seems to be pretty standard handling.
However, we don't actually need all of it. The part about calculating
pitch and reading blocks only accesses a subset of the `ImageFormat`
struct, so we can strip our implementation to just that.
Fatshark has a few weird string fields, where they provide a length
field, but then sometimes write a shorter, NUL-terminated string into
that same field and adding padding up to the "advertised" length.
To properly read those strings, we can't rely on just the length field
anymore, but need to check for a NUL, too.
lint/clippy Checking for common mistakes and opportunities for code improvement
build/msvc Build for the target platform: msvc
build/linux Build for the target platform: linux
For most of the game files, we don't know the actual name, only the hash
of that name. To still allow building bundles that contain files with
that name (e.g. to override a game file with a custom one), there needs
to be a way to tell DTMT to name a file such that its hash is the same
as the one in the game.
The initial idea was to just expect the file name on disk to be the
hash, but that wouldn't allow for arbitrary folder structures anymore.
So instead, there is now a new, optional setting in `dtmt.cfg`, where
the modder can map a file path to an override name.
This re-enables stdout/stderr logging for release binaries for DTMM.
As a GUI application, it usually won't be started from a CLI, and there
should be no negative impact from that.
But since stdout logging is synchronous and much faster than the async
action that writes to the log file, it might get to log more when the
application panics.
Two different functions were each reading the bundle database
from the backup, so their changes would overwrite each other.
Additionally, mod bundles were missing from the database.
Ref: #28.
After digging through the VT2 SDK `.exe`, I found that `.package` files
(`stingray::ResourcePackageResource`) actually have more data than I
originally knew about. Most notably, there is a 1 byte `flags` value
that is written at the end of every package file.
Depending on what value those flags have, more data could come after it,
but in most cases, it's just that one byte, which I must have missed in
the binary.
Ref: #28.
Ref: #36.
With splitting DMF and DML, there is now more than one case where this
is needed, so it may well be made proper now.
The template still defines them, and, as with VT2 most creators will
probably stick with it, but they do have the option to make a non-DMF
mod now.
