Reckoning

v1.1.6 (2026-05-25)

Full Changelog Previous Releases

• fix: weekly reset (#140)
  • fix: weekly reset
  • bug fixes
  • more fixes
  • more fix
  • more fix
  • more fix
  • more
  • fix
  • fix
  • more fix
  • fix: week-0 completions silently dropped from weekly history
    currentWeek > 0 guard excluded pre-epoch completions entirely, and the
    backfill check (existing.week or 0) > 0 failed to migrate old records
    whose stored week was 0 — so both the new entry and the old-format
    backfill were silently skipped for any week-0 completion.
    Co-Authored-By: Claude Sonnet 4.6 (1M context) noreply@anthropic.com
  • fixes
  • fix
  • more
  • more
  • fix
  • fix: align week math with server, propagate weeklyPoints on broadcast
  • DatabaseUtils.GetCurrentWeek: drop DST-aware Mountain offset; match
    the server's pure-UTC week math so exports submitted shortly after
    Tuesday reset during MDT are no longer rejected as "future week".
  • DatabaseUtils.CompleteAchievement: relax outer week>0 guard to >=0
    for consistency with the backfill (week 0 = pre-launch) check.
  • GuildSyncUtils.BroadcastCompletion: include weeklyPoints in the
    COMPLETION message so peers don't see a stale total until the next
    heartbeat. OnCompletionReceived applies it monotonically and gates
    the timestamp/version overwrite to avoid regressing on out-of-order
    packets.
  • ReckoningAchievementFrame/CommandUtils: treat presence of rec.history
    as implying weekly cadence so accumulated points still show when
    Enums isn't wired up yet during early UI render.
    Co-Authored-By: Claude Sonnet 4.6 (1M context) noreply@anthropic.com
  • fix: weekly history sync edge cases
  • MergeMemberData/UpdateMemberInfo: gate weeklyPoints on lastSeen so
    corrections (correctionSync invalidations, history wipes) propagate
    downward via full sync. Out-of-order packets still take the max.
    Previously the unconditional math.max contradicted OnCompletionReceived's
    documented intent and pinned weeklyPoints at a permanent floor.
  • OnCompletionReceived: create a stub member record when we receive a
    COMPLETION from a sender we have never synced with. Previously the
    broadcast's weeklyPoints was silently dropped until the next full
    SYNC_RESPONSE arrived, so the leaderboard showed 0 weekly points for
    the sender in the meantime.
  • ExportUtils: count one per (achievementId, weekNumber) entry in wh
    so a player with multiple weekly completions sees the true award
    count in the "Exporting N achievements" message.
  • RebuildCompletedFromEngine: prefer the existing on-disk completedAt
    before falling back to time(). On guild-sync rebuilds the engine may
    not have a timestamp for an id, and the previous code silently
    rewrote the historical completedAt to "now", which would change
    correction-sync gating decisions for that record.
    Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com
  • fix: gate weeklyPoints update on broadcast freshness
    OnCompletionReceived previously applied math.max for weeklyPoints with
    no freshness check. If a correctionSync invalidation lowered a sender's
    true weeklyPoints (say 100 → 50) and the corrected total reached us via
    a fresh heartbeat, a delayed older COMPLETION broadcast carrying the
    pre-correction 100 would re-inflate member.weeklyPoints back to 100
    until the next heartbeat arrived (up to 60s of wrong leaderboard data).
    The completion-timestamp gate (ts >= existingTs) already distinguishes
    fresh broadcasts from stale ones; weeklyPoints rides on the same
    authoritative snapshot, so apply the same gate to it.
    Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com
  • fix: empty history table no longer suppresses inv fallback
    The inv-fallback branch in ExportUtils only fires when wh's weekMap is
    empty (all entries failed correctionSync). It walked rec.history first
    and only fell to rec.completedAt in an elseif — so when rec.history was
    a present-but-empty table (e.g., DebugReset cleared the last entry), the
    inner iteration found latestTs=0 and the elseif never ran, leaving no
    inv signal to the server. With a legacy character_achievements row still
    present, getLegacyWeeklyAchievementsForCharacter would silently re-credit
    the achievement on the next import.
    Run both branches sequentially: history first, then rec.completedAt as
    a second-chance source for latestTs.
    Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com
  • fix: preserve history on CompleteAchievement when weekly classification fails
    If aUtils:GetAchievement returns nil for an id (e.g., the achievement was
    removed in a content update but the local db still tracks it), or Enums
    isn't loaded yet, the weekly branch was skipped and the new entry table —
    constructed without a history field — silently destroyed any prior weeks
    on disk. Seed entry.history = existingHistory by default so the weekly
    branch is the only path that mutates it.
  • feat: schedule reset detection at exact week boundary
    PLAYER_ENTERING_WORLD covers login, reload, and zone transitions but
    misses the case of a player who logs in pre-reset and never zones
    through the boundary. A cancellable C_Timer scheduled for next boundary
    +60s slack fires CheckWeeklyReset live; re-armed by both the timer's
    own callback and each PLAYER_ENTERING_WORLD so re-arms don't pile up.

  ---

  Co-authored-by: Claude Sonnet 4.6 (1M context) noreply@anthropic.com