Skip to main content

Update Your Manifest

Overview​

Your manifest (manifest.json) provides important metadata to Blish HUD prior to your module loading. The manifest specification is kept in our manifest.json repository and is subject to revisions in the future.

Manifest Format (v1)​

An example manifest.json with all attributes filled can be found here.

Required Attributes​

Name​

The display name of the package.

{
    "name": "Marker Deleter"
}

Version​

The version of the package. Should be Semanticly Versioned. Other packages can require your package as a dependency using version ranges (similar to npm).

{
    "version": "1.2.3"
}

Namespace​

This is the primary identifier - it is a unique name for the package. Do not change this value once your package has been published. It is used internally within Blish HUD for Settings and more. Modules should not be within the bh namespace unless they have been contributed and approved to the base community packages. The manifest.json namespace and the C# namespace you use in your .cs files are unrelated. They can be the same but do not have to be. 

{
    "namespace": "jdoe.mypackages.markerdeleter"
}
info

When choosing your namespace, it is important to keep it unique from other module developers. A good namespace will be prefixed with your own unique handle, for example, acme.supermodule and acme.awesomemodule - both of which start with acme. You may wish to use your online handle.

In any case, it is expected that the namespace will be prefixed with something.

Package​

The name of your compiled module with ".dll" at the end.

{
    "package": "Marker Deleter.dll"
}
info

If you experience issues getting the package value correct, you can open your bhm with an application such as 7-Zip to ensure that the DLL within it matches the package attribute you've specified.

Manifest Version​

The version of manifest used. This is currently 1.

{
    "manifest_version": 1
}

Contributors​

The author of the module, along with any contributors. At least one contributor must be listed. The name is required for each contributor. The username and url fields are both optional.

{
    "contributors": [
        {
            "name":     "Freesnöw",
            "username": "LandersXanders.1235",
            "url":      "https://github.com/dlamkins"
        },
        {
            "name":     "jdoe",
            "username": "jdoe.1234"
        }
    ]
}

Description​

A description of the module.

{
    "description": "This module allows you to select any marker and delete it."
}

Dependencies​

The dependencies required for your module. Our implementation is similar to npm. We use semver.net to verify dependency versions.

A dependency on bh.blishhud indicates the versions of Blish HUD the module supports.

{
    "dependencies": {
        "bh.blishhud" : "~0.7.1",
        "example.module.namespace" : "~1.2.3",
    }
}
info

It is important to specify an accurate bh.blishhud dependency with version range to ensure that the proper versions of your module are displayed to users when using the repository.

URL​

A url that can be used to link to the project or a link to more details instructions.

{
    "url": "https://github.com/yourname/yourmodule/README.md"
}

This value is currently not used.

Optional Attributes​

Directories​

A list of directory names that are used by the module. These directories will be registered by the FileService and a button to open the directory directly will be shown in the module settings. Do not include subfolders (e.g. "markers/data") in your manifest - they are not supported in the manifest and your module must manage those directly.

{
    "directories": ["markers"]
}

Enabled Without GW2​

Allows the module to continue to run when GW2 is not running and Blish HUD is still running in the tray. Do not set to true unless your module requires this. Modules that enable this will be treated with more scrutiny. 

{
    "enabled_without_gw2": false
}

API Permissions​

Gives the module permission to access the specified API permissions. A permission can be marked as optional if the functionality of the module does not rely on the permission (the module must check for this). A description can also be provided to provide justification to the end user as to why the permission is needed.

If no API permissions are needed, do not include api_permissions at all.

{
    "api_permissions": {
        "account"     : { "optional": true,  "details": "Needed if you want the special feature enabled." },
        "inventories" : { "optional": false, "details": "Needed to review the item in your inventory." }
    }
}