Active Disclaimer: This is a copy & paste from ShneekyTheLost's blog for archive purposes; it has not yet been edited for formatting/clarity.

Right, so this guide is written specifically for those individuals who have a mod pack on the ATLauncher and are wanting some tips on how to go about setting everything up.It can be a bit confusing, particularly to someone who has no prior XML experience, but I think we can get through this fairly painlessly.

I will be assuming for this guide that you are already set up with an account on the ATLauncher Admin site. Please contact RyanTheAllmighty for any questions or concerns on that front.

Now then, logging in will bring you to the Dashboard page. Once you get your mod pack setup and online, it will be able to tell you some metrics about your mod pack. Things like how many people have downloaded or played your mod pack in the past 24 hours, how many hours they have played on it, that sort of stuff. It’ll be in a little green oval over the overall ATLauncher numbers once you get your mod pack ‘live’. So, for right now, it’s really not that important to you. On the left is a menu with ‘Packs’ and ‘Forge Libraries’ as options. Let’s go over that right now.

If your pack is for 1.5.2 or prior, you don’t need to touch the ‘Forge Libraries’ button at all. For 1.6.x and going forward, you will eventually, but not right now. For now, let’s click on ‘packs’.

Now then, you should be seeing the name of your pack, as well as some buttons under the ‘manage’ heading. If you don’t, contact RyanTheAllmighty for support. These buttons are ‘Files’, ‘Settings’ ‘Versions’ and ‘Stats’. We’ll be primarily concerned with the first three.

Getting your pack set up

So, let’s start by clicking on ‘Settings’. You’ve got some options you can toggle, which you can play around with to suit your tastes, but more importantly are the next few sections.

The ‘Description’ area lets you type in your text blurb that players are going to see when they click on your pack in the ATLauncher GUI. Make it short, sweet, and to the point. Check out some of the Descriptions for other mod packs for ideas. Basically, give them a ‘mission statement’, the purpose for the pack’s existence, and what makes this pack unique among the other packs out there.

The Image will be the picture which the players will see in the ATLauncher’s GUI when they click on your mod pack. Pull up the ATLauncher and look at some of the other packs to give you some ideas. Mind the very strict size restriction.

These two features are your ‘front door’ or ‘splash page’. This is what players will encounter when they first see your mod pack in the GUI, so make sure you leave a good first impression.

Next are going to be ‘testers’. These are the people who have access to the ‘dev’ versions of your mod pack. I’d go ahead and include you in that, plus if you have any beta testers, them as well. I cannot begin to tell you how insanely useful it is to have a beta tester or two, particularly if they are running a different OS. Sometimes what can cause a crash on one system will run just fine on another, and you won’t catch it until players complain. However, the truism in Customer Service is that only 10% of all customers will bother to complain, the rest will simply walk away. So take player feedback and bug reports very seriously if you want your pack to thrive. That’s one of the huge strengths of the ATLauncher, you can push updates within minutes of receiving a bug report. Take advantage of it!

Now save your Description and Testers list, and head back to the ‘Packs’ page. Time to dive into the guts and get this mod pack rolling.

That’s how we code here on the ATLauncher, dawg

Okay, now it’s time to get down to some brass tacks. Let’s click on Versions.

Here’s where the magic happens, folks. All of your XML coding is done here. Your rolling changelog is also here. You can update this and users can view it from the ATLauncher website. This is a good communication tool to convey what has changed with your mod pack between versions.

So, before we start adding in mods, we’re going to need to start the coding off properly. Now it’s time to introduce you to some XML concepts.

The first concept I’m going to introduce you to are ‘paired tags’. You know how in BBCode if you want to bold something, you have to use B in brackets, then end it with a /B in brackets? It’s the same concept here, only we use < and > signs to contain them rather than brackets.

The second concept I want to introduce you to is commenting. Commenting looks like this:

<!– this is a comment! –>

<!– Everything here is also a comment

It keeps going until it sees the closing –>

Comments are not processed by the XML, it is used to leave notes for yourself, and to help you organize your code. When you have like 80+ mods in a mod pack, it can get VERY easy to get disorganized, and it’ll then take you FOREVER to find the lines you are looking for.

Indentation, likewise, is also extremely important. Think of a numbered list, and one of the items on the numbered list has another list. The numbered list is indented, and the second list is further indented. It’s the same concept with coding. Every time you work ‘within’ a paired tag, you’ll want to indent to keep everything straight and make sure you don’t miss a close-tag. Because if you miss a close-tag, then Cuthulu rises from the deep and destroys the world. Or at least it’ll yell at you and not allow you to save, which pretty much amounts to the same thing when you’re trying to write code.

The first paired tags are going to be ‘version’. This means that <version> is going to be the very first line in your code, and </version> is going to be the very last line of your code. Always. If it isn’t, then you will fail horribly, and the entire universe will pause for the expressed purpose of pointing and laughing at you. Or so it will seem when you try to save the code.

The next set of tags you will be using will be the ‘pack’ tags. Within those tags you will want several lines that are going to be absolutely required, however here’s where we’re going to have to take a split, because which lines of code you need next will depend on which version of minecraft your mod pack is designed for.

For packs running 1.5.2 or previous:

  • Version. This is going to be what version of your mod pack you are working on. It can accept alphanumeric codes. Most developers have their own way of numbering their mod pack versions.
  • Minecraft. This is going to be what version of minecraft you are running on
  • extraarguments (optional). Extra java arguments for running minecraft.

However, for packs running 1.6.x or later:

  • version. As before
  • minecraft. as before

But now we're going to need to open up a new tab and pull up the ATLauncher admin page on a fresh tab, we’re going to be doing some copypasting.

Click on the ‘Forge Libraries’ tab. Put in the full version number for the minecraft version you are using and the forge version you are using. So, running on the final recommended version of Forge for 1.6.2, it would be:

Minecraft: 1.6.2


If you are lucky, and Forge’s website isn’t being overloaded, you’ll get a whole lot of code. We’re going to copypasta into your xml window, then do some editing.

You’ll notice it has a mainclass and extraarguments lines in it. After those, you’ll want to close that ‘pack’ tag.

Then it’ll have a bunch of library code. This should probably just be left alone unless you know what you are doing.

Now we’ve set up the infrastructure code for the mod pack! Save the code. If it gives you an error message, check the line it is complaining about. Odds are you forgot to close a tag somewhere.

So now you’ve got your version tags, your pack tags, and if you are running 1.6.x+, the libraries tags. Next up is going to be the mods tags.

PROTIP - You can upload all of the library files to your admin side, just like any other mod file, and point the code to the files server-side. This prevents any shennanigans with Forge's site either being down or being overwhelmed causing problems for new users.

Before we begin the next section, a word from our Sponsors

Okay, before I start talking about the mods section, I want to make one thing absolutely crystal clear:


To protect yourself from accusations, you WILL want to have copies of every single mod’s permission to distribute available. My personal suggestion is to screenshot, crop, then save in an imgur account, creating an album for the permissions. That way, if anyone tries to tell you that they are distributing a mod without your permission, you can link the album and prove otherwise immediately. This is basic CYA here. I cannot strongly recommend hard enough to do so BEFORE you upload your first mod.

Failure to follow these precautions will leave you vulnerable to being marked as the biggest douchebag the modding community has ever seen since Technic got bee-bombed by Sengir for not getting his permission before adding Forestry into their pack. You will never be able to be respected after that, you might as well quit the modded minecraft community because your infamy will outlast time itself.

Serious as a heart attack, people. This will get your mod pack pulled immediately, and can quite easily ruin your reputation permanently. Do not pass Go, do not collect $200. Screw this up at your own risk. You have been warned.

And now, for the boring copypasta part

Right, so first we’ll go over what we do with mods that you DO have said permission to distribute. Then we’ll go over what we do with the ones we don’t have permission to distribute ourselves.

The mods section of your code can be arranged however you like. Some people like to arrange by non-optional and optional, some like to arrange by permission to distribute and no permission to distribute. Some people like to sort by filetype. Whatever you choose to do, I’d suggest using comments to break up the sections, because otherwise it can be a nightmare finding the precise mod you are looking for.

Every mod code follows the same basic layout There are the required tags and the optional tags.

Right now, you should probably switch to the tab you pulled up the forge libraries on (or, for a 1.5.2 pack, pull up a new tab and get to the admin page) and hit the ‘files’ button on the ‘packs’ tab. Either way, you should have a tab with the ‘files’ button and a tab with the ‘version’ button up. You’ll be doing a lot of switching back and forth and copy/pasting between them.

Now then, first I want to share with you a brief tip on how to keep your pack organized. I’d strongly suggest that if you plan on keeping your pack up to date on later versions of Minecraft, and you want to support previous versions of minecraft (which can be a good idea, not everyone likes going to the next version of minecraft. Most of my users currently are on the 1.5.2 version rather than the 1.6.2 version), you will want to keep your files segregated so you don’t accidentally delete a necessary file. For this purpose, create a folder. I like to name the folder whatever version of minecraft that version of the mod pack will be supporting, since that tends to be the most common dividing line. Basically, any version you are going to continue supporting after you start developing a new branch should have their own folder. You will never want to put any actual files in the ‘root’ folder.

Now that you’ve made the folder, open it up. It didn’t look like anything changed, but believe me, it did.

Okay, let’s add our first mod. Let’s make it Forge, since it has some unique characteristics about it. Now, Forge has a blanket permission to distribute, so no worries uploading it. So, select ‘single upload’, browse to the version of Forge you will be using, and upload it! Now, when it is done uploading, you’ll see a pop-up window with code. Remember how I told you that you’d be doing a lot of copying and pasting? Yea, that’s what you’ll be working with. But before we do that, click back over to your tab with the xml coding up.

You’re going to want to make the <mods> </mods> tags after ‘libraries’ but before </version>. Then we’re going to use the <mod />tag. Unlike the other tags you’ve played with so far, the <mod /> tag carries all the information within the tag itself, which is why it has a /> at the end. There’s going to be several pieces of information contained within this, and you’ll need to do this for every single mod in your mod pack.

First is the name=”modname” part, which basically tells it which mod you are talking about.

Then we have version=”version number”. This is the version of the mod you are using (i.e. ’′ for the version of Forge used in the prior example).

Then we have type=”forge”. This is unique to Forge itself, nearly every other mod you will be including will be type=”mods” (or coremods for versions prior to 1.6.x).

Next is going to be website=”the mods website dot com”. We need to support the mod authors and give credit where credit is due. Either link their website, if they have one, or the minecraft forum post, or wherever they have their mod posted.

Along the same vein is donation=”link to donate button”. After all, we do want to support our mod authors, if someone wants to donate to a mod author, it is only polite to provide a finely crafted link to facilitate this.

Next is description=”a brief and clever description of the mod”. This is what the user will get when they look at the mod list on your mod pack’s web page. Make it brief and descriptive.

NOW we go back to that other tab, then copypasta the contents into the tag. This will include the URL of the mod itself (which will probably look like: packs/YourPackHere/files/FolderName/ModFileName for mods you have permission to upload), the actual file name for the mod, a line called download=”server” and the md5 hashtag.

Without getting into technical details, md5 hashtags make sure that your file is properly downloaded without corruption. It’s not like you have to do anything special to get it, so include it. The download=”server” means you’ve uploaded it to your files, so that’s where it should look for the URL.

Now close the tag with />

So you should have something like this:

<mod name=”Forge”









description=”The API needed for your mods to run”/>

Now save it. Then repeat this process for every single mod you have permission to upload.

There’s a couple more tags that can be used that we should probably go over.

optional=”yes” is used if you want your users to have the option to use that mod in your mod pack, but don’t want to force them to do so. In other words, you are letting them know you officially support this mod, and you’ve got a config file for it, but you aren’t going to make them go into the instance folder and manually remove it if they don’t want to use it. Some mods have varying results depending on the computer specs. Optifine is notorious for this, some computers it can help tremendously but others it just crashes horribly. Also, Optifine is one of those mods you shouldn’t be uploading. We’ll get to those in a second.

server=”no” is used if the mod is a client-side mod only and doesn’t need to be loaded onto the server (for mods such as REI’s Minimap).

depends=”OtherMod” is used to set dependencies. For example, if you have Forestry Plugins, it requires Forestry to be installed, otherwise it’ll crash trying and being unable to find Forestry. Use the exact name used in the name=”ModName” tag for the relevant mod.

How to allow your users to enjoy mods with restrictive permissions without being a douchebag

ATLauncher has a very unique feature which is absolutely amazing. It lets you incorporate mods into your mod pack that you don’t actually have permission to distribute. Instead, it will open up the download page for the mod in question and request that the user download it themselves and put it in the ATLauncher/downloads folder, then click ‘okay’ to continue. It will then check to be certain that the mod is actually IN the downloads folder, if it isn’t, it will pop up the window again. It will also do this if you are linking the wrong version of the mod, so make sure you have your links correct or the user will get stuck in an infinite download loop.

This starts off just like any other mod entry, down to where you would normally copypasta the information. Clearly, you can’t do that here, because you didn’t upload it.

download=”browser” tells the ATLauncher that this is a mod the user is going to have to manually download.

file=”File To Be Downloaded”. Make sure you have it EXACTLY right or it will cause infinite loops.

url=”the link to the download for the mod”. It has to point to the right link or you get infinite loops.

md5=”hashtag” is going to be a little trickier, unfortunately. It is technically able to be skipped, but you can also google for how to generate MD5 sums.

Now keep doing this for every mod you don’t have permission to distribute.

I’d also save after every mod entered just to be sure I didn’t screw anything up. After all, even Jesus saves.

Publishing and Updating your mod pack

Okay, assuming everything saves properly, you’ve got a couple more things to do before you publish.

First off, there’s a cute little button between the changelog and the xml coding we skipped earlier, we need to use it real quick. Basically, you take a zip of the config folder you’ve created for your mod pack, and upload it there. This is going to be the config folder which will be dropped into the user’s instance/minecraft/config folder. If you need to change it, you’ll need to change the files, re-zip, and re-upload.

Second off, you’re going to want to beta-test the dev version before you publish it. After all, you don’t want give new users something that crashes, now do you? This is something you and your Testers will be able to accomplish now. Go into the ATLauncher, click on your mod pack (feel proud that you’ve actually got a mod pack up on the launcher now!), and start playtesting and bug-hunting. I’d also empty out your ATLauncher/downloads folder before running just to be sure you don’t have any ‘download this mod manually’ infinite loops, those things are annoying.

Once you are certain that your pack is stable, THEN you go to your Packs tab, click ‘versions’, then click ‘Publish’.

Bask in your triumph! You have done it! You’ve got a mod pack LIVE up on ATLauncher! Rejoice! Bring up your MP3 player and play some suitably epic music while you strike a triumphant pose. Crack open a cold one. Sit back and relax.

Then one of several things is going to happen. Most likely, you’re going to get a bug report. NO ONE can catch every little bug or glitch in a mod pack, it’s just not humanly possible. Even the best testers aren’t going to catch everything. Also possible is that one of the mods in your mod pack just updated and it has some amazing feature that simply has to be included!

Well, have no fear, this is the easy part. First, open up your dev version, then change the version of your mod pack. This is important, without this step, it will pitch a fit when you try to save, because that version of your mod pack is already live, your dev version can’t be the same version! Then apply the changes as necessary, save, and publish. If you are uploading a new file, then upload, copypasta the data over the old data, change the information relevant to that mod to match the new stuff. Go test it to make sure that your fix actually DID fix the problem. If it did, then publish your new version. BAM! Just like that, you’ve just solved a crisis! It just makes you want to lean back in an executive office smoking a Cuban cigar with ‘Hail to the Chief’ playing in the background.

Of course, finding the causes for bugs can sometimes be a frustrating and irritating process. I would strongly suggest having at least one person willing to be a beta tester who has access to the dev version to playtest. But ALWAYS test your new version BEFORE Publishing. Trust me, nothing is more embarrassing than to accidentally break your mod pack, and have to apologize to your user-base and quickly fix what you just broke. At least if you broke something on the dev version, it doesn’t get out in public. It makes you seem a whole lot smarter and more professional.

In Conclusion (finally)

Yes, it is more difficult to make and push public a mod pack on the ATLauncher than on the two other primary launchers (FTB and Tekkit). However, I feel that the advantages significantly outweigh the disadvantages. It isn’t really all that hard to do, although it can be tedious mind-numbingly boring copypasta for every single mod. But the ability to push instant updates is just amazing, and once you have your mod pack running, maintaining and updating it is a snap!

admin_assistance_guide.txt · Last modified: 2019/06/08 05:49 (external edit)
CC Attribution-Share Alike 4.0 International
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0