Create plugin for clearing of combat, sparring, and hunting reports with configurable filtering and overlay UI

[pajawojciech]

Summary

Adds a new plugin to automatically clear combat/sparring/hunting reports from buffer. Features configurable filtering by type, overlay UI settings, and control panel integration.

This does NOT hide the left-side notifications on screen:

Features

• Time-triggered clearing: Runs every 100 ticks
• Configurable filtering: Separate toggles for combat, sparring, and hunting logs
• Sparring enabled by default: Targets the most common spam source
• Command interface: Configure via console commands; auto-enables when filters specified
• Overlay UI: Settings panel with enable toggle and filter toggles

• Control panel integration: Plugin in Gameplay tab with autostart options

Usage

logcleaner              - show status
logcleaner enable       - enable plugin
logcleaner disable      - disable plugin
logcleaner sparring     - enable sparring filter (auto-enables plugin)
logcleaner all          - enable all filters (auto-enables plugin)
logcleaner combat,hunting - enable specific filters
gui/logcleaner          - open settings overlay

Tests done

• 50 dwarves training generate ~100-200 reports per 100 ticks
• Cleaning time < 2 ms (minimal performance impact)
• Plugin state persists across save/load
• Autostart works for new embark
• Old fort ran over 1 year, and all wanted reports preserved (my calculations show in this case ~3 years before buffer overflow)

Three tabs are empty

Now you can finally keep your reports clean enough to actually spot when Urist McSad is depressed or when a tantrum spiral starts

Related issues

#3694
#3397

Related PR in scripts repo (gui and autostart)

DFHack/scripts#1536

[Bumber64]

The frequency should be a prime number (e.g., 97) for timestream reasons. This should be defined as a variable near the top, not a magic number in an if statement.

You need something like this during report deletion:

if (report->flags.bits.announcement)
    erase_from_vector(world->status.announcements, &df::report::id, report_id);

(Popups don't need to be handled because they're deleted upon viewing, even if someone was crazy enough to enable them for combat messages.)

Myk has a similar unfinished plugin. He ran into some kind of issue, but I don't remember specifics. Maybe it was the performance impact of unit.reports.log, which is less an issue at the frequency you're running?

You could probably delete the unit report logs as you're iterating them (by doing so in reverse order). I think DF itself leaves these stale entries lying around, which would be good to clean up so we can iterate less.