v1.5

Dom Compiler

Run as a command line process. It will package all .dme files into a single .dm file, and copy all referenced artwork to the compiled mod.

This enables you to split your mod into several files, gaining a better overview of its' contents. You can also integrate it with Visual Studio Code or other text processors to enable you to quickly iterate and deploy without working on it inside the Dominions mod directory.

When compiling, it will automatically detect all art references made in the mod and copy them to the output directory.

Changes

Define and by characters

For commands specifying <path> or <path mask> a shorthand is now supported:

#magicskill F2G2 will give a mage 2 fire and 2 glamour magic.

#magicskill DDDD you can use numbers or repeat letters to define the magic. This gives a mage death 4.

#custommagic FW 100 will give the mage 100% chance to get either fire or water magic.

Shorthand letters for paths are as follows:

• F = Fire
• A = Air
• W = Water
• E = Earth
• N = Nature
• D = Death
• S = Astral
• G = Glamour
• B = Blood
• H = Holy (Priest levels)

Lowercase is also supported, left to your preference.

Better control for ordering of commands

Commands in a single file are now grouped and output in the order they're written in the file. You can now perform ordering-sensitive modding.

Getting started

This tool is executed from the command line, and is as such distributed bare-bones. Structuring the project and your developing environment is up to you. I've used Visual Studio Code for myself, which you can use as a base for your own mods. You can find this project here.

Quick start (Windows)

Download the sample 'SampleMod-VSCode', unzip and open in VSCode.

Contributing

For bugs, feature improvements, or other spicy opinions feel free to raise an issue here.

v1.4

Dom Compiler

Run as a command line process. It will package all .dme files into a single .dm file, and copy all referenced artwork to the compiled mod.

This enables you to split your mod into several files, gaining a better overview of its' contents. You can also integrate it with Visual Studio Code or other text processors to enable you to quickly iterate and deploy without working on it inside the Dominions mod directory.

When compiling, it will automatically detect all art references made in the mod and copy them to the output directory.

Changes

Will now detect commands such as req_targowner for relative ids

Getting started

This tool is executed from the command line, and is as such distributed bare-bones. Structuring the project and your developing environment is up to you. I've used Visual Studio Code for myself, which you can use as a base for your own mods. You can find this project here.

Quick start (Windows)

Download the sample 'SampleMod-VSCode', unzip and open in VSCode.

Contributing

For bugs, feature improvements, or other spicy opinions feel free to raise an issue here.

1.3

Dom Compiler

Run as a command line process. It will package all .dme files into a single .dm file, and copy all referenced artwork to the compiled mod.

This enables you to split your mod into several files, gaining a better overview of its' contents. You can also integrate it with Visual Studio Code or other text processors to enable you to quickly iterate and deploy without working on it inside the Dominions mod directory.

When compiling, it will automatically detect all art references made in the mod and copy them to the output directory.

Changes

Now built with a build tool!

Getting started

This tool is executed from the command line, and is as such distributed bare-bones. Structuring the project and your developing environment is up to you. I've used Visual Studio Code for myself, which you can use as a base for your own mods. You can find this project here.

Quick start (Windows)

Download the sample 'SampleMod-VSCode', unzip and open in VSCode.

Contributing

For bugs, feature improvements, or other spicy opinions feel free to raise an issue here.

1.2

Dom Compiler

Run as a command line process. It will package all .dme files into a single .dm file, and copy all referenced artwork to the compiled mod.

This enables you to split your mod into several files, gaining a better overview of its' contents. You can also integrate it with Visual Studio Code or other text processors to enable you to quickly iterate and deploy without working on it inside the Dominions mod directory.

When compiling, it will automatically detect all art references made in the mod and copy them to the output directory.

Changes

now detects relative id for the #transform command

Getting started

This tool is executed from the command line, and is as such distributed bare-bones. Structuring the project and your developing environment is up to you. I've used Visual Studio Code for myself, which you can use as a base for your own mods. You can find this project here.

Quick start (Windows)

Download the sample mod and open in Visual Studio Code.

Contributing

For bugs, feature improvements, or other spicy opinions feel free to raise an issue here.

1.1

Dom Compiler

Run as a command line process. It will package all .dme files into a single .dm file, and copy all referenced artwork to the compiled mod.

This enables you to split your mod into several files, gaining a better overview of its' contents. You can also integrate it with Visual Studio Code or other text processors to enable you to quickly iterate and deploy without working on it inside the Dominions mod directory.

When compiling, it will automatically detect all art references made in the mod and copy them to the output directory.

Changes

This version adds support for relative site index & enchantment numbers, allowing you to use the $ syntax when making global enchantments and when referencing site numbers. These are also added as new optional arguments to the command line --siindex | --start-site-index and --enindex | --start-enchnbr-index.

NOTE that these new arguments meant that some old arguments have changed:

• --eindex has become --ecindex
• --sindex has become --spindex

Getting started

This tool is executed from the command line, and is as such distributed bare-bones. Structuring the project and your developing environment is up to you. I've used Visual Studio Code for myself, which you can use as a base for your own mods. You can find this project here.

Quick start (Windows)

Download the sample mod and open in Visual Studio Code.

Contributing

For bugs, feature improvements, or other spicy opinions feel free to raise an issue here.

1.0

Dom Compiler

Run as a command line process. It will package all .dme files into a single .dm file, and copy all referenced artwork to the compiled mod.

This enables you to split your mod into several files, gaining a better overview of its' contents. You can also integrate it with Visual Studio Code or other text processors to enable you to quickly iterate and deploy without working on it inside the Dominions mod directory.

When compiling, it will automatically detect all art references made in the mod and copy them to the output directory.

Usage

DomCompiler arg0 [arg1] [--windex | --start-weapon-index] [--aindex | --start-armor-index] [--mindex | --start-monster-index] [--sindex | --start-spell-index] [--nindex | --start-nation-index] [--eindex | --start-eventcode-index]
Parses all .dme files in the working directory and outputs them to a single .dm file, copying all used art assets in the process.
arg0: path to the output file, as an absolute path or relative to arg1.
arg1 (optional): path to working directory. Will use the default working directory if unspecified.
--windex | --start-weapon-index (optional): start index to use for relative ids for weapons (1000-3999).
--aindex | --start-armor-index (optional): start index to use for relative ids for armors (300-999).
--mindex | --start-monster-index (optional): start index to use for relative ids for monsters (5000-8999).
--sindex | --start-spell-index (optional): start index to use for relative ids for spells (1300-3999).
--nindex | --start-nation-index (optional): start index to use for relative ids for spells (159-499).
--eindex | --start-eventcode-index (optional): start index to use for relative ids for spells (-300--5000).

Indices default to their minimum absolute value, so 1000 for weapons, -300 for event codes, etc. Setting an id close to it's maximum value is not recommended, as ids can then overflow outside the recommended range.

Example1 - Simple, Windows

./DomCompiler.exe %appdata%/Dominions6/mods/MyMod.dm

Example2 - Specific source directory & weapon index, Windows

./DomCompiler.exe %appdata%/Dominions6/mods/MyMod.dm C:/Users/Doe/Documents/MyMod --windex 1500

Other features

This compiler allows you to use local ids for weapons, armors, monsters, etc. so you can work with smaller, more graspable numbers for your entries. For instance a monster can defined as:
#newmonster $1
Instead of
#newmonster 5000
The compiler will then remap the '$1' to an index suitable for modded content. By default it will start at the minimum suggested from the modding manual, so for monsters $1 becomes 5000, $2 becomes 5001, etc.

This remapping can be configured by passing a specific index as an argument when compiling. With this you can define your own ranges of ids that your mod operates with. This is useful if you wish to ensure compatibility with other mods.

Getting started

This tool is executed from the command line, and is as such distributed bare-bones. Structuring the project and your developing environment is up to you. I've used Visual Studio Code for myself, which you can use as a base for your own mods. You can find this project here.

Limitations

The ordering of mod command blocks are currently fixed, which may produced some unintended effects compared from standard Dominions modding. This can cause some unintended effects when copying spells, monsters, etc. Consider the below example found in example project:

#newspell -- Cheaper Terracotta Army
#copyspell 1149
#fatiguecost 700
#restricted 151
#end

#selectspell 1149 -- Generic Terracotta Army
#notfornation 151
#end

Here the intent is to provide a cheaper "Terracotta Army" for the mod nation. When parsed in this order it works as intended. But if it looked like this in the output mod:

#selectspell 1149 -- Generic Terracotta Army
#notfornation 151
#end

#newspell -- Cheaper Terracotta Army
#copyspell 1149
#fatiguecost 700
#restricted 151
#end

Then the #notfornation command would apply to the new spell we designed for our nation, rendering both disabled for it. To minimize issues, the compiler will always order #new entries before #select entries. If your mod heavily relies on the order of #new & #select entries, it may not generate the output you expect.

Contributing

For bugs, feature improvements, or other spicy opinions feel free to raise an issue here.

Alpha

Dom Compiler

Run as a command line process. It will package all .dme files into a single .dm file, and copy all referenced artwork to the compiled mod.

Arguments

arg0: path to the output file (.../mod.dm). If relative path wil be relative to path in arg1.
arg1: path to source directory to build from

Optional Arguments

TODO

Other features

Can use relative ids within the dme files, these will then be mapped to absolute ids. In later versions this allows you to remap the id range for your mod to ensure compatability with other mods. For instance
#newmonster $1
could be mapped to
#newmonster 5050

The $[int] is context sensitive. It uses different ranges for monster, spells, eventcodes, etc. as suggested by the mod manual.