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.

[pajawojciech]

The frequency should be a prime number

Fixed

---

You need something like this during report deletion:

world->status.announcements does not contain sparring, combat and hunting reports

---

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?

I set frequency to 1 (every tick) and still can't see any performance impact. Performance check says that one run takes less than 2 ms.
Myk proposition uses buckets and reinserts reports. I think my version is simpler: foreach unit, get sparring reports (or combat and hunting reports if enabled) and remove them from units and from world.status.reports

---

You could probably delete the unit report logs as you're iterating them

I accomplish this using log.clear();

[ab9rf]

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.

While I agree that the magic number should be defined as a symbolic constant, using a prime number doesn't really have anything directly to do with timestream. The idea behind using prime numbers is to avoid phasing with other tools that also run at periodic tick intervals so that two "expensive" tools don't both always, or frequently, run on the same tick, which might lead to visible stuttering for the user.

We've talked about providing a system where tools that need to run periodically request an "approximate frequency" and Core then alllocates them in a uniform manner across all tools so that everyone gets about the frequency they want while avoiding phasing, but this hasn't been implemented yet.

As to 2 ms per tick: this may not seem by much, but please remember that at 100 fps the total per tick budget is only 10 milliseconds and the target time budget for all of DFHack is 5% of that, or 0.5 ms. If you're using 2 ms per tick, that's 4x over budget and thus not remotely acceptable.

Finally, running more often than once per ten ticks is almost certainly overkill. A lot of things in DF happen once every ten, once every 50, or once every 100 ticks. Given this, 97 is probably an especially good number to use, as it falls just below the "once every 100" frequency.

[ab9rf]

This is inefficient, requiring repeated scans of the reports vector for each removal and may have to move elements repeatedly. Consider using std::erase_if instead, which will only make one scan of the vector, and intelligently collapses the gaps.

[ab9rf]

these should all be constexpr