The mod causes desyncs and we can see from the script.dat that the server and new player joining have different states.
It looks like this is caused by the script.OnLoad function calling ApplySettings which modifies the game state.

Thanks for reporting.
Apparently missed the clear note in the docs of that hook about what is allowed there.
Will probably fix within a day or two, just need to check which hook to move that stuff to and test it properly.

we hot fixed the ApplySettings and it hit the later things below causing different desyncs in MP.

your use local variable under the libs/zones for zones.init that isn't MP safe.
also the use of on_tick_init to rewrite the on_tick event function may differ between server and clients.
in the desync we saw that the mod global "chunk_list" was different between server and client.

I found the Mod Making Factorio discord a great place for peer review/assistance/pointers on these types of things. as I'm not an expert.

Oh, so it's not as simple as one issue and requires avoiding bunch of caveats and a lot of MP testing.
This is troubling, as obviously I don't play factorio multiplayer at all and can't really do the latter, while changing a lot of things is also somewhat difficult as I don't have much spare time to dedicate to this atm.

So guess I'll have to put up a notice that mod is not compatible with multiplayer in general and leave it at that.
If you or anyone else can find and fix/test places where multiplayer issues occur, shouldn't be a problem to merge these fixes into the mod, but don't think I can do it myself.

Thanks again for looking into this, and sorry if it caused you a bit of pain and work, didn't know it was that tricky to have factorio lua stuff to work in multiplayer.

Yea multiplayer requires the code to be written to a more precise standard of compliance with the factorio data cycle. While in SP you can write it in more flexible ways as your client is the server.

If you want a list of things to check that are not sync-friendly, this contains a good list (complete list as far as I've experienced thus far):
https://wiki.factorio.com/Tutorial:Modding_tutorial/Gangsir#Multiplayer_and_desyncs

Do note, there can be singleplayer issues as well if not coded properly.

Thanks.

Seem to be relatively short list, and I think muppet9010 mentioned all issues from there before - local vars, script.on_event from event, on_load stuff - so guess will try to fix all these.
Kinda doubt it'll work reliably without first-party testing anyway, as no code I write ever does :)

Singleplayer issues tend to be easy to spot when playing myself, except for ones that are from various mod interactions.

You can test MP on your own. Download the standalone version of the game and host a server with it (graphics or headless). Then join with your main or other factorio installs.
I run 3 on my pc, 2 clients (windowed) and 1 as dedicated server. So I can shoot real other players when things don't work out 😂

Hm, yeah, though borders on "too much effort" to bother with, when all I really want is working singleplayer version for myself.

Updated the mod, removing all code patterns documented in that wiki article.
But didn't test it in multiplayer myself, so I'd suggest still steering clear of it in actual games (as I assume breaking game for multiple people at the same time is really bad), unless you specifically want to test it or something.
If anyone finds it working without issues there for a reasonable amount of time and save/load cycles, maybe let me know, will remove that mp-compatibility notice.
And if the opposite happens and you know what might be the cause in the code, please leave a note too, might be able to fix it.

removing all code patterns documented in that wiki article.

Nope, spoke too soon, found more locals, will fix them too, eventually...

Fixed last known desync cause I could find in 0.1.7.
If anyone would happen to have it working without issues for long mp games, maybe leave a note here.

in Zones.lua you declare the Lua global ForestArea and then appear to set and read from it within functions. But I can't see where you ensure that each player who loads into an MP game has their ForestArea local variable set to have a fully populated list equal to that the server built up over time?

It's a reference to a global.zones.forest_area, bound in zones.init_refs on new game or game load, via zones.init_refs.
As globals are safe to use and are synced between players, pretty sure that one should be safe, no?

I'm surprised to see SpawnChanceCache local there though, which is even separate from "-- Refs to globals" above it, looks like I managed to miss making that one global too somehow.

I setup a test map with some biters vs wisps in heavy tress. Set so biters and wisps fight. I left it running with heavy-mode turned on to check for desync risk and got the below issue to occur.
https://www.dropbox.com/s/oca2imquotn5muu/wisps%20heavy%20mode%20dumps.zip?dl=0
This is the dump from heavy-mode (game state). If you use a text comparison tool (beyond compare) on to the 2 files you will see that there are different numbers and types of wisps occuring.

I did this as we had odd issues with desyncs in an MP game the other night.

oh I didn't see you'd mapped it in an zones.lua/zones.init_refs()
sorry this code style isn't what I'm used to and I struggle to follow it.

Oh well, thanks for testing.
Guess I'll fix that leftover local, but it's unlikely to ever be stable in multiplayer like that anyway, as I suspected.
(same as with any other code really - either you test it extensively or it doesn't work)

in a large desync report from our MP game I could see in the script.dat that the games random number generator was out of sync between joining client and server. But I couldn't compare the game state data as the files are massive.
Different calling of math.random() would cause the random number generation difference I think, so SpawnChanceCache looks like a valid cause of that. Fingers crossed that is the only remaining issue.

Should be fixed in 0.1.12, maybe indeed the last one of stray locals, but of course still wouldn't suggest messing-up multiplayer games just for this mod.
Don't think math.random() was called differently due to that cache, but its output could've been interpreted in diff ways, which I guess is where difference in wisps on the map might come from.

Just to report it doesn't go well in MP still (i try it from time to time because i like the idea, but don't feel like spending hours to see what's wrong ^^; ). I have a bunch of other mods, so maybe my game is not the easiest point to debug from ( if you want a desync report i can surely generate one, but i didn't see anything inside which is helpful apart CRC differences). Thanks for the work anyway :)

is this investigation still ongoing? Currently we are playing solo but later this year we are going to do some MP ;). I fell in love with this mod during my SP game. Especially now with regrowing tree's :p. Would be cool if we could keep it running in MP. Is it possible if I would run a server locally on my own PC, and connect to that server with my client to generate desync reports? that way I could deliver some input

is this investigation still ongoing?

Haven't done anything beyond what was last state here, i.e. still shouldn't work with MP as of now, as there were no new releases since then.
Don't play or mod factorio these days either, so not sure if maybe RocketManChronicles (current mod owner) has plans to look into it.

Just a word to say I aml (we are ? ) still very interested about MP and this mod :)

-> https://mods.factorio.com/mod/Will-o-the-Wisps_updated-2/discussion/5f32c3abda774079f31f4fba

I guess problem is exactly same as before, like you suggested.