Will-o'-the-Wisps updated deprecated


A glowing enigmatic life form was found to inhabit alien forests at night. Based on the original mod by Betep3akata. Probably won't work in multiplayer.

Content
1 year, 9 months ago
0.16 - 1.1
2.43K
Enemies

b [fixed] Settings Not respected

4 years ago

Wisps continue to attack even with settings 'wisps can retaliate' off.

4 years ago

nvm wrong version of mod, sorry

I am also having this issue, My settings are not being used whenever i use this mod.
I wanted to set the wisps to be passive things just to add some ambiance but i cant stop them from attacking anytime i hit a tree with a car or shoot one accidentally, if i do all the wisps in the area attack me.

4 years ago

I seem to be having the same issue. I installed it for the same reason as B0bwong. All combat-related settings are disabled yet they still retaliate and can be attacked.

4 years ago

This was a bug in two places - broken even before 1.0, and cutscene in 1.0 added another minor incompatibility.
Fixed both in 0.3.2, should work as expected, I think, but do let me know if it still does not.

Btw, there's quick way to check wisp-player aggression settings via console ("tilde" key on the left of "1"), using "/wisp stats" command there.
It should print like like this: "wisps: cease-fire-settings w/p=peace/peace wa/p=war/war w/b=peace/peace wa/b=peace/peace"
There, "wa/p" is always "war/war" (that's relations of "wisp-attack" vs player force(s) - always war), but w/p is the one of regular wisps vs player(s), and should depend on settings (e.g. player can be aggressive to wisps if "turrets shoot wisps" option is enabled). "w/b" and "wa/b" are relations against biters.

Pre-0.3.2, w/p always showed war/war, due to those aforementioned bugs.
0.3.2 should run migration to fix that when installed, and not have this issue in new games.

4 years ago
(updated 4 years ago)

Not completely fixed yet:

  • Player starts game and makes a save.
  • Player quits and changes runtime-global option.
  • Player loads saved game -- changes to settings will be overwritten by saved state.

It's easy to handle in multiplayer where on_player_joined_game triggers whenever somebody joins the game (new player or returning). In single player mode, that event triggers only once, after on_init. Calling Init.settings from on_load is bad, and on_init will only run when a new game is created or when the mod is added to an existing game.

I suggest moving the settings from runtime-global to startup because on_configuration_changed will only trigger in these cases:

Register a function to be run when mod configuration changes. This is called any time the game version changes, prototypes change, startup mod settings change, and any time mod versions change including adding or removing mods.

EDIT: Just realized that isn't such a good idea either, because you'd have to restart the entire game if you want to change a setting … Initializing stuff sure is one of the toughest things about modding! :-D

4 years ago

Hm, will need to test the case you suggested, but I think it should work with how things are now, and if not, gotta be another bug somewhere.

Runtime settings indeed have little to do with on_configuration_changed, and iirc init process here shouldn't even care about these events, as all configuration is done on first game tick or whichever event might come before it, i.e. just apply all settings/changes as necessary whenever the game is ready, not splitting this into steps/events too much.
Might be misremembering something too, will check.

4 years ago

It doesn't work, I've tested:

New game, with "Wisps can retaliate" on. Saved, quit, turned the setting off. Loaded -- and on checking, it was on again. I've just made a thread about this here. I think this is a major limitation of the runtime-global setting type in general, that's why I usually avoid making such settings. :-)

4 years ago

Oh, I see, you mean not an issue with how mod reacts to these, but how factorio handles runtime settings on per-save basis in general, i.e. that it loads runtime settings along with save, not with the game.
But imo that's the expected behavior - these settings are under "Map", so clearly they apply to a specific Map you're playing, why shouldn't they?

4 years ago
(updated 4 years ago)

To be clear, just tested the thing, and here's what I see happening:
- Start new game, "Wisps can retaliate" setting is on by default.
- Save game.
- Quit game, go to main menu, disable "Wisps can retaliate" setting.
- Load game, check menu, see that "Wisps can retaliate" setting in enabled, as it was when game was saved.

This is the both expected and actual result for me, so don't really see the issue.
But can see that it might be unexpected that any settings at all are saved with the game like that, and I guess a complaint about how per-map settings work in factorio.

4 years ago

Oh, I see, you mean not an issue with how mod reacts to these, but how factorio handles runtime settings on per-save basis in general, i.e. that it loads runtime settings along with save, not with the game.

Exactly this. :-=

But imo that's the expected behavior - these settings are under "Map", so clearly they apply to a specific Map you're playing, why shouldn't they?

I'd expect this to be true for multiplayer. where a setting change can only be made by an admin anyway because it affects many players. In single player, I am the admin and want to change things whenever I choose to. Perhaps I'm not the typical player, as I've never come even close to launching a rocket yet, and have been adding/removing mods to/from my game all the time. In this case, it makes sense to check and adjust all mod settings (including runtime-global) before loading the game. Seeing all my changes gone after loading is quite frustrating there. :-)

4 years ago
(updated 4 years ago)

Yeah, maybe on loading screen, same as with mod differences, settings diffs should also be displayed.
And if so, would be nice to have some "use global values" checkbox there to apply your global changes to that save, same as it's done with mod differences (out of necessity, as you can't not apply missing or changed mods, as old ones aren't in the save, unlike settings).
It seem to be a relatively minor feature too, so maybe factorio devs would be open to adding that kind of UI (UI is always so much work though!).

4 years ago

Perhaps I'm not the typical player, as I've never come even close to launching a rocket yet, and have been adding/removing mods to/from my game all the time.

I think that's pretty typical for a relatively deep open-ended games like factorio to not bother exploring some tech paths, like that one.
Don't really consider rocket to be any kind of end-state here myself, more like "produced first cog" milestone, and some mods like Krastorio2 make it explicitly not so.
Kinda same as you might've never built a specific configuration of craft in Kerbal Space Program or never conquered whole map or seen some events in Paradox games.

4 years ago

Yeah, maybe on loading screen, same as with mod differences, settings diffs should also be displayed.
And if so, would be nice to have some "use global values" checkbox there to apply your global changes to that save, same as it's done with mod differences (out of necessity, as you can't not apply missing or changed mods, as old ones aren't in the save, unlike settings).

Basically that would amount to "Trigger on_runtime_mod_setting_changed" when the game loads and "use global values" is unchecked, because the mod must have a way to react to that change.

4 years ago
(updated 4 years ago)

Basically that would amount to "Trigger on_runtime_mod_setting_changed" when the game loads

Yeah, definitely.

"use global values" is unchecked

Such checkbox would probably need better name however, as I've meant "use global values" as in "use values from main menu", while you clearly read it as "use values from in-game globals" :)

4 years ago

Such checkbox would probably need better name however, as I've meant "use global values" as in "use values from main menu", while you clearly read it as "use values from in-game globals" :)

Almost correct. I meant the settings stored in the saved game. These should correspond to what we've stored in the mod's global table, of course, but the game has no chance to know how our global table is structured.

New response