GetModConfigData(modname, true/false/nil) will always return the client data (true) over the server data (false/nil) in a world without caves.
A world with caves does not have this problem thanks to the separation between client and server, which no-caves does not have.
I'm assuming that ModIndex.savedata.known_mods[modname].modinfo.configuration_options is getting overwritten by the client's configuration, since it gets called after the server's config does.
I verified this by manually calling TheSim:GetPersistentString() on the corresponding mod configuration paths for the client and server, and they returned the correct results.
I have linked a video demonstrating the issue.
If you need any additional information or something else, please let me know and I will get back to you ASAP.
Also, if this is one of those issues where you can't really fix it because of mods depending on the broken behavior or something, please still let me know anyway so I can implement the workaround in my own mod. :^)
Thank you for your time!
Compare the results of GetModConfigData with TheSim:GetPersistentString()'s data in ModIndex.LoadModConfigurationOptions
In a world without caves, client options will always take precedence.
Code used to check in video
_G.check = function(client_config) print("checking with client_config =", client_config) local modname = "workshop-2189004162"; local key = "show_world_events" print("GetModConfigData:", GetModConfigData(key, client_config)) local filename = KnownModIndex:GetModConfigurationPath(modname, client_config); TheSim:GetPersistentString(filename, function(safe, res) if not safe then return print('GetPersistentString fails in cave-enabled world X') end; local axd, data = RunInSandboxSafe(res); if not axd then return print('GetPersistentString fails in cave-enabled world Y') end; for i,v in pairs(data) do if v.name == key then print("GetPersistentString:", v.label, ":", v.saved) end; end; end); print'-------------------------------' end
Link to video:
A developer has marked this issue as fixed. This means that the issue has been addressed in the current development build and will likely be in the next update.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!Register a new account
Already have an account? Sign in here.Sign In Now