Changes

{{Under construction}}

{{Under construction}}

Creating configs in Forge is fairly simple as Forge provides a ton of tools for configs. In addition, Forge will automatically update their values as the config files are edited and cache the values so you do not need to do so.

Creating configs in Forge is fairly simple as Forge provides a ton of tools for configs. In addition, Forge will automatically update the config values you read in code and will also cache the config values for you.

To begin, create a new class file and add this:

To begin, create a new class file and add this:

</syntaxhighlight>

</syntaxhighlight>

Here, setupConfig method will add to the builder that there should be a "example_int_config_entry" entry in the toml file, it has a default value of 5, and will only accept a user-entered value between 2 and 50. The it assigns that resultant ForgeConfigSpec.DoubleValue to the exampleIntConfigEntry field. Now the exampleIntConfigEntry field can be call with <code>.get()</code> anywhere in our code to get the current config value for that config entry at the time.

Here, setupConfig method will add an config entry to the builder. This defineInRange states that there should be a "example_int_config_entry" entry in the toml file, it has a default value of 5, and will only accept a user-entered value between 2 and 50. The it assigns that resultant ForgeConfigSpec.IntValue to the exampleIntConfigEntry field. Now the exampleIntConfigEntry field can be call with <code>.get()</code> anywhere in our code to get the current config value for that config entry at the time.

There are many kinds of config entries you can make. Some of the more commonly used ones are:

There are many kinds of config entries you can make. Some of the more commonly used ones are:

* .define - takes the default config value.

* .define - takes the default config value.

* .defineInRange - takes the default, the minimum, and maximum config values in that order.

* .defineInRange - takes the default, the minimum, and maximum config values in that order.

* .defineList - takes the default list to use and a validator to run on each list entry when the user tries * to change the config file to make sure it is correctly edited by user.

* .defineList - takes the default list to use and a validator to run on each list entry when the user tries to change the config file to make sure it is correctly edited by user.

Furthermore, you may attach a comment or translation key to your builder that is creating the config entries. And using <code>builder.push("...")</code> and <code>builder.pop();</code> before and after some config entries will put them into a category (comments can be attached to categories as well). Here is a large example of all this:

Furthermore, you may attach a comment or translation key to your builder that is creating the config entries. And using <code>builder.push("...")</code> and <code>builder.pop();</code> before and after some config entries will put them into a category. (comments can be attached to categories as well) Here is a large example of all this:

<syntaxhighlight lang="java">

<syntaxhighlight lang="java">

</syntaxhighlight>

</syntaxhighlight>

Now it is time to register your config file so that Forge can create and read the config file. Doing do, you simply call <code>ModLoadingContext.get().registerConfig</code> and pass in, the <code>ModConfig.Type</code>, the <code>GENERAL_SPEC</code> from your config file, and the name of the config file (make sure you include <code>.toml</code> as well. Like so:

Now it is time to register your config file so that Forge can create and read the config file. Doing so, you simply call <code>ModLoadingContext.get().registerConfig</code> and pass in, the <code>ModConfig.Type</code>, the <code>GENERAL_SPEC</code> from your config file, and the name of the config file. (make sure you include <code>.toml</code> as well) Here's what that would look like:

<syntaxhighlight lang="java">

<syntaxhighlight lang="java">

ModLoadingContext.get().registerConfig(ModConfig.Type.COMMON, ModConfig.GENERAL_SPEC, "modconfig.toml");

ModLoadingContext.get().registerConfig(ModConfig.Type.COMMON, ModConfig.GENERAL_SPEC, "modconfig.toml");

</syntaxhighlight>

</syntaxhighlight>

  '''NOTE:''' Forge will only update the values of your config fields in code after the registry events are finished. Therefore, only attempt to read the config values after the registry events are completed. (FMLCommonSetupEvent and later is safe)

'''NOTE:''' Forge will only update the values of your config fields in code after the registry events are finished. Therefore, you should only attempt to grab the config values after the registry events are completed. (FMLCommonSetupEvent and later are safe)

The ModConfig.Type determines where your config files goes and its behavior. While COMMON is generally used the most, the other config types do have specific uses. A simple summary is:

The ModConfig.Type determines where your config files goes and its behavior. While COMMON is generally used the most, the other config types do have specific uses. A simple summary is:

* ModConfig.Type.COMMON - Exists in the config folder above the mods folder and will apply to all worlds created. (Works for both client and servers)

* ModConfig.Type.COMMON - Exists in the config folder above the mods folder and will apply to all worlds created. (Works for both client and servers)

* ModConfig.Type.CLIENT - Same as COMMON except the config file is only ever loaded on the client. Never on server.

* ModConfig.Type.CLIENT - Same as COMMON except the config file is only ever loaded on the client. Never on server.

* ModConfig.Type.SERVER - Exists only in a world's own config folder ona per-world basis. This is read on both server and on single player as well.  

* ModConfig.Type.SERVER - Exists only in a world's own config folder on a per-world basis. This is read on both server and on single player as well.  

If you are going to have many config files for organization, you make want to put them into a specific folder for your mod within the config folder. Such as <code>configs/modid/blocks.toml</code> and <code>configs/modid/entities.toml</code> However, you would need to make that new folder first as Forge will not do it for you. Example:

If you are going to have many config files for organization, you make want to put them into a specific folder for your mod within the config folder. Such as <code>configs/modid/blocks.toml</code> and <code>configs/modid/entities.toml</code> However, you would need to make that new folder first as Forge will not do it for you. Example: