Sidebar

Table of Contents

There are a lot of things you can do to make your life easier as a server admin. I'll try to gather some of them on this page as they come up. Now, in no particular order, here is some random advice :)

Test First

Always make sure your changes are going to work before you foist them off on your players. I personally use MultiMC to iterate on client changes (and id conflict resolution) until I'm comfortable adding a new mod to the mix. Then I set up a local server and update a local copy of the serverpack.xml - loaded from a different place than the players download their live configs. This way I can test updating and connecting several times before I upload the changes to the production environment.

When a patch is ready, I will usually warn active players in chat and upload the new serverpack. While they log out to apply the patch, I upload the updated mods & configs to the server itself, save, and shut it down. Then I take a backup of the world before upgrading the server's mods and rebooting. By then, my players have probably finished updating as well and are ready to get back to it - and I am reliably confident that nothing is going to break for them :)

Validate your XML

A corollary to this is making sure your XML is well-formed. There's nothing so obnoxious as a missing / somewhere that a good XML editor (or at least one with good syntax highlighting). Save yourself a few headaches, and let the computer validate things for you wherever possible.

Use MD5's

Always always provide an MD5 checksum for any mods or configfiles you reference. This will save tons of downloading time on the part of your players - and can change a 5 minute update into a 30 second update. Any file that matches its provided MD5 after being downloaded will be cached - then the next time an update runs, the locally cached version of the file will just be used instead.

The things to remember when using MD5's:

The checksum is for the file itself, and not its URL (duh, I know - but we've seen this problem before, sometimes people aren't thinking).

Always update the MD5 when you update the underlying file. If an old version is cached, the client will use that instead of downloading the new file until the MD5 changes in the serverpack.

Optional mods

If you specify <Required>false</Required> in a module definition, the player will not be required to download it to play on your server. When working with optional mods, you can set <IsDefault>true</IsDefault> to tick the checkbox by default - requiring players to opt out rather than opt in to the mod.

This is good for things like a minimap mod or optifine or something that may or may not be of universal interest - but is the kind of thing you can assume people will want. Personally, I flag everything that isn't actually required to log in to the server as optional just in case someone needs to remove it for one reason or another.

Ask For Help

If you have a question or problem setting things up that these docs don't answer, feel free to ask. We hang out in #MCUpdater on esper.net and are usually willing to help people figure out problems if we're no busy with family or work or something. While we won't just build your serverpack for you, we can probably look at what you've come up with yourself to help you figure out why it isn't working.

Server Revisions

The revision attribute on server definitions is a way for you to identify different builds of your serverpack. Every time you change a config file or module, you should increment the revision somehow. Revisions don't need to be integers - or even numerical for that matter but I recommend you stick with something sane and obvious.

On my server, the current serverpack revision is 0.3.1.8. The previous revision players saw was 0.3.1.7, but the rev before that was 0.2.6. The update to 0.3.0 (MC 1.4.6 from 1.4.5) did not go smoothly and I had to update to 0.3.1 almost immediately. Then, I had to iterate a bunch on config files and minor tweaks as the bugfixes trickled out in the wake of the MC 1.4.6 release. My next planned version is 0.3.2, unless something big happens, then I might jump to 0.4.0. The individual numbers don't matter to MCU - just as long as they change every time a new update goes out to the players. I use this sort of numbering scheme to help myself keep track of changes.

Lazy Serverpacks

Not that I officially recommend this method - especially not in the long run - but it is an option for cases where you want to get up and running as quickly as possible.

Simply bundle as many mods and configs as possible into a big fat zip file ala a typical modpack. Then define it all as a single Module. Once your players are using MCU and are playing on the server, start moving mods out of the zip and into their own directives for better update support.

Another slightly less lazy way of doing this is by packaging a mod's configs together with it in a single zip.

Modless Modules

Sometimes you want to deliver something to the players that isn't actually a mod, like a texturepack or something. If the thing you're delivering is multiple files, you can always just zip it up and tell the serverpack to extract it to the root.

Another way to manage this is by providing an empty file as the “module” and specifying the not-mod file as a config. You can repeat the process multiple times by using the same empty file (and its associated md5) for all of the config files you are delivering in this way. This is how I provide easy download links for texturepacks.

Use a Batch File

Sometimes Windows doesn't like running jars directly - and it certainly doesn't like running them as an admin user. The easiest way to get around this restriction is by using a simple batchfile like this: