Fix decoration reward timestamp to prevent duplicate rewards

[AngeloTadeucci]

Summary by CodeRabbit

• Bug Fixes
  • Fixed an issue where decoration experience rewards could be claimed multiple times during a single interior check-in session by implementing proper reward claim tracking.

[coderabbitai]

📝 Walkthrough

Walkthrough

The changes refactor decoration reward timestamp management by moving its update from the GainExp method in the Home model to the InteriorCheckIn method in the HousingManager. This enables prevention of repeated decoration rewards within a single check-in lifecycle through an early return condition.

Changes

Cohort / File(s)	Summary
Decoration Reward Timestamp Management Maple2.Model/Game/User/Home.cs	Removed DecorationRewardTimestamp update from GainExp method; the method now only updates DecorationLevel and DecorationExp based on exp and mastery table.
Housing Check-In Logic Maple2.Server.Game/Manager/HousingManager.cs	Added early return in InteriorCheckIn when DecorationRewardTimestamp is non-zero to prevent repeated rewards; set DecorationRewardTimestamp to current Unix timestamp after awarding decoration experience.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Suggested reviewers

• Zintixx

Poem

🐰 A bunny hops through housing grounds,
Where decorations spin around,
The timestamp now guards the prize,
One gift per visit—no surprise!
Check-in flows with newfound grace, 🏡✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: preventing duplicate decoration rewards by fixing the timestamp logic.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

• 📝 Generate docstrings (stacked PR)
• 📝 Generate docstrings (commit on current branch)

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch claude/fix-decoration-gift-exploit-YVwGL

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@Maple2.Server.Game/Manager/HousingManager.cs`:
- Around line 474-476: After calling Home.GainExp(...) and setting
Home.DecorationRewardTimestamp, immediately persist the home to prevent
duplicate claims by calling SaveHome() (or the existing persistence method)
before sending the client reward packet; update the code path around
Home.GainExp, Home.DecorationRewardTimestamp and
session.Send(CubePacket.DesignRankReward(Home)) to invoke SaveHome() right after
setting the timestamp and ensure any SaveHome() errors are handled/logged.
- Around line 410-412: The current guard uses Home.DecorationRewardTimestamp !=
0 which permanently blocks future rewards; change it to compare the stored
timestamp against the current time window (e.g., same calendar day or
configurable cooldown) instead of checking non-zero. Locate the check around
Home.DecorationRewardTimestamp in HousingManager (the early return) and replace
it with logic like: convert DecorationRewardTimestamp to a
DateTime/DateTimeOffset, get the server local/UTC "today" boundary used by other
rewards, and return only if the stored timestamp falls within the same
day/cooldown as now; also ensure when awarding the decoration reward you update
Home.DecorationRewardTimestamp to the current Unix time (matching the stored
unit) so future comparisons work correctly.