69 lines
3.6 KiB
Markdown
69 lines
3.6 KiB
Markdown
# Planung und Quellen
|
|
|
|
Dieser Ordner fasst Ideen, Skizzen, Kopien von Mockups und andere Rohdaten zusammen, die nicht im Webroot liegen sollen.
|
|
|
|
Beispiele:
|
|
- Notizen zur UI-Story oder zum Menüfluss
|
|
- Wireframes im SVG/PNG-Format
|
|
- Prototyp-Dateien (.psd, .xd, .fig, ...)
|
|
- Auszug aus Konzeptpapiere oder Projekt-Backlog
|
|
|
|
Trage neue Einträge ein, bevor du sie weiterverarbeitest und eventuell in `web/` übernimmst.
|
|
|
|
---
|
|
|
|
## Offene Punkte & Plan: Auto-Cost + Temperatur-UI (SSOT v1.2)
|
|
|
|
### Kontext (SSOT)
|
|
- Auto-Cost (Kosten/Bauzeit automatisch aus Effekten ableiten) gemäß SSOT v1.2.
|
|
- Temperatur bleibt **als °C gespeichert** und soll in der UI angezeigt werden.
|
|
|
|
### Entscheidungen
|
|
- **Auto-Cost-Profile (Option 3):**
|
|
- `auto_cost_profile` im Blueprint hat Vorrang.
|
|
- Fallback über Tags (z. B. `auto_cost:resource` → Profil `resource`).
|
|
- Profile zentral in **neuer** Konfig `config/auto_cost_profiles.json`.
|
|
- Optionaler `auto_cost_override` pro Blueprint für gezielte Abweichungen.
|
|
|
|
### ToDos (geplant)
|
|
1) **UI-Temperatur dynamisch anbinden**
|
|
- Ressourcen-Partial erweitert (Desktop/Mobile).
|
|
- UI-Update liest `planet.temperature_c` aus State-Response.
|
|
|
|
2) **Auto-Cost/Score berechnen (SSOT-konform)**
|
|
- Effekt-Schema auf `amount` ausrichten.
|
|
- Effekte: produce/consume/convert/capacity_add/queue_slots_add/points_add/modifier_add/grant_capability.
|
|
- Deterministische Score → cost/build_time Ableitung.
|
|
|
|
3) **Auto-Cost-Profile & Weights**
|
|
- Neue Konfig `config/auto_cost_profiles.json` mit Profilen + Tag-Mapping.
|
|
- Gewichtstabelle/Multiplikatoren per Profil (dynamisch erweiterbar).
|
|
|
|
4) **EventQueue-Integration (generisches Modul)**
|
|
- Auto-Cost nur bei `auto_cost: true` oder fehlenden `cost/build_time`.
|
|
- Bestehende Blueprints mit festen Kosten bleiben unverändert.
|
|
- **EventQueue gilt pro Planet (planet_id), nicht account-weit.**
|
|
- **Getrennte Queues pro Kategorie** (z. B. Gebäude, Schiffe, Verteidigung, Klonen):
|
|
- Jede Kategorie hat **eigene Slot-Limits** (z. B. Gebäude: 2/Planet; Schiffe: 10/Werft; Verteidigung: 100/Station).
|
|
- Slots entstehen durch passende Gebäude/Capabilities je Kategorie.
|
|
- **Gemeinsame Job-Tabelle** mit `job_type` (Kategorie) + `planet_id`, damit Abarbeitung/Services wiederverwendbar bleiben.
|
|
- Module registrieren neue `job_type`/Limits deklarativ (kein Kernel-Patch).
|
|
- **Queue-Löschung (modulgesteuert)**:
|
|
- Job-Record enthält `origin_module` (welches Modul den Eintrag erzeugt hat).
|
|
- Job-Record enthält `is_deletable` (true/false), damit das System Löschbarkeit prüft.
|
|
- Beim Löschen wird **ein Modul-Event** (z. B. `onEventCancelled`) an `origin_module` gesendet.
|
|
- Queue-gebundene Typen (Build/Forschung/Produktion) verdichten `queue_position` und berechnen Start/Finish neu.
|
|
- Fixzeit-Events (z. B. Flottenbewegungen) bleiben unverändert; keine Positions-Verdichtung.
|
|
- **Forschung**: nutzt dieselbe Job-Tabelle, aber **account-weiten Scope** (z. B. `scope_type=account`, `scope_id=user_id`) und `job_type=research`.
|
|
|
|
### Akzeptanzkriterien (grün wenn …)
|
|
- UI zeigt `temperature_c` für aktuellen Planeten (°C) in Desktop + Mobile.
|
|
- Auto-Cost berechnet deterministisch aus Effekten & Profil-Weights.
|
|
- `auto_cost_profile` überschreibt Tag-Fallback; `auto_cost_override` wirkt auf einzelnes Blueprint.
|
|
- BuildQueue nutzt Auto-Cost nur bei `auto_cost` oder fehlenden Kosten.
|
|
|
|
### Risiken/Notizen
|
|
- Effekt-Schema mismatch (`value` vs `amount`) muss konsistent gelöst werden.
|
|
- Unvollständige BuildQueue-Integration darf bestehende Flows nicht brechen.
|
|
- Konfig muss erweiterbar bleiben (neue Kategorien zur Laufzeit).
|