Hi,
Retried to use this great mod, but desync still happen. I'm pretty sure it comes from this mod (although i have a lot of others) since i added it last and recently.
I play on headless server and from experience, a source of desync is the server continuing to run while no players are present, could it be a reason ?

It was OK while i was in game, i left the game run several hours ok, and it occured when i reconnected. For some reasons, when i try to reconnect it's ok.

Desync report here, if it can help : http://blackdiam.net/factorio/srv19/desync-report-2020-08-11_18-00-43.zip

Thanks !

MP desync with only this mod and no others, from a new game :
https://blackdiam.net/factorio/srv20/desync-report-2020-08-12_13-07-55.zip

To make it happen, i had to move a bit, as it seems staying standing at start location didn't make any desync.
/toggle-heavy-mode doesn't seem to trigger a desync too
In this game, i never used my right click (no tree cut, no stone gathered, etc.) -> it's probably not linked to an active action.

In the desync files it seems the only differences between reference and desync is about random/pollution/spread but i'm no expert on this.

Hi! I'll probably won't have the time to look at that until some time after Factorio 1.0 has been released. I'm still busy with some other mods, plus work in RL demands more time than I'd like right now.

NP, thanks for answer and i'll still give it a look from time to time anyway :)

I could imagine it has to do with a change in Factorio 0.18.28:

Lua functions are now explicitly disallowed in the script 'global' table.

I've just looked at global, and there are functions defined. Scary stuff, what they do is still beyond me. :-)

Could you edit control.lua and replace function Init.globals (lines 892--907) with this code, please?

function Init.globals()
    utils.log('Init: globals')
    local sets = utils.t([[
        wisps wisp_drones wisp_congregations
        uv_lights detectors wisp_attack_entities ]])
    for k, _ in pairs(utils.t([[
            wisps wisp_drones wisp_congregations wisp_attack_entities
            uv_lights detectors zones map_stats work_steps init_state ]])) do
        if global[k] then
          goto skip end
        global[k] = {}
        if sets[k] and not global[k].n then global[k].n = #(global[k]) end
    ::skip:: end
    if not global.conf then global.conf = {} end
    for k, v in pairs(conf_base) do
      if type(v) ~= "function" then
      global.conf[k] = v
      end
    end
    zones.init_globals(global.zones)
end

I'm not at all sure this will fix the desync, but who knows? :-)

Sure, i'll try this and let you know !

Side question, i saw this fork this morning : https://mods.factorio.com/mod/The_Night_Has_A_Thousand_Eyes
Although the author says it's for personal use (i assume therefore this one stays the "official version" ?), maybe he fixed a few things of interest ? Or maybe you're already working together idk :)

Sure, i'll try this and let you know !

Great!

Side question, i saw this fork this morning : https://mods.factorio.com/mod/The_Night_Has_A_Thousand_Eyes
Although the author says it's for personal use (i assume therefore this one stays the "official version" ?), maybe he fixed a few things of interest ? Or maybe you're already working together idk :)

I didn't know yet, but I guess you could say we're working together in a way. I've also been discussing the mod with the previous owner of Will-o'-the-Wisps updated (the original of my fork), so there is hope that we may get somewhere eventually …

So far so good (i left it unattended on background server / client), but it takes sometimes a while - several hours - before "breaking" so i'll tell you back a bit later too.

Side question, out of curiosity, how are the buildings picked for purple wisps ? Just to make sure they are still useful when playing with mods.

Side question, out of curiosity, how are the buildings picked for purple wisps ?

They are just listed here explicitly by prototype type and category:
https://github.com/mk-fg/games/blob/94d962e/factorio/Will-o-the-Wisps_updated/prototypes/changes.lua#L12-L18

They were different in the original mod (iirc they were affecting electrical poles), but I thought it was too annoying and picked buildings that were more rare and concentrated, instead of ones that require to spam pretty much whole base with lamps.
It's probably good to know the list in advance for multiplayer or when choosing whether it's a mod for you, but bit of a mystery seem to be part of this mod's design, and kinda in-line with how it looks/plays.

maybe he fixed a few things of interest ?

I've spotted some aggression fixes so far, though they seem to hard-disable settings for these, so maybe not good for merging.
And not sure what's the actual bug there, but didn't test to see if I can reproduce it either.
(related reports - https://mods.factorio.com/mod/Will-o-the-Wisps_updated/discussion/5e779fd5bc4e78000ec5321c )

And there are a bunch of internal code refactoring, from the oddball style that I've used, but these don't change how stuff works.

I've also been discussing the mod with the previous owner of Will-o'-the-Wisps updated (the original of my fork), so there is hope that we may get somewhere eventually …

I've merged fixes from here and great "strict mode" hack that Pi-C suggested for finding various global-use bugs, so also fixed a bunch of those there.
Don't really have much time to actually play and test the game lately though (work, life, etc), but did want to play 1.0 again, and got back into it recently, though mostly been updating and fixing mods so far, not actually playing (except for one modded game where biters ate me before I could even build assemblers!).

Side question, out of curiosity, how are the buildings picked for purple wisps ?

They are just listed here explicitly by prototype type and category:
https://github.com/mk-fg/games/blob/94d962e/factorio/Will-o-the-Wisps_updated/prototypes/changes.lua#L12-L18

They were different in the original mod (iirc they were affecting electrical poles), but I thought it was too annoying and picked buildings that were more rare and concentrated, instead of ones that require to spam pretty much whole base with lamps.
It's probably good to know the list in advance for multiplayer or when choosing whether it's a mod for you, but bit of a mystery seem to be part of this mod's design, and kinda in-line with how it looks/plays.

So it means that if I play with mods which add other power generation methods (AAI, Pyanodon, etc.) or which add other defenses (Rampant Arsenal), most of the buildings would be "safe" unless i add them manually ? (== there's no way to target "all power-generating buildings" or "military buildings", for example)

I agree that the balance between "interesting" and "bloody annoying" is thin xD Good choice to have removed poles from the list :)

There are a few changes i'd do probably too on my side if no interest for all, like being able to target purple wisps (i don't see why not, and it makes the game unplayable before lamps, which are extremely far in my game). Would give some interest to put defenses also in the inner base, not only on external walls.

Still no desync observed so far, FYI - if i'm not claiming victory too soon :)

Good job !

So it means that if I play with mods which add other power generation methods (AAI, Pyanodon, etc.) or which add other defenses (Rampant Arsenal), most of the buildings would be "safe" unless i add them manually ?

No no, exactly the opposite, as far as I can tell!
(though caveat is that I don't actually play with any of these big mods myself, so don't know for sure)

But the gist is - in factorio, all behavior of an entity (e.g. building) is hard-coded in C++ and determined by its prototype.
(see https://wiki.factorio.com/Prototype_definitions for full list)

So when you want to make a "power-generating building" your choice is to either:

• Pick one of the prototypes and tweak its appearance and parameters that are not hardcoded (e.g. which fluid it consumes instead of steam, at which rate, how many kW generates, etc) - in this case "type" will be same exact "offshore-pump", "boiler", "solar-panel", etc - as these are not just names, they are behaviors that game provides.

• Make arbitrary decorative building and code all its effects in lua, e.g. make resources disappear/appear when its working on each tick - this is bad for performance, hard to implement and generally unnecessary in most cases (as you can cleverly re-purpose game types for many odd uses), so I think rarely done, but again, haven't used too many mods myself, so maybe wrong about this?

And as you can see, purple wisps should affect first category of modded buildings, but probably not the second (unless they end up using same types but disabling attached game behavior).

like being able to target purple wisps

Hmm, that might be impossible, as they're not technically a unit, but rather a cloud of smoke :)
But you can certainly "target" them in other ways, e.g. have mod check if button is pressed and remove them from near-pointer area with a flash.

it makes the game unplayable before lamps

Hmm, that's interesting, guess I tend to progress faster and don't have many of these before getting to lamps and later-game pollution levels.
You can of course just disable their damage in mod settings, but maybe some easier mitigation technique can be devised, ideally with entirely different mechanic than just "kill"?
(e.g. suppress their spawn in polluted forests somehow, or maybe shield stuff...)

Would give some interest to put defenses also in the inner base, not only on external walls.

Actually yeah, that might be the shielding thing I was thinking above.

But you can certainly "target" them in other ways, e.g. have mod check if button is pressed and remove them from near-pointer area with a flash.

Also for turrent-type building, I think this can be done by "find_nearest_enemy" + some clever use of rendering api maybe to draw "fake" firing effects.
It might also be possible to have turrets force-target non-units like smoke, but idk, seems a bit unlikely.

Thanks for all answers, very enlightening !

I'll leave the server run this afternoon (have to go back work :p ) and I'll tell you later about the fix :)

One other interesting tweak in the awesomely-named "The Night Has A Thousand Eyes" fork of this mod that I forgot above is:

removed anonymous functions from on_nth_tick dispatch tables tasks_monolithic and tasks_entities

Idk if or why it might be cause for desync - not smart/knowledgeable-enough about these - but did ask about it here:
https://mods.factorio.com/mod/Will-o-the-Wisps_updated-2/discussion/5f3b667e256045642e1fc9bc

So maybe that's also a potential tweak to make if desyncs will still happen.
A bit unfortunate that they are so probabilistic and hard to test for, but oh well.

Also I think one good advice about these in general (from MP desync thread on other fork of this mod) is to just go and ask in factorio discord for help, where actual factorio devs and people who do know what they are doing hang out.
(though I kinda neglected that advice myself, as it's a bit like firehose of activity in there, near-impossible to follow for me)

It might also be possible to have turrets force-target non-units like smoke, but idk, seems a bit unlikely.

I do that in Water Turrets with fire, by placing a dummy on the fire's location. Turrets will attack the dummy, and if it dies, the script will remove the fire entity.
It's not working optimally yet, it's rather inefficient. But that's also a limitation because the mod currently works with old Factorio versions where event filtering isn't available at all (Factorio <0.18.0) or not for script-raised events (Factorio <0.18.27).

I'll have to check again, it may be possible to attack smoke (or fire, in my case) even without using a dummy entity by generating a separate id that can be used instead of the non-existing unit_number. Would depend on if turrets can be made to auto-attack such entities, perhaps it is necessary to use an entity-with-force, have to check that.

Side question, i saw this fork this morning : https://mods.factorio.com/mod/The_Night_Has_A_Thousand_Eyes
Although the author says it's for personal use (i assume therefore this one stays the "official version" ?), maybe he fixed a few things of interest ? Or maybe you're already working together idk :)

"She" but yes I've been talking to both Pi-C and mk-fg to an extent, between the bug report and some emails respectively. I don't have a ton to add just yet and most of my work has been focused on cleaning up the code in my fork and understanding what's being done where so I can make the somewhat significant changes that I want for my server. A side effect is that it's not as simple as a merge to bring some of the changes (hopefully improvements?) I've been making to the 'official' branch. That said, I do have some changes coming up that might be worth back-porting - eg I just got done cleaning up the console command parser so it uses a modular interface instead of an if..elseif stack, which should make adding new debug commands to the console much easier.

https://media.discordapp.net/attachments/737315017296314459/747629226924048405/unknown.png

E: now with contextual help and localized strings too. (and inconsistent variable formatting)

I just got done cleaning up the console command parser so it uses a modular interface instead of an if..elseif stack, which should make adding new debug commands to the console much easier.
https://media.discordapp.net/attachments/737315017296314459/747629226924048405/unknown.png

E: now with contextual help and localized strings too. (and inconsistent variable formatting)

That looks useful! :-)

I just pushed a new release of my fork if you want to pull it down and take a look. It also has a pseudo-oo version of the console parser I wrote in the file cliEngine.lua although that's almost certainly overkill for this.

Thanks, I'll probably do that later today -- after work. :-D

@digital_pet, mk-fg: May I suggest adding this line to control.lua?

if script.active_mods["gvv"] then require("__gvv__.gvv")() end

There's a new debugging mod around that looks really promising. It will allow you to inspect the global table at runtime if that line is found somewhere in the main chunk of control.lua. There's another mod by the same author which allows tracing event calls. Could be quite useful as well … :-)

Not sure how it'd help with mp desyncs, afaik globals are always synced by factorio and can't be a problem.
But guess if someone does have that mod installed/enabled, they are in the mood to do some debugging, so won't hurt to enable and init it for them, will do.

Nice! :-)

Yes, I know this probably won't help much with MP issues, but there may be other bugs -- and I knew that both of you have been reading this thread, so this seemed a good place to mention it.

Yeah, thanks for bringing it up.

You suggested it just as someone has issues with some weirdness with globals/save in the other mod, so already suggested it to them and enabled it there:
https://mods.factorio.com/mod/Moon_Logic/discussion/5f55071254dbb0ecb39e6908

:-)