Jump to content

Configuration sync with server


SirWindfield

Recommended Posts

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 by SirWindfield
Link to comment
Share on other sites

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.

I. Stellarium for Minecraft: Configurable Universe for Minecraft! (WIP)

II. Stellar Sky, Better Star Rendering&Sky Utility mod, had separated from Stellarium.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

I. Stellarium for Minecraft: Configurable Universe for Minecraft! (WIP)

II. Stellar Sky, Better Star Rendering&Sky Utility mod, had separated from Stellarium.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Choonster

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Link to comment
Share on other sites

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.

I. Stellarium for Minecraft: Configurable Universe for Minecraft! (WIP)

II. Stellar Sky, Better Star Rendering&Sky Utility mod, had separated from Stellarium.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.