Changes

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.

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.

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.

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 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">

//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));

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

ModLoadingContext.get.registerExtensionPoint(ExtensionPoint.DISPLAYTEST, (() => Pair.of((() => FMLNetworkConstants.IGNORESERVERONLY).asJava, asJavaBiPredicate((_: String, _: java.lang.Boolean) => true))).asJava)

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.