Utilizing the <Import> element to have incremental updates

As I’m sure you’ve seen, most packs start with an <Import>  element that adds Forge and its dependencies to a pack…  But did you know that all it does is import from another <Server>  element either in the same file or from a different one?  Today I’m going to show you how to set up your pack to allow you to do incremental updates.

To start with, I will show you an example from my own server:

At first, you can see that it has the standard Forge import, but then you’ll see that there are no <Module> entries in the main file of the pack.  It’s important to note that <Import> elements are processed in the order that they appear in the file and will be processed before <Module> elements.  This system relies on a mechanic of how MCUpdater handles the mod list:  There can only be one entry in the list per ID and adding a new mod with the same ID will replace the existing one.  The “optional” ServerPack is a more generic pack so we will skip over it, but the reason it is listed above the others is so that should the pack need to replace a mod from the optional pack, it will be able to.  This brings us to the first actual entry of the pack: <Import url="http://files.mcupdater.com/lunaa1710-redux/05312015.xml">05-31-2015</Import> which contains the following:

You may notice something interesting about this list…  there are no <ConfigFile> entries.  Those are added later, which I will get to soon.  This is the initial pack definition, and will most likely be the longest XML in your pack.  Now I’ll show you the first update that was made <Import url="http://files.mcupdater.com/lunaa1710-redux/06102015.xml">06-10-2015</Import> which contains:

This list is much shorter and contains only the mods that have been updated.  I’ll spare you the details of the other updates.  The final <Import> element is the configs:

This one is slightly different.  All of the <Module> elements are <ModType>Override</ModType> this type will modify the existing entry for a ModID instead of replacing it entirely.  By doing this, no matter how many times a mod has been updated over the course of the server, the configs will only be specified once.

Now, the question you may ask yourself is “Why would I do this?”  The reasons that I have come up with are:  1) It provides a relatively clear changelog, and 2) Should something go wrong with a mod in an update, you can simply remove that entry from the update’s XML and the pack will revert to the previous version of the mod.

I originally did the splitting of the mods and configs by hand, but as of FastPack 1.6.11, this can be done automatically.

This is the staging area that I use for my own pack:

When you are first setting this up, you won’t have the update folders.  You would use FastPack somewhat like this:

This will create the XML with the mods without the  <ConfigFile> entries.  Then you would do something like this:

This will create the XML with overrides that have the <ConfigFile> entries.  Then you would assemble a new XML like this:

This is your basic pack at this point and no updates have been made yet.

When it is time for your updates, you would create a new folder and place all of the updated mods in it. Then you would run FastPack like this:

Now you would modify the XML above so that you would have this:

If your updates will need new configs, they can be added/updated in the original configs folder and FastPack can be run again as above to generate a new configs.xml file.  This assumes that you are making subfolders for your updates (as I did above).

If when you are updating, you actually want to remove a mod that was previously in the pack, you will need to modify the XML for the update by hand and create a <Module> entry with <ModType>Removal</ModType>

If you have any questions, you can always ask them in the #MCUpdater channel on Espernet IRC.