---
layout: blog
title: 💻 Your Minecraft Modding Questions, Answered
description: I asked yall to send me your modding and programming questions on Twitter and Discord, and in this post, I try to answer all of those.
tags: [Minecraft, Featured]
discuss: https://twitter.com/Ellpeck/status/1373660751060160512
---

Hi, I'm Ellpeck. I'm the creator of a bunch of Minecraft mods, including Actually Additions, Nature's Aura and Pretty Pipes. A while ago, I also started taking [commissions](https://ellpeck.de/commissions), so the list of Minecraft mods I've created is slowly, but surely, growing.

I asked all of you on Twitter and in [my Discord server](https://ellpeck.de/discord) if there are any modding and programming-related questions you'd like me to answer. Since most of the questions yall ended up asking were related to Minecraft modding, I thought I'd make the post exclusively about that after all. It also means that you might find this post interesting even if you don't program or make Minecraft mods yourself, because the questions ended up being pretty general.

Here goes.

# How do you keep yourself interested
> ...in an idea or project, so you won't abandon it after two days of enjoying it? (canitzp)

Hahaaa. I really wish I had an answer for that. I have *countless* abandoned projects, as do most people that work in creative fields in some capacity. I recently made most of them public on my [GitHub](https://github.com/ellpeck), so if you go there and scroll back far enough, you'll find some old games and unfinished mods.

So how *do* I keep myself interested? After all, I've made and finished a bunch of stuff. Since I suffer pretty massively from depression and anxiety, it's especially hard for me to commit and pull through on anything, really. However, there's a huge thing I've learned: If you start losing motivation for something, *don't* try to fight it. If you do, you'll just force yourself to work on the project without actually being interested, causing you to burn out with it even more. Instead, accept that you're losing interest and move on to something else. While the first strategy has lead me to abandon projects entirely several times, the latter only caused me to take fairly long breaks, but so far, I've always returned to projects that I didn't try to push myself to work on.

# Good tips before diving into modded Minecraft?
> (Afkman57)

I'm not sure if you mean *playing* modded Minecraft or *creating* mods, so I'll just answer the question for both!

Before diving into *playing*, I think it's really important to know what you're getting yourself into, because expectations can pretty drastically change your experience of things. (Most) Minecraft mods are *not* commercial products, and they *don't* have quality control. Authors don't get paid for creating mods, and they don't *owe* you anything just because you downloaded their mods. I think this is very important to realize because I've interacted with so many people before that think if you download a mod, it's like you're buying a product with the promise of life-long support. If something breaks in a certain way, or something works in a way that you dislike, but the mod's author doesn't agree with what you see as a problem, they have *no* obligation to change it for you. On the other hand, modded Minecraft can be *incredibly* fun. With well-made mods, there is so much new stuff to discover and create that it feels like you got yourself an entirely different, new game.

Before diving into *creating mods*... well. The most important piece of advice I personally have for you is: **Learn the language first**. If you're creating mods for Java Edition, *please* have at least a basic understanding of Java first. The first time I tried my hand at programming was for a Minecraft mod (Actually Additions' sort of roots, actually) and it went horribly, because I didn't understand what was part of the language I was using and what was part of the rather complex Minecraft and Forge API. For example, because Minecraft makes heavy use of method chaining[^1], when I first started out, I used to think that that was just an inherent property of the language (which obviously makes very little sense). I don't know if that was just me being a bit slow, or if that's the kind of misunderstanding that comes from not really learning a language before diving head-first into a project that uses it.

# Maybe some good guidelines
> ...on code-format or even conventions for forge-modding. (Afkman57)

Oh boy. Talking about conventions is always a tough one, because people disagree so fundamentally on what is good code and what isn't. A great example was when I learned that, in professional software engineering, early returns[^2] are apparently considered "bad practice" because they "decrease readability." How decreasing the amount of nesting (and thus, the amount you have to scroll to the right by) also decreases *readability*, when I think it massively *increases* readability, I'm not sure. Maybe that was just my software engineering professor having a field day, though. I really hope it's that.

When it comes to programming in languages that don't *rely* on formatting for their syntax (like Python), the actual formatting you use doesn't matter, even though some people might have you believe that it's *extremely important* to put opening braces on a new line. For me, the only important thing is that **you keep it consistent**. If you use an IDE, your best bet is to configure its auto-formatter exactly the way you like, and then using the format button every now and again (or even turning on format on save!) to make sure that, no matter how horrible your formatting is, at least it's consistently so.

# Any useful tools, resources, utilities etc. 
> ...for modding would be good too. (Afkman57)

I think the best, and most important tool, for modding, and any kind of programming, is a git server, be it GitHub, Bitbucket or whatever else. Source control is amazing, because not only does it allow you to see exactly what you (and your colleagues) changed an when, but it also allows you to revert any of your changes or merge them together. 

The other very useful thing about git websites like GitHub is that you can *look at other people's code* and take it as an implicit sort of tutorial. There are countless times where I looked at the code of other, bigger mods in an attempt to find useful information on how to realize certain things in my own mods. In the very first version of Actually Additions that had [Laser Relays](https://ellpeck.de/actaddmanual/#laserRelays), they were pretty much an exact copy of [Immersive Engineering](https://www.curseforge.com/minecraft/mc-mods/immersive-engineering)'s wire system, in terms of their inner workings. When you look at and especially copy other people's code, though, make sure of two things:
- *Understand* the code you're copying. If you don't understand it, you might as well just be mindlessly copying random code from random places.
- Keep the code's *license* in mind. Some licenses allow you to copy code freely, some require you to give credit and some don't allow you to copy any code at all. Even if a project allows you to copy code without giving credit, it's always good practice to do so anyway.

# How much work did it take to make Actually Additions
> ...from start to finish? Also how long did it take you to go from an idea to a first "prototype"? (Spo0ok)

This is an incredibly tough question, because of course I didn't record an exact measurement of how many hours I sunk into creating Actually Additions. What I do know, however, is this: It look *a long time*. Actually Additions was one of my first mods, and as previously discussed, I was not very good at any kind of programming when I started out, so I made al ot of mistakes, and I copied a lot of code without understanding it. That being said, I can give a rough estimate based on data that I already discussed in my [post about its features](https://ellpeck.de/blog/actually_additions). 

The first file I uploaded to CurseForge was [this one](https://www.curseforge.com/minecraft/mc-mods/actually-additions/files/2229705), on *March 15, 2015*. I know that, before I started uploading the mod to CurseForge, I had a Minecraft Forum page (it was still that time in 2015), and I would release early versions of the mod on Mediafire or some other site. That wouldn't have lasted that long, though, and looking at the commit history for the mod, the first time I referred to it as Actually Additions wasn't long after the repository was first created, [in March 2015](https://github.com/Ellpeck/ActuallyAdditions/commit/2a2308c0ce35fe8a5ac9dcea100b9aeb941c495a). I made my last real contribution [in June 2017](https://github.com/Ellpeck/ActuallyAdditions/commits/main?after=896a082d747a3e19755ded1973544d59fa992787+244).

That means, to create all of the features that the mod currently has, it took me about two years. I know that measurement is pretty reasonable, because I took almost no breaks when I first created the mod. This information also means that I have now *not* worked on the mod for longer than I originally *did* work on it. It's been like that for a long while actually, because 2017 is surprisingly far in the past. That's honestly kind of scary. I'm getting old, aren't I?

---

So yea, that's about it in terms of modding-related questions. I hope you found this post enjoyable. If you did, and if you have more questions for me to answer, you can always reply to the discussion tweet linked right at the end of this post, and if there are enough additional questions, I might make a second one.

Anyway, thanks for reading! ❤

[^1]: Method chaining is a concept that is used in a few languages, but especially Java. The idea is that, when you create non-static methods that change certain properties about an object, you make the method return *the object itself*. This allows for multiple method calls to be done in one line, which is especially useful when creating a system where you apply a bunch of settings to an object. `new Block().setHardness(3).setLightLevel(15);`

[^2]: Short-circuiting out of methods using `return` instead of having a bunch of nested checks
