Proper Mod Structuring - Revision history

Jonathanpecany at 21:46, 2 September 2021

2021-09-02T21:46:52Z

Jonathanpecany: Changes some typos and added in some words.

2021-09-02T21:46:06Z

Changes some typos and added in some words.

N1K-x: Properly reference the mods.toml file page

2021-09-01T11:08:42Z

Properly reference the mods.toml file page

N1K-x at 11:02, 1 September 2021

2021-09-01T11:02:24Z

Show changes

SciWhiz12: remove extraneous whitespace

2021-08-29T14:09:11Z

remove extraneous whitespace

ChampionAsh5357: Update mods.toml to v37

2021-07-29T22:12:39Z

Update mods.toml to v37

N1K-x: Add another possible way of laying out subpackages

2021-07-29T10:14:38Z

Add another possible way of laying out subpackages

Jriwanek: Correct for 1.16.5

2021-06-28T22:20:03Z

Correct for 1.16.5

ShrimpBot: Categorize with Category:Beginner Topics by SizableShrimp#0755

2021-05-19T00:58:52Z

Categorize with Category:Beginner Topics by SizableShrimp#0755

ChampionAsh5357: Fix the information about file.jarVersion, thanks Ater

2021-04-10T23:18:59Z

Fix the information about file.jarVersion, thanks Ater

Show changes

← Older revision		Revision as of 21:46, 2 September 2021
Line 1:		Line 1:

−	The structure of your mod is important in keeping your mod organized, for both your benefit and the benefit of anyone who wishes to make a feature or an add-on for your mod. A disorganized mod structure may cause headaches when someone is trying to update it to a higher version, especially if they cannot modify the package structure, due to i.e. licensing.	+	The structure of your mod is important in keeping your mod organized, for both your benefit and the benefit of anyone who wishes to make a feature or an
		+	add-on for your mod. A disorganized mod structure may cause headaches when someone is trying to update it to a higher version, especially if they cannot modify the package structure, due to i.e. licensing.

	{{Tip\|Note that this page is only a recommendation for your mod structure; you may structure your mod in any way you see fit.}}		{{Tip\|Note that this page is only a recommendation for your mod structure; you may structure your mod in any way you see fit.}}

← Older revision		Revision as of 21:46, 2 September 2021
Line 1:		Line 1:

−	The structure of your mod is important in keeping your mod organized, for both your benefit and the benefit of anyone who ~~wishses~~ to make a feature for your mod. A disorganized mod structure may cause headaches when someone is trying to update it to a higher version, especially if they cannot modify the package structure, due to i.e. licensing.	+	The structure of your mod is important in keeping your mod organized, for both your benefit and the benefit of anyone who wishes to make a feature or an add-on for your mod. A disorganized mod structure may cause headaches when someone is trying to update it to a higher version, especially if they cannot modify the package structure, due to i.e. licensing.

	{{Tip\|Note that this page is only a recommendation for your mod structure; you may structure your mod in any way you see fit.}}		{{Tip\|Note that this page is only a recommendation for your mod structure; you may structure your mod in any way you see fit.}}

@@ Line 40: / Line 40: @@
 The <code>@Mod</code> annotation indicates to the mod loader that this class is the entry point of your mod. Each <code>@Mod</code> annotation and their value should be paired with a mod id entry in your <code>mods.toml</code> file.
-== [[Mods.toml file]] ==
+== mods.toml file ==
 [[Category:Getting Started]]
 [[Category:Beginner Topics]]

@@ Line 43: / Line 43: @@
 The <code>mods.toml</code> file is read by the mod loader to determine what mods are packaged into your JAR file, and what information to display to the user in the Mods listing screen (accessible by pressing the "Mods" button on the main menu of the game).
-The <code>mods.toml</code> file is formatted in [https://toml.io/en/ Tom's Obvious Minimal Language]
+The <code>mods.toml</code> file is formatted in [https://toml.io/en/ Tom's Obvious Minimal Language], or TOML for short. The example <code>mods.toml</code> file in the MDK provides comments explaining the contents of the file. It should be stored under the <code>META-INF</code> folder in your resources directory (<code>src/main/resources/META-INF/mods.toml</code>).
 Example <code>mods.toml</code> file
@@ Line 86: / Line 81: @@
      side="BOTH"
 </syntaxhighlight>
 If the <code>version</code> is specified as<code>${file.jarVersion}</code>, Forge will replace the string with the 'Implementation Version' specified in the jar manifest at runtime. Since the userdev environment has no jar manifest to pull from, it will be <code>NONE</code> instead. As such, it is usually recommended to leave this field alone.

@@ Line 18: / Line 18: @@
 * '''Group by Function''': Another common strategy is to make subpackages for grouping classes that have a common purpose. For example, your blocks classes can be under <code>blocks</code>, your entities classes can be under <code>entities</code>, your helper utilities can be under <code>helpers</code>, etc.
-No matter how your final structure looks like it is highly recommended to add a <code>client</code> subpackage under your main package. This helps to isolate your [[Sides|client-only code]] from the rest, such as your GUIs and renderers.
+No matter how your final structure looks like it is highly recommended to add a <code>client</code> subpackage under your main package. This helps to isolate your [[Sides|client-only code]] from the rest, such as your Screens and renderers.
 By keeping your code in clean subpackages, you can grow your mod much more organically.
@@ Line 53: / Line 53: @@
 <syntaxhighlight lang="TOML">
 modLoader="javafml"
-# Forge for 1.16.5 is version 36
+# Forge for 1.17.1 is version 37
-loaderVersion="[36,)"
+loaderVersion="[37,)"
 license="All rights reserved"
 issueTrackerURL="github.com/MinecraftForge/MinecraftForge/issues"
@@ Line 75: / Line 75: @@
      modId="forge"
      mandatory=true
-     versionRange="[36,)"
+     versionRange="[37,)"
      ordering="NONE"
      side="BOTH"
@@ Line 82: / Line 82: @@
      modId="minecraft"
      mandatory=true
-     versionRange="[1.16.5]"
+     versionRange="[1.17.1,1.18)"
      ordering="NONE"
      side="BOTH"
@@ Line 90: / Line 90: @@
 If the <code>version</code> is specified as<code>${file.jarVersion}</code>, Forge will replace the string with the 'Implementation Version' specified in the jar manifest at runtime. Since the userdev environment has no jar manifest to pull from, it will be <code>NONE</code> instead. As such, it is usually recommended to leave this field alone.
-The <code>mods.toml</code> is split into three parts: the non-mod-specific properties, which are linked to the mod file; the mod properties, with a section for each mod; and dependency configurations, with a section for each mod's dependencies.Here is a table of attributes that may be given to a mod, where<code>mandatory</code>means there is no default and the absence of the property causes an error.
+The <code>mods.toml</code> is split into three parts: the non-mod-specific properties, which are linked to the mod file; the mod properties, with a section for each mod; and dependency configurations, with a section for each mod's dependencies. Here is a table of attributes that may be given to a mod, where<code>mandatory</code>means there is no default and the absence of the property causes an error.
 ===Non-Mod-Specific Properties===
@@ Line 111: / Line 111: @@
 |'''mandatory'''
 |The acceptable version range of the language loader, expressed as a [https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html Maven version spec]. For the Forge-provided Java loader, the version is the major version of the Forge version.
-|<code>"[36,)"</code>
+|<code>"[37,)"</code>
 |-
 |<code>license</code>

@@ Line 13: / Line 13: @@
 === Using Subpackages ===
-Rather than clutter up a single class and package with everything, it is recommended you break your mod into subpackages.
+Rather than clutter up a single class and package with everything, it is recommended you break your mod into subpackages. Below are a few possible methods for laying out your folder structure though you may as well come up with your own layout too.
-A common strategy is to make a subpackage for grouping classes that have a common purpose. For example, your blocks classes can be under <code>blocks</code>, your entities classes can be under <code>entities</code>, your helper utilities can be under <code>helpers</code>, etc.
+* '''Group by Logic''': One possible strategy is to make subpackages for logical units of your mod. For example, if you have a block called Super Furnace you would put its block, its block entity and its item all under <code>feature/superfurnace</code>.
-It is recommended to add a <code>client</code> subpackage under your main package, to isolate your [[Sides|client-only code]] from the rest, such as your GUIs and renderers.
+No matter how your final structure looks like it is highly recommended to add a <code>client</code> subpackage under your main package. This helps to isolate your [[Sides|client-only code]] from the rest, such as your GUIs and renderers.
 By keeping your code in clean subpackages, you can grow your mod much more organically.
 == Class Naming Schemes ==
@@ Line 27: / Line 30: @@
 The usual style is to use suffixes for your classes, for example:
-* An <code>Item</code> called <code>PowerRing</code> would be in the <code>items</code> package, with a class name of <code>PowerRingItem</code>.
+* An <code>Item</code> called <code>PowerRing</code> would have a class name of <code>PowerRingItem</code>.
-* A <code>Block</code> called <code>NotDirt</code> would be in a <code>blocks</code>  package, with a class name of <code>NotDirtBlock</code>.
+* A <code>Block</code> called <code>NotDirt</code> would have a class name of <code>NotDirtBlock</code>.
-* A <code>TileEntity</code> for a block called <code>SuperChewer</code> would be in a <code>tile</code> or <code>tileentity</code> package, with a class name of <code>SuperChewerTile</code>.
+* A <code>BlockEntity</code> for a block called <code>SuperChewer</code> would have a class name of <code>SuperChewerBlockEntity</code>.
 == The Mod File ==

← Older revision		Revision as of 00:58, 19 May 2021
Line 268:		Line 268:

	[[Category:Getting Started]]		[[Category:Getting Started]]
		+
		+
		+	[[Category:Beginner Topics]]