fix(killtracker): v2.12 codex tracking#2336
Conversation
📝 WalkthroughWalkthroughKilltracker v2.12 adds complete end-to-end codex tracking: persistent data fields for finds and search counts, event parsing from downstream codex-found messages, weekly reset and backfill support with eligibility gating by a configurable weekly cap, summary reporting with codex totals and status, detailed codex report generation, and external spreadsheet submission for codex records. ChangesCodex Tracking Feature
🎯 4 (Complex) | ⏱️ ~45 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@scripts/killtracker.lic`:
- Around line 425-426: Don't reset $killtracker[:weekly_codex_searches] unless
you also rebuild it; remove the line that sets
$killtracker[:weekly_codex_searches] = 0 or replace it with logic that
recomputes weekly_codex_searches from the same data used to rebuild
$killtracker[:weekly_codex]. Locate the assignments to
$killtracker[:weekly_codex] and $killtracker[:weekly_codex_searches] and either
only zero/recompute weekly_codex or add code to aggregate existing kill
records/events into $killtracker[:weekly_codex_searches] (same
time-window/bucketing logic used for weekly_codex) so the count remains correct
after running the fix.
- Around line 1225-1228: The codex event is currently recording the gem search
counter ($killtracker[:weekly_ascension_searches]) into ev[:searches_week] which
miscounts codex-only eligibility; change the stored value to the codex counter
($killtracker[:weekly_codex]) so that the codex record created at
$killtracker[:codex_found][key] uses $killtracker[:searches_since_codex] and
$killtracker[:weekly_codex] (keep the existing keys searches_since and
searches_week).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: d9d5712d-6b9d-4984-8123-db387ee567f9
📒 Files selected for processing (1)
scripts/killtracker.lic
| $killtracker[:weekly_codex] = 0 | ||
| $killtracker[:weekly_codex_searches] = 0 |
There was a problem hiding this comment.
Don't zero weekly_codex_searches unless you also rebuild it.
This method recomputes weekly_codex, but not weekly_codex_searches. After ;kt fix find count, the codex summary added in this PR will show 0 current-week codex searches until more kills arrive, even if the previous value was correct.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@scripts/killtracker.lic` around lines 425 - 426, Don't reset
$killtracker[:weekly_codex_searches] unless you also rebuild it; remove the line
that sets $killtracker[:weekly_codex_searches] = 0 or replace it with logic that
recomputes weekly_codex_searches from the same data used to rebuild
$killtracker[:weekly_codex]. Locate the assignments to
$killtracker[:weekly_codex] and $killtracker[:weekly_codex_searches] and either
only zero/recompute weekly_codex or add code to aggregate existing kill
records/events into $killtracker[:weekly_codex_searches] (same
time-window/bucketing logic used for weekly_codex) so the count remains correct
after running the fix.
| $killtracker[:weekly_codex] += 1 | ||
| $killtracker[:codex_found][key] = { | ||
| searches_since: $killtracker[:searches_since_codex], | ||
| searches_week: $killtracker[:weekly_ascension_searches], |
There was a problem hiding this comment.
Persist the codex search counter here, not the gem search counter.
Line 1228 stores weekly_ascension_searches into codex events, but codex eligibility is now tracked independently. Once a character is gem-ineligible but still codex-eligible, detailed codex reports, averages, and sheet exports will all undercount because they read ev[:searches_week] from this record.
Suggested fix
$killtracker[:codex_found][key] = {
searches_since: $killtracker[:searches_since_codex],
- searches_week: $killtracker[:weekly_ascension_searches],
+ searches_week: $killtracker[:weekly_codex_searches],
name: name,
room: room,
creature: $killtracker[:creature]
}🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@scripts/killtracker.lic` around lines 1225 - 1228, The codex event is
currently recording the gem search counter
($killtracker[:weekly_ascension_searches]) into ev[:searches_week] which
miscounts codex-only eligibility; change the stored value to the codex counter
($killtracker[:weekly_codex]) so that the codex record created at
$killtracker[:codex_found][key] uses $killtracker[:searches_since_codex] and
$killtracker[:weekly_codex] (keep the existing keys searches_since and
searches_week).
Summary by CodeRabbit
Release Notes