Sides - Revision history

ChampionAsh5357: Update to 1.19

2022-06-13T19:43:53Z

Update to 1.19

SciWhiz12: it's now NetworkConstants without the FML prefix

2021-12-23T01:50:09Z

it's now NetworkConstants without the FML prefix

ChampionAsh5357: Update to 1.17

2021-07-29T23:18:28Z

Update to 1.17

ShrimpBot: Categorize with Category:Common Concepts by SizableShrimp#0755

2021-05-19T00:59:03Z

Categorize with Category:Common Concepts by SizableShrimp#0755

ChampionAsh5357: Add Kotlin and Scala translations

2021-04-08T02:49:49Z

Add Kotlin and Scala translations

ChampionAsh5357: Fix hyperlinks

2021-01-07T16:22:12Z

Fix hyperlinks

Unbekannt: modloading process is missing

2020-12-21T13:20:42Z

modloading process is missing

SciWhiz12: Text replacement - "{{Colored box|title=Important|content=" to "{{Tip/Important|"

2020-12-21T03:01:19Z

Text replacement - "{{Colored box|title=Important|content=" to "{{Tip/Important|"

SciWhiz12: Text replacement - "{{Colored box|title=Tip|background-title-color=#633193|content=" to "{{Tip|"

2020-12-20T22:25:50Z

Text replacement - "{{Colored box|title=Tip|background-title-color=#633193|content=" to "{{Tip|"

SciWhiz12: monospaced font for certain header text

2020-11-29T03:31:44Z

monospaced font for certain header text

@@ Line 75: / Line 75: @@
 So for one-sided mods, you would typically register your event handlers using [[#DistExecutor|<code>DistExecutor</code>]] or <code>@EventBusSubscriber(value = Dist.*)</code>, instead of directly calling the relevant registration methods in the constructor. The idea is that, if your mod is loaded on the wrong side, it should simply do nothing: listen to no events, do no special behaviors, and so on. A one-sided mod by nature should not register blocks, items, … since they would need to be available on the other side, too.
-Additionally, if your mod is one-sided, it typically does not forbid the user from joining a server that is lacking that mod, but the server menu will display the server as being incompatible (with a red <code>X</code> at the side). Therefore, you should register an <code>IExtensionPoint$DisplayTest</code> extension point to make sure that Forge does not think your mod is required on the server: (this is usually done in the mod constructor)
+Additionally, if your mod is one-sided, it typically does not forbid the user from joining a server that is lacking that mod. Therefore, you should set the <code>displayTest</code> property in your [[Mods.toml|mods.toml]] to whatever value is necessary.
 {{Template:Tabs/Code_Snippets

@@ Line 79: / Line 79: @@
 {{Template:Tabs/Code_Snippets
 |java=// Make sure the mod being absent on the other network side does not cause the client to display the server as incompatible
-ModLoadingContext.get().registerExtensionPoint(IExtensionPoint.DisplayTest.class, () -> new IExtensionPoint.DisplayTest(() -> FMLNetworkConstants.IGNORESERVERONLY, (a, b) -> true));
+ModLoadingContext.get().registerExtensionPoint(IExtensionPoint.DisplayTest.class, () -> new IExtensionPoint.DisplayTest(() -> NetworkConstants.IGNORESERVERONLY, (a, b) -> true));
 |kotlin=// Make sure the mod being absent on the other network side does not cause the client to display the server as incompatible
-ModLoadingContext.get().registerExtensionPoint(IExtensionPoint.DisplayTest.class) { IExtensionPoint.DisplayTest(Supplier { FMLNetworkConstants.IGNORESERVERONLY }, BiPredicate { _: String, _: Boolean -> true }) }
+ModLoadingContext.get().registerExtensionPoint(IExtensionPoint.DisplayTest.class) { IExtensionPoint.DisplayTest(Supplier { NetworkConstants.IGNORESERVERONLY }, BiPredicate { _: String, _: Boolean -> true }) }
 |scala=import scala.compat.java8.FunctionConverters._
 // Make sure the mod being absent on the other network side does not cause the client to display the server as incompatible
-ModLoadingContext.get.registerExtensionPoint(IExtensionPoint.DisplayTest.class, (() => new IExtensionPoint.DisplayTest((() => FMLNetworkConstants.IGNORESERVERONLY).asJava, asJavaBiPredicate((_: String, _: java.lang.Boolean) => true))).asJava)
+ModLoadingContext.get.registerExtensionPoint(IExtensionPoint.DisplayTest.class, (() => new IExtensionPoint.DisplayTest((() => NetworkConstants.IGNORESERVERONLY).asJava, asJavaBiPredicate((_: String, _: java.lang.Boolean) => true))).asJava)
 |}}

@@ Line 11: / Line 11: @@
 * '''Physical Server''' - Often known as the dedicated server, the ''physical server'' is the entire program that runs whenever you launch any dedicated server executable or JAR (<code>minecraft_server.jar</code>) that does not bring up a playable GUI.
 * '''Logical Server''' - The ''logical server'' is what runs game logic: mob spawning, weather, updating inventories, health, AI, and all other game mechanics. The logical server is present within the physical server, but is also can run inside a physical client together with a logical client, as a single player world. The logical server always runs in a thread named the <code>Server Thread</code>.
-* '''Logical Client''' - The ''logical client'' is what accepts input from the player and relays it to the logical server. In addition, it also receives information from the logical server and makes it available graphically to the player. The logical client runs in the <code>Client Thread</code>, though often several other threads are spawned to handle things like audio and chunk render batching.
+* '''Logical Client''' - The ''logical client'' is what accepts input from the player and relays it to the logical server. In addition, it also receives information from the logical server and makes it available graphically to the player. The logical client runs in the <code>Render Thread</code>, though often several other threads are spawned to handle things like audio and chunk render batching.
 In the Minecraft codebase, the physical sides are represented by an enum called <code>Dist</code>, while the logical sides are represented by an enum called <code>LogicalSide</code>.
@@ Line 19: / Line 19: @@
 == Performing Side-Specific Operations ==
-=== <tt>World#isRemote</tt> ===
+=== <tt>Level#isClientSide</tt> ===
-This <code>boolean</code> check is the most common way (and the most recommended way) to check the currently running '''logical side'''. Querying this field on a <code>World</code> object establishes the logical side that the world belongs to. That is, if this field is <code>true</code>, the world extends <code>ClientWorld</code> and is currently running on the logical client, while if the field is <code>false</code>, the world extends <code>ServerWorld</code> and is running on the logical server.
+This <code>boolean</code> check is the most common way (and the most recommended way) to check the currently running '''logical side'''. Querying this field on a <code>Level</code> object establishes the logical side that the level belongs to. That is, if this field is <code>true</code>, the level extends <code>ClientLevel</code> and is currently running on the logical client, while if the field is <code>false</code>, the level extends <code>ServerLevel</code> and is running on the logical server.
 It follows that the physical/dedicated server will always contain <code>false</code> in this field, but we cannot assume that <code>false</code> implies a physical server, since this field can also be <code>false</code> for the logical server inside a physical client (in other words, a single player world).
-Use this check whenever you need to determine if game logic and other mechanics should be run. For example, if you want to damage the player every time they click your block, or have your machine process dirt into diamonds, you should only do so after ensuring <code>world.isRemote</code> is <code>false</code>. Applying game logic to the logical client can cause desynchronization (ghost entities, desynchronized stats, etc.) in the best case, and crashes in the worst case.
+Use this check whenever you need to determine if game logic and other mechanics should be run. For example, if you want to damage the player every time they click your block, or have your machine process dirt into diamonds, you should only do so after ensuring <code>level#isClientSide</code> is <code>false</code>. Applying game logic to the logical client can cause desynchronization (ghost entities, desynchronized stats, etc.) in the best case, and crashes in the worst case.
 This check should be used as your go-to default. Aside from the sided events and <code>DistExecutor</code>, rarely will you need the other ways of determining sides and adjusting behavior.
@@ Line 39: / Line 39: @@
 Considering the use of a single "universal" jar for client and server mods, and the separation of the physical sides into two jars, an important question comes to mind: How do we use code that is only present on one physical side? All code in <code>net.minecraft.client</code> (such as anything rendering-related) is only present on the physical client, and all code in <code>net.minecraft.server.dedicated</code> is only present on the physical server.
-If any class you write references those names in any way, they will crash the game when that respective class is loaded in an environment where those names do not exist. For example, a very common mistake in beginners is to call <code>Minecraft.getMinecraft().<doStuff>()</code> in block or tile entity classes, which will crash any physical/dedicated server as soon as the class is loaded.
+If any class you write references those names in any way, they will crash the game when that respective class is loaded in an environment where those names do not exist. For example, a very common mistake in beginners is to call <code>Minecraft.getMinecraft().<doStuff>()</code> in block or block entity classes, which will crash any physical/dedicated server as soon as the class is loaded.
-How do we resolve this? Forge provides the <code>DistExecutor</code> utility class, which provides various methods to run and call different code depending on the physical side.
+How do we resolve this? Forge provides the <code>DistExecutor</code> utility class, which provides various methods to run and call different code depending on the physical side. There are two versions of each method: <code>safe*</code> and <code>unsafe</code>. <code>safe*</code> methods accept a supplied method reference from another class; otherwise, an error will be thrown. <code>unsafe*</code> methods accept a doubly supplied instance instead. <code>unsafe*</code> methods could cause <code>ClassNotFoundException</code>s depending on how they are used, though in standard cases referencing an external class within the double supplier should be safe. In any case, make sure you understand how the [https://docs.oracle.com/javase/specs/jvms/se16/html/jvms-5.html#jvms-5.4.1 class verifier] works to load classes before using this.
 {{Tip/Important|
@@ Line 48: / Line 48: @@
 === Thread Groups ===
-If <code>Thread.currentThread().getThreadGroup() == SidedThreadGroups.SERVER</code>, it is likely the current thread is on the logical server. Otherwise, it is likely on the logical client. This is useful to retrieve the '''logical''' side when you do not have access to a <code>World</code> object to check <code>isRemote</code>. It ''guesses'' which logical side you are on by looking at the thread group of the currently running thread. Because it is a guess, this method should only be used when other options have been exhausted. In all other cases, you should prefer checking <code>world.isRemote</code> to this check.
+If <code>Thread.currentThread().getThreadGroup() == SidedThreadGroups.SERVER</code>, it is likely the current thread is on the logical server. Otherwise, it is likely on the logical client. This is useful to retrieve the '''logical''' side when you do not have access to a <code>Level</code> object to check <code>isClientSide</code>. It ''guesses'' which logical side you are on by looking at the thread group of the currently running thread. Because it is a guess, this method should only be used when other options have been exhausted. In all other cases, you should prefer checking <code>level#isClientSide</code> to this check.
 === <tt>FMLEnvironment.dist</tt> ===
@@ Line 58: / Line 58: @@
 Annotating a method or field with the <code>@OnlyIn(Dist)</code> annotation indicates to the loader that the respective member should be completely stripped out of the definition not on the specified '''physical''' side. Usually, these are only seen when browsing through the decompiled Minecraft code, indicating methods that the Mojang obfuscator stripped out.
-{{Tip/Important|There is little to no reason for using this annotation directly. The only valid reason to use this annotation is if you are extending a vanilla class that is already annotated with <code>@OnlyIn</code>. In all other cases where you need to dispatch behavior based on physical sides, use <code>DistExecutor</code> or a check on <code>FMLEnvironment.dist</code> instead.}}
+{{Tip/Important|There is '''NO''' reason for using this annotation directly. Use <code>DistExecutor</code> or a check on <code>FMLEnvironment.dist</code> instead.}}
 == Common Mistakes ==
@@ Line 75: / Line 75: @@
 So for one-sided mods, you would typically register your event handlers using [[#DistExecutor|<code>DistExecutor</code>]] or <code>@EventBusSubscriber(value = Dist.*)</code>, instead of directly calling the relevant registration methods in the constructor. The idea is that, if your mod is loaded on the wrong side, it should simply do nothing: listen to no events, do no special behaviors, and so on. A one-sided mod by nature should not register blocks, items, … since they would need to be available on the other side, too.
-Additionally, if your mod is one-sided, it typically does not forbid the user from joining a server that is lacking that mod, but the server menu will display the server as being incompatible (with a red <code>X</code> at the side). Therefore, you should override the <code>DISPLAYTEST</code> extension point to make sure that Forge does not think your mod is required on the server: (this is usually done in the mod constructor)
+Additionally, if your mod is one-sided, it typically does not forbid the user from joining a server that is lacking that mod, but the server menu will display the server as being incompatible (with a red <code>X</code> at the side). Therefore, you should register an <code>IExtensionPoint$DisplayTest</code> extension point to make sure that Forge does not think your mod is required on the server: (this is usually done in the mod constructor)
 {{Template:Tabs/Code_Snippets
 |java=// Make sure the mod being absent on the other network side does not cause the client to display the server as incompatible
-ModLoadingContext.get().registerExtensionPoint(ExtensionPoint.DISPLAYTEST, () -> Pair.of(() -> FMLNetworkConstants.IGNORESERVERONLY, (a, b) -> true));
+ModLoadingContext.get().registerExtensionPoint(IExtensionPoint.DisplayTest.class, () -> new IExtensionPoint.DisplayTest(() -> FMLNetworkConstants.IGNORESERVERONLY, (a, b) -> true));
 |kotlin=// Make sure the mod being absent on the other network side does not cause the client to display the server as incompatible
-ModLoadingContext.get().registerExtensionPoint(ExtensionPoint.DISPLAYTEST) { Pair.of(Supplier { FMLNetworkConstants.IGNORESERVERONLY }, BiPredicate { _: String, _: Boolean -> true }) }
+ModLoadingContext.get().registerExtensionPoint(IExtensionPoint.DisplayTest.class) { IExtensionPoint.DisplayTest(Supplier { FMLNetworkConstants.IGNORESERVERONLY }, BiPredicate { _: String, _: Boolean -> true }) }
 |scala=import scala.compat.java8.FunctionConverters._
 // Make sure the mod being absent on the other network side does not cause the client to display the server as incompatible
-ModLoadingContext.get.registerExtensionPoint(ExtensionPoint.DISPLAYTEST, (() => Pair.of((() => FMLNetworkConstants.IGNORESERVERONLY).asJava, asJavaBiPredicate((_: String, _: java.lang.Boolean) => true))).asJava)
+ModLoadingContext.get.registerExtensionPoint(IExtensionPoint.DisplayTest.class, (() => new IExtensionPoint.DisplayTest((() => FMLNetworkConstants.IGNORESERVERONLY).asJava, asJavaBiPredicate((_: String, _: java.lang.Boolean) => true))).asJava)
 |}}

← Older revision		Revision as of 00:59, 19 May 2021
Line 88:		Line 88:

	This tells the client that it should ignore the server version being absent, and tells the server that it should not tell the client this mod should be present.		This tells the client that it should ignore the server version being absent, and tells the server that it should not tell the client this mod should be present.
		+
		+
		+	[[Category:Common Concepts]]

@@ Line 70: / Line 70: @@
 This mistake can also be made explicitly by accessing physical client-only classes such as <code>Minecraft</code> from common code that runs or can run on the logical server. This mistake is easy to miss for beginners, who debug in a physical client. The code will work there, but will immediately crash on a physical server. For this reason, it is always recommended to test your mod with the physical/dedicated server.
-=== Writing One-Sided Mods ===
+===Writing One-Sided Mods===
 Your mods are expected to always load, regardless of if they are loaded on the client or the server. For one-sided mods, this means that they must still run on the opposite physical side.
@@ Line 78: / Line 77: @@
 Additionally, if your mod is one-sided, it typically does not forbid the user from joining a server that is lacking that mod, but the server menu will display the server as being incompatible (with a red <code>X</code> at the side). Therefore, you should override the <code>DISPLAYTEST</code> extension point to make sure that Forge does not think your mod is required on the server: (this is usually done in the mod constructor)
-<syntaxhighlight lang="java">
+{{Template:Tabs/Code_Snippets
-//Make sure the mod being absent on the other network side does not cause the client to display the server as incompatible
+|java=// Make sure the mod being absent on the other network side does not cause the client to display the server as incompatible
 ModLoadingContext.get().registerExtensionPoint(ExtensionPoint.DISPLAYTEST, () -> Pair.of(() -> FMLNetworkConstants.IGNORESERVERONLY, (a, b) -> true));
-</syntaxhighlight>
+|kotlin=// Make sure the mod being absent on the other network side does not cause the client to display the server as incompatible
 This tells the client that it should ignore the server version being absent, and tells the server that it should not tell the client this mod should be present.

@@ Line 31: / Line 31: @@
 === Sided Setup Events ===
-There are different events which are fired at different stages during the [[Modloading|modloading process]]. Most of these events are fired on both physical sides, except for the '''sided setup events''': <code>FMLClientSetupEvent</code> and <code>FMLDedicatedServerSetupEvent</code>, which is fired on the physical client and the physical/dedicated server respectively.
+There are different events which are fired at different stages during the [[Stages_of_Modloading|modloading process]]. Most of these events are fired on both physical sides, except for the '''sided setup events''': <code>FMLClientSetupEvent</code> and <code>FMLDedicatedServerSetupEvent</code>, which is fired on the physical client and the physical/dedicated server respectively.
 These events should be used for running side-specific initialization code. It is recommended to either put your sided event handler registration behind a <code>DistExecutor</code> call, or use the <code>@Mod.EventBusSubscriber</code> anntoation with '<code>value = Dist.CLIENT</code> for clients (or <code>value = Dist.DEDICATED_SERVER</code> for the dedicated server) to conditionally register your event handlers and prevent the classes referenced within from crashing upon being loaded.
@@ Line 64: / Line 64: @@
 === Reaching Across Logical Sides ===
-Whenever you want to send information from one logical side to another, you must '''always''' use network packets. It is incredibly tempting, when in a single player scenario, to directly transfer data from the logical server to the logical client.
+Whenever you want to send information from one logical side to another, you must '''always''' use [[SimpleChannel|network packets]]. It is incredibly tempting, when in a single player scenario, to directly transfer data from the logical server to the logical client.
 This is actually very commonly inadvertently done through static fields. Since the logical client and logical server share the same JVM instance in a single player scenario, both threads writing to and reading from static fields will cause all sorts of race conditions and classical issues associated with threading.
@@ Line 74: / Line 74: @@
 Your mods are expected to always load, regardless of if they are loaded on the client or the server. For one-sided mods, this means that they must still run on the opposite physical side.
-So for one-sided mods, you would typically register your event handlers using [[#DistExecutor|<code>DistExecutor</code>]] or ''@EventBusSubscriber(value = Dist.*)'', instead of directly calling the relevant registration methods in the constructor. The idea is that, if your mod is loaded on the wrong side, it should simply do nothing: listen to no events, do no special behaviors, and so on. A one-sided mod by nature should not register blocks, items, … since they would need to be available on the other side, too.
+So for one-sided mods, you would typically register your event handlers using [[#DistExecutor|<code>DistExecutor</code>]] or <code>@EventBusSubscriber(value = Dist.*)</code>, instead of directly calling the relevant registration methods in the constructor. The idea is that, if your mod is loaded on the wrong side, it should simply do nothing: listen to no events, do no special behaviors, and so on. A one-sided mod by nature should not register blocks, items, … since they would need to be available on the other side, too.
 Additionally, if your mod is one-sided, it typically does not forbid the user from joining a server that is lacking that mod, but the server menu will display the server as being incompatible (with a red <code>X</code> at the side). Therefore, you should override the <code>DISPLAYTEST</code> extension point to make sure that Forge does not think your mod is required on the server: (this is usually done in the mod constructor)

← Older revision		Revision as of 13:20, 21 December 2020
Line 1:		Line 1:
		+	{{Under construction}} <!-- modloading process is missing -->
	A very important concept to understand when modding Minecraft are the two sides: '''client''' and '''server'''. There are many, many common misconceptions and mistakes regarding siding, which can lead to bugs that might not crash the game, but can rather have unintended and often unpredictable effects.		A very important concept to understand when modding Minecraft are the two sides: '''client''' and '''server'''. There are many, many common misconceptions and mistakes regarding siding, which can lead to bugs that might not crash the game, but can rather have unintended and often unpredictable effects.

@@ Line 14: / Line 14: @@
 In the Minecraft codebase, the physical sides are represented by an enum called <code>Dist</code>, while the logical sides are represented by an enum called <code>LogicalSide</code>.
-{{Colored box|title=Tip|background-title-color=#633193|content=It is guaranteed that the logical cient always runs on the physical client; however, the same cannot be said of the logical server.}}
+{{Tip|It is guaranteed that the logical cient always runs on the physical client; however, the same cannot be said of the logical server.}}
 == Performing Side-Specific Operations ==

@@ Line 18: / Line 18: @@
 == Performing Side-Specific Operations ==
-=== world.isRemote ===
+=== <tt>World#isRemote</tt> ===
 This <code>boolean</code> check is the most common way (and the most recommended way) to check the currently running '''logical side'''. Querying this field on a <code>World</code> object establishes the logical side that the world belongs to. That is, if this field is <code>true</code>, the world extends <code>ClientWorld</code> and is currently running on the logical client, while if the field is <code>false</code>, the world extends <code>ServerWorld</code> and is running on the logical server.
@@ Line 34: / Line 34: @@
 These events should be used for running side-specific initialization code. It is recommended to either put your sided event handler registration behind a <code>DistExecutor</code> call, or use the <code>@Mod.EventBusSubscriber</code> anntoation with '<code>value = Dist.CLIENT</code> for clients (or <code>value = Dist.DEDICATED_SERVER</code> for the dedicated server) to conditionally register your event handlers and prevent the classes referenced within from crashing upon being loaded.
-=== DistExecutor ===
+=== <tt>DistExecutor</tt> ===
 Considering the use of a single "universal" jar for client and server mods, and the separation of the physical sides into two jars, an important question comes to mind: How do we use code that is only present on one physical side? All code in <code>net.minecraft.client</code> (such as anything rendering-related) is only present on the physical client, and all code in <code>net.minecraft.server.dedicated</code> is only present on the physical server.
@@ Line 49: / Line 49: @@
 If <code>Thread.currentThread().getThreadGroup() == SidedThreadGroups.SERVER</code>, it is likely the current thread is on the logical server. Otherwise, it is likely on the logical client. This is useful to retrieve the '''logical''' side when you do not have access to a <code>World</code> object to check <code>isRemote</code>. It ''guesses'' which logical side you are on by looking at the thread group of the currently running thread. Because it is a guess, this method should only be used when other options have been exhausted. In all other cases, you should prefer checking <code>world.isRemote</code> to this check.
-=== FMLEnvironment.dist ===
+=== <tt>FMLEnvironment.dist</tt> ===
 <code>FMLEnvironment.dist</code> holds the '''physical''' side your code is running on, as a value of <code>Dist.CLIENT</code> or <code>Dist.DEDICATED_SERVER</code>. This is determined by the mod loading code, so it always hold the correct value. However, there is little reason to directly query this variable, as most use-cases can use <code>DistExecutor</code> instead (which uses this value internally).
-== @OnlyIn ==
+== <tt>@OnlyIn</tt> ==
 Annotating a method or field with the <code>@OnlyIn(Dist)</code> annotation indicates to the loader that the respective member should be completely stripped out of the definition not on the specified '''physical''' side. Usually, these are only seen when browsing through the decompiled Minecraft code, indicating methods that the Mojang obfuscator stripped out.