An example mod for Minecraft 1.7.10 with Forge focussed on a stable, updatable setup.
We had our fair share in struggles with build scripts for Minecraft Forge. There are quite a few pitfalls from non-obvious error messages. This Example Project provides you a build system you can adapt to over 90% of Minecraft Forge mods and can easily be updated if need be.
We all have been there! Check out our FAQ. If that doesn't help, please open an issue.
Creating mod from scratch:
git init; git commit --message "initialized repository"
../gradlew build
We also have described guidelines for existing mod migration and porting
build.gradle
with a newer versionsrc/main/scala/
instead of src/main/java/
)build.gradle
: This is the core script of the build process. You should not need to tamper with it, unless you are trying to accomplish something out of the ordinary. Do not touch this file! You will make a future update near impossible if you do so!gradle.properties
: The core configuration file. It includesdependencies.gradle[.kts]
: Add your mod's dependencies in this file. This is separate from the main build script, so you may replace the build.gradle
if an update is available.repositories.gradle[.kts]
: Add your dependencies' repositories. This is separate from the main build script, so you may replace the build.gradle
if an update is available.jitpack.yml
: Ensures that your mod is available as import over Jitpack..github/workflows/gradle.yml
: A simple CI script that will build your mod any time it is pushed to master
or main
and publish the result as release in your repository. This feature is free with GitHub if your repository is public.You may activate Forge's Access Transformers by defining a configuration file in gradle.properties
.
Check out the example-access-transformers
branch for a working example!
Warning: Access Transformers are bugged and will deny you any sources for the decompiled minecraft! Your development environment will still work, but you might face some inconveniences. For example, IntelliJ will not permit searches in dependencies without attached sources.
Mixins are usually used to modify vanilla or mod/library in runtime without having to change source code. For example, redirect a call, change visibility or make class implement your interface. It's an advanced topic and most mods don't need to do that.
You can activate Mixin in 'gradle.properties'. In that case a mixin configuration (usually named mixins.mymodid.json
) will be generated automatically, and you only have to write the mixins itself. Dependencies are handled as well.
Take a look at the examples in Hodgepodge and Angelica.
If your project requires custom gradle commands you may add a addon.gradle[.kts]
to your project. It will be added automatically to the build script. Although we recommend against it, it is sometimes required. When in doubt, feel free to ask us about it. You may break future updates of this build system!
If you need access to properties modified later in the buildscript, you can also use a addon.late.gradle[.kts]
.
For local tweaks that you don't want to commit to Git, like adding extra JVM arguments for testing, use addon[.late].local.gradle[.kts]
.
If you tried out this build script we would love to head your opinion! Is there any feature missing for you? Did something not work? Please open an issue and we will try to resolve it asap!