Foundation Book XIV: The Command and Terminology Lexicon#

Official syntax, context, provenance, and search discipline#

The job of this volume#

Dominions modding is written in a compact language whose commands often look self-explanatory. That appearance is deceptive. A token can be correctly spelled and still be unusable because it appears outside the right object block, follows the wrong selector, carries the wrong argument form, relies on an undocumented expansion, or belongs to a newer executable than the manual that a project was built against. A patch announcement can prove that a command existed or changed without explaining its complete syntax. A current manual can list a token without describing its behaviour. Several different object types can even use the same command spelling for different fields.

This volume supplies the retrieval layer needed to navigate that language. Its canonical subjects are:

• official command spellings and syntax locators;
• object context and command-domain classification;
• current-manual, reference-list, mention-only, template, and patch provenance;
• controlled reconciliation of patch-note shorthand and spelling discrepancies;
• safe lookup, testing, versioning, and maintenance procedures;
• a complete searchable locator for the current official manuals;
• a website-ready command register with stable records and aliases.

Book VIII remains the canonical explanation of parser state, object design, events, maps, AI scaffolding, compatibility, and testing. Book XIII remains the canonical release chronology. Book XIV does not repeat either volume. It answers a narrower question: what exactly is this token, where is it officially located, what kind of evidence supports it, and which chapter owns the surrounding design problem?

The result serves two audiences at once. A new modder can identify the right manual and avoid common syntax traps. An experienced maintainer can search by command, domain, version, patch record, template expansion, documentation status, or canonical destination without manually combing through several PDFs.

Technical baseline#

The ruleset baseline is unmodded Dominions 6.37. The currently published official documents carry different internal versions, while the compiled locator retains its separately labelled extraction revision:

This version difference matters. “Current download,” “locator snapshot,” and “same version as the executable” are not synonyms. The live Modding Manual is one release behind the game baseline, while the complete token locator is still pinned to its 6.34 extraction; the Event and Map Making manuals remain older separately versioned sources. Nothing in that observation makes the documents unreliable. It means their claims must be labelled precisely and supplemented by later official patch evidence where necessary.

The compiled register contains 1,609 distinct official hash tokens found across the three-manual locator snapshot. Of these, 1,540 have an official definition or syntax line, 60 occur only in an official reference list or example-style block, and nine are mentioned without a complete definition line. The total also includes 29 double-hash message substitutions and thirteen documented command templates. Template expansion creates 97 additional lookup aliases without pretending that those aliases were separately printed as definitions. Book XIII names 226 patch-note tokens through 6.37: 221 are reconciled in the locator snapshot, while the five event commands introduced by 6.36 remain official patch-only records pending a full current-manual locator rebuild. Version 6.37 introduced no additional hash commands.

Evidence key#

The following labels appear throughout the volume and its data register.

The evidence label answers how the token is known. It does not say that the token is strategically wise, compatible with every other mod, or safe to add to an ongoing game.

Part I: Reading the Modding Language#

A command is an instruction inside a stateful document#

Every ordinary Dominions mod command begins with a single hash sign. The parser does not read each line as an isolated request. A selector or creation command establishes the current object, following commands alter that object, and #end closes the block where the language requires it. The same spelling can therefore mean different things under different selectors.

Consider #name. The token is defined for weapons, armour, monsters, blessings, sites, nations, spells, magic items, and mercenaries. A search result that merely says “#name exists” is almost useless. The operative questions are which object is active, which syntax variant is printed for that object, which parser phase handles it, and which closing rule applies. The register therefore stores every official definition context instead of collapsing all occurrences into a single undifferentiated sentence.

Book VIII, Part I owns the full parser model. The compact rule for lookup is simpler:

Command spelling identifies a language feature; the active object block determines what that feature addresses.

Command, argument, value, and block#

A command is the hash-prefixed keyword. An argument is information supplied after that keyword. A value is the concrete number, string, name, filename, or mask substituted for the argument notation. A block is the span between an object selector or creator and its terminating #end, where one is required.

The manual notation is descriptive rather than literal:

Angle brackets are not normally typed. A line such as #gcost <gold> means that <gold> is replaced by an integer. Square brackets in the printed syntax mark an optional component; they are not usually literal punctuation either. Quotation marks are different: when the manual prints a string in quotes, the quotes are part of the practical syntax.

Comments and explanatory text#

Two consecutive hyphens begin a comment. The parser ignores the remainder of that line. Comments are not decoration in a serious project. They preserve intent, source version, ownership, compatibility decisions, reserved identifiers, and reasons for non-obvious values.

A useful comment records something that cannot be recovered by reading the command alone:

-- Reserved unit range 9100-9149; do not allocate automatically.
-- Vanilla 6.37; syntax located in the 6.34 command-locator snapshot, p. 13.
#newmonster 9100

Comments that merely repeat a token add little. “Set the name” above #name will not help a later maintainer understand why an identifier is fixed, why a copied field is retained, or which combined-mod collision was avoided.

The four principal argument classes#

The Modding Manual identifies integer, percentage, string, and bitmask arguments. Their failure modes differ.

An integer is a whole number. It may be a quantity, identifier, level, code, index, flag value, or enumerated choice. Treating every integer as a quantity causes subtle errors: a path number is not a path level, a monster number is not a count, and an effect number is not a magnitude.

A percentage is also written as an integer. The command defines how that integer is interpreted. Some percentages accept values above 100; others describe chances bounded by a conventional range; still others act as modifiers rather than probabilities. The argument label is therefore not a universal validation rule.

A string is text. Names and filenames are strings, but they carry different operational constraints. Object names can create ambiguous references when several objects share a name. Filenames are case-sensitive and must obey lobby-safe naming rules. Quotation marks protect spaces in string values; they do not remove filename restrictions.

A bitmask represents a set as a sum of powers of two. Bitmask errors are rarely obvious to the eye because an incorrect sum is still a valid integer. A proper record keeps both the decimal total and its component flags. When a terrain mask, path mask, damage mask, or event mask changes, the components should be recalculated rather than adjusted by guesswork.

Names and numbers are different forms of reference#

Many selectors accept either an object name or number. Names are readable but can be ambiguous, can change between versions, and cannot reliably cross every mod boundary. Numbers are precise but can collide, can be allocated differently when content order changes, and are difficult to understand without a registry.

The safest choice depends on the project:

• a small private balance patch may prefer names for untouched vanilla objects;
• a distributable content mod benefits from fixed IDs and a published allocation register;
• a compatibility patch needs explicit knowledge of both source projects’ identities;
• an ongoing-game update must preserve the identifiers already embedded in the save;
• a cross-mod reference should never assume that a name provides a stable linking contract.

Book VIII owns allocation and collision engineering. Book XIV records whether syntax allows a name, a number, or either form.

Binary commands and clearing state#

A command printed without an argument commonly enables a fixed attribute. Its absence does not necessarily mean “false” after an object has been copied. A copied object may already carry the field, and a clearing command may be needed to remove inherited state.

This is why #copy..., #clear, specialised clearing commands, and zero-valued arguments cannot be treated as interchangeable. Their behaviour depends on the object language. Copy-first and clear-first create different starting states. The lexicon locates the commands; Book VIII, Section “Copy-first and clear-first are different designs” owns the design consequences.

Optional arguments are branches, not decorative hints#

Square-bracket arguments represent alternative valid forms. The short form and long form may not be semantically identical. Optional identifiers can affect automatic allocation. Optional names can change display behaviour. Optional values can select defaults that later game versions revise.

For maintainable source, the chosen form should be deliberate and documented. Omitting an argument because the notation looked complicated is not the same as selecting the default knowingly.

The vertical bar means exclusive alternatives#

The manual uses a vertical bar to mean “or”. In syntax such as:

#selectweapon "<weapon name>" | <weapon nbr>

the selector takes a name or a number. The entire expression is not typed. Mixing both forms can produce a parse error or leave unexpected trailing input. Website presentation must escape the bar inside Markdown tables so it is not mistaken for a column boundary.

Templates describe a grammar#

Thirteen official entries are templates rather than literal commands. Four substitute terrain words, while nine describe numeric ranges. #(terrain)fortrec is not a line to paste into a mod. It is a compact grammar covering forms such as #forestfortrec, #plainfortrec, and #dripfortrec, subject to the terrain restrictions printed beside the template.

The same principle governs #hero1...10, #multihero1...7, #battlesum1...5, and similar families. The ellipsis describes a range. It is not part of a literal command. Search systems should resolve a concrete family member back to the template without rewriting the official definition.

Template generation carries two risks. First, not every visually plausible substitution is legal. Sea, deep-sea, and kelp recruitment use special rules in the fort variants. Second, family notation in a patch announcement can be looser than the formal template in a manual. Controlled alias records solve the retrieval problem while retaining those qualifications.

Double-hash substitutions are not commands#

Event and global-enchantment messages support substitutions such as ##landname##, ##godname##, and ##targname##. These tokens are interpreted inside supported text. A single-hash command controls the event or object; a double-hash substitution changes the message produced by that object.

Capitalisation can be meaningful. The official reference includes both lower-case and capitalised pronoun forms. The lexicon therefore preserves exact case for double-hash tokens even though ordinary command lookup is normalised for search.

Part II: Context Is Part of Syntax#

The same spelling can serve several object languages#

The register identifies 107 tokens whose official definition contexts span more than one command domain. Familiar examples include #name, #descr, #clear, #end, #att, #def, #range, #sound, #sample, #homerealm, and #magic.

This is not accidental duplication. Dominions exposes related fields through separate object parsers. A command can therefore be legitimate in several places while accepting different arguments or changing different records. A flat alphabetical glossary that retains only one definition will inevitably mislead readers.

Every context-sensitive record in the data layer retains:

• each official manual;
• the manual’s internal version;
• the printed page;
• section and subsection;
• evidence strength;
• the syntax line where one is present;
• a domain-specific canonical destination.

Selection establishes the target#

Selectors such as #selectweapon, #selectarmor, #selectmonster, #selectnation, #selectspell, and their counterparts establish which object receives subsequent changes. Creation commands such as #newweapon, #newmonster, and #newspell create a target and then open its modification context.

The selector line is part of the meaning of every command beneath it. Removing a selector while copying a snippet can redirect valid commands into the preceding object. This failure can survive superficial review because each individual line is spelled correctly.

#end closes a context, not a universal transaction#

#end appears throughout the manuals. Its practical role is determined by the active parser. A missing #end can cause later commands to be swallowed by the wrong block; an extra one can close a block early. Source formatting should make block boundaries visually obvious even though indentation itself is not the primary parser rule.

A robust block convention uses:

• one blank line before a selector or creator;
• a comment naming the object’s stable ID and purpose;
• consistent indentation for commands inside the block;
• an explicit #end aligned with the opening selector;
• a validation check that counts and pairs block openings with endings where the language permits that static test.

Load order changes what context can see#

Dominions parses object categories in a documented order and loads each mod as a whole. A reference that appears later in the file can still work when its object category is parsed earlier, while a reference into a different enabled mod may fail even when the other file appears above it in a user’s preference screen.

The command lexicon does not attempt to encode every cross-object dependency. It supplies domain and manual context. Book VIII, Part I owns parser order; Book VIII, Part XI owns compatibility engineering.

A syntax locator is not a compatibility promise#

An officially defined command can still be unsafe in a particular project. Common causes include:

• both mods selecting and altering the same vanilla object;
• automatic IDs shifting after new content is inserted;
• a copied object inheriting fields that a later version added;
• event codes colliding between unrelated projects;
• a template alias being legal only for some terrain variants;
• a command added after the minimum game version declared by the mod;
• a mid-game change altering the meaning of identities already stored in the save.

The presence of a command in this lexicon establishes retrievability, not project compatibility.

Part III: The Evidence Ladder and Version Drift#

Official definition#

A defined token has a bold syntax or definition line in one of the current official manuals. This is the strongest documentation state in the register. It establishes the printed spelling, argument form, page, and object context. It may also supply constraints in the surrounding manual prose that the website register deliberately does not reproduce.

The register is a locator, not a replacement copy of the manuals. After a command is found, the cited page remains the authoritative place to read its complete official explanation.

Official reference-only entry#

Sixty tokens occur only in an official list or example-style block. Several monster abilities fall into this category, including commands gathered in the Modding Manual’s compact monster-command pages. Other entries are message substitutions printed as reference tables.

Reference-only does not mean unofficial. It means the official document supports the spelling or existence without supplying a full definition line. Behavioural summaries should not be invented to fill that gap. A verified mod example or controlled runtime test can add evidence later, but it must remain labelled separately from the manual.

Official mention-only entry#

Nine tokens have only prose mentions in the current documents: #afflictions, #airattuned, #coldrec, #dom6title, #fireattuned, #forestrec, #heatrec, #multihero1, and #nogeosrc.

Some are understandable through a nearby template or surrounding discussion. Others expose a documentation gap. Mention-only status prevents an incidental sentence from being promoted into a complete syntax contract.

Official patch evidence#

Patch announcements answer historical questions: when a token was added, corrected, expanded, deprecated, or discussed. They rarely define the entire command. Book XIII preserves the complete announcement chronology and record identity. Book XIV links each extracted token to that chronology and then asks whether current manual documentation matches it.

Of the 221 patch-note tokens:

• 196 match current official definitions exactly;
• two match current official reference-only entries;
• sixteen resolve through official templates;
• three require controlled spelling reconciliation;
• three are family shorthand rather than literal commands;
• one is a double-hash message placeholder rather than a command.

This distribution is the clearest reason not to publish a raw patch-token list as a command manual.

Patch wording can be historically exact and operationally incomplete#

The official announcement is preserved as the historical source even when a later manual clarifies a different spelling. The patch ledger should not be rewritten to make the historical text look cleaner. The command lexicon instead creates a reconciliation record containing the patch token, present locator, resolution status, note, version, record ID, and source locator.

That separation protects both forms of truth:

• Book XIII answers what the announcement said;
• Book XIV answers how that expression relates to the current official documentation.

Three controlled spelling discrepancies#

#addseduction and #addseductions#

The 6.12 announcement says #addseduction. The Event Modding Manual 6.29 defines #addseductions <value>. The lexicon preserves the singular patch token and resolves it to the plural manual command. No claim is made that both spellings are accepted by the executable.

#illusionimmune and #illusionsimmune#

The 6.08 announcement says #illusionimmune. The Modding Manual 6.34 defines #illusionsimmune. The plural form receives the manual locator; the singular form remains a historical alias marked as a mismatch.

#res_mnrbs and #req_mnrbs#

The 6.34 announcement says #res_mnrbs. The Event Modding Manual 6.29 defines #req_mnrbs. Since the manual predates the announcement, the difference could represent a patch-note typo, a renamed command, or an undocumented second form. Official text alone does not determine which spellings the 6.35 executable accepts. The controlled mapping supports retrieval, while runtime acceptance remains a separate question.

Three family expressions#

The extracted token #not comes from the announcement expression #not(dis)mounted. It resolves to #notmounted and #notdismounted; there is no literal #not command claim.

The extracted token #force comes from #force...vis. It resolves to the documented forced-gem event-effect family: #force1d3vis, #force1d6vis, #force2d4vis, #force2d6vis, #force3d6vis, and #force4d6vis.

The expression #battlesum1dX uses a capital X as a family placeholder. The current manual defines #battlesum1d2 and #battlesum1d3. The lexicon links the patch expression to both.

The patch placeholder ##varXXX#

The 6.16 announcement describes ##varXXX## for printing event variables in messages. The patch importer captured the inner #varXXX token because it was designed to find hash expressions. Book XIV corrects the classification, not the historical record: this is a double-hash message pattern, not a command line.

Part IV: Command Domains#

Why domains matter#

Alphabetical search is good for a known spelling. Domain search is better when the desired operation is known but the command name is not. The register assigns each occurrence to an object language using its official manual, page, section, and subsection. A token can belong to more than one domain.

Counts overlap where a token has several contexts. They measure retrievable language surface, not relative strategic importance.

Mod metadata and sound#

Metadata commands make a mod identifiable to the game and to players. A stable display name, meaningful version, clear description, and suitable icon are part of release engineering. #domversion deserves particular attention because it communicates a minimum executable version; leaving it absent does not make newer commands compatible with older builds.

Sound commands form a compact object language with selectors, import paths, sample modes, and looping rules. Filename and network-lobby constraints apply just as strongly to audio assets as to sprites and map files.

Weapons and armour#

Weapon syntax separates base damage, number of attacks, attack and defence modifiers, length, range, ammunition, damage type, resistance interactions, targeting qualifiers, secondary effects, and post-hit effects. Similar-looking commands can belong to spell or item contexts as well, so the domain locator should be checked before reusing a line.

Armour commands are fewer but strongly coupled: protection, defence, encumbrance, resource cost, armour type, and material interact with unit statistics and damage resolution. The lexicon identifies syntax; Book IV owns combat interpretation and Book VIII owns object construction.

Monsters, commanders, mounts, and forms#

Monster modding is the largest language surface in the general manual. It includes statistics, costs, recruitment rules, body types, slots, creature status, movement, stealth, healing, reduction, immortality, auras, seasonal powers, combat abilities, non-combat abilities, shape changes, summons, mounts, leadership, paths, research, gem production, and special magic.

The compact monster-command reference also contains dozens of reference-only tokens. Their presence is official, but complete semantics cannot be inferred from the spelling alone. A command named like a familiar in-game ability may expose only part of that ability or accept values whose interpretation is not shown in the list.

Names and blessings#

Name-table modding is small but identity-sensitive. Clearing a name table and adding names changes a shared resource, not merely one unit’s display label.

Bless modding uses familiar generic tokens such as #name within a specialised block. Its scale and path requirements are access rules, while effect commands alter sacred units. Strategic blessing design remains in Book III; the lexicon supplies only the language locator.

Sites and nations#

Sites can grant income, recruitment, scales, ritual access, scrying, special effects, and throne powers. Nation blocks then assemble recruitment, province defence, gods, infrastructure, dominion, reanimation, and AI hints into a playable state.

Terrain recruitment is the main template-heavy area. Literal forms such as #forestrec and #dripfortcom resolve to (terrain) definitions. Fort and non-fort variants are distinct, and underwater cases carry explicit exceptions. Search aliases should never erase those restrictions.

Spells and magic items#

Spell commands define access and delivery as well as effects. Research school, level, path requirements, fatigue cost, range, targeting, area, damage, precision, effect numbers, chaining, special attributes, global-enchantment behaviour, rare caster requirements, and AI hints can all matter.

Magic-item commands combine construction access with persistent abilities. Many monster abilities are reused in item context, which makes command collisions common. A token documented for monsters is not automatically documented for items; the entry must contain the item domain or an explicit cross-context statement.

Events#

Event commands are divided into requirements and effects. Requirements filter when, where, for whom, and against which target an event is valid. Effects alter state after selection. Event codes and variables create memory across events. Message substitutions expose names and state inside text. Global events extend the scope beyond one province.

The event language is especially vulnerable to plausible but false assumptions. Several requirements can be combined, repeated, or negated; target requirements do not always select a target by themselves; and a perfectly valid event can remain practically impossible because its conditions never overlap.

Maps#

Map commands define identity, image, size, provinces, connections, names, terrain, colours, starts, victory restrictions, scenario ownership, contents, magic, dominion, scales, and planes. Some commands act on an explicitly numbered province; others operate on the currently active province selected by #land or #setland.

The distinction between global map state and active-province state is another form of parser context. A copied line can be valid yet alter the wrong province if the selector context is missing.

AI and general commands#

AI modding exposes bounded hints and templates, not a general programmable strategic brain. The language can shape Pretender design, research targets, and some preferences. Book VIII, Part X owns the capability boundary.

General commands affect broader game or mod state. Their apparent simplicity makes them easy to place without considering version, load order, or campaign consequences. Each should be treated as a project-level change.

Part V: A Safe Lookup Workflow#

Beginner route: from desired result to a valid line#

1. Define the object being changed: weapon, armour, monster, site, nation, spell, item, event, map, or another supported type.
2. Search the domain rather than guessing a command name.
3. Open the cited official page and read the surrounding explanation.
4. Confirm whether the entry is defined, reference-only, mentioned-only, or a template.
5. Copy the printed command spelling and replace argument labels deliberately.
6. Confirm the selector or creator that establishes the active object.
7. Confirm whether #end is required.
8. Load the smallest possible mod containing only the relevant block.
9. Inspect the resulting object or event before integrating the change into a larger project.
10. Record the game version, manual version, and result.

This route is slower than pasting an isolated line and much faster than debugging a large file whose parser context is already uncertain.

Expert route: from token to maintenance decision#

1. Search the normalised token and all aliases.
2. Review every context when the token is marked context-sensitive.
3. Compare current-manual syntax with every linked patch record.
4. Check the mod’s declared minimum game version.
5. Inspect neighbouring source for selector state, copied fields, clearing operations, and identifier ownership.
6. Check combined-load-order overlap with other active mods.
7. Decide whether the change is static, load-validated, object-validated, or behaviour-validated.
8. Preserve a minimal reproduction when runtime evidence adds knowledge beyond the official text.

When a command is known but its meaning is not#

A reference-only or mention-only token should trigger a bounded evidence search:

• read the full surrounding official page;
• search later official patch announcements;
• inspect current official examples if available;
• inspect a reputable working mod while treating it as implementation evidence, not official documentation;
• create a minimal reproduction;
• vary one argument at a time;
• record accepted syntax separately from observed effect;
• avoid generalising beyond the tested version and context.

The absence of an official description is not permission to replace it with a confident guess.

When a patch token fails to parse#

The reconciliation table should be checked before assuming the game rejected a once-valid command. The token may be:

• a family expression such as #force...vis;
• a terrain template member;
• a numeric template member;
• a manual spelling mismatch;
• a message placeholder;
• a command added after the running executable;
• a command valid only in another object context.

If none applies, the failure becomes a research item rather than an invitation to cycle through arbitrary spellings.

Minimal reproduction structure#

The smallest useful test file contains metadata, one object, one disputed command, and no unrelated content:

#modname "Command Test"
#description "Isolates one syntax question."
#version 0.01
#domversion 6.37

-- One fixed object, one command under review, one expected result.
#selectmonster 123
  #command_under_test <value>
#end

The selected object and command must be appropriate to the test. A disposable copy is preferable when altering a vanilla object would contaminate comparison. Event and map tests require their own minimal harnesses.

Four different validation claims#

These claims should not be collapsed into “works.”

Deprecated commands#

The official manuals mark #coastunit1...3 and #coastcom1...2 as deprecated. Their presence in the locator supports legacy-source diagnosis, not new use. A deprecated token should remain searchable because removing it would make old mods harder to audit. Search results should place the replacement route and warning ahead of convenience.

Minimum game version#

#domversion states the minimum Dominions version required by a mod. The value should follow the newest feature actually required, not the version on the developer’s computer by habit. Patch provenance makes that decision more defensible: if a required command first appears in 6.30, a lower declaration needs specific evidence that the command existed earlier.

The first patch mention is not always the true introduction. Some announcements describe a fix to an existing command. Direction and classification must therefore be read with the version, not inferred from date alone.

Part VI: Patch-to-Manual Reconciliation#

The controlled exceptions#

The following table contains every patch token that does not resolve as an exact current-manual token. Exact matches remain available in the full patch index.

How to read the table#

A template alias resolves a concrete spelling to the official template that defines the family. A spelling mismatch preserves both source forms. A family shorthand expands an announcement expression into documented members. A message placeholder changes grammar class. None of these mappings asserts that every displayed form is accepted literally by the executable.

Exact matches still require context#

An exact string match is not the end of analysis. #clear, #name, and #end all have exact definitions in several object contexts. The patch record establishes a historical change, while the manual entry establishes a current locator. The active object still determines practical meaning.

A patch can correct behaviour without changing syntax#

Many patch records say that a command “didn’t work,” accepted a wider value, became valid in another context, or was deprecated. The syntax before and after the patch can be identical. A current command index therefore needs both syntax status and behavioural history.

Book XIII remains the place to inspect the full release context. The command register stores only the links needed to move between the present locator and the historical ledger.

Part VII: Search and Website Architecture#

One content identity, several views#

The PDF and website should not maintain separate command facts. Both are generated from the same record identity. The website can provide several views without duplicating content:

• alphabetical command search;
• domain browser;
• manual and page browser;
• patch-version browser;
• documentation-gap queue;
• context-collision view;
• template and alias explorer;
• deprecated-command list;
• message-substitution reference;
• canonical links into Book VIII and Book XIII.

Command record fields#

Each record contains:

Alias records are explicit#

An alias record contains the searchable literal form, the official template it resolves to, the derivation basis, and a synthetic flag. It does not copy the template definition into a second command record. This keeps search convenient without creating false official entries.

Patch reconciliation is a separate relation#

The patch relation retains the historical token even when it differs from the current manual. Its status and note explain the mapping. This design prevents a later manual update from rewriting the patch archive and prevents a historical typo from contaminating current syntax search.

Useful search filters#

Practical website filters include:

• exact spelling;
• substring or prefix;
• command kind;
• domain;
• manual version;
• documentation status;
• patch version;
• patch classification;
• direction such as added, corrected, deprecated, or changed;
• context-sensitive only;
• template-derived aliases only;
• entries needing runtime work.

Search results should show the caution before the syntax when an entry is ambiguous or incomplete.

Search examples#

Schema and integrity checks#

The JSON schema validates required identity, status, domain, locator, and hash fields. Additional semantic checks are still necessary:

• command and ID uniqueness;
• valid manual IDs;
• pages within each manual’s page count;
• every alias target exists;
• every patch record ID exists in the official ledger;
• every patch token has one reconciliation outcome;
• no unresolved patch token is published as complete;
• status totals match the record collection;
• every canonical destination resolves in website navigation.

Part VIII: Expert Essays#

Essay I: Syntax Is Not Semantics#

Syntax answers whether a line belongs to the language. Semantics answers what state that line changes. Operational behaviour answers what happens when the state enters the game. Strategy answers whether that result is useful. Compatibility answers whether the project remains coherent beside other projects and across versions.

Dominions mod discussions often skip directly from syntax to strategy. A command is found, a line parses, and a broad claim follows. Each skipped layer creates a different risk. A correctly parsed event requirement may make an event impossible. A correctly displayed ability may apply to a mount rather than its rider. A correctly modified spell may never be selected by AI casting logic. A strategically interesting unit may collide with another mod’s identifier.

The lexicon deliberately stops at retrieval and evidence. That limit makes it more useful, not less. A clear boundary allows every later claim to cite the right layer instead of treating a command name as proof of an entire system.

Essay II: Command Context Is a Public Interface#

A mod file looks like a private implementation detail, but every released command block becomes part of a public interface. Save files retain identities. Compatibility patches select objects. Other maintainers read names and number ranges. Players depend on declared versions and load order. Workshop updates replace files inside ongoing campaigns.

Context-sensitive commands reveal this interface most clearly. #name is not a single global naming function; it is a family of fields exposed through different object parsers. The selector, parser phase, object ID, and closing boundary are part of the contract.

Good source makes that contract legible. It freezes identifiers, documents ranges, isolates object blocks, states dependencies, and avoids unnecessary selection of shared vanilla objects. Poor source can still load, but it forces every later maintainer to reconstruct the contract from behaviour.

Essay III: Patch Notes Are Change Evidence, Not a Replacement Manual#

Patch notes are written to explain what changed. Compression is useful in that setting. #force...vis efficiently tells experienced modders that a family was fixed. #not(dis)mounted compactly names two related commands. “New nation commands: #forestfortrec, #forestfortcom, etc.” signals a broader addition without printing a grammar.

The same compression becomes hazardous when harvested into a reference. Ellipses look like literal characters. Parentheses look like optional text. Singular and plural spellings become competing commands. A message placeholder becomes a single-hash token after naive extraction.

The solution is not to distrust patch notes. It is to preserve their purpose. Book XIII stores change evidence. Book XIV reconciles expressions to present documentation. Neither source is forced to do the other’s job.

Essay IV: Templates Are Grammars, Not Abbreviations#

A template such as #(terrain)rec defines a productive rule: substitute an allowed terrain word to create a literal command. This is more powerful than an ordinary abbreviation because it can generate forms not separately listed. It is also more dangerous because readers can generate plausible but invalid forms.

Formal grammar has constraints. The manual’s terrain list, fort exceptions, and underwater alternatives define the valid language. A search system should expose those constraints with the template. Generating aliases without a target link produces convenient misinformation; refusing to generate aliases makes ordinary source unnecessarily hard to search.

The controlled alias is the middle path. It states that the concrete term is derived, records the official template, and retains the synthetic status. Search becomes broader while evidence remains exact.

Essay V: Documentation Gaps Should Remain Visible#

A reference-only command creates an uncomfortable blank. The token is official, but the intended value range or detailed behaviour may not be printed. There is a temptation to fill the gap with community consensus and remove the warning once a likely explanation appears.

That approach destroys useful information. A later reader can no longer tell which part came from Illwinter, which part came from a working mod, and which part came from a test. The confident summary may remain correct for years, yet its evidence chain has been lost.

A visible gap supports cumulative research. Official existence, community implementation, runtime acceptance, observed effect, version, and test conditions can each be recorded. Later evidence adds a layer instead of replacing the uncertainty with anonymous certainty.

Part IX: Maintenance and Review Protocols#

Before adding a command to a project#

• Confirm the object domain.
• Open the official locator rather than relying on the command name.
• Verify every argument and alternative form.
• Check whether the token is a template or message substitution.
• Check linked patch records.
• Confirm the minimum executable version.
• Inspect selector, copy, clear, and #end context.
• Check identifier ownership and combined-mod overlap.
• Build a minimal reproduction for incomplete behaviour.
• Record the evidence level beside the design decision.

When reviewing a legacy mod#

• Record the mod version and original game baseline.
• Extract every hash token without assuming all are commands.
• Resolve template members and deprecated families.
• Identify tokens absent from the current official register.
• Compare context-sensitive syntax against the active selector.
• Flag automatic IDs and shared event codes.
• Preserve old spellings until acceptance has been tested.
• Separate parser migration from balance changes.
• Test a clean new game before testing a historical save.
• Publish the compatibility boundary.

When an official source disagrees with another official source#

• Preserve both spellings or statements.
• Record source version and date.
• Determine whether one source describes history and the other current syntax.
• Search later official corrections.
• Avoid inventing a winner when runtime evidence is absent.
• Test both forms in the smallest valid context if acceptance matters.
• Report the result as versioned runtime evidence.

When a new patch arrives#

1. Archive the official announcement and metadata.
2. Rebuild the official patch ledger.
3. Extract candidate commands and message tokens.
4. Compare them with exact manual tokens.
5. Resolve templates, family expressions, and spelling discrepancies explicitly.
6. Download and hash any updated manuals.
7. Rebuild the command register and schema validation.
8. Review documentation-status changes.
9. Update Book XIII chronology only for historical change.
10. Update Book XIV only for syntax, context, provenance, or retrieval changes.
11. Re-run navigation, duplicate, voice, and visual checks.
12. Publish a bounded change note.

Documentation-defect report#

A useful report contains:

• game version;
• manual title and internal version;
• page and section;
• exact printed token;
• conflicting official token or patch record;
• minimal valid block;
• parser result;
• observed behaviour;
• save, mods, and load order where relevant;
• a statement separating observation from inference.

This format is far more actionable than “the command does not work.”

Part X: Complete Search Locators#

How to use the appendices#

The following appendices are mechanically generated from the validated command register. Their compact entries are locators rather than replacements for the official explanations. “Defined” points to an official syntax line. “Reference” marks an official list or example entry. “Mention” marks prose-only evidence. Template and message tokens retain their grammar class.

The first locator contains every distinct hash token found in the current official manuals. The patch column shows the first linked version when Book XIII contains a command record. The syntax column preserves the strongest official syntax line without copying the manual’s explanatory prose.

Templates#

0-9#

A#

B#

C#

D#

E#

F#

G#

H#

I#

K#

L#

M#