rgonsal/comunidadhll
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: add realtime killfeed and player color tasks

Browse Source
This commit is contained in:
devRaGonSa
2026-05-21 19:06:06 +02:00
parent 4d7acb6fc5
commit c5c91d1945
2 changed files with 356 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

187
ai/tasks/pending/TASK-156-current-match-realtime-killfeed-and-home-buttons-layout.md Normal file
View File

@@ -0,0 +1,187 @@
# TASK-156 - Current match realtime killfeed and home buttons layout
Status: pending
## Goal
Refine the current-match kill feed into a real-time FPS-style panel and make the home server card buttons sit at the bottom-right aligned with the map card, without changing unrelated layout.
## Background
The current-match page already has a compact kill feed overlay implemented in `frontend/assets/js/partida-actual.js` and related CSS.
The current visual direction is closer to the goal, but the desired behavior is now more specific:
- The feed should feel like a real-time FPS killfeed screen.
- It should not look like a static list of historical events.
- Each event should show only:
- killer
- weapon icon or compact weapon label
- victim
- The feed should behave like a small rectangular live panel.
- Events should fill from top to bottom in three visual columns.
- As new events arrive, old events should visually shift left and eventually disappear.
- The visible feed must be capped and must not grow indefinitely.
- Repeated polling must not duplicate events or cause visual flicker.
There is also a small home page layout request:
- In the home server cards, only the "Historico" and "Partida actual" buttons should remain.
- Those buttons should sit lower, at the bottom-right, aligned with the map card height.
- Do not change anything else in the home layout.
Current user-observed issues:
- The kill feed is still too much like a list rather than a real-time screen.
- The home server card buttons are still too high and leave unused empty space in the bottom-right corner.
## Files to Read First
- `AGENTS.md`
- `ai/repo-context.md`
- `ai/architecture-index.md`
- `frontend/partida-actual.html`
- `frontend/assets/js/partida-actual.js`
- `frontend/assets/js/main.js`
Inspect the current-match kill feed behavior, current polling/deduplication state, relevant current-match CSS, and the home server card action markup before changing code.
## Expected Files to Modify
Allowed changes:
- `frontend/assets/js/partida-actual.js`
- `frontend/partida-actual.html` if needed
- `frontend/assets/css/historico.css` or relevant current-match CSS
- `frontend/assets/css/styles.css` or home CSS for the server card button alignment
- `frontend/assets/js/main.js` only if the button markup still needs cleanup
- local weapon icon/fallback assets if necessary
- focused frontend validation
## Constraints - DO NOT BREAK
- Do not break `/api/current-match/kills`.
- Do not expose raw AdminLog lines.
- Do not fabricate kill events.
- Do not show stale kills as live kills.
- Do not query RCON directly from the frontend.
- Do not break the current-match scoreboard/header.
- Do not break the historical page.
- Do not break historical match detail pages.
- Do not depend on server #03.
- Do not add external/CDN image dependencies.
- Do not reintroduce the home card "Scoreboard publico" button.
- Do not change the home server card content except button placement/layout if not strictly needed.
- Keep current public scoreboard URLs trusted and without `/games`.
## Implementation Requirements
### 1. Current-match kill feed layout
- Replace any remaining card/list feel with a compact rectangular "live feed screen".
- The feed should visually fit in a bounded panel.
- It should not expand vertically without limit.
- It should show a maximum number of events, for example 12 or 15.
### 2. Event rendering
Each event must show only:
- killer name
- weapon icon or compact weapon badge
- victim name
Avoid noisy timestamp display in the main row unless it is subtle or useful.
### 3. Three-column live flow
- Desktop layout must visually use three columns.
- Events should fill top-to-bottom and then across columns in a predictable way.
- Newer events should be visually prioritized.
- Older events should move/disappear as the capped list updates.
- On tablet/mobile, fall back safely to two columns or one column.
### 4. Real-time behavior
- Preserve `event_id` deduplication.
- Do not duplicate rows on polling.
- Avoid full-panel flicker every poll.
- Keep already-rendered events stable when no new events arrive.
- Add/remove events cleanly when the cap is exceeded.
### 5. Weapon display
- Use local/fallback icons or compact glyph badges.
- Include mappings for currently seen examples:
- `M1 GARAND`
- `MP40`
- `M1A1 THOMPSON`
- `UNKNOWN`
- Unknown weapons should show a generic fallback, not broken image.
- Do not use external URLs.
### 6. Teamkill
- Teamkills must remain distinguishable but compact.
- Do not let teamkill badges dominate the layout.
### 7. Feed copy
- If there are no current events: "Todavia no se han detectado bajas en esta partida."
- If events are current/open-window: "Bajas detectadas en la partida actual."
- If events are fresh but partial: "Cobertura parcial desde AdminLog reciente."
- If stale/no current events: "Sin bajas recientes asociadas a la partida actual."
### 8. Home server card layout
- Ensure only two per-server buttons are visible:
- "Historico"
- "Partida actual"
- Remove/hide "Scoreboard publico" from the home server card.
- Move the two buttons down to the lower-right of the card, aligned visually with the map card at the bottom-left.
- Keep the map card compact and do not enlarge it.
- Do not change the rest of the home content/layout.
- Preserve responsive behavior.
### 9. Validation
- Run `node --check frontend/assets/js/partida-actual.js`.
- Run `node --check frontend/assets/js/main.js` if modified.
- Run `git diff --check`.
- Rebuild frontend if needed.
## Manual Verification Steps
- Open `http://localhost:8080/partida-actual.html?server=comunidad-hispana-01`.
- Open `http://localhost:8080/partida-actual.html?server=comunidad-hispana-02`.
- Verify the kill feed looks like a compact rectangular live overlay.
- Verify each event row shows:
- killer
- weapon icon/badge
- victim
- Verify the feed uses three columns on desktop.
- Verify older events disappear instead of growing endlessly.
- Verify repeated polling does not duplicate events.
- Verify the feed does not flicker on every refresh.
- Verify unknown weapons use a fallback.
- Verify no raw AdminLog line is displayed.
- Open the home page: `http://localhost:8080/`.
- Verify each server card shows only:
- Historico
- Partida actual
- Verify those buttons sit at the bottom-right, visually aligned with the map card.
- Verify no other home page layout area changes unexpectedly.
## Expected Outcome
The current-match kill feed behaves like a compact real-time combat overlay, and the home server card action buttons are cleanly aligned bottom-right with only "Historico" and "Partida actual" visible.
## Outcome
Document the validation performed, notable decisions, and any follow-up task that should be created instead of expanding this task.
## Change Budget
- Prefer fewer than 5 modified files.
- Prefer changes under 200 lines when feasible.
- Split the work into follow-up tasks if limits are exceeded.

169
ai/tasks/pending/TASK-157-current-match-player-team-colors.md Normal file
View File

@@ -0,0 +1,169 @@
# TASK-157 - Current match player team colors
Status: pending
## Goal
Render current-match player/stat rows with team-aware colors/styles consistent with the historical match detail page.
## Background
The current-match page now has a live player/statistics section backed by:
- `GET /api/current-match/players?server=...`
The current implementation is AdminLog-derived and partial/event-derived because:
- RCON `getSession` player counts are unverified.
- No current RCON player-list wrapper exists in the codebase.
- AdminLog kill events can identify players involved in recent/current events.
The user now wants players to be shown like in the historical detailed match page:
- Players should be visually distinguishable depending on team.
- Team coloring should match or be consistent with the historical match detail page.
- The current live stats section should not remain visually generic.
## Files to Read First
- `AGENTS.md`
- `ai/repo-context.md`
- `ai/architecture-index.md`
- `frontend/assets/js/partida-actual.js`
- `frontend/partida-actual.html`
- the historical match detail frontend code and CSS that already color player teams
Inspect the current `/api/current-match/players` payload, the live player rendering, and existing historical detail team classes before choosing frontend or backend changes.
## Expected Files to Modify
Allowed changes:
- `frontend/assets/js/partida-actual.js`
- `frontend/partida-actual.html` if needed
- `frontend/assets/css/historico.css` or relevant current-match CSS
- `backend/app/payloads.py` only if team fields are not currently projected clearly
- `backend/app/rcon_admin_log_storage.py` only if normalized team values need cleanup
- focused tests if backend normalization changes
## Constraints - DO NOT BREAK
- Do not fabricate team values.
- Do not imply the player list is a complete live roster if it is only AdminLog-derived.
- Do not expose raw AdminLog lines.
- Do not expose admin-only/sensitive fields.
- Do not break historical match detail player stats.
- Do not break historical materialization.
- Do not query RCON directly from the frontend.
- Do not depend on server #03.
- Do not show misleading team colors if team is unknown.
- Do not show fake players.
## Implementation Requirements
### 1. RCA first
- Inspect the current `/api/current-match/players` response.
- Determine whether each player row includes team or enough information to infer team safely.
- Compare CSS/classes used by the historical match detail page for team coloring.
### 2. Backend data contract
If player rows already include reliable team values:
- Preserve the existing endpoint and document available team fields.
If team values exist in storage but are not exposed:
- Add normalized team fields to each player row, for example:
- `team`
- `team_label`
- `team_side`
- Use only values supported by AdminLog/current data.
If team is unknown:
- Return null/unknown.
- Do not guess.
### 3. Frontend rendering
- Update the current-match player stats section so rows/cards are styled by team:
- Allied/US/Soviet/Commonwealth/etc. side should use the same or consistent allied styling.
- Axis/Germany side should use the same or consistent axis styling.
- Unknown team should use neutral styling.
- Reuse historical detail team classes if possible.
- If historical detail uses existing CSS modifiers, prefer them over creating conflicting styles.
### 4. Visual requirements
- Player name should be readable.
- Team color should be visible but not overwhelming.
- Team badge/label may be shown if useful.
- Partial/event-derived confidence must remain visible.
- The section should not look like a final historical table unless data is complete.
### 5. Sorting
- Preserve current sorting if implemented:
- kills descending
- deaths ascending
- name
- If not implemented, add stable sorting consistent with current endpoint.
### 6. Empty state
If no player data exists:
- Show: "Todavia no hay estadisticas fiables de jugadores para esta partida."
### 7. Partial state
If stats are AdminLog-derived:
- Show: "Estadisticas parciales derivadas de eventos recientes."
- Do not imply this is the complete roster.
### 8. Tests
If backend changes are made, add/update focused tests for:
- team fields are projected when available
- unknown team remains unknown/neutral
- no raw AdminLog exposure
- unsupported server rejection still works
- partial/event-derived metadata is preserved
### 9. Validation
- Run `python -m compileall backend/app` if backend changed.
- Run focused backend tests if changed.
- Run `node --check frontend/assets/js/partida-actual.js`.
- Run `git diff --check`.
## Manual Verification Steps
- Call `Invoke-RestMethod "http://localhost:8000/api/current-match/players?server=comunidad-hispana-01" | ConvertTo-Json -Depth 20`.
- Call `Invoke-RestMethod "http://localhost:8000/api/current-match/players?server=comunidad-hispana-02" | ConvertTo-Json -Depth 20`.
- Verify player rows include team/side data when available or unknown/null when not.
- Open `http://localhost:8080/partida-actual.html?server=comunidad-hispana-01`.
- Open `http://localhost:8080/partida-actual.html?server=comunidad-hispana-02`.
- Verify live player/stat rows are colored by team when team is known.
- Verify unknown-team players use neutral styling.
- Verify the section clearly indicates partial/event-derived stats.
- Verify no fake complete roster is implied.
- Verify historical match detail player colors still work.
## Expected Outcome
The current-match player/stat section uses team-aware colors consistent with the historical detail page while remaining honest about partial/event-derived live data.
## Outcome
Document the validation performed, notable decisions, and any follow-up task that should be created instead of expanding this task.
## Change Budget
- Prefer fewer than 5 modified files.
- Prefer changes under 200 lines when feasible.
- Split the work into follow-up tasks if limits are exceeded.