[Oxyd] [1.1.53] Multiplayer fails silently to sync specific mod settings

[robot256]

This report is the outcome of investigating my LAN headless server issues (viewtopic.php?f=49&t=101460). With certain mods and mod settings, joining the game does not correctly synchronize the mod settings, and causes the client and server to reach different stages of the handshake process. Specifically, the client times out saying "cannot communicate with server", while the server log contains either no mention of the connection attempt or "Refusing connection ... ModSettingsMismatch". This occurs even when the client and server mod settings are identical (manually synchronized).

To reproduce:

Use the attached mod-list.json, mod-settings.dat, and save file. Download Alien Biomes, Dectorio 0.12.5 (version is important), and Asphalt Paving. Start a server, either headless or with the client. With another fresh Factorio install, try to synchronize and connect to the server. It should download the three mods on the first connection attempt, and then fail on the second one without ever presenting the "sync mod settings with server" dialog box.

Removing any one of the three mods from the server results in the settings synchronizing correctly and making the connection. It may even have something to do with vestigial data in this particular mod-settings.dat for mods that are not currently enabled. Another possible contributor is the fact that version 0.12.5 of Dectorio has conditional "require" statements during loading, which may not be triggering the correct error handlers resulting in a silent failure.

If this does not cause an error for some reason, I'll try to find another case that does. I have had some trouble reproducing the problem, but it is very consistent when I reach an affected configuration.

[robot256]

I resolved the problem in my setup by doing the following:

1. Modified the Dectorio mod files so that there are no conditional `require` statements.

2. Rebuilt `mod-settings.dat` from scratch with only the mods needed for my campaign, without any clumsy hex editing like the last one.

3. Copied this new `mods` folder to the headless server.

Doing this resulted in consistent connections to the server and correct operation of mod settings sync logic.

Therefore, I believe the underlying problem from this report is that "mod contents mismatch" errors and "mod settings mismatch" errors created by the scenario I posted are not handled consistently during the multiplayer join and sync process.

[Oxyd]

2. Rebuilt `mod-settings.dat` from scratch with only the mods needed for my campaign, without any clumsy hex editing like the last one.

“Clumsy hex editing”? The core issue here seems to be that your mod settings are corrupted, so when the client receives them it refuses to load them and consequently stops the connection process.

[robot256]

Fair enough... I didn't think I had messed up the file since it still loaded fine in single player. I posted this mostly out of frustration that the error messages didn't point me anywhere near the actual problem. See my other report for what is hopefully a more reasonable deadlock situation that might be fixable.

[Oxyd]

Right. I've done two things here:

• If the client receives something it can't parse, it'll show an error and go back to main menu. It already complained in the log file about corrupt data, but I guess that's easy to miss.
• Loading a save will make use of the same checks that the client balked on, so you won't be able to serve that map in the first place.

[robot256]

That's perfect. Thank you!