feat: Gegner-Kampfwerte cachen (weniger ViewPlayer-Calls) #3

Merged
DasAoD merged 1 commit from feature/enemy-fighters-cache into main 2026-08-11 00:14:10 +02:00
Owner

Was

Bisher wurde bei jedem Simulationslauf für jede ausgewählte Gilde die komplette Mitgliederliste erneut per ViewPlayer geholt — auch wenn dieselbe Gilde Sekunden vorher schon simuliert wurde (z. B. um mit anderer Pilz-Anzahl zu vergleichen). Das war der letzte fehlende Baustein: die eigene Seite hatte schon einen Cache, die Gegner-Seite nicht.

Lösung

Neuer EnemyFightersCache (analog zum bestehenden OwnFightersCache, aber als HashMap<Gildenname, Cache>, da mehrere Gegner-Gilden parallel gecacht werden können):

  • Cache bleibt gültig, solange sich das Mitglieder-Roster laut aktuellen Scan-Daten nicht geändert hat und er < 6h alt ist — gleiches Prinzip wie beim eigenen Cache.
  • Wird invalidiert bei Login, Charakterwechsel, Logout.
  • Obergrenze von 100 gecachten Gilden (ältester Eintrag wird verdrängt), damit der Speicherverbrauch bei Nutzung über viele Tage nicht unbegrenzt wächst.

simulate_one_guild ruft jetzt get_enemy_fighters() auf, statt die ViewPlayer-Schleife selbst zu machen — reiner Refactor der bisherigen Fetch-Logik in eine wiederverwendbare, gecachte Funktion. Am Verhalten für eine neue, noch nie simulierte Gilde ändert sich nichts (erster Aufruf holt weiterhin frisch).

Test

cargo build --all-targets kompiliert ohne Warnungen.

🤖 Generated with Claude Code

## Was Bisher wurde bei **jedem** Simulationslauf für **jede** ausgewählte Gilde die komplette Mitgliederliste erneut per `ViewPlayer` geholt — auch wenn dieselbe Gilde Sekunden vorher schon simuliert wurde (z. B. um mit anderer Pilz-Anzahl zu vergleichen). Das war der letzte fehlende Baustein: die eigene Seite hatte schon einen Cache, die Gegner-Seite nicht. ## Lösung Neuer `EnemyFightersCache` (analog zum bestehenden `OwnFightersCache`, aber als `HashMap<Gildenname, Cache>`, da mehrere Gegner-Gilden parallel gecacht werden können): - Cache bleibt gültig, solange sich das Mitglieder-Roster laut aktuellen Scan-Daten nicht geändert hat **und** er < 6h alt ist — gleiches Prinzip wie beim eigenen Cache. - Wird invalidiert bei Login, Charakterwechsel, Logout. - Obergrenze von 100 gecachten Gilden (ältester Eintrag wird verdrängt), damit der Speicherverbrauch bei Nutzung über viele Tage nicht unbegrenzt wächst. `simulate_one_guild` ruft jetzt `get_enemy_fighters()` auf, statt die ViewPlayer-Schleife selbst zu machen — reiner Refactor der bisherigen Fetch-Logik in eine wiederverwendbare, gecachte Funktion. Am Verhalten für eine **neue**, noch nie simulierte Gilde ändert sich nichts (erster Aufruf holt weiterhin frisch). ## Test `cargo build --all-targets` kompiliert ohne Warnungen. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Bisher wurde bei JEDEM Simulationslauf für JEDE ausgewählte Gilde die
komplette Mitgliederliste erneut per ViewPlayer geholt - auch wenn
dieselbe Gilde Sekunden vorher schon simuliert wurde (z.B. um mit
anderer Pilz-Anzahl zu vergleichen).

Neuer EnemyFightersCache (analog zum bestehenden OwnFightersCache,
aber als HashMap<Gildenname, Cache> da mehrere Gilden parallel
gecacht werden können):
- Cache bleibt gültig, solange sich das Mitglieder-Roster laut
  aktuellen Scan-Daten nicht geändert hat UND er < 6h alt ist.
- Wird invalidiert bei Login, Charakterwechsel, Logout (wie der
  eigene Cache).
- Obergrenze von 100 gecachten Gilden, ältester Eintrag wird verdrängt
  (verhindert unbegrenztes Wachstum bei Nutzung über viele Tage).

simulate_one_guild ruft jetzt get_enemy_fighters() auf statt die
ViewPlayer-Schleife selbst zu machen - reiner Refactor der bisherigen
Fetch-Logik in eine wiederverwendbare, gecachte Funktion.

Getestet: cargo build --all-targets kompiliert ohne Warnungen.
DasAoD merged commit b4e72826d9 into main 2026-08-11 00:14:10 +02:00
Sign in to join this conversation.
No description provided.