[lex]

Stacked on #1654 (Update to Factorio 2.1): until that merges this diff includes its commits too. The change for review is one commit: compare factorio-2.1...event-registry-debug.

RedRafe's commit from #1569, cherry-picked (it keeps his authorship). Under _DEBUG, utils/event_core keeps a count of the handlers registered per event (by name, e.g. on_player_created, plus on_init, on_load and on_configuration_changed) and writes it to script-output/event_handler_registry.json each time one is added, to see which events a scenario listens to. Without _DEBUG nothing changes.

It doesn't depend on 2.1, but develop no longer runs on a 2.1 install, so it's stacked to be tested there. On a local 2.1.23 the develop, crashsite and diggy templates pass (58, 90 and 71 passed, 0 failed); luacheck .: 0 warnings / 0 errors.

🤖 Generated with Claude Code

[grilledham]

Is this something you think would be useful? if so we can merge it. But I don't think I'd make use of this, so if you wouldn't make use of this either then I think we can abandon this instead. Of course, that doesn't mean we can't change our minds later and add this later.

[lex]

I wouldn't use it either, so let's close it.

What it writes is how many handlers each event has (on_player_created: 12, on_tick: 5), rewritten to script-output on every Event.add while the scenario loads. When an event goes wrong, the count is rarely the question: a slow on_tick or a handler registered twice wants to know which modules registered them, and the counts can't say. When we've chased event problems lately, the stack trace in factorio-current.log or a quick probe was enough.

If we want it later, I'd rather have each handler's source (file and line, from debug.getinfo) recorded as it's added, and a debug command that prints them for one event on demand, instead of a file written on every registration.