We started getting mod mismatch errors after the last update.

It appears to be caused by the require statements that are made conitionally based on settings in data-final-fixes.lua on line 12 and data.lua on lines 8-13

The simplest solution is to try to update the mod again, I could mix up the archives, I just don’t see another explanation.

I changed the version to make it more convenient to update.

Version: 0.8.6
Date: 06. 03. 2020.
Bugs:
- mod mismatch error correction

If the error repeats, then we will look for a solution.

the solution to desyncs and mismatches would be to not selectively require files, but conditionally run the code inside them. That way all MP clients have the same checksum for the mod, as if some don't match the server settings then it won't allow the connection

And updating to version 0.8.6 will not help, as I understand it?

Those. to start you need to return the old settings?

Theoretically, I am returning the old settings in version 0.8.7, will you need to sync successfully? And after that, install 0.8.8 where the current settings will be installed, will this help? I just don’t quite understand.

For verification, I can offer

Old settings GoogleDrive - Load-Furn_0.8.7 or GoogleDrive - Load-Furn_0.8.7 (There were 2 archives, I don’t remember what was originally ...)

New settings GoogleDrive - Load-Furn_0.8.8

The mod can still cause a mismatch/desync if the server has different settings than default because there is the chance of the require'd lua files being different. The solution to that is to require all lua files but conditionally call code inside them instead.

I made some changes to 0.8.6 files that were causing the issue: https://drive.google.com/open?id=1X2oa0HAdps01ldx8Sm6_WdMGD7RpNCU9

Line 11 in data.lua

Line 20 and 67 in prototypes/belt/items.lua
Line 3 and 680 in prototypes/belt/entity.lua
Line 22 and 85 in prototypes/belt/recipes.lua

Line 19 and 54 in prototypes/loader/items.lua
Line 95 and 147 in prototypes/loader/entity.lua
Line 20 and 73 in prototypes/loader/recipes.lua

Line 265 and 267 in prototypes/furnaces/recipesFix.lua

I understand that he refers to
data-final-fixes.lua on line 12 of the changes in settings.lua
was
{
type = "bool-setting",
name = "load-furn-legacy",
setting_type = "startup",
default_value = true
order = "c"
},
has become
{
type = "bool-setting",
name = "load-furn-legacy",
setting_type = "startup",
default_value = false,
order = "c"
},
as well as on data.lua on lines 8-13 due to changes in settings.lua
was
{
type = "bool-setting",
name = "logist",
setting_type = "startup",
default_value = false,
order = "b"
},
has become
{
type = "bool-setting",
name = "logist",
setting_type = "startup",
default_value = true
order = "b"
},

From the files that you sent, I understand that on your server it should be like this
{
type = "bool-setting",
name = "load-furn-legacy",
setting_type = "startup",
default_value = true
order = "c"
},
{
type = "bool-setting",
name = "logist",
setting_type = "startup",
default_value = true
order = "b"
},
This is evident from the changes that you sent.

Or you can name the server, I will try to synchronize, so I can make a change until I reach a match

Until changes are made so that lua files are not conditionally loaded based on settings, this problem will never be fixed. So changing settings will not fix this, it is only a bandaid

.

I replaced the files, it should work now, please check
Version: 0.8.7
Date: 06.03.03.20.
Bugs:
- mod mismatch error correction

In the long run, yes. As it would ensure that all clients have the same checksum for the mod.

They shouldn't, in theory break anything (they didn't in my save) but it might be worth double checking to make sure

In many mods, downloading files is done through the settings, I did not think that this could lead to such problems ... although this is logical.
I must say that I played a little on the network, basically it was a single player game.
Honestly, I forgot when I played for the last time, probably a year ago