[1.16.4] [SOLVED] Config sync between client/server

[Purplicious_Cow]

I have a general question about Configs in 1.15/1.16. Is there a way to force sync Common config between server and client (where Server is the owner of record)?

 

I have several common config values that should be controlled by the values from the server (when on server). With Common spec, however, users can change Common values client side and the server does not override them. This allows certain players to take advantage of game play by lowering difficulty or enabling features they shouldn't have in a group setting.

 

If I use the Server type spec, this puts all of these 'protected' values into the Server config, which is actually stored within the 'Save' file on the World server. This means that players who use the mod primarily in a single player setting will have to update their config preferences every time they create a new world, which seems like an extraordinary inconvenience for single players.

 

What is the recommended approach for solving this issue? Thank you for any guidance.

 

 

[ChampionAsh5357]

The client spec should be the only config to be applied on the physical client side. Common specs take precedent on whichever physical side holds the logical server. As such, they can consider to be accurate when being applied to the logical server. A common spec should be used when applying to a logical server if it should modify all instances of the underlying world being played. If its a per world configuration, then a server config should take priority.

7 hours ago, Purplicious_Cow said:

This allows certain players to take advantage of game play by lowering difficulty or enabling features they shouldn't have in a group setting.

This is not true. This means that you are trying to execute logical server code on the logical client, which leads to desynchronization. If you really do need to sync the common configuration, you can send a packet. Here is also an unofficial version of the packet docs as well for more reference.

[Purplicious_Cow]

God, sometimes I wonder about my brain. I just tested several cases and proved your point. The bug was in my checking of the configuration value. No need for packets. Maybe another cup of coffee.

[Purplicious_Cow]

Just to put a cap on this one in case anyone falls into this trap, I had originally been confused by the Minecraft Forge notes found in the update to the ModConfig class, where it states that Common and Client sides are not synced, meanwhile the Server side is. 

From https://github.com/MinecraftForge/MinecraftForge/blob/1.16.x/src/main/java/net/minecraftforge/fml/config/ModConfig.java

 

The description below from the Forge code could use some clarification. In the end the COMMON spec was the correct one for the case I presented above, and the error I was seeing was somewhere else in my own code.

 

public enum Type {
        /**
         * Common mod config for configuration that needs to be loaded on both environments.
         * Loaded on both servers and clients.
         * Stored in the global config directory.
         * Not synced.
         * Suffix is "-common" by default.
         */
        COMMON,
        /**
         * Client config is for configuration affecting the ONLY client state such as graphical options.
         * Only loaded on the client side.
         * Stored in the global config directory.
         * Not synced.
         * Suffix is "-client" by default.
         */
        CLIENT,
//        /**
//         * Player type config is configuration that is associated with a player.
//         * Preferences around machine states, for example.
//         */
//        PLAYER,
        /**
         * Server type config is configuration that is associated with a server instance.
         * Only loaded during server startup.
         * Stored in a server/save specific "serverconfig" directory.
         * Synced to clients during connection.
         * Suffix is "-server" by default.
         */
        SERVER;

        public String extension() {
            return StringUtils.toLowerCase(name());
        }
    }

 

Edited January 3, 2021 by Purplicious_Cow