Bug: on_runtime_mod_setting_changed handler crashes when another mod changes a setting from script
kry-picker-extended/scripts/itemcount.lua:48 errors with bad argument #3 of 3 to '__index' (string expected, got nil) whenever any mod writes a runtime-global setting from script. Script-initiated settings changes deliver the event with event.player_index = nil (only changes a player makes through the Mod Settings GUI carry an index — see the API docs for on_runtime_mod_setting_changed), and line 48 appears to index with it unguarded.
Reproduced deterministically: a one-line mod doing settings.global["any-setting"] = { value = ... } triggers it; in multiplayer it surfaces as a repeated chat error. Original user report (triggered via Rail Logistics Daemon’s pause control, but any script-side settings write does it): https://mods.factorio.com/mod/RailLogisticsDaemon/discussion/6a8a23e82d21a8edabe3087b
Suggested fix: early-return when event.player_index is nil (or when event.setting_type ~= "runtime-per-user", if the handler only cares about per-player settings — that also skips other mods’ global settings entirely).

I was wondering why I couldn't trigger this bug, and finally realized this was on 2.0; I completely rewrote the Item Count script in 2.1 and unknowingly resolved that issue already.

I don't know if I wanna backport the whole script to fix such a minor issue (never knew scripts could update mod settings, but it surely must not be all that common, since I've never run into the bug myself).

I get it. Once you start a long pyanodons run updating mods can be a pain resolving all of the conflicts. I will mention that this issue is fixed in 2.1 and it will not get fixed on previous versions. They do have a workaround, I put this option in two places, and it only affects when a player choose it from the Help menu but works fine when selected from the mod > per map settings, so I will recommend them to use it from there.