Creating Modpacks

Before we go create a modpack from scratch, let's see the example modpacks first.

Starting with the Examples

Inside sample-files, you will find two example modpacks:

• "lightpack"
• "monsterpack"

Explanation

In the folder for each modpack, you will find:

• modpack.json has basic information about the modpack. You can edit this file in a text editor.
• loaders/ contains various installers (NOT -universal versions) of mod loaders, like Forge, LiteLoader, etc. This folder is blank if you have a vanilla modpack.
• src/ is what will go on the user's computer for the modpack.

Client and Server Files

Because the launcher handles both server and client modpacks, there needs to be a way for you to tell the launcher which ones are server-only and which ones are client-only.

Within src/, you will find "_CLIENT" and "_SERVER" folders. A file that's under a _CLIENT folder will only appear in the client modpack, and similarly for _SERVER. You can put these folders anywhere at any depth, and they also don't actually appear in the final modpack. For example, if you put minimod.jar into src/mods/_CLIENT/minimod.jar, the client would actually have it at src/mods/minimod.jar (the _CLIENT folder disappears).

In the sample project, you will find a _CLIENT and _SERVER used throughout.

Optional Features

You can make some files optional. For an example of this, browse to sample-files/lightpack/src/mods/_CLIENT.

Find two files:

• CoolGrass.info.json
• SomeMinimap.info.json

Inside those files, you will find something like:

{
  "feature": {
    "name": "SomeMinimap",
    "description": "SomeMinimap gives you a cool minimap.",
    "recommendation": "starred",
    "selected": true
  }
}

• "name" is the name of the "feature"
• "description" is a short description that the user can read
• "recommendation" can be omitted, or it can be starred or avoid
• "selected" can be true to have it selected by default or false to have it unselected by default

How do you name these files? Since the .jar is CoolGrass-1.0.jar, you can name it:

• CoolGrass-1.0.jar.info.json
• CoolGrass-1.0.info.json
• CoolGrass-1.info.json
• CoolGrass.info.json
• CoolGra.info.json
• CoOlGRa.info.json

As you see, you can simply use the prefix of the file that you want to make optional.

Note: If you want to make optional features that cover several files (in different places), read Optional Features. However, you can't have one feature depend on a second feature at the moment.

Download from a Custom URL

If you have some mod that you want to have the launcher download from a custom URL (other than your website), you can create a ".url.txt" file alongside the .jar, as illustrated below.

In the file, you'd put the URL:

You may want to do this if the mod author asks you to redirect downloads to his or her own site, as it may record statistics.

Note: You need to make sure that the .jar that you have is the exact same version as the one at the URL, otherwise the launcher may keep redownloading the file because it thinks the downloaded file has been corrupted since last update.

Creating a Modpack

The easiest way to start a new modpack is use the modpack tools GUI.

1. Copy the build-tools-X.X.X-SNAPSHOT-all.jar file from the launcher's build-tools/build/libs folder to a folder where you plan to store your modpack's files.
2. Run the .jar by double clicking it.
3. Click "Edit modpack.json" and fill in the values:
   • "Name" is the name of the folder that the client will use to store the modpack's files, so it should not contain any funky symbols
   • "Title" can be anything and it overrides the name field when showing the name of the modpack
   • "Game Version" is the Minecraft version
   • "Launch Flags" is a list of Java flags (one per line) that will be used during launch
   • "User Files" is a list of files (one per line) that will not ever be overwritten when the user updates the modpack (use a asterisk (*) to match wildcards)
   • "Optional Features" can be used to define sets of files that appear only if the user chooses to enable them (see the Optional Features page)

Then you'll need to actually add the modpack's files:

• Put mod loader installers (NOT universal versions) into loaders/ (for Forge, LiteLoader, etc.)
• Put the modpack's files (config, mods) into src/.

Testing the Modpack

The GUI has a function to test the modpack:

Just click "Run Modpack" to test your modpack.

You can click "Test Launcher Options" if you want to adjust memory options for your test instance.

All the files needed to run the test launcher go into a staging/ folder within your modpack folder, which is all temporary and you can delete whenever you don't need them anymore.

If you want to test the modpack as someone who is installing the modpack for the first time, close the test launcher if it's open, click "Delete Instance from Test Launcher," and run the modpack again.

Publishing the Client Modpack

To build the modpack for release, use the "Relaese" tab:

You'll need to choose a version for this release. Every time you push an update, you have to change this value to something else entirely so that the launcher can compare it with the currently installed version to discover the update. By default, the current date and time is filled in for you, which you are free to use.

The manifest filename is for the specific modpack. You can keep this value the same for every update for the same modpack, and the field should already be pre-filled in for you based on the "name" field from modpack.json.

Clicking "Build..." will generated the proper files.

Using the Command Line

If you are planning to only use the GUI, you can skip this section. Otherwise, this section details how you can build the modpack just using command line tools, which can be more easily integrated into other systems.

1. From the launcher-builder/build/libs/ folder, copy launcher-builder-X.Y.Z-SNAPSHOT-all.jar to your modpack's folder.
2. Open terminal or command prompt and navigate to the directory of your modpack.
   • Windows users: Hold down your SHIFT key, right click the folder that contains "modpack.json", and click "Open command window here".
3. Run the following command (note: put it on one line, and change "X.Y.Z" to the right version):

java -jar launcher-builder-X.Y.Z-SNAPSHOT-all.jar 
	--version "pick_a_version"
	--input . 
	--output upload 
	--manifest-dest "upload/your_modpack.json" 

• "version" is the version of your modpack and it doesn't have to be a number -- whenever you want to push an update, you have to change the version code to anything else that has never been used before
• "input" is the folder with "loaders," "src," and "modpack.json" -- . means "the current folder"
• "output" is the folder to put the output
• "manifest-dest" is the manifest file that is generated

There should be a upload/ folder now with the generated files.

Uploading the Files

After you're done, upload the contents of upload/ (or wherever you choose to output it to) to your web server, just like how you uploaded the sample files. If there's already an objects or libraries folder, just merge it with the new files.

If you are using FTP to upload, remember to switch your client to "binary mode."

If you have previously uploaded the modpack, you can skip re-uploading existing files.

Updating the Package Listing

The last file you need to make this work is the packages.json file. It's a list of the modpacks that the user can download, so you need to update this so the launcher knows about your new modpack.

If you're using packages.php instead (the PHP version), you can actually skip this section because the PHP file updates itself automatically.

packages.json looks something like this:

{
    "minimumVersion": 1,
    "packages": [
        {
            "name": "Your Modpack",
            "title": "Light Modpack",
            "version": "pick_a_version",
            "location": "your_modpack.json",
            "priority": 1
        }
    ]
}

If you need more than one modpack, then it looks like this:

{
    "minimumVersion": 1,
    "packages": [
        {
            "name": "Your Modpack",
            "title": "Light Modpack",
            "version": "pick_a_version",
            "location": "your_modpack.json",
            "priority": 1
        },
        {
            "name": "Other Modpack",
            "title": "Other Modpack",
            "version": "pick_a_version",
            "location": "other_modpack.json",
            "priority": 1
        }
    ]
}

Be careful about commas: you need one between entries, but you can't have a hanging one on the last entry.

Testing Properly

Run the launcher (the -all.jar in launcher/build/libs) and see if your newly created modpack works.

How to Do Modpack Updates

To do updates:

1. Build the modpack (as in run the program) the same way that you did above.
2. Upload changed files from upload/. You do not need to worry about conflicts.
3. If you are not using the automatic PHP version: change the version of the modpack in package.json.

Warning: If you use something like CloudFlare, it will cache files so your new version will not take effect. You may have to purge the cache.

Tip: For more permanent installations, you can make it all automatic by using a continuous integration server like Jenkins or TeamCity.

Multiple Modpacks

If you have multiple modpacks, you still upload everything to the same folder, merging "objects" and "libraries". Just make sure that the package listing file lists all the modpacks.

You can see this in the sample project: sample-files/upload/ contains files for both light and monster modpacks and package.json links to both.

Next Steps

At this point,

• You may want to replace all the images in launcher/src/main/resources/com/skcraft/launcher/ if you have not done so yet.
• You may want to change the name of the launcher in launcher/src/main/resources/com/skcraft/launcher/lang/Launcher.properties if you have not done so yet.

You can now release the launcher (the -all.jar in launcher/build/libs), but you may want to use the bootstrapper instead which can handle self-updating of the launcher. See Configuring-Self-Update.