Minecraft Modpack Making 104: Intro to Configuration

How to configure mods using built-in tools.

So you have a mod list figured out (for now). Now it’s time to make everything behave the way you want it to. The first place you’ll want to comb through is your config files. Hopefully by now you’ve already launched your modded game and generated all the configuration files - but if not, do that now! Then, open your workspace and click the config folder in the Explorer sidebar. You’ll see a bunch of folders and files - we’re gonna go through those in this step!

Now you might think that this is a weird place to begin, but let me explain why I think going through all your configs right off the bat is a good idea. It’s all about familiarity! I can’t count how many times I’ve had someone (or myself) complain about X, Y, or Z happening, and realizing that I remembered there’s a config option to fix that issue. Having that kind of broad knowledge about your mods can make you a much better modpack maker in general.

So you want to go through all those files, one by one, and take a look at the different options they offer for configuration. If you want to make changes, do so! You’ll see in the above screenshot that I’ve set the “fruitsDropChance” to 0, because I don’t want items (which are considered entities by Minecraft) to be cluttering up the ground beneath fruit trees, and potentially contributing to lag.

Some configs will be easier to read than others, but remember that if you get stuck, a lot of mods will have help available either on the mod page, in a wiki, or through their discord. Google can sometimes help as well - users on reddit especially ask and answer a lot of questions, so googling “(your search terms) reddit” can be a good resource.

One thing to note is that some mods will use a binary system for their config options. Many will make it user-friendly and have things set to “true” or “false” - but sometimes you’ll need to input 0 or 1 instead. 0 means false/disabled and 1 means true/enabled. Unless, of course, the mod author says “Do you want to disable this feature?” in which case it’s reversed. The lesson here is to read things carefully!

Types of Config Files

Different mods will use different types of files for their configs. Common types include .json or .json5, .toml, and sometimes .config, .properties, or even .csv. All of these are openable in VS Code and you generally won’t notice too big of a difference between them. However, it’s important to get the syntax correct depending on what file you’re editing! This is why VSCode with linting extensions is so helpful, as it will tell you if you’ve used the wrong type of quotation marks, or forgotten a semicolon.

TOML

Here’s an example of a .toml file. You can see that the different colors indicate different types of data. The green lines preceded by “#” are comments - these are for the end user to read, and are invisible to the computer reading the code. The light blue words before the equals signs are the variables you’re configuring the values for. You do not want to edit these, as the mod needs them exactly as they are in order to interpret the config correctly.

After the equals sign is what you’ll be editing.

The dark blue “true/false” texts are boolean values. These can only be “true” or “false,” and they do not need quotation marks.

The light green numerical values are called “integers” (if they’re whole numbers) or “floats” (if they have a decimal)*. These values need to be numerical, and do not need quotation marks. The comments will usually tell you what the range you can use is, and what larger vs smaller numbers indicate. In many cases, you cannot add a decimal to an integer field, and you require a decimal in a float. The default value for the field will usually indicate which type it is.

Finally, you can see the orange values which are in quotation marks. These are called “strings,” and they require double quotes in .toml files. A string is a type of input made up of something that should be interpreted literally - the most common use is entity, block, or item IDs*. This is best explained by example:

The mod wants to know which entities can survive underwater. It COULD say: “Can fish survive underwater? yes/no. Can iron golems survive underwater? yes/no” and so on - but this would mean that anything the mod doesn’t specifically ask about cannot be added to the list. Strings allow the mod to ask “What can survive underwater?” and you can say: “minecraft:cod”, “minecraft:iron_golem”, “unusualfishmod:amber_goby” and so on. The string can be anything of the defined type, but you need to be sure you’re spelling it correctly, or the mod may error (or just won’t include what you want in the list).

*These are a bit of a simplification, but for now let’s just go with it.

JSON and JSON5

These files are much the same as the previous ones, except you’ll notice that comments in json5 are prefixed by “//” instead of “#.” Additionally, fields are now in quotation marks, and lists are in arrays (denoted with =[“listitem”, “listitem2”]). However, the other things remain consistent.

About Config, Defaultconfig, and Serverconfig

There are three main folders where your configs/settings will be saved. The main folder is, obviously, /config/. However, some settings apply to the server and will go into the /serverconfig/ folder, which is located within your save data - /saves/World/serverconfig/.

Now, you might be wondering, how am I supposed to ship out server configs, then? Users aren’t going to want to use my save. And that’s where /defaultconfigs/ comes in. That folder will automatically place any serverconfig files inside of it into the serverconfig folder of each newly created world. However, it will not overwrite any files which are already in a created world, so keep that in mind - when you’re changing files in defaultconfigs, that existing users will not get access to those changes unless they create a new world, or edit the files themselves. It’s a good idea to keep all changes in your /serverconfig/ folder and /defaultconfig/ folder the same at all times, so that the game performs properly on your machine, and those of your playerbase.

Testing Your Changes In-game

So, you’re not supposed to change configs while the game is open. It can cause weirdness, and sometimes results in the changes getting reverted by the game. Additionally, launching the game when config files are open can sometimes cause a crash. However, despite being a fan of good practice, I keep both the game and my configs open nearly all the time, and just deal with wonkiness when it comes up.

There are a few ways you can test your changes in the game. The first is the /reload command, which works for many server-sided changes. Then, there’s F3+T, which reloads resources and textures, and can work for client-sided changes. Finally, there’s restarting the game entirely, which is needed for changes which are implemented at startup. If you change a config, and /reload doesn’t work, you may need to fully restart the game to test it. Over time, you’ll get a feel for what changes fall into which category. A general guideline is that anything which involves enabling/disabling items, setting mob spawning, and editing the way blocks behave will all require a restart.

Configuring Game Settings

Another thing you’ll want to configure are the default settings which ship with your modpack. Maybe you include resourcepacks which you want your users to have enabled by default, or maybe you want to ensure that they have leaves set to fancy. Maybe there’s a setting which needs to be enabled or disabled in order to be compatible with a mod. And you definitely want to include your custom keybindings!

So, no big deal; we’ll just include the options.txt file with the modpack, right? Wrong! Including the options.txt will indeed ship those options to your users - every single time you update the modpack. This means that anyone who customizes the options to run on their potato computer, or a left-handed person who rebinds keys to accommodate, will need to re-do all their changes every time they update the modpack. That’s a bad user experience, and we want to avoid it at all costs. I recommend using a mod like DefaultSettings or Default Options to save all your desired changes and ship them out only to new installs. As a note: KubeJS purports to have this same function, but in my experience, it does not properly give new installations the correct options.

Also, let’s talk a little about what you might want to change.

Keybindings

It is with absolute certainty that I say you will need to customize your keybindings, because mods are complete madlads when it comes to binding things by default. I’ve had mods that bound things to the T key, which is insane because that’s the default Minecraft chat hotkey, and why would you conflict with the base game?? But rants aside, it’s also incredibly common for mods to overwrite each other’s keybindings.

My personal method for refining the keybinds is to go (in game) into the Options > Controls > Keybindings, and go through the entire list unbinding anything that I don’t think will be used commonly. You can unbind something by selecting it and pressing ESC. This process will free up keys for more commonly used keybindings, leaving users the option to bind them to the key of their choice if it becomes necessary.

Now you can use the “toggle free” button to see which keys do not currently have anything bound to them. These will largely be punctuation keys or number pad keys. I recommend not using numpad keys, as many people have a keyboard without a numpad at all. But make a note of the keys which are not currently bound.

You can now use these free keys to rebind things which conflict. There’s some nuance here, though - not everything that conflicts needs to be rebound. For example, in JEI and inventories you can hit “r” to see recipes and “u” to see uses, and “a” to bookmark. However, outside of the inventory menu, all of those keys can be used for something else (well, except “a” because that is already used). If you’re not sure whether a conflict needs rebinding, test it out!

Now if you absolutely have too many features which need keybinds, may I recommend the mod MineMenu. It introduces a radial wheel, which the modpack maker can customize with a bunch of different keybindings. You can configure whether opening the radial requires you to hold a key or if it’s a toggle, and you can assign 10 different keybinds to the radial. Be aware that not every keybind is a good candidate for the radial wheel. Some simply do not work (for example, “Call Luggage” from the Luggage mod does not), and anything that requires a quick response (such as using a modded ability) or holding down the keybind (such as for Ultimine/Vein mining) will be frustrating to use in that context. But many others will be just fine, and ultimately it’s up to you to decide whether the mod is worth adding, for you.

Options

In general, users will set their options to the values they personally like, and which work on their machines. However, I like to set these up initially to values which I recommend, in case the user doesn’t edit them. For the most part I aim for high performance: I set chunk render distance to 8, and turn off mipmaps, for example. But some choices are just opinionated: I set the gui scale to 2, and turn off view bobbing.

Resource Packs

If you want to include resource packs with your modpack, I highly recommend using the mod Resource Pack Overrides. It will allow you to define which resourcepacks are enabled by default. In my experience, neither DefaultSettings, Default Options, nor KubeJS will properly enable resourcepacks for new users. It’s frustrating, but what can you do. Please note that Resource Pack Overrides will not apply to existing installations. If you add more resource packs later in development, make sure to mention it in the patch notes to ensure that users will know to enable them manually!

More Configuratin’

That’s all for this chapter on how to configure your modpack. In the next chapter, we’ll address compatibility through datapacks and scripts!