Overview
The plugin manifest is a JSON file that describes your plugin’s metadata, dependencies, and configuration. It’s used by:- The plugin installer to display information
- Dalamud to determine compatibility and load order
- The repository system to distribute updates
MyPlugin.json), and DalamudPackager automatically generates the full manifest during build.
Minimal Manifest
For development, create a JSON file with your plugin’s name:MyPlugin.json
The
InternalName must match your assembly name and should never change once published.Full Manifest Fields
Here are all available fields fromIPluginManifest (Dalamud/Plugin/Internal/Types/Manifest/IPluginManifest.cs:8-127):
Required Fields
The internal identifier for your plugin. Must match the assembly name and remain consistent across versions.
The display name shown in the plugin installer.
The plugin author’s name or list of authors.
Description Fields
A short, one-line description of your plugin’s main purpose. Displayed prominently in the installer.
A longer, detailed description of your plugin’s functionality and features.
What’s new in this version. Shown when the plugin is updated.
Categorization
List of tags for search and filtering in the plugin installer.
Category tags defined on the plugin (used internally by the plugin repository).
Versioning
The version of your plugin. Automatically set by DalamudPackager from your assembly version.Set in your
.csproj:Version of the testing variant of your plugin. Users can opt into testing versions.
The Dalamud API level your plugin targets. This ensures compatibility.Current API level:
10 (see PluginManifest.cs:85)The API level for the testing variant of your plugin.
Minimum Dalamud version required by your plugin.
URLs and Media
URL to your plugin’s source code repository or website.
URL to an icon image for your plugin (shown in the installer).
List of screenshot URLs to display in the plugin installer.
Behavioral Flags
Whether your plugin can be safely unloaded outside the framework thread.Set to See PluginManifest.cs:141
true if your plugin doesn’t interact with the game client directly.Whether your plugin supports Dalamud’s profile system.See PluginManifest.cs:145
Whether this plugin is only available for testing (not for general release).
Load Configuration
The required Dalamud load step for this plugin. Controls when your plugin loads.Values (see PluginManifest.cs:118-125):
0: During Framework.Tick when drawing facilities are available1: During Framework.Tick2: No requirement (default)
Whether Dalamud must load this plugin synchronously, not at the same time as other plugins.Set to See PluginManifest.cs:130
true if your plugin has strict initialization requirements.Load priority for this plugin. Higher values mean higher priority.See PluginManifest.cs:137
Feedback and Distribution
Message shown to users when they submit feedback about your plugin.
Whether your plugin accepts user feedback through Dalamud.See PluginManifest.cs:156
Statistics (Read-Only)
These fields are populated by the plugin repository and are read-only:Total number of downloads for your plugin.See PluginManifest.cs:93
Unix timestamp of the last update.See PluginManifest.cs:97
Advanced Fields
DIP17 channel name for alternative distribution channels.See PluginManifest.cs:163
Game version this plugin is compatible with. Managed by the repository.See PluginManifest.cs:77
Download URL for initial installation (managed by repository).See PluginManifest.cs:103
Download URL for updates (managed by repository).See PluginManifest.cs:109
Download URL for testing versions (managed by repository).See PluginManifest.cs:115
Whether the plugin is hidden in the installer (managed by repository).See PluginManifest.cs:50
Example: Complete Manifest
Here’s a comprehensive example:MyPlugin.json
DalamudPackager Integration
DalamudPackager reads your manifest and.csproj to generate the final manifest:
.csproj
Testing Variants
You can offer a testing version with newer features:- Set
TestingAssemblyVersionhigher thanAssemblyVersion - Set
TestingDalamudApiLevel(if needed) - Users can opt into testing in plugin settings
Best Practices
Semantic Versioning
Use semantic versioning: MAJOR.MINOR.PATCH
- MAJOR: Breaking changes
- MINOR: New features
- PATCH: Bug fixes
Detailed Descriptions
Write clear, detailed descriptions and changelogs. Users need to understand what your plugin does.
Consistent InternalName
Never change
InternalName after release. It’s used to track updates and user installations.Tag Appropriately
Use relevant tags to help users find your plugin. Check existing plugins for common tags.
Next Steps
Plugin Interface
Learn about the plugin interface and available services