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.
DML's package needs to be added to the boot bundle as well. Current
issue: Adding any package file to the bundle breaks the game's loading.
But I don't know where this messes things up.
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.
There are a bunch of optional commands provided by druid that trigger
this, but we only really need it to check for custom ones that weren't
implemented, yet.
Ditch the `.mod` file and move its data into the config file.
The `run` function was the only thing that could have been dynamic, but
the vast majority of mods in VT2 never made use of that. Infact, VMF was
probably the only mod that had a different content for that.
This removes the LuaJIT binary as a runtime dependency and decreases
the complexity of the compilation, by not needing to juggle a bunch of
temp files anymore.
However, it was a bit of a pain to get everything set up in the end.
Closes#4.
The file header format is a bit more complex than I first realized,
especially around when a path to `data/` is included, and which size
field determines its file name length.
This type is similar to an `Either` between a `Murmur64` hash and a
`String`. This is necessary to be able to retain hash information where
the hash is not in the dictionary, but at the same time allow string
names where they are available.
Up until now, when reading a bundle, all hashes would be converted to
strings, which made sense for displaying those names. But when writing
the same bundle back, those strings ended up being re-hashed, resulting
in incorrect hashes.
This is mostly helpful to check/debug whether the internal dictionary
actually contains the expected data. For manually looking through the
entire dictionary, opening the CSV file is still more convenient.
The compiler doesn't complain about this, so I assumed it
was able to correctly resolve a conversion
`BundleFileType` -> `Murmur64` via their shared `From` impl: `u64`.
But it appears that is not the case, and the simple `t.into()` just
calls itself. So I need to do the conversion via the intermediary value
manually.
