Tips on organizing mod files and their changes?

[Dominick]

Greetings everyone,

I would like to ask for some tips on how to organize mod files and their changes in the course of modding.

On what platform(s) do you keep the most up to date files, especially if you work in a team, and in which way and how often do you archive files from previous versions of mod(s)?

How do you write down internal and/or public change notes for each version, e. g. do you write down every change in internal notes or do you group up some changes in a single note?

How do you numerate every version of the mod? When do you numerate the mod version with the next number and how large are your goals for every next number?

If you have any links you think could be useful, they are more than welcome!

Thank you very much for your answers in advance and if you have any other advices for a modding/programming newbie, please let me know!

All the best,
Dominik

[Callistonian]

My mod hosts all pre-release files for the next update on OneDrive which provides 1TB space with a paid Microsoft 365 account. We host utility/auxiliary files on Dropbox for free (not as much space needed). Since these hosting platforms cost money, there's no point archiving previous version there - that can be done on ModDB or other distribution platform. Change logs (text files) for previous versions can easily be hosted anywhere for free. These are all forms of centralized version control (master mod files on a server with particular team members given edit access). As far as I'm aware, this is the most common version control paradigm used for Medieval 2 mods. I know there are some mods for other games that use Git and other distributed version control systems, but this hasn't been adopted for M2 as far as I know. The main benefit of using a distributed system is that multiple people can theoretically work in the same files (such as campaign_script) at once and merge in their edits, but in practice this would be a nightmare to coordinate between modders, not to mention that most of a mod's assets are non-mergable binary files (2D, 3D, audio) which don't benefit from such a system.

In my opinion, it's important to maintain a detailed internal change log. When you're ready to publish an update, you can generate a public change log by pulling and aggregating the biggest items from the internal log. The internal log should be easily accessible to all team members (including playtesters) and each entry should include at least the following: 1) name of person who made the edit, 2) date of the edit, 3) list of files edited, 4) brief description of the nature of the edit. For my mod, we use a Discord channel editable by modders and readable by playtesters which automatically handles the name and date so the modder just needs to include the list of files edited and brief descriptions. The level of detail provided in the descriptions can vary widely for my mod from small easily reproducible steps to high level statements. You don't necessarily need the change log to consist of reproducible steps. The important thing is that the other team members understand what's going on and can get the needed files without downloading all 10-20 GB of the entire mod for every small edit. An example change log entry for my mod might be:

- battle difficulty, not strat difficulty, affects enemy captain-led unit experience (CS)
- fixed spacing on settlement names for scrolls (ICRASN)

Neither of these items are likely to make it into a public change log.

The versioning scheme you use is completely a matter of opinion. I think ones place version numbers (1.0 vs. 2.0) should be reserved for major changes to the mod that are certainly incompatible with each other. Tenths place versions (1.1 vs. 1.2) can also be major releases or patches depending on your preference. I wouldn't go deeper than that for public releases unless you plan on having more than 10 significant patches per major release. Deeper version numbers (1.1.1 vs. 1.1.2) can be used to keep track of internal patches, but I've never felt a need to do this - the current up-to-date pre-release files are just whatever is on the hosting site.

[Gigantus]

The EBII team uses Tortoise GIT which allows you to add comments when 'commiting' changed files which also serves as 'revision' number, eg consecutive numbering of edits - the version number you often see on beta releases. Apparently it also allows for patch compiling.
Maybe get in touch with QuintusSertorius - he is their go to person.

[Dominick]

My mod hosts all pre-release files for the next update on OneDrive which provides 1TB space with a paid Microsoft 365 account. We host utility/auxiliary files on Dropbox for free (not as much space needed). Since these hosting platforms cost money, there's no point archiving previous version there - that can be done on ModDB or other distribution platform. Change logs (text files) for previous versions can easily be hosted anywhere for free. These are all forms of centralized version control (master mod files on a server with particular team members given edit access). As far as I'm aware, this is the most common version control paradigm used for Medieval 2 mods. I know there are some mods for other games that use Git and other distributed version control systems, but this hasn't been adopted for M2 as far as I know. The main benefit of using a distributed system is that multiple people can theoretically work in the same files (such as campaign_script) at once and merge in their edits, but in practice this would be a nightmare to coordinate between modders, not to mention that most of a mod's assets are non-mergable binary files (2D, 3D, audio) which don't benefit from such a system.

In my opinion, it's important to maintain a detailed internal change log. When you're ready to publish an update, you can generate a public change log by pulling and aggregating the biggest items from the internal log. The internal log should be easily accessible to all team members (including playtesters) and each entry should include at least the following: 1) name of person who made the edit, 2) date of the edit, 3) list of files edited, 4) brief description of the nature of the edit. For my mod, we use a Discord channel editable by modders and readable by playtesters which automatically handles the name and date so the modder just needs to include the list of files edited and brief descriptions. The level of detail provided in the descriptions can vary widely for my mod from small easily reproducible steps to high level statements. You don't necessarily need the change log to consist of reproducible steps. The important thing is that the other team members understand what's going on and can get the needed files without downloading all 10-20 GB of the entire mod for every small edit. An example change log entry for my mod might be:



Neither of these items are likely to make it into a public change log.

The versioning scheme you use is completely a matter of opinion. I think ones place version numbers (1.0 vs. 2.0) should be reserved for major changes to the mod that are certainly incompatible with each other. Tenths place versions (1.1 vs. 1.2) can also be major releases or patches depending on your preference. I wouldn't go deeper than that for public releases unless you plan on having more than 10 significant patches per major release. Deeper version numbers (1.1.1 vs. 1.1.2) can be used to keep track of internal patches, but I've never felt a need to do this - the current up-to-date pre-release files are just whatever is on the hosting site.

Thank you for this in-depth explanation, it is very useful and much appreciated! I will definitely use some of your solutions, for example on internal change notes, however the explanation also gave me insight on how to properly organize things in tune with my own ideas, considering the mod is small right now.

The EBII team uses Tortoise GIT which allows you to add comments when 'commiting' changed files which also serves as 'revision' number, eg consecutive numbering of edits - the version number you often see on beta releases. Apparently it also allows for patch compiling.
Maybe get in touch with QuintusSertorius - he is their go to person.

I will consider contacting him if the modding team expands to see what might be the best solution for cooperative modding. Thank you!