Add Visual Alert when Attacked #2358
Conversation
…on player status. Added functionality to clear seen attack IDs when the player dies and to check for new attacks, ensuring alerts are only activated for non-retreating attacks. This improves the game's responsiveness to player actions and incoming threats.
WalkthroughTracks and records recent outgoing attacks and incoming attacks in AlertFrame, adds retaliation window and alert cooldown constants, prevents duplicate alerts with a seen set, prunes stale tracking state when player is missing/dead, and updates lastAlertTick when an alert is activated. Changes
Sequence Diagram(s)sequenceDiagram
participant Game as Game.ticks()
participant Alert as AlertFrame
participant Out as trackOutgoingAttacks()
participant In as checkForNewAttacks()
participant Seen as seenAttackIds
participant UI as activateAlert()
Game->>Alert: tick()
Alert->>Alert: is player alive?
alt missing or dead
Alert->>Seen: clear()
Alert->>Out: clear()
Alert-->>Game: return
else alive
Alert->>Out: record outgoing attack timestamps
Out->>Out: prune older than RETALIATION_WINDOW_TICKS
Alert->>In: iterate incomingAttacks
loop each incoming attack
In->>Seen: contains(id)?
alt already seen
In-->>Seen: skip
else not seen
In->>Out: check recent outgoing from same attacker (retaliation?)
In->>Alert: is small attack? within cooldown?
alt retaliation OR small OR cooldown
In->>Seen: add(id) // no alert
else
In->>Seen: add(id)
In->>UI: activateAlert()
UI->>Alert: set lastAlertTick = Game.ticks()
end
end
end
In->>Seen: remove ids no longer active
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20–30 minutes
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks✅ Passed checks (2 passed)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🧰 Additional context used🧠 Learnings (5)📚 Learning: 2025-10-20T20:15:28.858ZApplied to files:
📚 Learning: 2025-10-08T17:14:49.369ZApplied to files:
📚 Learning: 2025-10-18T17:54:01.311ZApplied to files:
📚 Learning: 2025-08-24T11:13:08.495ZApplied to files:
📚 Learning: 2025-10-27T09:47:26.395ZApplied to files:
🧬 Code graph analysis (1)src/client/graphics/layers/AlertFrame.ts (5)
🔇 Additional comments (6)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/client/graphics/layers/AlertFrame.ts (1)
80-86: Consider simplifying duplicate validation.The player existence and liveness check here is duplicated in
checkForNewAttacks()(lines 124-127). Since the early return on line 86 guarantees thatmyPlayerexists and is alive when reaching line 96, the check insidecheckForNewAttacks()is redundant.You could remove lines 124-127 to simplify the code, though the duplicate check doesn't cause issues (defensive programming).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/client/graphics/layers/AlertFrame.ts(3 hunks)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-10-18T17:54:01.311Z
Learnt from: sambokai
Repo: openfrontio/OpenFrontIO PR: 2225
File: src/core/execution/FakeHumanExecution.ts:172-173
Timestamp: 2025-10-18T17:54:01.311Z
Learning: In src/core/execution/FakeHumanExecution.ts, MIRVs and ground attacks should not be mutually exclusive. The considerMIRV() method should not short-circuit maybeAttack() - both actions can occur in the same tick.
Applied to files:
src/client/graphics/layers/AlertFrame.ts
📚 Learning: 2025-10-08T17:14:49.369Z
Learnt from: Foorack
Repo: openfrontio/OpenFrontIO PR: 2141
File: src/client/ClientGameRunner.ts:228-234
Timestamp: 2025-10-08T17:14:49.369Z
Learning: In `ClientGameRunner.ts`, the `myPlayer` field is always set when `shouldPreventWindowClose()` is called, so the null check in that method is sufficient without needing to fetch it again from `gameView.playerByClientID()`.
Applied to files:
src/client/graphics/layers/AlertFrame.ts
🧬 Code graph analysis (1)
src/client/graphics/layers/AlertFrame.ts (1)
src/core/game/GameView.ts (1)
myPlayer(592-594)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: 🔍 ESLint
🔇 Additional comments (3)
src/client/graphics/layers/AlertFrame.ts (3)
24-24: Good choice of data structure.Using a Set for tracking unique attack IDs is clean and efficient for duplicate detection.
95-96: LGTM!Clean integration of the new attack detection logic into the tick cycle.
123-149: ****The
incomingAttacks()method is fully typed to returnAttack[](seesrc/core/game/PlayerImpl.ts:1170andsrc/core/game/Game.ts:651), nevernullorundefined. TypeScript's type system guarantees the return value is always an array. The for-loop on line 132 is safe and will not crash.Likely an incorrect or invalid review comment.
…f the player's troops
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/client/graphics/layers/AlertFrame.ts(4 hunks)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-10-20T20:15:28.858Z
Learnt from: sambokai
Repo: openfrontio/OpenFrontIO PR: 2225
File: src/core/execution/FakeHumanExecution.ts:51-51
Timestamp: 2025-10-20T20:15:28.858Z
Learning: In src/core/execution/FakeHumanExecution.ts, game balance constants like MIRV_COOLDOWN_TICKS, MIRV_HESITATION_ODDS, VICTORY_DENIAL_TEAM_THRESHOLD, VICTORY_DENIAL_INDIVIDUAL_THRESHOLD, and STEAMROLL_CITY_GAP_MULTIPLIER are experimental tuning parameters subject to frequent change during balance testing. Do not flag changes to these values as issues or compare them against previous values.
Applied to files:
src/client/graphics/layers/AlertFrame.ts
📚 Learning: 2025-10-08T17:14:49.369Z
Learnt from: Foorack
Repo: openfrontio/OpenFrontIO PR: 2141
File: src/client/ClientGameRunner.ts:228-234
Timestamp: 2025-10-08T17:14:49.369Z
Learning: For the window close confirmation feature in `ClientGameRunner.ts`, the troop count requirement (>10,000 troops) from issue #2137 was intentionally removed because it was arbitrary and troop count can be reported as low despite having significant land. The confirmation now triggers for any alive player regardless of troop count.
Applied to files:
src/client/graphics/layers/AlertFrame.ts
🧬 Code graph analysis (1)
src/client/graphics/layers/AlertFrame.ts (2)
src/core/game/GameView.ts (1)
myPlayer(592-594)src/client/graphics/layers/EventsDisplay.ts (1)
tick(189-253)
2 participants
Description:
Added prominent red alert notifications for incoming land attacks, reusing the existing betrayal alert mechanism. Players will now receive visual feedback when they are being attacked, improving awareness of incoming threats.
Addressing #2355
Please complete the following:
Please put your Discord username so you can be contacted if a bug or regression is found:
kerverse