Configuration sync with server

[SirWindfield]

I craeted a configuration file using the new 1.12 annotations offered by forge (@Config). Now I wanted to implement config syncing between client and server. Searching for some time lead to to the following posts here on this forum:

1) 

2) 

As /u/diesieben07 (@diesieben07) mentioned in the second link, the best way is to store the configs both on client side and use the server side config if it is available. But since I am using the forge annotations I do not even have two separate classes with those values (since the fields are static). Do I just set the static fields to the new values received from the server? And if so, how can I tell forge to write my new values to the client config file?

It know how to achieve this using the "old" way with configuration files but I have no idea how to do it with the annotations.

 

Any help is appreciated. Here is the config file if it is needed:

package morethanhidden.restrictedportals.config;

import net.minecraftforge.common.config.Config;

@Config(modid = "restrictedportals")
public class RPConfiguration {

    @Config.Comment("The list of dimension ids.")
    @Config.LangKey("config.name.dimension_ids")
    public static int[] dimensionIds = {-1, 1};

    @Config.Comment("The list of item ids that need to be in the player's inventory while entering a dimension.")
    @Config.LangKey("config.name.item_ids")
    public static String[] itemIds = {"minecraft:flint_and_steel", "minecraft:ender_eye"};

    @Config.Comment({"Specifies the dimensions that require a new key each time a player visits them.", "The used key " +
            "will get removed from the inventory after entering the dimension."})
    @Config.LangKey("config.name.teleport_player_on_fail")
    public static int[] oneTimeUseOnlyKeyDimensionIds = {};

    @Config.Comment({"If set to true, the player will get teleported to his spawn if he fails to enter a dimension",
        "Useful when trying to visit the end, as you would fall into the lava otherwise."})
    @Config.LangKey("config.name.onetimeuse")
    public static boolean teleportPlayerOnFail = true;

    @Config.Comment("The message displayed when a player has not the required items on him")
    @Config.LangKey("config.name.missing_item_message")
    public static String itemMissingMessage = "Please craft the following item to enter %dim%: %item%";

    @Config.Comment("The message displayed when unlocking a new dimension.")
    @Config.LangKey("config.name.dimension_unlocked_message")
    public static String dimensionUnlockedMessage = "You unlocked %dim%!";
}

Edit: It seems that ConfigManager#sync only lets you sync to the fields when you modify the content through the GUI. Is there some way to do it the other way, writing the static fields to the file?

Edited January 13, 2018 by SirWindfield

[Abastro]

How to implement it is just a matter of choice.

You can make a new instance of the RPConfiguration class on client and manually sync the fields. Forge won't do any server-client syncing for you.

 

Or, you could just wait till 1.13 like me, it introduces synchronized data packs.

[SirWindfield]

Making a new instance of RPConfiguration is not possible if you use the @Config annotations since your fields have to be static. 

At least for me, the annotation system has no way to actually set the fields manually since you have not access to the underlying Configuration instance.

@diesieben07 did post solutions, but those did not involve the new annotation system introduced in 1.12.

[Abastro]

13 hours ago, SirWindfield said:

Making a new instance of RPConfiguration is not possible if you use the @Config annotations since your fields have to be static. 

At least for me, the annotation system has no way to actually set the fields manually since you have not access to the underlying Configuration instance.

@diesieben07 did post solutions, but those did not involve the new annotation system introduced in 1.12.

Well, why can't you get and set the fields when it's not final?

Also you can create instance of RPConfiguration since it's not final. You need separate instance than the static one anyway, considering the combined client. Just send sync packet based on the static configuration and setup separate client config with the packet. 

Anyway, forge does not have any tool for this. You have to do it yourself.

[SirWindfield]

Ye but the only way to do the syncing is by making the fields non static so each instance has actually other values, am I right? But that would conflict with the configuration annotation api. Because that api actually expects values to be static. 

Quite upset that those two APIs can't work together. But creating a GUI for a simple Configuration is not hard at all. So I will probably just make the fields non static and use instances then. Thanks.

[Choonster]

Only the fields of the top-level class need to be static, the fields of the other classes need to be non-static.

 

You could create your @Config class such that it has two static fields of the same type, one public (to store the server-side settings and be used by the config system) and one protected (to store the client-side copy of the server-side settings). You can then create the fields for all of your settings inside of the class you used for the fields.

 

Something like this:

@Config(modid = "<modid>")
public class ModConfig {
	
	public static final ConfigOptions serverOptions = new ConfigOptions();
	
	protected static final ConfigOptions clientOptions = new ConfigOptions();	
		
	public static class ConfigOptions {
		public int foo = 1;
		
		public float bar = 3.0f;
		
		public String baz = "baz";
	}
}

 

Edited January 14, 2018 by Choonster

[Abastro]

5 hours ago, SirWindfield said:

Ye but the only way to do the syncing is by making the fields non static so each instance has actually other values, am I right? But that would conflict with the configuration annotation api. Because that api actually expects values to be static. 

Quite upset that those two APIs can't work together. But creating a GUI for a simple Configuration is not hard at all. So I will probably just make the fields non static and use instances then. Thanks.

Ah, I didn't read your code carefully. As Choonster said, you don't have to make every fields static. Just the field holding the whole configuration need to be static. You can create a new class containing all the configuration fields.

You can do as what Choonster said. You can store the client configuration fields in any class/instance you want if you use it properly. I prefer to put it in either the mod instance or the network instance which can be accessed from the mod instance.