What we’re going to do is enter the folder where the mods exist for our pack. Then go up a folder and make a few temporary folders. Note this whole process is actually easier to do from the command line as shown in the video. I like to make the following folders: 1, 2, 3, 4, and good.

Firstly though, we need to identify all the dependency mods—I call them library mods because they contain a library of code to make other mods work. I got used to saying “library” during my Amiga Computer phase from 1987 through 2006, and also when I got involved in Windows from 1992 to now. As you can see, I use some powerful mass renaming mechanisms in the Linux CLI to rename them quickly. You can do the same thing with Windows apps, and if you’re a DOS or PowerShell guru. Or you can install Windows Subsystem for Linux and then a distro like Ubuntu, all available on the Windows Store, and then you can follow right along with me—no problem at all.

The purpose of renaming the files is so that I can move them around easily and not move those that shouldn’t be moved. So the library files are either identified with 00_ or LIB_; they’ll remain in the mods folder. But for now, we can move them to the “good” folder, even though we don’t know if they are good or not.

Now split your remaining mods into 4 groups. I recommend grabbing them from the end to keep it straight in your mind. Move each quarter batch to one of the numbered folders. Then, in each folder, rename the batch of files to be prefixed by the folder name. In Linux, this is rather easy:

# Bash script
prefix=$(basename "$PWD")
for f in *.jar; do
    mv "$f" "${prefix}_$f"
done

# PowerShell script
$prefix = Split-Path -Leaf (Get-Location)
Get-ChildItem *.jar | ForEach-Object {
    Rename-Item $_ -NewName ("{0}_{1}" -f $prefix, $_.Name)
}

For example, I just renamed a bunch of archives in my working folder for developing server packs.

With all of our batches prepared, we need to get around to testing. So move all the files in “good”—i.e., our library files, the dependencies—to the “mods” folder.

Then start the pack up. Make sure your console stays open so you can find the problem mod. If anything should crash the pack launch, it will probably be an unspecified dependency mod. Simply get it from the other folders, rename it accordingly, and restart. It has been my experience that dependency mods typically don’t cause packs to misbehave—that’s not a guarantee though.

If you’re lucky, the libraries test will fail, which would indicate the rest of the mods are probably all good. Since we wouldn’t have a place to put them, we could make another folder called “temp” and move them there. That way, we could split the libraries into 4 batches and get around to finding which one is causing the problem.

Needs to be said: If you have a server pack that needs testing, you will need to do this in tandem for both the client and the server. This can get very tedious very fast. Such is the life of a pack developer.

For obvious reasons: Keep your eye on what you’re after; doing this splitting method can cause you to think you have other errors when you don’t.

Let’s assume that all the libraries (dependencies) were good. You wouldn’t move these to “good”; you need them for the other batches to even run. So leave them in the “mods” folder.

Now grab batch one and move its files to the “mods” folder. Start the pack, see if it gives the problem in that one special way that you’re trying to isolate. If it doesn’t have the problem, you can stop the pack and move those files from “batch 1” to the “good” folder.

Repeat for each of the batches.

If during a batch test you find the issue that you’re tracking, that’s the batch you will need to split. You can put half of its mods in one of the empty batch folders (1, 2, 3, 4) and leave half in the mods folder.

Run the pack again. Test for your issue. If it doesn’t show up, move this half to the “good” folder. Now test the other half; it should trip out. So split again.

Repeat. By now, you should realize what is going on.

Eventually, you will have just one mod in the “mods” folder that causes the problem you were trying to isolate. In essence, you have isolated it. And all of your existing mods that were good are in the “good” folder where you were moving them.