Trying to sync server -> client configs, but maybe I'm doing it wrong.

[Insane96MCP]

I'm trying to sync server config with client, and I've came up with this IMessage. https://github.com/Insane-96/NetherGoldOre/blob/1.12/common/net/insane96mcp/nethergoldore/network/ConfigSync.java

package net.insane96mcp.nethergoldore.network;

import io.netty.buffer.ByteBuf;
import net.insane96mcp.nethergoldore.lib.Properties;
import net.minecraft.client.Minecraft;
import net.minecraft.util.IThreadListener;
import net.minecraftforge.fml.common.network.simpleimpl.IMessage;
import net.minecraftforge.fml.common.network.simpleimpl.IMessageHandler;
import net.minecraftforge.fml.common.network.simpleimpl.MessageContext;

public class ConfigSync implements IMessage {

	int minNuggetsPerOre, maxNuggetsPerOre, minExperienceDrop, maxExperienceDrop, orePerVein, minY, maxY;
	float veinPerChunk, pigmanAggroChance, pigmanAggroRadius;
	
	@Override
	public void fromBytes(ByteBuf buf) {
		minNuggetsPerOre = buf.readInt();
		maxNuggetsPerOre = buf.readInt();
		minExperienceDrop = buf.readInt();
		maxExperienceDrop = buf.readInt();
		orePerVein = buf.readInt();
		veinPerChunk = buf.readFloat();
		minY = buf.readInt();
		maxY = buf.readInt();
		pigmanAggroChance = buf.readFloat();
		pigmanAggroRadius = buf.readFloat();
	}

	@Override
	public void toBytes(ByteBuf buf) {
		buf.writeInt(Properties.config.drops.minNuggetsPerOre);
		buf.writeInt(Properties.config.drops.maxNuggetsPerOre);
		buf.writeInt(Properties.config.drops.minExperienceDrop);
		buf.writeInt(Properties.config.drops.maxExperienceDrop);
		buf.writeInt(Properties.config.generation.orePerVein);
		buf.writeFloat(Properties.config.generation.veinPerChunk);
		buf.writeInt(Properties.config.generation.minY);
		buf.writeInt(Properties.config.generation.maxY);
		buf.writeFloat(Properties.config.oreProperties.pigmanAggroChance);
		buf.writeFloat(Properties.config.oreProperties.pigmanAggroRadius);
	}

	public class Handler implements IMessageHandler<ConfigSync, IMessage> {

		@Override
		public IMessage onMessage(ConfigSync message, MessageContext ctx) {
			IThreadListener iThreadListener = Minecraft.getMinecraft();
			iThreadListener.addScheduledTask(new Runnable() {
				
				@Override
				public void run() {
					Properties.config.drops.minNuggetsPerOre = message.minNuggetsPerOre;
					Properties.config.drops.maxNuggetsPerOre = message.maxNuggetsPerOre;
					Properties.config.drops.minExperienceDrop = message.minExperienceDrop;
					Properties.config.drops.maxExperienceDrop = message.maxExperienceDrop;
					Properties.config.generation.orePerVein = message.orePerVein;
					Properties.config.generation.veinPerChunk = message.veinPerChunk;
					Properties.config.generation.minY = message.minY;
					Properties.config.generation.maxY = message.maxY;
					Properties.config.oreProperties.pigmanAggroChance = message.pigmanAggroChance;
					Properties.config.oreProperties.pigmanAggroRadius = message.pigmanAggroRadius;
				}
			});
			return null;
		}
		
	}
}

The fact is that I think there's a better way to do so, I find this way clunky. Any advice is appreciated.

Edited October 23, 2018 by Insane96MCP

[V0idWa1k3r]

3 hours ago, Insane96MCP said:

The fact is that I think there's a better way to do so, I find this way clunky.

This is a pretty good way to sync the config values. The only problem with this approach is that when the player leaves the server it's config values will still be the server's so I would also keep a backup copy before accepting server configs and revert to it when the player disconnects.

 

You could iterate the properties in the config, write their values to the buffer prefixing everything with the size of the property map, then read them as raw byte arrays as long as there is something to read from the buffer, then recreate the values in the handler from the byte arrays. This approach is however worse than the one you are using since

• It assumes that all values in the config are 4-byte values(but there are ways around that but that makes the packet way longer and thus adds even more data to be transferred to the client when they log in)
• It will not work well if the config versions differ from client to server(a new mod version or something) but to be fair your current approach won't work either and again there are ways around that but again that would make the packet even longer. 

[Insane96MCP]

I just realized I don't need to do it for useless properties, only for things that may give problems from a client server prospective (e.g. mining speed for a tool, or similar)

[Insane96MCP]

On 10/23/2018 at 2:56 PM, V0idWa1k3r said:

The only problem with this approach is that when the player leaves the server it's config values will still be the server's so I would also keep a backup copy before accepting server configs and revert to it when the player disconnects

I'm having some slight problems reverting config back on logout. I have this event: 

@SubscribeEvent
public static void EventClientDisconnectionFromServer(ClientDisconnectionFromServerEvent event) {
  Properties.config = Properties.localConfig;
  System.out.println(Arrays.toString(Properties.config.hardness.blockHardness) + " " + Arrays.toString(Properties.localConfig.hardness.blockHardness));
}

The problem is that for some reasons the localConfig is changed to the server config too, without anyone touching it. (https://github.com/Insane-96/IguanaTweaksReborn/blob/master/common/net/insane96mcp/iguanatweaks/lib/Properties.java#L26

https://github.com/Insane-96/IguanaTweaksReborn/blob/master/common/net/insane96mcp/iguanatweaks/network/ConfigSync.java#L54)
 

My guess is that since ConfigOptions is static, changing the config object, changes the one in localConfig too.

Edited November 5, 2018 by Insane96MCP

[Laike_Endaril]

If you only want the variables normally controlled by your config to change on the client *for the current session* I would not directly overwrite the variables being controlled by the client's config at all (backup or no).

 

Instead, I would use two variables; the normal client config variables, and a separate set of variables sent by the server, which take precedence over the client ones.  This will prevent any possibility of the actual config file on the client being changed.

 

On the client side, you will of course need to clear the values of the "server-set" when disconnecting from the current server.

[V0idWa1k3r]

9 hours ago, Insane96MCP said:

My guess is that since ConfigOptions is static, changing the config object, changes the one in localConfig too.

Well, yes, if the fields are static then they are not instance-based and thus you can't simply create another instance and be content. You need a different approach.

 

3 hours ago, Laike_Endaril said:

If you only want the variables normally controlled by your config to change on the client *for the current session* I would not directly overwrite the variables being controlled by the client's config at all (backup or no).

 

Instead, I would use two variables; the normal client config variables, and a separate set of variables sent by the server, which take precedence over the client ones.  This will prevent any possibility of the actual config file on the client being changed.

 

On the client side, you will of course need to clear the values of the "server-set" when disconnecting from the current server.

I kinda see your point but this is ultimately more work than the one config idea. Keeping two configs means that you now need to write the ugly:

int hardness = player.isConnectedToAServer() ? ServerConfig.hardness : ClientConfig.hardness;

everywhere(pseudo-code obviously). 

[Laike_Endaril]

5 minutes ago, V0idWa1k3r said:

I kinda see your point but this is ultimately more work than the one config idea. Keeping two configs means that you now need to write the ugly:

int hardness = player.isConnectedToAServer() ? ServerConfig.hardness : ClientConfig.hardness;

everywhere(pseudo-code obviously). 

I was thinking something more like this...

 

Normal config class:

import net.minecraftforge.common.config.Config;

@Config(modid = YourMod.MODID)
public class ClientConfig
{
    public static int powerLevel = 9001;
}

 

CombinedConfig, the class handling the combination ofc:

Spoiler

import io.netty.buffer.ByteBuf;
import net.minecraftforge.common.MinecraftForge;
import net.minecraftforge.fml.common.eventhandler.SubscribeEvent;
import net.minecraftforge.fml.common.network.FMLNetworkEvent;
import net.minecraftforge.fml.common.network.simpleimpl.IMessage;

public class CombinedConfig implements IMessage
{
    public static int powerLevel = ClientConfig.powerLevel;

    public CombinedConfig()
    {
        MinecraftForge.EVENT_BUS.register(CombinedConfig.class);
    }

    @Override
    public void fromBytes(ByteBuf buf)
    {
        powerLevel = buf.readInt();
    }

    @SubscribeEvent
    public static void EventClientDisconnectionFromServer(FMLNetworkEvent.ClientDisconnectionFromServerEvent event)
    {
        powerLevel = ClientConfig.powerLevel;
    }

    @Override
    public void toBytes(ByteBuf buf) {}
}

 

 

At this point, you should simply be able to reference CombinedConfig.powerLevel throughout the rest of your project.  Or you can put a getter in CombinedConfig and make that variable private if you're worried about public access to it.

[Insane96MCP]

On 11/5/2018 at 9:15 PM, Laike_Endaril said:

I was thinking something more like this...

 

Normal config class:

import net.minecraftforge.common.config.Config;

@Config(modid = YourMod.MODID)
public class ClientConfig
{
    public static int powerLevel = 9001;
}

 

CombinedConfig, the class handling the combination ofc:

  Hide contents

import io.netty.buffer.ByteBuf;
import net.minecraftforge.common.MinecraftForge;
import net.minecraftforge.fml.common.eventhandler.SubscribeEvent;
import net.minecraftforge.fml.common.network.FMLNetworkEvent;
import net.minecraftforge.fml.common.network.simpleimpl.IMessage;

public class CombinedConfig implements IMessage
{
    public static int powerLevel = ClientConfig.powerLevel;

    public CombinedConfig()
    {
        MinecraftForge.EVENT_BUS.register(CombinedConfig.class);
    }

    @Override
    public void fromBytes(ByteBuf buf)
    {
        powerLevel = buf.readInt();
    }

    @SubscribeEvent
    public static void EventClientDisconnectionFromServer(FMLNetworkEvent.ClientDisconnectionFromServerEvent event)
    {
        powerLevel = ClientConfig.powerLevel;
    }

    @Override
    public void toBytes(ByteBuf buf) {}
}

 

 

At this point, you should simply be able to reference CombinedConfig.powerLevel throughout the rest of your project.  Or you can put a getter in CombinedConfig and make that variable private if you're worried about public access to it.

With this the problem is that if I have lots of properties I have to double them.

[Laike_Endaril]

1 hour ago, Insane96MCP said:

With this the problem is that if I have lots of properties I have to double them.

If you mean in RAM, then yes, but if the alternative is to keep a copy of the previous value of each config option and reset them to what they were before joining the server, well...that also keeps a 2nd copy of each config option.  Both methods will also require you to reset something when leaving a server.

 

Other than that, my method only has one advantage.  Because mine never touches the client config directly, even if the client's game process is interrupted while connected to a server, their config file will not be corrupted...whereas if you are changing the actual client config, even temporarily, using the server's settings, the server's settings will be their new "client" settings from then on out until they either manually change them or log onto a different server and the same thing happens there.  You could prevent that issue by saving the entire client config to a separate file (not a config file) and deal with saving/loading that, but that would be an over-complicated workaround.

 

And ofc. when I say "the client's game process is interrupted" I mean either...

1. The game crashes

2. The client user ends the game process

3. Probably if the client user presses alt+f4, though I haven't tested that so don't take my word on it

4. The client's power goes out

5. Possibly if the client's OS decides to suddenly force a restart to install updates...

 

It's a bit of a niche advantage, but I don't really see a disadvantage.  That said it's not my mod, that's just how I would do it.

 

 

Edit 1 ===================================

Just in case you were thinking there was a 2nd config FILE, no there is not.  I may have named the class "CombinedConfig" but it doesn't generate or use a config file itself.

Edited November 9, 2018 by Laike_Endaril

[Animefan8888]

@Insane96MCP You could also just reload your config on disconnect or when the client opens another server or a singleplayer world.

[Insane96MCP]

On 11/9/2018 at 4:29 PM, Animefan8888 said:

@Insane96MCP You could also just reload your config on disconnect or when the client opens another server or a singleplayer world.

How I can reload config from file?

[Animefan8888]

8 hours ago, Insane96MCP said:

How I can reload config from file?

You could probably just post a OnConfigChangeEvent to the event bus.