ae777000e2
The goal of this change is to let plugins register their own self-tests. We do this through the `ISelfTestRegistry` interface. For a plugin it would look like this: ```csharp [PluginService] public ISelfTestRegistry SelfTestRegistry // Somewhere that gets called by your plugin SelfTestRegistry.RegisterTestSteps([ new MySelfTestStep(), new MyOtherSelfTestStep() ]) ``` Where `MySelfTest` and `MyOtherSelfTest` are instances of the existing `ISelfTestStep` interface. The biggest changes are to `SelfTestWindow` and the introduction of `SelfTestWithResults`. I wanted to make sure test state wasn't lost when changing the dropdown state and I was finding it a bit annoying to work with the Dictionary now that we can't just rely on the index of the item. To fix this I moved all the "test run" state into `SelfTestWithResults`, most of the changes to `SelfTestWindow` are derived from that, other then the addition of the combo box. The documentation for this service is a bit sparse, but I wanted to put it up for review first before I invest a bunch of time making nice documentation. I'm keen to hear if we think this is useful or if any changes are needed. |
||
|---|---|---|
| .github | ||
| .nuke | ||
| build | ||
| Dalamud | ||
| Dalamud.Boot | ||
| Dalamud.Common | ||
| Dalamud.CorePlugin | ||
| Dalamud.Injector | ||
| Dalamud.Injector.Boot | ||
| Dalamud.Test | ||
| DalamudCrashHandler | ||
| docs | ||
| external | ||
| imgui | ||
| lib | ||
| targets | ||
| tools | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| build.cmd | ||
| build.ps1 | ||
| build.sh | ||
| CreateHashList.ps1 | ||
| Dalamud.sln | ||
| Dalamud.sln.DotSettings | ||
| Directory.Build.props | ||
| docfx.json | ||
| filter_imgui_bindings.ps1 | ||
| filterConfig.yml | ||
| generate_imgui_bindings.ps1 | ||
| global.json | ||
| index.md | ||
| LICENSE | ||
| README.md | ||
| release.ps1 | ||
| sign.ps1 | ||
| stylecop.json | ||
Dalamud 
Dalamud is a plugin development framework for FFXIV that provides access to game data and native interoperability with the game itself to add functionality and quality-of-life.
It is meant to be used in conjunction with XIVLauncher, which manages and launches Dalamud for you. It is generally not recommended for end users to try to run Dalamud manually as XIVLauncher manages multiple required dependencies.
Hold Up!
If you are just trying to use Dalamud, you don't need to do anything on this page - please download XIVLauncher from its official page and follow the setup instructions.
Building and testing locally
Please check the docs page on building Dalamud for more information and required dependencies.
Plugin development
Dalamud features a growing API for in-game plugin development with game data and chat access and overlays. Please see our Developer FAQ and the API documentation for more details.
If you need any support regarding the API or usage of Dalamud, please join our discord server.
Thanks to Mino, whose work has made this possible!
Components & Pipeline
These components are used in order to load Dalamud into a target process. Dalamud can be loaded via DLL injection, or by rewriting a process' entrypoint.
| Name | Purpose |
|---|---|
| Dalamud.Injector.Boot (C++) | Loads the .NET Core runtime into a process via hostfxr and kicks off Dalamud.Injector |
| Dalamud.Injector (C#) | Performs DLL injection on the target process |
| Dalamud.Boot (C++) | Loads the .NET Core runtime into the active process and kicks off Dalamud, or rewrites a target process' entrypoint to do so |
| Dalamud (C#) | Core API, game bindings, plugin framework |
| Dalamud.CorePlugin (C#) | Testbed plugin that can access Dalamud internals, to prototype new Dalamud features |