I'm still investigating what's going on so forgive me for not having all the details but it seems that the wisp faction that is supposed to be peaceful at game start is being set to war under certain circumstances, potentially related to the "rampant" mod.

Using the admin command "/wisp peace" sets the player force peaceful towards the wisp force but does not set the wisp force peaceful to the player force - using the server command "/c game.forces["wisp"].set_cease_fire("player", true)" then correctly sets the wisp force cease fire towards the player force.

I've now tested this without any other mods and the issue remains

With "wisps can retaliate"enabled and "automated defenses target all wisps" disabled, the cease-fire-settings line from /wisp stats is w/p=war/war wa/p=war/war
With wisps can retaliate disabled the line is w/p=war/war wa/p=peace/war

Expected would be w/p=peace/peace wa/p=war/war and w/p=peace/peace wa/p=peace/peace respectively

Adding the following code to wisp_force_init after line 54 results in the expected behavior more or less in single player (player will still be at war with the WA faction with wisps can retaliate disabled)
if wisps.name == 'wisp' then
wisps.set_cease_fire(game.forces.player, true)
game.forces.player.set_cease_fire(wisps, conf.peaceful_defences)
end

E: however this does not work for multiplayer, it appears the issue is in the function wisp_player_aggression_set()

Ok final post I hope:

There are two issues - one that wisp_player_aggression_set() is not called on the player force when a new game is started which is a bug I am not prepared to chase down and two that wisp_player_aggression_set() was completely broken. This simplified version retains all the functionality of the original and works appropriately when combined with my earlier change to wisp_force_init()

local function wisp_player_aggression_set(player_force)
game.forces.wisp.set_cease_fire(player_force, true)
game.forces.wisp_attack.set_cease_fire(player_force, false)
player_force.set_cease_fire(game.forces.wisp, conf.peaceful_defences)
player_force.set_cease_fire(game.forces.wisp_attack, false)
end

E: left out the setup for wisp_attack at first, but it's probably best to assume factions could potentially not default to war.

Thanks a lot for your efforts!

There are two issues - one that wisp_player_aggression_set() is not called on the player force when a new game is started which is a bug I am not prepared to chase down.

I've done this for minime yesterday. In new games, players won't be initialized in on_init (because that is called before any player has joined) and in on_player_joined_game (because players won't get a character before the cutscene ends. I'd be quite surprised if the cutscene wouldn't be the cause of the problem you've described. Will have a look later today -- after I'm done with work in RL. :-)

Yup. I just found an old forum post that mentioned that player.connected, which get_player_forces() checks, is false in on_init starting on 0.14, so that line was never doing anything. I'm still not quite sure why wisp_player_aggression_set() wasn't working, but it's fewer lines to just unroll the loop so may as well.

Thanks for testing indeed, as I've seen people reporting it after 0.18 too, will try to pick this up into older mod as well.

Also, quickly looking over other and planned changes:

removed function definitions from config.lua

Probably hard to merge due to style changes, but Pi-C also suggested to do that yesterday, and I've uploaded new version of the v1 mod with this tweak.

removed anonymous functions from on_nth_tick dispatch tables tasks_monolithic and tasks_entities

I wonder about rationale for these - are they potentially an issue for multiplayer?
Asking because mod's had quite a few desync sources due to my crappy code for a while, and idk about all of them, so wondering if that's one more to the pile :)

wisp_player_aggression_set() is not called on the player force when a new game is started which is a bug I am not prepared to chase down

Apparently was related to somewhat-convoluted init process that I've used there.

"if not (InitState and InitState.configured) then return end" in on_player_change hook was preventing that (broken, ta for the fix) func from running, because InitState.configured was not set.
Adding "if not InitState.configured then Init.state_tick() end" should fix that, as everything mod needs to init should be there at that point (I think?), fixed it in the old mod as well (0.3.2).

(there's a bit of a long story of how that init process came to be, related to https://forums.factorio.com/viewtopic.php?f=7&t=70952&p=430652 - where at some point I just gave up initializing stuff in inter-dependent and sometimes reshuffled "steps" with what becomes available and put whole thing off to do on first tick or any other place where everything is available)

Um, also, sorry to hijack this thread, but I think this can likely cause MP desync cause:
https://github.com/mk-fg/games/blob/1089857/factorio/Will-o-the-Wisps_updated/control.lua#L488-L489
(as it updates file-global var which isn't synced between players, unlike proper "global" ones, apparently missed it when fixing these before)

Which I thought you might want to also fix in The Night Has A Thousand Eyes, given that it's mp-focused.

There are few other issues which "safe mode" snippet uncovered, but I think above one looks the most obvious and aggregious, sitting right at the top of control.lua like that :)

Also, quickly looking over other and planned changes:

removed anonymous functions from on_nth_tick dispatch tables tasks_monolithic and tasks_entities

I wonder about rationale for these - are they potentially an issue for multiplayer?
Asking because mod's had quite a few desync sources due to my crappy code for a while, and idk about all of them, so wondering if that's one more to the pile :)

Anonymous functions are just somewhat difficult to maintain and it's much easier for me to follow control flow when I separate the actual "does stuff bits" from where I dispatch tasks or subscribe to events. It also allows me to change how I go about dispatching things more easily when the two are separated. Generally I use them to call out to a function that actually does the work if they're going to be more than one or two lines long. (or in this case, I just assign the function as a value in the table.)

They "should" be MP-safe but truthfully I'm still learning a lot about factorio's API (and lua, I'm primarily a python programmer these days with rare and terrifying ventures into javascript) so I'm not an expert on desyncs. I'm just simplifying the control flow as much as possible which will make it easier for me to figure out where/when things are changing.

Um, also, sorry to hijack this thread, but I think this can likely cause MP desync cause:
https://github.com/mk-fg/games/blob/1089857/factorio/Will-o-the-Wisps_updated/control.lua#L488-L489
(as it updates file-global var which isn't synced between players, unlike proper "global" ones, apparently missed it when fixing these before)

Which I thought you might want to also fix in The Night Has A Thousand Eyes, given that it's mp-focused.

There are few other issues which "safe mode" snippet uncovered, but I think above one looks the most obvious and aggregious, sitting right at the top of control.lua like that :)

Thank you so much for this, I'll be sure to fix that in my fork.

Oh also, since we're all working on different versions of this right now if we want to keep a chain of communication open regarding this mod without taking over one version's discussions I'd be fine with doing a group email chain - my gmail is CorgskiSA

I've made my final release: Added filtering to entity-removal events, added handlers for script-raised events, and combined some if-then statements with elseif.

About event filtering: You probably should attach the filters directly on registering the events. I've attached them in a function called from on_init, on_configuration_changed, and on_load after a check that a version >=0.18.27 of the base mod is used (0.18.27 is the first version that fully supports event filtering). As your mod is for 1.0, this check isn't needed.

About group email: Sorry, I'm out. :-) With this release, I retire from Will-o'-the-Wisps development. The mod should be in a working state now for anyone still playing Factorio 0.18, and it can still be used with Factorio 1.0. As the original mod has been updated for Factorio 1.0, there is no reason for me to continue -- my mod was meant as a temporary fill-in until the original mod is updated, that has been the plan right from the start. I won't deprecate it, because it is still useful for Factorio 0.18. Also, I may revive it if it should ever be necessary again. But for now, my priority is fixing a heap of bugs in my other mods. But thanks a lot for your help again! Getting bug reports motivated me to finally get active on this. :-)

The other mod currently says it's only for Factorio 0.17. For those of us playing with Factorio 1.0, your mod is our only option.

@PrestonLeeCole: Quoting myself:

I won't deprecate it, because it is still useful for Factorio 0.18. Also, I may revive it if it should ever be necessary again.

I didn't really expect that my fork would be needed so soon again, but as you may have noticed, I've already made a bugfix release since my announcement that I'd quit from working on this mod. :-)

The other mod currently says it's only for Factorio 0.17. For those of us playing with Factorio 1.0, your mod is our only option.

Yeah, it was temporarily rolled back there due to some unforseen events, sorry for confusion, see "bugs and crashes" thread there for more info.
Should probably get it back to 1.0 in a few days, when I can test it myself again and make sure it doesn't grief people by crashing their game all the time, and that post will become relevant again :)

EDIT: posted almost at the same time as ^^^

Y'all are superstars, thanks so much for everything you're doing. Also @mk-fg I haven't replied to your email yet but I will soon