[General] - Mod-config un-replicated

[lishid]

Bug Submission:

Category: General

Issue Title: Mod-config un-replicated

Issue Description: Server/Host mods that have some kind of config option (for example, different versions of recipe) does not replicate the config options on the client. This causes inconsistencies whenever the server changes certain config option to non-default, where the client would see different recipes than the server recognizes.

Steps to Reproduce: Install a mod with configurable difficulty of recipe. Set a non-default value for server side configuration option.

Login and verify that client-side still sees the default recipe.

(The following mods have an internal workaround to forcefully replicate server config, and thus is NOT adequate for bug reproduction: Large Chest, Rabbit Nest, Craftable Tentacle Spike)

[lishid]

The workaround mentioned is to manually add a component attached to "world_network" prefab, and use netvars to replicate configuration options which then overrides the client's version after joining a server.

[PeterA]

Thanks for posting this @lishid, do you have an example of this bug happening with an existing mod?

[lishid]

For reproduceability, you could use an un-patched version of my mod here: http://pastebin.com/5VydsrFt

 

A server side installation that uses a non-default setting won't cause the client to obtain the same setting, thus the client's crafting recipe would show the default option, or whatever the client configured that mod to be.

 

This is useful for some mods if it's only a visual difference and clients might want to have their own configuration different, but it does break certain mods introducing things that would be otherwise incompatible if not synced through.

 

The best method to fix this, would be to adding a flag for each config option whether it should be synced down from the server before loading the mod. This would allow mod developers to choose which configs are purely graphical or needs to be synced.

[rezecib]

@lishid, That system already exists. The mod config is supposed to propagate from the server, and you can add an extra argument (true) to the GetModConfigurationData calls to force it to load the local config instead. I use this in Global Positions, for example (for whether to show player target indicators on screen all the time or only with the scoreboard up), and it worked when I was testing it.

 

So whatever's going wrong here is a bug and unintended behavior.

[lishid]

@rezecib, I just discovered that such an option exist! Should have looked more carefully.

 

Looking at it now, though, I have not ever set the 'get_local_config' option while the config did not get propagated down. I can do some further testing but I did remember explicitly test that the config wasn't propagated down until I manually did it through a netvar.