HEMTT
0.6.2Schema URL
The hemtt.json or hemtt.toml file is used to configure your HEMTT Project. All examples are done using JSON, but both files support every feature of HEMTT. hemtt.toml will be used if both files are present.
Properties
Long name of your project.
Prefix used for CBA macros and the release directory name.
Author of the project.
HEMTT will look for addons/main/script_version.hpp and use it for the version number. If you are not using the CBA project structure or do not have that file you can add a version number in the HEMTT project file.
HEMTT will copy the files to the release directory after a successful release build. Supports glob patterns.
HEMTT will include matching relative or absolute paths when building.
HEMTT will exclude matching files when building.
HEMTT will build the specified addons from the ./optionals folder.
HEMTT will by default build optionals into their own mod folders, which can be directly launched by the user. This can be turned off to build optional PBOs directly into optionals folder.
HEMTT will skip building the specified addons.
HEMTT will apply specified header extensions to each PBO. Supports templating.
HEMTT will use the specified mod name (without @) to form @mod folder. Supports templating.
HEMTT will use the specified key name for .bikey and .biprivatekey names. Supports templating.
HEMTT will use the specified signature name as part of the full signature (.bisign) name. Supports templating.
HEMTT will use the specified signature version. Currently Supported: V2, V3 (Experimental).
If set to true, HEMTT will use (and reuse) releases/keys/{keyname}.biprivatekey. It will be generated if it doesn't exist. The default behaviour is to generate a new private key each time and discard it immediately. HEMTT strongly recommends that you only reuse the key if you are making a client-side mod where it will not matter if clients are running different versions of the mod.