Difference between revisions of "Getting Started/1.16"

From Forge Community Wiki
(Copy Getting Started to MC1.16 archive)
 
(Copy Getting Started to MC1.16 archive)
 
Line 13: Line 13:
 
**** <code>resources</code> - The resources for the <code>main</code> source set
 
**** <code>resources</code> - The resources for the <code>main</code> source set
 
***** <code>META-INF</code> - The folder for '''metadata inf'''ormation files<ref>[https://stackoverflow.com/a/6075320/14416954 StackOverflow answer]: ''... Basically, if it was stored in META-INF, it was Meta-data Information...''</ref>
 
***** <code>META-INF</code> - The folder for '''metadata inf'''ormation files<ref>[https://stackoverflow.com/a/6075320/14416954 StackOverflow answer]: ''... Basically, if it was stored in META-INF, it was Meta-data Information...''</ref>
****** <code>mods.toml</code> - The [[Proper Mod Structuring#The mods.toml file|<tt>mods.toml</tt> file/1.16]], where mods are declared
+
****** <code>mods.toml</code> - The [[Proper Mod Structuring#The mods.toml file/1.16|<tt>mods.toml</tt> file]], where mods are declared
***** <code>pack.mcmeta</code> - File used by Minecraft to [[mc:Data Pack#pack.mcmeta|identify data and resource packs/1.16]]
+
***** <code>pack.mcmeta</code> - File used by Minecraft to [[mc:Data Pack#pack.mcmeta/1.16|identify data and resource packs]]
** <code>.gitattributes</code> - Used by [[wikipedia:Git|Git/1.16]] for specifying attributes for files<ref>[https://git-scm.com/docs/gitattributes Official git documentation on <tt>.gitattributes</tt>]</ref>
+
** <code>.gitattributes</code> - Used by [[wikipedia:Git/1.16|Git]] for specifying attributes for files<ref>[https://git-scm.com/docs/gitattributes Official git documentation on <tt>.gitattributes</tt>]</ref>
 
** <code>.gitignore</code> - Used by Git for specifying intentionally untracked/ignored files<ref>[https://git-scm.com/docs/gitignore Official git documentation on <tt>.gitignore</tt>]</ref>
 
** <code>.gitignore</code> - Used by Git for specifying intentionally untracked/ignored files<ref>[https://git-scm.com/docs/gitignore Official git documentation on <tt>.gitignore</tt>]</ref>
 
** <code>build.gradle</code> - The Gradle buildscript, which defines the project and tasks<ref>[https://docs.gradle.org/6.9/userguide/tutorial_using_tasks.html Gradle User Guide for 6.9: ''Build Script Basics'']</ref>
 
** <code>build.gradle</code> - The Gradle buildscript, which defines the project and tasks<ref>[https://docs.gradle.org/6.9/userguide/tutorial_using_tasks.html Gradle User Guide for 6.9: ''Build Script Basics'']</ref>
Line 48: Line 48:
 
** Pick a unique and memorable modid. The modid must be between 2 and 64 characters, and must consist of lowercase letters, numbers, underscores (<code>_</code>) and hyphens (<code>-</code>). The recommendation is to avoid using acronyms and abbreviations.
 
** Pick a unique and memorable modid. The modid must be between 2 and 64 characters, and must consist of lowercase letters, numbers, underscores (<code>_</code>) and hyphens (<code>-</code>). The recommendation is to avoid using acronyms and abbreviations.
 
* Change the <code>archivesBaseName</code> variable to your modid. This is used as the base name for the JAR file when you build your mod, and as the <tt>artifactId</tt> of your mod's [https://maven.apache.org/pom.html#Maven_Coordinates maven coordinates].
 
* Change the <code>archivesBaseName</code> variable to your modid. This is used as the base name for the JAR file when you build your mod, and as the <tt>artifactId</tt> of your mod's [https://maven.apache.org/pom.html#Maven_Coordinates maven coordinates].
* Change the <code>group</code> to your [[Proper Mod Structuring#Packaging|unique root java package/1.16]]. This is used as the <tt>groupId</tt> of your mod's maven coordinates.
+
* Change the <code>group</code> to your [[Proper Mod Structuring#Packaging/1.16|unique root java package]]. This is used as the <tt>groupId</tt> of your mod's maven coordinates.
 
* In the <code>jar</code> task, change the values of the <code>Specification-Vendor</code> and <code>Implementation-Vendor</code> keys to your username/brand name or other form of identification.
 
* In the <code>jar</code> task, change the values of the <code>Specification-Vendor</code> and <code>Implementation-Vendor</code> keys to your username/brand name or other form of identification.
* ''Optional suggestion: '' Change the <code>version</code> variable to have a 0 as the major version (ex. <code>'0.1'</code>. This is to follow [[Semantic Versioning#During Development|semantic versioning guidelines/1.16]] for versions in active development.
+
* ''Optional suggestion: '' Change the <code>version</code> variable to have a 0 as the major version (ex. <code>'0.1'</code>. This is to follow [[Semantic Versioning#During Development/1.16|semantic versioning guidelines]] for versions in active development.
  
 
== Building and Testing ==
 
== Building and Testing ==
Line 58: Line 58:
 
* <code>runClient</code>, for starting the client.
 
* <code>runClient</code>, for starting the client.
 
* <code>runServer</code>, for starting the dedicated server. ''You will need to accept the EULA through the <tt>eula.txt</tt> after running the server for the first time.''
 
* <code>runServer</code>, for starting the dedicated server. ''You will need to accept the EULA through the <tt>eula.txt</tt> after running the server for the first time.''
* <code>runData</code>, for starting the client in [[Datageneration|data generation/1.16]] mode.
+
* <code>runData</code>, for starting the client in [[Datageneration/1.16|data generation]] mode.
  
 
{{Tip|Always test your mod in both the client and the dedicated server, even if you are making a one-sided mod. Mods should not crash when running on both sides, and one-sided mods should not crash if they run on the wrong side.}}
 
{{Tip|Always test your mod in both the client and the dedicated server, even if you are making a one-sided mod. Mods should not crash when running on both sides, and one-sided mods should not crash if they run on the wrong side.}}
Line 64: Line 64:
 
You can build your mod's final JAR using the <code>build</code> task. The resulting JAR will be located in the <code>build/libs</code> folder under your project directory.
 
You can build your mod's final JAR using the <code>build</code> task. The resulting JAR will be located in the <code>build/libs</code> folder under your project directory.
  
[[Category:Getting Started/1.16]]
+
[[Category:Getting Started/1.16|Category:Getting Started]]
  
  
[[Category:Beginner Topics/1.16]]
+
[[Category:Beginner Topics/1.16|Category:Beginner Topics]]

Latest revision as of 04:14, 27 July 2021

Minecraft Forge is a modding framework, designed to allow different mods to load and work together to be compatible. Through the years, there has been many changes in the Forge tooling to make working with mods as seamless as possible. It is now easier than ever to start making your own mod.

The Mod Development Kit

The Mod Development Kit or MDK is a downloadable archive that contains the basic skeleton for starting a new mod. It contains the following files and folders:

  • The Mod Development Kit
    • gradle/wrapper/ - The folder containing the Gradle wrapper, Forge uses Gradle 6.9
    • src - The sources folder
      • main - The main source set
        • java - The java sources for the main source set
          • ...
        • resources - The resources for the main source set
    • .gitattributes - Used by Git for specifying attributes for files[2]
    • .gitignore - Used by Git for specifying intentionally untracked/ignored files[3]
    • build.gradle - The Gradle buildscript, which defines the project and tasks[4]
    • changelog.txt - The Forge version changelog
    • CREDITS.txt - Forge's credits/thank you file
    • gradle.properties - The Gradle properties file, for defining additional variables and options[5]
    • gradlew - The *nix shell file for executing the Gradle wrapper
    • gradlew.bat - The Windows batch file for executing the Gradle wrapper
    • LICENSE.txt - File containing the licensing information for Forge and libraries
    • README.txt - Readme file with basic setup instructions

Basic MDK Setup

  1. Download the MDK from the official Minecraft Forge download site and extract the MDK into an empty folder.
  2. Open your IDE of choice, and import the project as a Gradle project.
    • For Eclipse: File > Import > Gradle > Existing Gradle Project, select the folder for the Project root directory, click Finish
    • For IntelliJ IDEA: File > Open, select and open the folder, select the build.gradle file, click OK, click Open as Project
  3. Wait for the setup process to complete and the Minecraft sources are decompiled.
  4. Generate the run configurations for your IDE using the appropriate Gradle task.
    These tasks can be run on the command line using (Windows) gradlew gen***Runs or (*nix) ./gradlew gen***Runs.
    • For Eclipse: the task is genEclipseRuns; to run in the IDE directly, open the Gradle Tasks tab on the bottom panel, wait until the tasks have loaded then expand the folder, expand the fg_runs folder, then double-click genEclipseRuns.
    • For IntelliJ IDEA: the task is genIntellijRuns; to run in the IDE directly, open the Gradle on the right, expand the project folder, double-click Tasks > fg_runs > genIntellijRuns.
    • For Visual Studio Code: the task is genVSCodeRuns
The most popular IDEs used by Forge and mod developers are Eclipse and IntelliJ IDEA. While Visual Studio Code has a run generation task, because of its relative unpopularity as an IDE for Minecraft modding, the user will have to self-diagnose any issues that may arise from their use of it.

Customizing the MDK

The MDK provides default values for the buildscript and mods.toml file. These values should be replaced with your own mod's information.

All edits should be done below the apply plugin: 'net.minecraftforge.gradle' line. The lines above it are required for the Forge MDK to work correctly, and should not be modified without proper knowledge.

  • All references to examplemod in the buildscript should be replaced with your modid.
    • Use your IDE's find-and-replace function to quickly replace these values.
    • Pick a unique and memorable modid. The modid must be between 2 and 64 characters, and must consist of lowercase letters, numbers, underscores (_) and hyphens (-). The recommendation is to avoid using acronyms and abbreviations.
  • Change the archivesBaseName variable to your modid. This is used as the base name for the JAR file when you build your mod, and as the artifactId of your mod's maven coordinates.
  • Change the group to your unique root java package. This is used as the groupId of your mod's maven coordinates.
  • In the jar task, change the values of the Specification-Vendor and Implementation-Vendor keys to your username/brand name or other form of identification.
  • Optional suggestion: Change the version variable to have a 0 as the major version (ex. '0.1'. This is to follow semantic versioning guidelines for versions in active development.

Building and Testing

You can test your mod in the development environment using either your IDE's run configurations and built-in debugging utilities, or by running the run* task as defined by the buildscript's run configurations.

There are three default run configurations with the MDK:

  • runClient, for starting the client.
  • runServer, for starting the dedicated server. You will need to accept the EULA through the eula.txt after running the server for the first time.
  • runData, for starting the client in data generation mode.
Always test your mod in both the client and the dedicated server, even if you are making a one-sided mod. Mods should not crash when running on both sides, and one-sided mods should not crash if they run on the wrong side.

You can build your mod's final JAR using the build task. The resulting JAR will be located in the build/libs folder under your project directory.