Minecraft Modpack Making 102: Setting up your workspace

Installing programs and customizing them to work for you!

Before we get into the nitty-gritty of making modpacks, let’s set up some programs so we can easily edit everything we need to.

CurseForge Launcher

First, let’s get our Minecraft installation set up. Grab the CF launcher from this link. Install it and launch it, then for the game you’ll obviously want to select Minecraft.

See that gear icon in the lower left? Let’s click that and get our settings in order.

I recommend setting it to turn off both CurseForge and Overwolf. I also recommend changing your Overwolf settings via the link in the center. Turn off the startup behavior, turn off the overlay for Minecraft, and definitely turn off Overwolf notifications.

Then go to your Minecraft Specific settings, available on the tab to the left. In this page, you’ll want to set your Preferred Release to “Beta” because not all mods are set to full Release. Change the other settings to your preferences, and make sure you allocate enough RAM!

It’s best to allocate at least 4gb and up to 10gb, making sure you leave 2gb free for your OS and other computer processes. 8gb is my personal sweet spot.

Now to set up our instance. My “My Modpacks” screen looks like this, but yours may be blank:

Click the “+ Create Custom Profile” as we mentioned earlier in the series, and choose your version and modloader, name your pack (this can be changed later), and start installation.

The “Add More Content” button is what will allow you to search for mods and more. See the tabs that say “Mods (0)” “Resources(0)” and so on? You can switch to those tabs and use “Add More Content” to search CurseForge for things like Resourcepacks and Shaderpacks. It’s unlikely you’ll include Shaders and Worlds in your modpack, but maybe you will choose to do so!

To finish your instance installation, launch the modpack once using the “Play” button, and then exit out. Another important location is the “hamburger” menu (three dots) next to the “Play” button.

You’ll use the “Open Folder” option to easily access all your Minecraft installation files. You’ll use “Profile Options” to do things like change the modpack name or update Forge. “Export Profile” is how you’ll export your modpack to upload to CurseForge. And “Repair Profile” can help fix installation issues, although I have never used it.

And then your CurseForge launcher is all set up! Let’s move on to the next program.

VS Code

Visual Studio Code is available for download here. Once it’s installed, open it up.

Look at all that potential! Let’s get it set up. First, let’s make a “workspace” based on your Minecraft installation. Remember the “Open Folder” option in CurseForge? That’s the folder we’re going to set as our Workspace. Click “File > Open Folder” and navigate to your instance folder. It should be something like C:\Users\Katu\curseforge\minecraft\Instances\The Best Modpack Ever

Once that’s open, you’ll see the Explorer tab open on the left, with all your folders and files listed. Now, go to “File > Save Workspace As” and name the workspace something you’ll remember. I recommend saving this file inside your Minecraft directory so it’s easy to find. Your workspace will remember what files you had open when you last used it, so you can easily find your place between sessions by making sure you open the workspace file instead of just VS Code (although often VS Code will open to your last used workspace anyway)!

There is a LOT of functionality in VS Code, and you won’t use most of it. But here are a few handy tricks:

• Using “Edit > Find in Files” will search every file in your workspace for your keyword. This can be really helpful if you’re trying to find a config option to change “cloud height”, or want to find all references you made to “minecraft:iron_ingot” in your scripts.
• “View > Word Wrap” will make all lines longer than the viewport wrap around, so instead of having to scroll to the right to read a long line, it will simply be visible.
• When you click to view a file, you’ll see the file name in the tab is in italics. This means it’s in preview mode, and when you click on another file, it will replace that one. If you want to fully open it, double click the file and you’ll see the title tab is not italicized. Now when you click another file, it will open a separate preview-mode tab.
• When a file has unsaved changes, there will be a round dot on the title tab. Use CTRL+S liberally while you work, as that quickly saves your work without clicking anything.
• If you want to view two files at the same time, right click one of the files and choose “Split Right” (or left, or up or down, depending on where you want to view the file). This will split your viewport in half so you can view both files simultaneously! You can un-split your screen by closing all the tabs on one side. **
• You can hide the left menu bar by clicking on whatever sidebar you have open. For example, if you have the Explorer tab open, click the Explorer icon to close it.

Now you’ll notice in the above screenshot that my files are colored. That’s because I have some extensions installed. Let’s get yours set up.

The “Extensions” button is the four squares with one of them slightly separated. Click that and you’ll be brought to a screen where you can search for and add extensions. Here are the ones I recommend adding:

• Datapack Helper Plus: This extension will help autofill fields in datapacks for you!
• Even Better TOML: Many minecraft config files are .toml format, and this will provide both color highlighting and “linting” (spellcheck for code)
• JSON5 Syntax: This provides color highlighting and linting for JSON files, which are often used in config and are the file format that most datapacks use.
• Excel Viewer: This allows you to edit CSV files in VSCode. You may not need this if you’re not using Spawn Balance Utility to manage your spawns.
• Rainbow CSV: Provides color highlighting for CSV files. Much like the last extension, you may not need this one unless you’re using Spawn Balance Utility.

Now that you have all your extensions set up, you’re ready to start working! But let’s set up one more program, because version control is important.

Github Desktop

Version control is a fancy way of saying “take regular backups.” It’s incredibly important when working with any kind of code, but especially when your basis is as buggy as modded Minecraft. You never know when one innocuous change will ruin your entire setup - and version control means you can easily restore the last working backup, or simply figure out which change you made that needs to be reversed.

Git is the industry standard (free) version control software. It is incredibly powerful, versatile, and as a result, terrifyingly intimidating to beginners. So we’re going to go with the “for babies” version - Github Desktop.

You can download Github Desktop here. You don’t need an account to use it offline, but I recommend making one so that you can save your files to the cloud. Now there are two ways to set up your Github repository (“repository” or “repo” is what Github calls your project files). One is cleaner but requires more initial setup. The other is a bit faster but can be a bit less organized. Let’s quickly go over how both work:

The Clean Way:

• Make 2 new repos in your Github Desktop folder - one for mods and one for code/configs - then use symlinks to link the folders together. Requires a program called Link Shell Extension.
• Allows you to have a private repo for mod changes, and a public repo for code and config. Really helpful if you plan to use Github for issue tracking or a wiki, and if you want to track mod and config changes separately (which, trust me, makes it way easier to troubleshoot).
• This is the way I do it and the way I recommend doing it.

The Easier Way:

• Create a dummy repo, doesn’t matter in what folder. Copy the “.git” folder and “.gitattributes” file to your Minecraft instance folder, then “Add local repo” and choose your instance folder.
• Doesn’t require any additional programs, but means you have to track all changes in one repo all at once. Also, you can’t make your repo public because that would be considering “redistributing” your mods, so you can’t use Github for issue tracking or wiki purposes. Also clutters your Minecraft instance folder with git-related files.

Now that you’re a little more informed, let’s go into each in detail:

The Clean Way

First, grab the program Link Shell Extension from this link. The 64 bit version at the very top is correct. Once it’s installed, it will give you a new context option when you right click on a file or folder: “Pick Link Source.” We’ll get back to this in a moment.

Next up, make yourself two Github repos: one for code and one for mods. You do this by going into Github and choosing “File > New repository.” Name each one appropriately (or inappropriately, I’m not your mom), set the “Local Path” to your Github directory (something like C:\Users\Katu\Documents\GitHub), and Create Repository. You can ignore the description, gitignore, and license fields if you want - or fill them out if you know what you want to put there! You’ll end up with two repos, here’s what our example ones are:

C:\Users\Katu\Documents\GitHub\MyModpack - this repo should be public, as it will allow users to file issues (important for troubleshooting later on) and also allows other people to see your code and potentially help you with it!

C:\Users\Katu\Documents\GitHub\MyModpackMods - this repo should be PRIVATE, as the redistribution of mods is generally frowned upon. It's important for YOU to always have access to an updated list of your mods and what changes you've made to them, but others don't need to see it.

Now for the fun part. You’ll want to have two File Explorer windows open to make this easier; one should be your Github repo location and one should be your Minecraft directory. First we’ll do the mods repo: in your Minecraft directory, right click the “mods” folder and choose “Pick Link Source.” Tab over to your mods repo and right click in the folder, then choose “Drop as > Junction.” This will cause the folder to become a symbolic link, or symlink, which is a fancy way of saying that you can access the files inside from multiple filepaths. It sounds complicated - it’s not. Don’t worry about it. If you want, you can also symlink your /resourcepacks/ folder this way.

Your mods repo should now look something like this. Ta da! That was easy. Now let’s do your coding repo. From your Minecraft directory, do the “Pick Link Source” and “Drop as > Junction” step for the following folders:

• /config/
• /defaultconfig/
• /kubejs/
• /saves/World/serverconfig/ (this one is a little complicated, as it’s actually located in your save directory. So if you haven’t made a new world, it won’t exist. You can either create a dedicated testing world now and link it, or skip this step until you have done so.)

You’ll also want to grab your workspace file and your options.txt. You can do this by right clicking the file in your Minecraft directory and choosing “Pick Link Source” as usual, but when you go to put it in your Github directory, choose “Drop As > Hardlink.”

And you’re done!

The “Easier” Way

In Github, choose “File > New repository.” Name it whatever you want and leave it in the default folder - we won’t be using it much. Once you’ve made it, select it and at the top, choose “Repository > Show in Explorer.” In the window that opens there will be two items: a folder called “.git” and a file called “.gitattributes” - copy these, then navigate to your Minecraft directory and paste them in.

Now go back to Github Desktop and choose “File > Add Local Repository.” Navigate to your Minecraft directory and confirm. You’re done!

Committing

Tada, you’re all set up and ready to make your first commit! A commit is like a snapshot of whatever state your files are in at the time, saved in case you ever need to revert back to it. To commit your initial files, enter a summary and an optional description. These can be whatever works for you - you’ll soon find a workflow that you enjoy. I personally use the “summary” to indicate the date of the changes (if in pre-release) or the modpack version the commit is for (if post-release). In the description, I write a bullet pointed list providing an overview of the changes I made. These are more easily readable than the auto-generated git “diffs” (short for differences).

We’ll go into greater detail about Github in a later chapter. For now, let’s move on to the fun stuff - picking mods!