Server Configuration Problems

[Jagm]

Hello, I've recently been having problems with server sided config files. My mod (Convenient Recipes) creates a config file in the config folder of the server but it doesn't work. The file works fine client side, but when I edit an option in the server config it doesn't do anything.

 

In the pre-initialisation method I am running this:

 

Configuration config = new Configuration(e.getSuggestedConfigurationFile());

config.load();

//Then my configuration options, for example:

allowChainMailCrafting = config.getBoolean("Chain Mail Crafting", "recipes", true, "Allows the crafting of chain mail armour from iron bars.");

config.save();

 

This all works fine in singleplayer but editing the server's config file doesn't do anything. It seems to be dependent on the client's configuration. Please let me know id I'm doing something stupid. Thank you for your consideration.

[Jagm]

Possibly. This is my only code related to configuration.

[Jagm]

My pre-initialisation method:

 

@EventHandler

public static void preInit(FMLPreInitialisationEvent e){}

 

I think the client being unable to see server config thing is my problem. Do you know of any mods with an example of how to pass server configurations to the client properly?

[Jagm]

I need the config to work on singleplayer worlds and on servers.

[Jagm]

In the load method

 

if(chainMailCrafting){

GameRegistry.addRecipe(new ItemStack(Items.chainmail_boots), new Object[]{"i i","i i",'i',Blocks.iron_bars});

GameRegistry.addRecipe(new ItemStack(Items.chainmail_leggings), new Object[]{"iii","i i","i i",'i',Blocks.iron_bars});

GameRegistry.addRecipe(new ItemStack(Items.chainmail_chestplate), new Object[]{"i i","iii","iii",'i',Blocks.iron_bars});

GameRegistry.addRecipe(new ItemStack(Items.chainmail_helmet), new Object[]{"iii","i i",'i',Blocks.iron_bars});

}

 

Why should that matter?

[Ernio]

Situation:

Client has config with TRUE. Server has FALSE.

You log in on server - client will have recipe, server won't.

 

Try crafting item - it will most likely appear in crafting result but pulling it out will not work.

 

To pass this problem you can use packets that will synchronize value on client once he has logged in, then make new IRecipe that will always ask if the result can be crafted (depending on this boolean).

Otherwise you will be left with client-side void-recipy that will not work, yet be visible.

 

EDIT:

This might have been the dumbest thing I wrote on forums in a long while - please correct me if I am wrong: Are recipes both-sided (like blocks)? If they are server-sided (result from server) then everything above is false.

 

EDIT 2: In case my statement was right:

You should never make registration depend on config. Rather make booleans that will be checked in runtime. E.g: Server has recipe, but client didn't register it. What now?

[artman41]

Situation:

Client has config with TRUE. Server has FALSE.

You log in on server - client will have recipe, server won't.

 

Try crafting item - it will most likely appear in crafting result but pulling it out will not work.

 

To pass this problem you can use packets that will synchronize value on client once he has logged in, then make new IRecipe that will always ask if the result can be crafted (depending on this boolean).

Otherwise you will be left with client-side void-recipy that will not work, yet be visible.

 

EDIT:

This might have been the dumbest thing I wrote on forums in a long while - please correct me if I am wrong: Are recipes both-sided (like blocks)? If they are server-sided (result from server) then everything above is false.

 

EDIT 2: In case my statement was right:

You should never make registration depend on config. Rather make booleans that will be checked in runtime. E.g: Server has recipe, but client didn't register it. What now?

 

If you're going to do this, I would suggest just removing client side configs entirely and depend solely upon server side configs since singleplayer runs it's own server, causing two sets of configs to be necessary.