Jump to content

GetModConfigData returns incorrect results without caves


penguin0616
  • Fixed

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! :D


Steps to Reproduce

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: 

 




User Feedback


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

Sign in

Already have an account? Sign in here.

Sign In Now

×
  • Create New...