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:
- Unzip project starter into project directory.
- Replace placeholders in LICENSE-template and rename it to LICENSE, or remove LICENSE-template and put any other license you like on your code. This is an permissive OSS project and we encourage you participate in OSS movement by having permissive license like one in template. You can find out pros and cons of OSS software in this article
- Ensure your project is under VCS. For example initialise git repository by running
git init; git commit --message "initialized repository". - Replace placeholders (edit values in gradle.properties, change example package and class names, etc.)
- Run
./gradlew build - Make sure to check out the rest sections of this file.
- You are good to go!
We also have described guidelines for existing mod migration and porting
- Updatable: Replace
build.gradlewith a newer version - Optional API artifact (.jar)
- Optional version replacement in Java files
- Optional shadowing of dependencies
- Simplified setup of Mixin and example
- Scala support (add sources under
src/main/scala/instead ofsrc/main/java/) - Optional named developer account for consistent player progression during testing
- Boilerplate forge mod as starting point
- Improved warnings for pitfalls
- Git Tags integration for versioning
- Jitpack CI
- GitHub CI:
- Releasing your artifacts on new tags pushed. Push git tag named after version (e.g. 1.0.0) which will trigger a release of artifacts with according names.
- Running smoke test for server startup. On any server crash occurring workflow will fail and print the crash log.
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 thebuild.gradleif an update is available.repositories.gradle[.kts]: Add your dependencies' repositories. This is separate from the main build script, so you may replace thebuild.gradleif 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 tomasterormainand 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!