Fix partner history display bugs: division-by-zero, timestamp sync, caching, and sorting

Summary

Fixes multiple bugs in the partner history system that caused incorrect display values and data corruption.

Issues Fixed

1. Division-by-Zero (-2147483648% Satisfaction)

Problem: Average satisfaction displayed as -2147483648% when sex types had zero recorded instances.

Root Cause: UpdateBestSex() and GetAVGSat() divided by sextypeCount without checking for zero, producing NaN which converts to Int32.MinValue.

Fix: Added zero-checks before division in both methods to return 0f instead of NaN.

2. Timestamp Synchronization Between Partners

Problem: Partner A's record says sex with Partner B was 1.6 days ago, but Partner B's record says 0.3 days ago.

Root Cause: Both partners independently called GenTicks.TicksAbs when recording events, capturing slightly different tick values.

Fix:

  • Modified RecordSex() and RecordOrgasm() to accept ticksAbs as parameter
  • Capture timestamp once in SexHistoryComp and pass to both partner records
  • Added ValidatePartnerTimestamps() to detect and repair corrupted saves where bestSexTickAbs > recentSexTickAbs

3. Partner Fields Showing "Unknown" After History Wipe

Problem: After wiping history, only "Best Sex Partner" populated correctly. Other fields showed "Unknown" even when data existed.

Root Cause:

  • UpdateStatistics() initialized mostID/bestID to Keyed.Unknown (localized string), causing dictionary lookups to fail
  • RecentPartnerRecord and FirstPartnerRecord properties didn't call UpdateCache() before accessing values
  • firstPartnerId only set when RJW called RecordFirstTime(), which didn't always happen
  • Best partner selection used < comparison, excluding partners with 0 satisfaction

Fix:

  • Initialize mostID/bestID to string.Empty instead of Keyed.Unknown
  • Converted properties to full getters that call UpdateCache() first
  • Auto-detect and set firstPartnerId in RecordSex() when empty
  • Changed comparison to <= to include zero-satisfaction partners

4. Partner List Sort Order Backwards

Problem: "Most" and "Recent" partner lists showed lowest values first instead of highest.

Fix: Changed OrderBy to OrderByDescending in SexStatusViewModel.cs for Recent and Most modes.

5. Performance Improvement

Problem: Used reflection to access recentSexTickAbs field, causing runtime overhead.

Fix:

  • Added Krafs.Publicizer package to project
  • Changed SexPartnerHistoryRecord fields from protected to internal
  • Replaced reflection with direct field access in ValidatePartnerTimestamps()

Testing

Tested by:

  • Wiping sex history in dev mode and recording new events
  • Verifying all partner fields populate correctly
  • Confirming timestamps match between partners
  • Checking sort order displays highest-first

Files Changed

  • Source/RJWSexperience/SexHistory/SexHistoryComp.cs
  • Source/RJWSexperience/SexHistory/SexPartnerHistoryRecord.cs
  • Source/RJWSexperience/SexHistory/UI/SexStatusViewModel.cs
  • Source/RJWSexperience/SexHistory/UI/SexStatusWindow.cs
  • Source/RJWSexperience/RJWSexperience.csproj
  • Source/RJWSexperience/packages.lock.json

Backward Compatibility

  • Save files with corrupted timestamps are automatically repaired on load via ValidatePartnerTimestamps()
  • Existing saves with "Unknown" partner fields, -2147483648% satisfaction, or incorrect sextype counts may require a dev mode history wipe to fully resolve due to the caching and data integrity fixes
  • New saves and freshly recorded sex events will work correctly without any manual intervention

Merge request reports

Loading