There comes a point in many pack development cycles that the odd error happens that must be fixed, but none of the crash-reports or log files indicate with any certainty which mod is causing the problem. That’s where the HALVES METHOD also known as THE BINARY SEARCH METHOD comes into play. I’ve made a video demonstrating how to do this. Watch it while I articulate in words what you must do.
Before you start I recommend you zip your pack folder for safety reasons. Like a big oops event.
-
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 tho we need to identify all the dependency mods, I call them library mods because they’re mods that contain a library of code to make other mods work. I got used to saying “library” during my Amiga Computer phase from 1987 thru 2006, and also when I got involved in Windows from 1992 to now. As you can see I use some powerful mass renaming mechanism in Linux cli to rename them quickly, you can do same thing with Windows apps and if your dos or powershell god. 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 tho we don’t if they are good or not.
Now split your remaining mods into 4 groups. I recommend grabbing them from the end to keep in straight in your mind. And 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:
prefix=$(basename "$PWD");for f in *.jar;do mv "$f" "${prefix}_$f";done
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 and 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 tho.
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 the 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 your 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 they are in the “good” folder where you were moving them.