Development

Introduction
Everyone can contribute to GTNH in one way or another. One possible way is to improve or expand the source code of the mods.

To get started, you first need a vision for what you want to do. If you have no idea you can look through issues and try to address some. If you do have a vision but want to hear more opinions on it, you can discuss it in a new Github issue or in Discord.

Getting started
If you found a mod that you want to edit, then create a fork of it by pressing the Fork button on its GitHub page. After that, you can clone your fork to a local repository, import it to your IDE, and get started on development. If you are not sure how to do something, try to look up how things similar to it were done before.

From scratch

 * 1) Create a new GitHub repository and clone it.
 * 2) Choose and download a Forge MDK, extract the ZIP-archive to the directory where you cloned your repository. If you are developing for Minecraft 1.7.10, then use SinTh0r4s' ExampleMod template.
 * 3) Edit your project details, such as its name, version, dependencies, and so on.
 * 4) Execute   in the root directory of your project.
 * 5) In Eclipse / IntelliJ IDEA, import your workspace as a Gradle project.
 * 6) Done.

From an existing repository

 * 1) Clone the repository.
 * 2) Execute   in the root directory of your project.
 * 3) In Eclipse / IntelliJ IDEA, import your workspace as an existing Gradle project. If the import fails, you may need to adjust the Gradle version and/or the buildscript. If you are developing for Minecraft 1.7.10, read this guide.
 * 4) Done.

Common issues

 * If your IDE tells you that stuff is missing even after you executed, then try to reload Gradle.
 * You need Java (64 bit) for development. Most mods work with any Java 8-20. However, some mods now use in gradle.properties. In that case you need at least Java 11 to compile them. If you have multiple Java versions on your machine, then you may need to set the   environment variable to the location of your desired Java installation and also configure it in your IDE.

Git Configuration
If you want to avoid signing commits with your real name, then please refer to the page Managing Git Identities.

Tools
All applications that are grouped together can do about the same. This does not mean that you can pick any one of them, as they differ in functionality, style, performance and customizability. It is recommended you look at what they can do and try each one out, so you can decide which application you want to use for which use case.

Code Editors

 * Notepad++
 * Visual Studio Code
 * Sublime Text
 * Atom

Integrated Development Environments

 * Eclipse Note: as of version 2020-09, using Java 8 became more difficult. 2020-06 is the last version with official support for Java 8.
 * IntelliJ IDEA

Image Editors

 * GIMP
 * Paint.NET
 * Krita
 * LibreSprite
 * Aseprite Paid
 * Photoshop Paid

Modeling

 * Blockbench
 * MagicaVoxel
 * Blender

Animation

 * Block Model Animator
 * Animated Textures Editor
 * LibreSprite

Miscellaneous

 * JSONLint
 * Palette Library
 * Resource Pack Workbench
 * Bearded-Octo-Nemesis 2 (BON2)
 * FernFlower
 * Java Decompiler
 * MCP Mapping Viewer
 * WinMerge

Code Style
For the full version of the GTNH Code Style please see a dedicated page - Code Style.

TL;DR:
 * Document your code, especially Javadoc-ing your methods and classes.
 * Keep your variables  unless they absolutely need to be different.
 * Don't change the existing public variables because it can break the code that uses them.
 * Use thread-safe collections where possible to account for future multithreading.
 * Don't make one method do too much. Add helper methods.
 * Use the  annotation when overriding methods.
 * Avoid tight coupling. Aim for your code to be loosely coupled.
 * Use semantic versioning.
 * Use the  file provided with the project or use this   if none was provided. You can check out the original site to discover more about it.

Contribution Procedure
Please do not have multiple changes/features in a single PR, make a separate PR for each. If they depend on each other, you can leave a note in the PR's description.
 * 1) Find something to contribute
 * 2) Fork the related projects (can skip this if you are a member of our github org)
 * 3) For certain old repos, buildscripts may need updating. See this guide.
 * 4) Push code into your fork (or on a separate branch in main repo)
 * 5) Open a pull request and provide a description on what it changes/adds/removes. Include pictures/graphs if necessary. If there is a related issue, link it. Ask for review from
 * 6) * DreamMasterXXL, if it's about quest and/or recipe change.
 * 7) * GTNewHorizons/developers team, if it's some java/scala/kotlin code change.
 * 8) * mitchej123, if it's NEI.
 * 9) * Original mod developer, if you are contributing to his mod and he/she is still around (e.g. glease for TC4Tweaks, SinTh0r4s for VisualProspecting, GlodBlock for GoodGenerators).
 * 10) Address review problems. Resolve merge conflicts (if any). Wait for final merge. DO NOT merge the PR yourself, even if approved! This is a task of GTNewHorizons/admin members.

If you are not sure how to fork and open pull requests, read this gist by Chaser324.

Resources
Not every wiki/tutorial/article/... listed here contains information about Minecraft version 1.7.10 but some topics haven't changed much and often the general methodology is the same. The newer the version, the less comparable the inner workings of Minecraft/Forge are to 1.7.10.

You can look at the source-code of most mods included in GTNH here.

If you look for something specific, use the search-function of your browser!

You can find an extensive list of modding resources, made by the MMD-Team, here.

Help

 * Mathematics on StackExchange: Forum for everything related to Mathematics
 * StackOverflow: Forum for everything related to Programming
 * #mod-dev ( GTNH Discord)
 * #mc-dev-other ( Minecraft Mod Development Discord)
 * #moddev ( Minecraft Pack Development Discord)
 * #mc-dev ( CurseForge Discord)
 * #help-modded-java ( Blockbench Discord)

Using DCEVM
For better hot-reload support in intellij you can use DCEVM. Instructions for linux:


 * Unpack Trava JDK 8 DCEVM on your machine.
 * Go into the unpacked JVM. In, make a copy of   called  . After that, copy the entire   folder and name it  . This tricks the IntelliJ plugin into thinking that the DCEVM install is valid as installed by the old 2018 installer.
 * Install HotSwapAgent plugin in IntelliJ.
 * Add the DCEVM JDK as an SDK in IntelliJ, it should autodetect most stuff but I had to manually copy over the javadoc path from my other java8 JDK.
 * Set DCEVM JDK as default for the project and Gradle.
 * Set the non-DCE JDK in Build, Exec & Deployment -> Compiler -> Scala Compiler -> Scala Compile Server.
 * In Build tools -> Gradle, set both build-and-run and run tests to using IntelliJ IDEA instead of Gradle.
 * In Tools -> HotSwapAgent, enable it for all configurations, and set the agent path to  in your DCEVM installation.
 * Make sure to use the Minecraft Client/Server IntelliJ configurations with the square frame icons instead of the runClient/etc. configurations with Gradle icons.
 * Debugging that config should show up loading the hot swap agent at the beginning of the logs.
 * If you have custom JVM args in the configs, make sure to remove all garbage-collection options as DCEVM works only with the default garbage collector.

Useful Options

 * # Enable Mixin Debug
 * # Verbose Debug Messages
 * # Export classes after mixins have been applied. If you include fernflower in your classpath, or copy org.jetbrains.fernflower into your mixin jar the exported classes will be decompiled
 * # Throw an error if the injection count doesn't match expectations
 * # Class Load Debugging
 * # Dump classes to `.minecraft/CLASSLOADER_TEMP`

Remote debugging

 * to wait for a debugger to be attached to the game before running code, put this in launcher args to debug the full pack
 * In IntelliJ, use Run->Attach to process to attach the debugger to the running instance.