Refactor production cost calculations and SQL query: Updated the QUERY_GET_BEST_PRODUCTION to implement a legacy formula for ranking based on effective market percentage and knowledge levels. Adjusted the calculation logic for costs and clarified documentation to ensure consistency with the new pricing strategy. Enhanced SQL query structure for improved clarity and performance in production worth assessment.
All checks were successful
Deploy yourpart (blue-green) / deploy (push) Successful in 2m41s
All checks were successful
Deploy yourpart (blue-green) / deploy (push) Successful in 2m41s
This commit is contained in:
@@ -43,15 +43,14 @@ effektiv_stückkosten = raw × (1 − discount)
|
||||
|
||||
## Ranking in SQL (`QUERY_GET_BEST_PRODUCTION`)
|
||||
|
||||
Sortierung nach **Gewinn pro Minute**, mit **demselben Verkaufs-Modell** wie `DirectorWorker::compute_piece_price_for_percent` / `compute_piece_sell_price` in `director.rs`:
|
||||
Sortierung nach einer **Legacy/UI-Formel** (historisch C++), damit die Reihenfolge zur **Produkt-Ertrags-Tabelle** passt — **nicht** identisch mit dem tatsächlichen Verkauf im Tick (`compute_piece_sell_price` in `director.rs`).
|
||||
|
||||
1. **Regionaler Basispreis:** `sell_cost × (worth_percent / 100)` — mit Fahrzeug `MAX(worth_percent)` über alle Filialregionen des Users, sonst nur Region der Direktor-Filiale.
|
||||
2. **Wissensband:** effektiver Verkaufspreis = Basis × **`0.6 + 0.4 × (k/100)`** mit k = Wissen 0…100 (linear zwischen 60 % und 100 % der Basis). Entspricht `min_price + (max_price − min_price) × k/100` mit `min = 0.6 × Basis`, `max = Basis`.
|
||||
3. **k:** `(2 × knowledge Spielercharakter + knowledge Direktor) / 3` aus `falukant_data.knowledge` (Produktzeilen für Charakter bzw. Direktor).
|
||||
4. **Stückkosten:** wie `piece_production_cost` (siehe oben).
|
||||
5. **Formel:** `(Verkaufspreis/Stück − Stückkosten) / production_time`. **Steuer** im Ranking nicht abgezogen.
|
||||
1. **Effektiver Markt-Prozentsatz:** `worth_percent + (2 × knowledge Spielercharakter + knowledge Direktor) / 3`, dann `× sell_cost / 100`. `worth_percent`: mit Fahrzeug `MAX(worth_percent)` über alle Filialregionen des Users, sonst nur Region der Direktor-Filiale.
|
||||
2. **Spielercharakter:** genau **einer** je User (`character.id` maximal unter `health > 0`), nicht alle `JOIN character ON user_id`.
|
||||
3. **Kosten im Ranking:** **`6 × category`** (linear, ohne Headroom-Rabatt wie bei `piece_production_cost`).
|
||||
4. **Formel:** `(sell_cost × (effektiver Prozentsatz) / 100 − 6 × category) / (300 × production_time)`. **Steuer** im Ranking nicht abgezogen.
|
||||
|
||||
**UI / Node:** Sollte dieselbe Preislogik wie der Daemon nutzen. Weicht `calcRegionalSellPriceSync` ab (z. B. 70 % statt 60 % unterhalb der Basis), Frontend an **diese** Rust-Formel anpassen — nicht umgekehrt den Daemon „blind“ an eine abweichende UI koppeln.
|
||||
**Hinweis:** Echter Stückpreis und Buchführung nutzen weiter `piece_production_cost` und das 60 %–100 %-Band auf der Basis — nur die **Auswahl „beste Produktion“** folgt der Legacy-Formel, damit Daemon und UI dieselbe Rangfolge zeigen.
|
||||
|
||||
## Parallelproduktionen
|
||||
|
||||
|
||||
Reference in New Issue
Block a user