User Tools

Site Tools





The heart of MCUpdater's functionality is the ServerPack.xml file (though it can be named whatever you want).

This file provides the information that MCUpdater needs to install and configure the user's Minecraft client to work with your server.

We link a functional example serverpack by default in all MCU builds as of late 2.2-dev. You can use this as a starting point for your own, or as more detailed reference than the example below.

A tool to generate the file is available here: Documentation for this tool can be found here: Otherwise, you can use your favorite XML editor with XSD support to edit the file. If you don't have one, I'd recommend Notepad++ with the XML Tools plugin.

Pre-MCUpdater 3.0

The XSD can be downloaded here.

<?xml version="1.0" encoding="UTF-8"?>
<ServerPack version="2.2"> <!-- The minimum version of MCUpdater required -->
    name="Your server's friendly name"
     <Module name="Sample Mod" id="sample" depends="" side="CLIENT"> <!-- side can be CLIENT, SERVER, or BOTH (default BOTH) -->
        <ModPath>mods/</ModPath> <!-- Optional to specify the path and filename.  Otherwise, will be saved as mods/#id#.jar or coremods/#id#.jar depending on the CoreMod element setting -->
        <JarOrder>0</JarOrder> <!-- Should be unique per mod with InJar set to true. Defines the order it is added to the jar. -->
        <IsDefault>true</IsDefault> <!-- Set to true if you are recommending that the client install this mod -->
        <Extract>false</Extract> <!-- This is used if the mod file needs to be extracted to the mods folder -->
        <InRoot>false</InRoot> <!-- If this needs to be extracted to the .minecraft folder, set this to true as well -->
        <CoreMod>false</CoreMod> <!-- If this mod goes in coremods (MC 1.3.x and later), set this to true -->
        <MD5></MD5> <!-- Optional, MD5 checksum of the file downloaded from URL above; will be used to avoid redundant redownloads -->
        <ConfigFile> <!-- Sample of a configuration file -->
           <NoOverwrite>true</NoOverwrite> <!-- Do not overwrite existing (new in 2.5) -->
        <ConfigFile> <!-- Sample of using ConfigFile elements for sub-modules -->
           <MD5></MD5> <!-- As above, but for the config file instead -->
        <!-- Any number of additional ConfigFile elements -->
     <!-- Any number of additional Module elements -->
  <!-- Any number of additional Server elements -->

MCUpdater 3.0

As of MCUpdater 3.0, the ServerPack format has been significantly modified. The new XSD can be downloaded here.

<ServerPack version="3.0">

A server pack file can contain multiple server definitions using the <Server> element which has the following attributes:

  • id - Specifies a unique identifier for the instance (should not contain spaces and is used for the path to the instance)
  • name - Specifies the name of the instance as shown to the user.
  • newsUrl - URL to the news page to be shown when the user selects the instance
  • iconUrl - URL to an icon to be displayed in the instance list (if omitted, a generic icon will be used)
  • version - The Minecraft version to be used for this instance
  • serverAddress - The hostname or IP address of the server this instance connects to
  • revision - An identifier to indicate when the pack has changed
  • generateList - create the servers.dat file for the in-game server list
  • autoConnect - automatically connect the player to the server when Minecraft is launched
  • mainClass - The class name to be used for launching Minecraft. THIS MUST BE SPECIFIED FOR FORGE TO LOAD AFTER 1.6 (This is typically set to net.minecraft.launchwrapper.Launch)
  • abstract - Causes this server definition to not appear in the instance list (this is best used with the <Import> element.
  • launcherType - Specifies which launcher style to use (default is to use to 1.6+ launch style), specify “Legacy” to use the old launcher style (often needed for pre-1.6 modded instances).
  • libOverrides - Space separated list of Maven-formatted libraries to override the versions specified by Mojang.

Within the <Server> element, you can have any number of <Import> and <Module> elements.


This element has one attribute, url, which identifies a remote server pack to import from. If you are importing from the current server pack, this is not needed. The text portion of this element indicates the id of the <Server> to import. The import functionality will correctly load older format server pack files.



  • id - A unique identifier. Recommended to be meaningful as it is used for naming the file downloaded.
  • name - The name displayed in the module list.
  • depends - A space separated list of module IDs that this module requires.
  • side - Indicates whether the module is valid on the CLIENT, the SERVER, or BOTH


  • URL - Where to download the file from. Has a priority attribute to indicate the order to try them in. May appear multiple times per <Module>
  • ModPath - The full relative path for the downloaded file (i.e. mods/foo.jar). If omitted, the file will be named based on the id and ModType.
  • Required - Boolean value indicating whether the mod is required. Has a boolean attribute of isDefault that will be used if Required is false.
  • ModType - Signifies what type of mod entry this is. Has universal attributes launchArgs (for command-line options to be passed to Minecraft) and jreArgs (for Java parameters)
    • Regular - File goes in mods folder and will be named with a .jar extension
    • Library - File goes in libs folder and will be named with a .jar extension. Anything with this will be added to the classpath at launch, prior to any mod loading mechanics. Attribute order controls the order in which the libraries will be loaded.
    • Coremod - File goes in coremods folder and will be named with a .jar extension.
    • Jar - File will be injected into the minecraft.jar. Attributes order and keepMeta control the order in which the files are added to the jar and whether the META-INF will be copied to the jar.
    • Extract - File will be extracted into mods folder (unless attribute inRoot=“true” is specified).
    • Litemod - File goes in mods folder and will be named with a .litemod extension
    • Removal - Mod will be removed from list (used if a mod that is imported using <Import> is not wanted)
    • Override - Existing mod in the list will be updated with any tags specified in this entry.
  • MD5 - The MD5 checksum of the file to be checked against for updates. If omitted, file will not be downloaded if already present.
  • Meta - An encapsulating tag for any metadata about the mod (authors, credits, description, etc.) This can be used with XSLT to render the XML in a web browser in an easily read format that includes the data present here.
  • ConfigFile - Additional files that are linked to this mod can be listed here. Can appear multiple times.
    • URL - The download URL of the config file.
    • Path - The relative path to download as (i.e. config/foo.cfg)
    • NoOverwrite - Boolean of whether the file should be overwritten (this should be true for any user configurable files)
    • MD5 - The MD5 checksum of the file.
  • Submodule - Additional mods that will be installed if the parent mod is selected. Can appear multiple times. Format is the same as <Module> but cannot contain <ConfigFile> or <Submodule> entries itself.

MCUpdater behavior

The XML files for every defined server are re-downloaded every time MCUpdater launches. If the 'revision' attribute is different from the previous launch, then the user will be prompted to update their mods. If Modules or ConfigFiles contain MD5 nodes, the MD5 checksums will be considered when deciding which files to re-download - any mod or config that does not have MD5's specified will always be re-downloaded.

The MCUpdater jar contains a file that tells it where to download its initial xml file from. Additional server definition XML URL's may be entered in from the menu once MCUpdater is running. If no serverpack address is defined in the properties file, the user may be prompted to enter a url when they launch MCU for the first time.


Starting with late 1.35 builds, the serverpack enforces a minimum version of MCUpdater and warns players using too-old jars. However, any newer version should always be compatible. Thus, when MCU is in version 3.0, it should still be able to read and take advantage of a serverpack that requires 1.37.

Directives may be deprecated (that is formally discouraged from further use), but they will likely not be removed unless their continued existence proves to be a problem. In that case, the period of deprecation before removal will be as long as possible.

There are several planned features that will add new options to the serverpack format. The current proposals live on the wiki here at XML Format Updates.

serverpack.txt · Last modified: 2014/12/02 10:19 by smbarbour