Difference between revisions of "Tutorial 1.18 Episode 6"

From McJty Modding
Jump to: navigation, search
Line 48: Line 48:
 
}
 
}
 
</syntaxhighlight>
 
</syntaxhighlight>
 +
 +
In our main mod file we call Config.register like this:
 +
 +
<syntaxhighlight lang="java">
 +
    public TutorialV3() {
 +
 +
        Registration.init();
 +
        Config.register();
 +
 +
        ...
 +
    }
 +
</syntaxhighlight>
 +
 +
A very important note about order here. Even though there seems to be an order here. i.e. first we call Registration.init() and then we call Config.register() that order is actually not important. The only thing both setup methods do is make sure that registration and configuration will kick in at the right time during mod setup. It's up to Forge to decide when this happens. And configuration occurs AFTER registration. This means that you should not use configuration to enable or disable registration of certain objects in your mod. Always register all objects. If you need a config to disable something then either do that through datapacks (disabling the recipe) or perhaps use conditional recipes (more on that in a possible future tutorial).
 +
 +
{{warning|1=Configuration happens AFTER registration but BEFORE FMLCommonSetupEvent!}}
 +
 +
{{warning|1=Server type configuration happens AFTER the world is loaded!}}

Revision as of 06:56, 7 March 2022

Links

Introduction

In this tutorial we explain how you can allow users to configure your mod. The Forge config system uses toml files for configuration. There are three types of configuration:

  • Client: client side configs are only relevant for the client. They are usually related to rendering, sound, and other things that are pure client side. The server doesn't know about these. These config files can be found in the config directoryof the Minecraft instance and so are global over all worlds (single and multi player)
  • Common: common configs are loaded on both the server and the client and are also stored in the global config directory. They are NOT synced which means that the client side version of these configs can differ from the server side version
  • Server: server configs are stored with the server instance (or with the world). They are stored in each <world>/serverconfig directory. Server configs are synced to the clients during connection but a client cannot override them. Note that all configs in the global defaultconfigs directory are automatically used for any new world

So when do you choose common and when do you choose server? Basically server should be the default because that way configs can be different depending on which server you play on. It's the most flexible technique. However for things like worldgen you need to put it in common since server side config doesn't exist yet when the world is first created.

Basic Setup

There are many ways to setup configuration for your mod. In this tutorial we present you one option. Start by making a Config class in the setup package (Config.java on Github). In this class we use the ForgeConfigSpec helper from Forge to generate configs for client, common, and server. We also split the actual setup of the configuration keys for each module in a separate file for clarity:

public class Config {

    public static void register() {
        registerServerConfigs();
        registerCommonConfigs();
        registerClientConfigs();
    }

    private static void registerClientConfigs() {
        ForgeConfigSpec.Builder CLIENT_BUILDER = new ForgeConfigSpec.Builder();
        PowergenConfig.registerClientConfig(CLIENT_BUILDER);
        ModLoadingContext.get().registerConfig(ModConfig.Type.CLIENT, CLIENT_BUILDER.build());
    }

    private static void registerCommonConfigs() {
        ForgeConfigSpec.Builder COMMON_BUILDER = new ForgeConfigSpec.Builder();
        OresConfig.registerCommonConfig(COMMON_BUILDER);
        ModLoadingContext.get().registerConfig(ModConfig.Type.COMMON, COMMON_BUILDER.build());
    }

    private static void registerServerConfigs() {
        ForgeConfigSpec.Builder SERVER_BUILDER = new ForgeConfigSpec.Builder();
        GeneratorConfig.registerServerConfig(SERVER_BUILDER);
        PowergenConfig.registerServerConfig(SERVER_BUILDER);
        ModLoadingContext.get().registerConfig(ModConfig.Type.SERVER, SERVER_BUILDER.build());
    }
}

In our main mod file we call Config.register like this:

    public TutorialV3() {

        Registration.init();
        Config.register();

        ...
    }

A very important note about order here. Even though there seems to be an order here. i.e. first we call Registration.init() and then we call Config.register() that order is actually not important. The only thing both setup methods do is make sure that registration and configuration will kick in at the right time during mod setup. It's up to Forge to decide when this happens. And configuration occurs AFTER registration. This means that you should not use configuration to enable or disable registration of certain objects in your mod. Always register all objects. If you need a config to disable something then either do that through datapacks (disabling the recipe) or perhaps use conditional recipes (more on that in a possible future tutorial).

18px-OOjs_UI_icon_notice-destructive.svg.png Warning: Configuration happens AFTER registration but BEFORE FMLCommonSetupEvent!
18px-OOjs_UI_icon_notice-destructive.svg.png Warning: Server type configuration happens AFTER the world is loaded!