The previous fix when the compiled bytecode wasn't accepted by the game
did work fine for Linux. But apparently on Windows, it procudes a stack
overflow when attempting to open a Lua state.
This reverts LuaJIT to a commit from 2019, which is quite old, but does
work. Further investigation is needed to determine if or how never
versions of LuaJIT could be used.
Fixes#110.
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.
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.
