This project currently depends on the Rust nightly toolchain. The preferred way to install a nightly toolchain is via rustup:
> $ rustup toolchain install nightlyCurrently me3 can be tested by running its test of unit suites, or by injecting me3-mod-host into a game and performing live debugging. Instructions are listed below for both.
Unit tests for the entire project can be ran with cargo, optionally specifying a package.
> $ cargo test [--package me3-mod-host]me3 comes with a Visual Studio Code workspace that contains a debugger launch configuration using LLDB and CodeLLDB. It will automatically start Dark Souls 3, inject me3_host, and attach the debugger.
Unfortunately LLDB cannot be used out of the box to debug Dark Souls 3 as it interferes with anti-debug routines. To work around this a patched LLDB is used that handles all exceptions as second-chance exceptions.
You will also need to tell vscode where to find your copy of the game by creating a workspace settings file.
See .vscode/settings.json.example for how to do this.
Every first launch in a vscode session may result in an error about missing Rust/Cargo tasks, if this happens you may ignore it and build me3 manually or install the rust-analyzer plugin and open a .rs file to initialize the extension.
This project uses rustfmt to handle formatting, and
contributions to its code are expected to be formatted with rustfmt (within reason) using the
settings in rustfmt.toml.
This project uses rust-clippy to handle linting, and contributions are expected to be checked using the settings in clippy.toml.
Note:
rustfmtandrust-clippyeach have many built-in defaults that will be deferred to in the absence of a corresponding rule inrustfmt.toml/clippy.toml.
Code contributed to this project should follow the Rust API Guidelines as much as possible (even if this project is an application instead of a library).