Before beginning any modding project, it is strongly recommended that you download a proper plaintext editor, as Microsoft Notepad is unacceptable for even the most simple of text-based modding. The most commonly used programs are Programmer's Notepad and Notepad++. Each has its benefits and drawbacks, but the important thing is that you use a program that saves formatting with the file and can monitor functions and brackets.

Programmer's Notepad:
https://www.pnotepad.org/

Notepad ++:
https://notepad-plus-plus.org/downloads/

My personal preference is Notepad++ due to the comparatively high ease-of-use, but your mileage may vary.

Plaintext editor in hand, you will then need to create the basic file structure of the mod. This consists of a folder in ...\User\Appdata\Roaming\coe5\mods that contains a text file labeled 'coe5ws.txt' (this is used to set visibility of the mod on the workshop), a PNG titled 'banner' that is no larger than 1MB (this is the first image attached to the mod on the workshop), a text file labeled <modnamegoeshere>.c5m (this is where all work is done), and a TGA-format picture that is no larger than 256x64 pixels (this is the image that shows up in-game for the mod). The name of the TGA picture can be whatever you want, but it must be specifically referenced in the c5m file and must be a valid size, or the mod will not load.

Example file structure:

Failing to have any of these elements will have an effect ranging from preventing the mod from being uploaded to simply doing nothing. The CoE5 modding manual does a rather good job of explaining this, but lacks some depth of detail present here.

An additional (and probably pointless) note: a 1MB PNG is approximately 768x768 pixels in size, so you have a lot of leeway for the size of your workshop page's banner..

There is a rather large amount of current and slightly outdated reference material for CoE5 that is available. The only thing that has not been properly ripped from a recent Illwinter game is events, which are Fun™. This section is largely devoted to my personally collected reference database, so links abound.

CoE5 Sprite Dump:
https://drive.google.com/file/d/1L2gFNlIOISnOuxV876iHQVmKwzZLUePo/view

Important: The Python script included in the link (run via the batch file included) requires Python 3.xx or higher and any version of Pillow to run to completion. Additionally, the directory provided in the batch file may require changing depending on desired output location and placement of the script.

Dominions 5 Sprite Dumps - courtesy of larzm:
Monsters - PNG (for viewing/editing):
https://drive.google.com/file/d/1EJ8A1azzYfFRFjJHB_0W-vO8RIQUW7Dp/view
Monsters - TGA (For placeholders or straight rips)
https://drive.google.com/file/d/1s_aBRg-mKrP3GtvxzMbqMlFCjSfpPCDm/view

CoE5's (Incomplete) modding manual:
http://www.illwinter.com/coe5/coe5modding.html#aff

CoE4's modding manual:
http://www.illwinter.com/coe4/coe4modding.pdf

CoE4 Data Rips for Terrain, Monsters, Rituals, Classes, Spells, Items, and Recruitment:
https://psteamcommunity.yuanyoumao.com/app/403950/discussions/1/1699415798780806822/

CoE5 Data Rips for Terrain, Monsters, Rituals, Spells, Items, and Recruitment (mostly complete):
https://psteamcommunity.yuanyoumao.com/app/1606340/discussions/1/3198114142283463845/

Ritual Resources:

Most info that is missing can be found via the inspect tool (Ctrl + i) in-game. Unfortunately, it does not work in post-game. The tool can be used on basically anything you can mouse over.

Basic audio editing is a simple affair. Any WAV file is eligible for use in CoE5 as in-game audio, so long as the compression rate is 22050 Hz. Changing said rate can be accomplished via Audacity or some other audio editing software. It should be noted that there will be a noticeable loss of audio quality if the compression rate is changed considerably.

Audacity can be found here and additional step-by-step tutorials can be found online through their manual:
https://www.audacityteam.org/download/

Once you have a WAV file with the appropriate compression rate, just change the file extension from .wav to .sw (or .sw2, though there may be additional steps to avoid tanking audio quality) and add a sample line in your .c5m file. You may need to unhide common file extensions in order to do this. The method for doing this varies by Windows version, but is typically accomplished by opening windows explorer, hitting Alt +T + O, going to view, and unchecking hide common file extensions.

From there you can use the new sample for whatever purpose you want. Bear in mind that there are a very limited number of slots for sound samples (2^8 or 256) and most are used by the game, so adding audio can easily result in compatibility issues.

In order to convert audio files to a WAV format, simply use Audacity or other audio editing software as above to do so, bearing in mind that there may be additional steps to preserve audio quality.

Creating new audio entirely is far more compicated and involved and is, as such, out of the scope of this guide.

While actual art editing is beyond both my expertise and the scope of the guide, a couple of artists have chimed in. From my understanding, there are two options. First, you can use GIMP (or alternatives, if they exist) to create and edit TGA files directly. This may save on file conversions, particularly if you are using one of the PNG sprite dumps as a reference point to edit their TGA counterparts.

GIMP can, of course, be found on their website. It is not a particularly light program, but it is occasionally mentioned by the artists I regularly interact with.

Direct link:
https://www.gimp.org/downloads/

The second option is to use XnView to manipulate either TGA or PNG images and convert as necessary. I am told that the main advantage to this option is that XnView can be used to save transparency layers for the purposes of making backgrounds and shadows, but I frankly have neither the talent nor the inclination to mess with art myself.

XnView's website can be found here:
https://www.xnview.com/en/

Finally, all Dominion 5, CoE4, and CoE5 sprite dumps are waaaaaaay up at the top of the guide. Dominions 5 even has dumps in both TGA and PNG which should prove most useful even if you aren't the artsy type.

Mechanically, there are some interesting things to note about sprites and their interactions with units in-game:

First, if a sprite is appropriately sized for a 1x2 or 2x1 (64x128px or the reverse) tile unit and any of the "unit size" traits are used, then the sprite will be centered on the unit's "center" but will either leave the bounds of the unit's "square" or only take up a small part of it. this is potentially useful for making better looking pike formations than what is normally possible in CoE or for giving the illusion of height/depth when used with pikes, banners, and other tall objects/units.

Second, if the above is true but a unit size is not used, then the unit will automatically be sized based on its sprite. This is potentially useful for long units such as chariots, serpents, or serpentine dragons, or for "small" giants which don't justify taking up 2x2 or 3x3 tiles. Alas, you cannot make tetris block shapes by using this property.

Internal Ordering
Conquest of Elysium mods are order-sensitive both internally and externally, which presents some unique challenges for maintaining internal cohesion and compatibility. For any given class - whether you are starting from scratch or modifying existing data - the more you change, the more order matters.

Internal ordering for new content, from top to bottom should be:
Game-altering content (SFX/BGM, new definitions or scripts)
Weapons
Units
Terrain
Rituals
Class content (Recruitment, starting troops/terrain/plane/etc, text/sound changes)
Events

Class and events are interchangeable with one another, but failing to adhere to the first four points of the ordering can very well wind up with you summoning nothing, having monsters with no weapons, or an inability to recruit units or cast rituals.

External Ordering
All mods have the same load priority by default. This can lead to some...interesting problems. Thankfully, there are now robust solutions to these problems, though they are imperfect and issues can still occur.

Filename Ordering
As of many patches ago (it was back in 5.10 or so, IIRC), Illwinter acceded to my request for filename ordering. When any two mods have the same modprio (see below), the mod with the higher priority filename will load first. This is derived from how the first character in the .c5m file is sorted alphanumerically, the overall length of the filename, and how each character after the first is sorted alphanumerically.

For reference, alphanumeric sorting uses the following pattern from highest sorting priority to lowest:
!@#$%^&*()1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz

All other symbols (including spaces or other breaks) either cannot be used for file names in Windows based systems or are so low priority as to be irrelevant.

modprio <x>
Modprio is a function that forces the mod to load before or after what is normal. All mods have a modprio of 5 if it is not defined by the creator. Setting the number lower will make the mod load earlier, while setting it higher loads it later. This is a great tool for sorting mods to prevent issues with - say - monster or ritual offsets. However, there are only 9 values for modprio, which limits its potential as a "cure-all", so modprio should only be used as a last resort.

newritpow and ritpow
Since we are severely limited by how many times we can safely use modprio, there are some considerations to factor in when making mods. First, ritpows pose a unique issue as both negative offsets (from the minimum value -1) and positive offsets (from the maximum value +1) are affected by load order, which can cause some funny, if frustrating issues. There are some options, but each has its own benefits and drawbacks.

• ritpow Option 1:
  Option 1 is to completely avoid making newritpows. The obvious benefit to this is that you'll never have to worry about ritual group compatibility. The drawback is that you are limited to vanilla ritpows and may need to resort to lengthy workarounds to add powers to new units without dragging along the rest of the ritpow, such as combining the notforpoor restriction and classcost <x> on units. This may be particularly burdensome if you are trying to maintain internal compatibility across several of your own mods.
  
  
• ritpow Option 2:
  Option 2 is to use positive offsets for your rituals within your newritpows. These start at 58 and are practically infinite. The primary benefit here is that it's easy to set up and keeps formatting with all existing rituals, which is great for beginners and sufferers of OCD. The problem, however, is that it is atrocious for external compatibility and you are essentially requires to use modprio 1-4 to prevent issues.
  
  
• ritpow Option 3:
  Ritpow option 3 is to use negative offsets for your rituals within your ritpows. These start at 0 and are, again, practically infinite in the opposite direction of the positives, but require slightly different syntax that is more dependent on the power <x> <y> function for units and the breaking up of blocks of rituals to tie them to specific units or groups of units, which is rather messy and hard to track. This method offers the same level of internal compatibility as positive offsets and somewhat less awful external compatibility, but for the price of significantly more work in the long run. Still, you might save on having to use modprio if you play your cards right.

Monster offsets
Monster offsets are used for a variety of tasks, ranging from creating monthly freespawns and automatic promotions, to changing units as part of mastery rituals. Like with newritpow offsets, these cause all sorts of issues for external compatibility, as well as some new ones for general modding. Unlike with ritpow offsets, monster ID's are not mapped in any official documentation and there are well over a thousand of them. Worse, none of the CoE5 monster offsets are available anywhere. As such, there are a few options to consider:

• Option 1:
  Avoid doing anything with monster offsets at all costs. You'll avoid pulling your hair out trying to find the exact offset needed to get from a vanilla monster to a modded monster or vice versa, only to have the offsets completely break when there's more than one mod in play. Obviously, this limits the Fun™ you can have/inflict on people, but you can work around some of the problems with monster offsets by using promotion rituals instead of mastery rituals.
  
  
• Option 2:
  Avoid doing anything with vanilla monsters' offsets. This is a less restrictive than option 1 and you can get around basically all offset issues by either creating new Totally Original Content™ monsters and offsetting based on those. Promotion rituals still work as a workaround with these, too. This also helps to avoid potential monster offset compatibility problems, as you are not reliant on load order to keep your monster offsets from breaking into a million pieces.
  
  
• Option 3:
  Avoid doing anything with new monsters' offsets. This is less restrictive than option 1, but you completely lose access to any monster offset dependent function for new monsters aside from 'mastery' via the promotion workaround. Should be avoided.
  
  copy functions
  This is rather simple: Don't try to have any copy function precede what is being copied. e.g. If you are trying to copy a custom monster's stats, the copystats "existingunit" function should be placed somewhere below where the monster was created in the mod. If the monster was in another mod, the other mod must have a higher load priority (lower number) and be listed as a dependency in the workshop.
  
  Failing to do either - where applicable - will result in the monster not working properly. The same is true of things like terrain, rituals, and weapons.

The good news regarding CoE5 modding is that as long as you heed the ordering above, syntax within each item you add matters very little. The only real caveat other than "make sure to have dependencies somewhere above what you are making" is to pay attention to case and how boolean arguments are written in the documentation.

For example:


Neither of these functions will work correctly. For the first example "dwarf worker" does not exist, as the monster's name is Dwarf Worker. For the second example, the NOT argument needs to be bracketed with parentheses in order to function for rituals. The unbracketed version of the argument only works for events and recruitment limiters.

So, with those changes, each function would appear thusly:


Other than the above considerations, you only need to make sure that any item starts with an opening function. This is the case both for editing existing content and creating new content.

For example:

This section is dedicated to examples of various commonly used code blocks within mods. These should be used for what they are - baseline examples - rather than absolute requirements for modding various things. Comments will be provided as they would be done in your own work and some attempt at formatting will be made, but Steam does not make clean formatting easy.

This section is going to be very long and full of code blocks. You have been warned.

Weapons are rather simple, as they have no dependencies. Breaking weapons is nigh on impossible. That said, you should avoid editing existing weapons and focus on making new weapons, as editing weapons can drastically alter game balance due to the amount of weapon sharing monsters have.

Example non-magic melee weapon with no status effect:

Example non-magic melee weapon with a basic status effect:

Example non-magic melee weapon with a basic primary AoE

Note that the AoE on the weapon can take on any value listed in the modding manual and will always share the damage type of the initial hit.

Example non-magic melee weapon with an advanced magic secondary AoE:

As you can see, in this example, the AoE is magical fire damage instead of blunt damage and only occurs if the initial hit did damage. This can be changed by using nextalways instead of next.

Example ranged weapon:

The same principles apply when making more advanced ranged weapons, but the game also takes into account whether projectiles can be fired over obstacles such as people or battlements. Remember to use 'lob' for arcing weapons and 'arrow' for weapons you want affected by wind guide/air shield.

Monsters are still fairly straightforward, but have the potential for having weapons and/or ritual powers as a dependency. As discussed above, weapons should be placed somewhere above any monster that uses them. The same is true for new ritual powers if you are using those on a monster.

In addition to the dependency issue, it is advised - for sanity's sake - that you avoid editing monsters that are heavily shared between classes and/or indie factions, as doing so could have profound and unforeseen effects on balance.

Example monster:

Note that meleeweapon 10 "Example Choppa" adds the listed weapon with a damage die of 10 or adds +10 to the die - making it a D17 if we go off our above example - if the weapon has a dmg value. The weapon will only be used in melee range.

Example mage:

Note that spell weapons are not used in melee unless spellweapon25, spellweapon50, or spellweaponbonus are used. These should be reserved for powerful combat casters and super combatants. Also note that the monster can use all three vanilla tiers of the Witch's rituals, meaning it should be used as a commander.

Example hybrid combatant:

Note that the monster can shoot while in melee as a bonus action. Using rangedweapon50 or rangedweapon25 will also allow the monster to fire while in melee, but will prevent the use of other attacks if used.

Wowee, we actually hit the character limit on a section. Let's see if we can do it again.

Rituals are, again, rather simple. They may have monster - and therefore weapon or ritual - dependencies, but for the most part you shouldn't have any trouble creating rituals and having them work as intended.

Included here are some commonly used rituals, but there are plenty of other possibilities. Obviously, all rituals can be used with newritpows, but all examples will use existing ritpows for the sake of example.

Example Mastery Workaround:

Mastery workarounds should ideally only be used when trying to expand on vanilla classes. We have no control over vanilla monster offsets, so this type of ritual bypasses them entirely while preserving the caster's spells, items, and ritual access. Note that they can also be used to promote monsters other than the caster in much the same way, so they can be used to give a class access to monsters with newritpows.

Example Tileforming Ritual:

Tileforming rituals simply change a tile from one ID to another, with all that that implies. The ritual need not be in "alter current tile" format like this, but it is perhaps the most balanced option, as ranged targeting options have no range limit. This is also the best way to add any terrain you create to a game due to the current issue with events.

Example Summoning Ritual:

Summoning rituals have a variety of uses, but they all boil down to "More troops". There are a few things to note about summoning rituals. First, the chance for each addstring can be manually set with sum0chance <x>, sum1chance <y>, etc. If they are not used, then all addstrings will have an equal chance of being pulled for the ritual. Second, defctrl can be used to determine the chance that the summoned monsters will be friendly. This is typically used in conjunction with varcost <x> to make people spend more on rituals in order to not die. defctrl <x> is overridden by ctrlchance <x> if it is present on a monster.

Example Portal Ritual:

Portals offer an excellent alternative to planeswapping as they can be used to target any terrain, are permanent until destroyed, and can be chained for multi-planar networks. However, their targeting is imprecise and requires a unique or near-unique destination terrain for the best chance of success. Failure to choose a rare or unique destination will result in stupid things happening, like a portal opening up next to a single crystal forest tile in The Void.

Example Planeswap Ritual:

Planeswap rituals offer quick an easy to setup access to other planes. They are a good option when you can't be sure there'll be unique terrain in a plane or don't want to use portals. The main caveat for planswap is that most planes do not mirror Elysium or each other. Oh, and they can be used to put indie doomstacks in another plane, I guess. Should be paired with a plane scrying ritual.

Example Teleport Ritual:

Teleport rituals are fun. They teleport you. There's nothing else to say. Alas, we have no range restrictions. Can be combined with planeloc <x> to make discount planeswap. Scrying pairs well with it.


Terrain is somewhat limited by available functions and the means to implement it. However it is straightforward. Whether editing existing terrain or making new terrain, you use selectterr <ID> to start the block. Unusued terrID's start at 360, according to Zymeth's work.

Example terrain:

Class editing is, again, rather straightforward but should be below any unit or weapon additions, as discussed earlier. A class block is necessary for all new classes, as it contains starting units, starting terrain, home terrain, and recruitment options.

Example class block:

Note that commander recruitment lines only have four values, rather than five. This is because adding a fifth will break the recruitment line because commanders are always supposed to be recruited alone.

Looks like we did it again. Boy, do I sure love hitting the character limit.

Finally, we come to events. Events are a pain, partially because we have no working examples or rips, and partly because debugging them is a sizeable task. Even so, we have options to play around with. Be aware that adding events will increase turn times.

Example event:

Note that the possible event effects are somewhat limited. For example, you cannot change the rate at which seasons occur via events, as the seasondelay function is a trigger, not an effect.

Events can be used for debugging and testing purposes, as well. For example, if you want to counteract or catalogue the events of a vanilla event you can (with a bit of guesswork and insight) create events to do so.

In this example, the pregame event converting Warlock's Apprentices to the Warlock type that corresponds to the starting gemtype in Warlock's startterr is reverted and a debug message is produced as an output.


Important to note is the fact that there's a maxturnnbr (minturnnbr with a NOT argument). With events that are made for a specific purpose in mind, it is a good idea to make sure they do not check and/or fire every single turn.

Events can also be used to perform multiple actions and can (in theory) set variables that they can then read and act (or not act) upon. They can also read variables from rituals and determine whether or not to fire from there.

In this example, the event checks for all four T3 Warlocks in a Tower of the Elements and will fire provided a variable is not 1, then sets that variable to 1 to prevent further firing in a game.


You should be as careful as possible when adding multiple effects and/or similar triggers, as both order and multiples of the same trigger type can have unintended consequences.