Mod settings setting_type = "startup" causes mod mismatch

Bugs that are actually features.
UberWaffe
Fast Inserter
Fast Inserter
Posts: 202
Joined: Mon May 04, 2015 4:53 am
Contact:

Mod settings setting_type = "startup" causes mod mismatch

Post by UberWaffe »

Did a quick search, did not see a similar topic.

Basically, if you have ingame mod settings

Code: Select all

settings.lua
of the type

Code: Select all

setting_type = "startup"
then if the users do not have the exact same settings, the game will give you and error that the mods mismatch even though their versions match.
(Have not tested other setting types.)

This is misleading, and the message should rather be that the mod settings differ for settings that are not player specific.
Better yet, it should ask to apply the host's settings to the client.

This might be a case where a symptom (different entities or recipes or techs) is the result of mod setting types that affect game state. (I.e. startup type settings).
If this is the case, I would still suggest that:

Code: Select all

If mod startup type setting differ AND versions match then
   message about settings mismatch
else if versions match AND startup settings match AND CRC mismatch then
   message about mods mismatch even though same version

Rseding91
Factorio Staff
Factorio Staff
Posts: 14093
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: Mod settings setting_type = "startup" causes mod mismatch

Post by Rseding91 »

UberWaffe wrote:Did a quick search, did not see a similar topic.

Basically, if you have ingame mod settings

Code: Select all

settings.lua
of the type

Code: Select all

setting_type = "startup"
then if the users do not have the exact same settings, the game will give you and error that the mods mismatch even though their versions match.
(Have not tested other setting types.)

This is misleading, and the message should rather be that the mod settings differ for settings that are not player specific.
Better yet, it should ask to apply the host's settings to the client.

This might be a case where a symptom (different entities or recipes or techs) is the result of mod setting types that affect game state. (I.e. startup type settings).
If this is the case, I would still suggest that:

Code: Select all

If mod startup type setting differ AND versions match then
   message about settings mismatch
else if versions match AND startup settings match AND CRC mismatch then
   message about mods mismatch even though same version
That's not how Factorio prototypes work.

All mod script files must be identical between all players - if the lua files differ then it's an error - and you get the message you're seeing.

When one peer doesn't have a setting defined in the Lua the game has no idea the setting even exists. It doesn't generate an ID for it and when you ask it "give me this setting" by name it has no idea what you're talking about.

The values of the settings are possible to sync between peers - which is what the game will do. But the contents of each script file must be identical between everyone.
If you want to get ahold of me I'm almost always on Discord.

UberWaffe
Fast Inserter
Fast Inserter
Posts: 202
Joined: Mon May 04, 2015 4:53 am
Contact:

Re: Mod settings setting_type = "startup" causes mod mismatch

Post by UberWaffe »

Apologies, it was late and I explained that badly and without steps to reproduce.

I'll double check the steps to reproduce tonight, but here is what we had experienced:
  • Both players subscribe the the ScienceCostTweaker mod.
  • The default for the mod's setting "sct-difficulty-cost" is "normal"
  • One player (in our case the host) changes the setting ingame to "uberwaffe" (one of the options available).
  • The game will restart for the player that changed the setting (It is of type setting_type = "startup"), and the mod will apply the changes to the prototypes (see script below)
  • Player now hosts a multiplayer game.
  • Second player tries to join the game. Gets a warning that says that the mods differ even though their versions match.
  • Second player goes to 'New Game' and opens mod settings.
  • Second player also changes the setting to "uberwaffe"
  • Game restarts for second player
  • Second player can now join the hosted game without getting the message.
The script the mod runs that relates to the setting affects prototypes (hence why I made it a startup type). See below if checking it will help, but in short it adjusts the costs of technologies & recipes based on the option chosen.

Code: Select all

if (settings.startup["sct-difficulty-cost"].value ~= "noadjustment") then

	-- Select the cost file depending on which one is requested.
	costConfig = "configs.costs." .. settings.startup["sct-difficulty-cost"].value
	require(costConfig)

	-- Iterate through all research, and update the costs as configured.
	for index,tech in pairs(data.raw.technology) do 
		-- First, determine the tier of the research, by looking at what types of science packs is used in its research cost.

		tier = 1
		multiplier = sciencecosttweaker.costs.tier1;
		for Index, Value in pairs( tech.unit.ingredients ) do
			if (tier < 2 and tech.unit.ingredients[Index][1] == "science-pack-2") then
				tier = 2
				multiplier = sciencecosttweaker.costs.tier2;
			end
			if (tier < 3 and tech.unit.ingredients[Index][1] == "science-pack-3") then
				tier = 3
				multiplier = sciencecosttweaker.costs.tier3;
			end
			if (tier < 4 and tech.unit.ingredients[Index][1] == "military-science-pack") then
				tier = 4
				multiplier = sciencecosttweaker.costs.military;
			end
			if (tier < 5 and tech.unit.ingredients[Index][1] == "production-science-pack") then
				tier = 5
				multiplier = sciencecosttweaker.costs.production;
			end
			if (tier < 6 and tech.unit.ingredients[Index][1] == "high-tech-science-pack") then
				tier = 6
				multiplier = sciencecosttweaker.costs.hightech;
			end
			if (tech.unit.count_formula ~= nil) then
				tier = 999999
				multiplier = sciencecosttweaker.costs.formula;
			end
		end

		-- If a multiplier is defined for this tier, then apply it.
		if (multiplier ~= nil) then
			local unitCopy = table.deepcopy( tech.unit )

			unitCopy.time = math.max(unitCopy.time * multiplier.time, 1);
				
			-- Now, since infinite research follows a slightly different layout, we have to account for that here.
			-- Only adjust the count if it has a count field
			if (unitCopy.count ~= nil) then
				-- Now adjust by the modifiers for this tier
				unitCopy.count = math.max(math.floor(unitCopy.count * multiplier.stepCount), 1);
			
				for Index, Value in ipairs( unitCopy.ingredients ) do
					-- For each type of science pack, multiply its count per research step by the given multiplier
					local ingredientName = Value[1]
					if (multiplier.cost[ingredientName] ~= nil) then
						local ingredientCostCount = Value[2]
						local mult = 1
						
						mult = multiplier.cost[ingredientName]
						ingredientCostCount = math.floor(ingredientCostCount * mult)
						ingredientCostCount = math.max(ingredientCostCount, 0);
						
						Value[2] = ingredientCostCount
					end
				end
			end
			
			-- If the tech uses a count formulae instead, then adjust the formula by wrapping it in our added strings
			if (unitCopy.count_formula ~= nil) then
				unitCopy.count_formula = multiplier.prefix .. unitCopy.count_formula .. multiplier.postfix
			end
			
			tech.unit = unitCopy
		end
		
	end
end

Rseding91
Factorio Staff
Factorio Staff
Posts: 14093
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: Mod settings setting_type = "startup" causes mod mismatch

Post by Rseding91 »

Ah, you're changing the prototype file contents when you use "require" conditionally based off the mod setting.

You can't do that or it won't work. You'll need to always require all files then just don't add them through data:extend based off the setting.
If you want to get ahold of me I'm almost always on Discord.

UberWaffe
Fast Inserter
Fast Inserter
Posts: 202
Joined: Mon May 04, 2015 4:53 am
Contact:

Re: Mod settings setting_type = "startup" causes mod mismatch

Post by UberWaffe »

Ah, that makes sense. Thanks.
I'll see how I can rewrite this then.

Post Reply

Return to “Not a bug”