FastPack Basics

FastPack is a command-line tool that scans a directory tree for mods and config files and builds a ServerPack.xml from what it finds. It is not the sharpest crayon in the box, but it can save you a lot of time building and updating your pack when the time comes.

A lot of FP’s usage is either mind-numbingly obvious or arcane beyond the scope of this basic document (which is current as of FastPack 1.6.11 – July 12, 2015). I am only going to cover basic use here with a few simple examples. More specific details will be forthcoming in blog posts and Q&A pages.

FastPack is under active development, with new features and intelligence added regularly. So if it has been more than a few weeks since you last used it, I recommend downloading a fresh copy.

There is no GUI for FastPack (we’ve had bad luck with graphical pack builders in the past), so to make things work, you will need to be comfortable typing at a command prompt. As our target audience is composed of people running their own Minecraft servers, I will quite blithely assume that you know how to open up a dos prompt or bash shell to the correct directory.

Since this is a jarfile we are executing from the command line, all FastPack calls will tend to be of the form java -jar MCU-FastPack-latest.jar (or whatever you may have renamed the jarfile to).

If you don’t provide any further parameters, it will give you an error saying which flags are absolutely required to get any output. For a list of all supported arguments, run FastPack with --help like so:

This XML will load into MCU but won’t download any mods, etc… It won’t even install Forge, so let’s remedy that.

Suppose I am creating a fresh pack for a new server called FastPack Test (because I am brimming with creativity at the moment). At the very least, I would start by modifying the command above to get something that looks closer to this:

In addition to populating the server ID and name attributes for us, it now also constructs an appropriate Forge import and a dummy Override to make the progress bar go a little nicer. You could safely remove the entire extra mod entry or you could update the Size to match the actual size of the forge jar if you wanted. Or you can just ignore it as good enough 😉

Now let’s add some mods. FP looks for mods in all folders below the --path that you start the search off in. For sanity, I’m going to put some mods under fptest/mods/ like so:

1

2

3

4

fptest

└── mods

├── ebxs-autumn-woods-0.0.3.jar

└── ebxs-core-0.1.3.jar

Now, when we re-run the exact same command as above, we see some additional output on the console:

1

2

fptest/mods/ebxs-autumn-woods-0.0.3.jar: 70 entries in file.

fptest/mods/ebxs-core-0.1.3.jar: 63 entries in file.

This lets us know that it identified and parsed the two mods, and sure enough, it added them to the xml, yielding an entry for EBXS Core that looks like this:

It identified the three mods correctly then it looked through additional files, assuming that they were configs. It did some pattern matching between what it knows about the mods in the list and the filenames of the configs to determine that config/Carnivora.cfg belonged to the mod named “Carnivora”, and generated the following XML for its entire mod entry: