Author: Scott Barbour

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.

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 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:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

sbarbour@Redstone:~/staging/lunaa1710-redux$ tree

.

├── client

│ ├── [1.7.10]ArmorStatusHUD-client-1.28.jar

│ ├── [1.7.10]DamageIndicatorsMod-3.2.3.jar

│ ├── [1.7.10]StatusEffectHUD-client-1.27.jar

│ ├── InGameInfoXML-1.7.10-2.8.1.80-universal.jar

│ ├── JourneyMap5.0.1_Unlimited_MC1.7.10.jar

│ ├── LunatriusCore-1.7.10-1.1.2.21-universal.jar

│ └── Waila-1.5.10_1.7.10.jar

├── config

│ ├── AdvGenerators

│ │ ├── client.config

│ │ ├── overrides

│ │ └── readme.txt

│ ├── AE2Stuff

│ │ ├── overrides

│ │ └── readme.txt

... Several lines later

│ ├── Treecapitator.cfg

│ ├── Waila.cfg

│ └── zettaindustries.cfg

├── mods

│ ├── 1.7.10

│ │ ├── [1.7.10]bspkrsCore-universal-6.16.jar

│ │ └── ForgeMultipart-1.7.10-1.2.0.344-universal.jar

│ ├── [1.7.10]Treecapitator-universal-2.0.5b.jar

│ ├── ae2stuff-0.2.1.22-mc1.7.10.jar

│ ├── AgriCraft-1.7.10-1.3.1.jar

│ ├── appliedenergistics2-rv2-stable-3.jar

│ ├── autopackager-1.5.4.jar

... Several lines later

│ ├── zettaindustries-0.2a.jar

│ └── zz-backpacks 1.7.10 - 3.0.3.jar

├── optional

│ ├── CodeChickenCore-1.7.10-1.0.6.44-universal.jar

│ └── NotEnoughItems-1.7.10-1.0.4.107-universal.jar

├── server

│ ├── Dynmap-2.1-forge-1.7.10.jar

│ ├── IvToolkit-1.2.jar

│ ├── Morpheus-1.7.10-1.6.4.jar

│ └── RecurrentComplex-0.9.6.2.jar

├── update-06162015

│ ├── buildcraft-7.0.11.jar

│ ├── buildcraft-compat-7.0.8.jar

│ ├── generators-0.9.14-DEV-mc1.7.10.jar

│ └── rftools-3.02.jar

├── update-06192015

├── Chisel2-2.3.10.686e081.jar

├── DynamicTransport-0.1.2.0-custom.jar

├── SlimevoidLibrary-2.0.4.6.jar

└── SolarFlux-1.7.10-0.8.jar

When you are first setting this up, you won’t have the update folders. You would use FastPack somewhat like 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.