Add raid transport feature and related updates: Introduce new raid transport functionality in FalukantService and FalukantController, including methods for retrieving raid transport regions and handling guard counts. Update frontend components to support guard count input and display related costs. Enhance localization files to include new terms for raid transport and associated metrics in English, German, and Spanish.

This commit is contained in:
Torsten Schulz (local)
2026-03-23 18:47:01 +01:00
parent 43dd1a3b7f
commit de52b6f26d
18 changed files with 886 additions and 82 deletions

View File

@@ -207,60 +207,68 @@ Der Daemon berechnet:
```text
certificateScore =
knowledgePoints * 0.35 +
productionPoints * 0.20 +
officePoints * 0.15 +
nobilityPoints * 0.10 +
reputationPoints * 0.10 +
housePoints * 0.10
knowledgePoints * 0.45 +
productionPoints * 0.30 +
officePoints * 0.08 +
nobilityPoints * 0.05 +
reputationPoints * 0.07 +
housePoints * 0.05
```
Zusätzlich gelten Mindestanforderungen je Stufe.
Balancing-Grundsatz:
- frühe und mittlere Zertifikate sollen primär über Wissen und Produktionspraxis erreichbar sein
- gesellschaftliche Faktoren wirken vor allem als Beschleuniger oder als Zugang zu hohen Zertifikaten
- vorübergehende wirtschaftliche Verlustphasen blockieren den normalen Aufstieg nicht automatisch
- ein normaler Produktionsverlust ist kein Downgrade-Grund
## 4.5 Mindestanforderungen je Zertifikatsstufe
Eine höhere Zielstufe darf nur erreicht werden, wenn neben dem `certificateScore` auch harte Mindestgrenzen erfüllt sind.
### Für Zertifikat 2
- `avgKnowledge >= 25`
- `completedProductions >= 5`
- `avgKnowledge >= 15`
- `completedProductions >= 4`
### Für Zertifikat 3
- `avgKnowledge >= 40`
- `completedProductions >= 20`
- `avgKnowledge >= 28`
- `completedProductions >= 15`
- kein harter Statuszwang
- Statusfaktoren dürfen den Score verbessern, sind hier aber noch nicht Pflicht
### Für Zertifikat 4
- `avgKnowledge >= 45`
- `completedProductions >= 45`
- mindestens einer der Statusfaktoren erfüllt:
- `officePoints >= 1`
- oder `nobilityPoints >= 1`
- oder `reputationPoints >= 2`
- oder `housePoints >= 1`
### Für Zertifikat 4
- `avgKnowledge >= 55`
- `completedProductions >= 60`
- mindestens zwei Statusfaktoren erfüllt
- oder `housePoints >= 2`
### Für Zertifikat 5
- `avgKnowledge >= 70`
- `completedProductions >= 150`
- `reputationPoints >= 3`
- `avgKnowledge >= 60`
- `completedProductions >= 110`
- `reputationPoints >= 2`
- mindestens zwei der folgenden:
- `officePoints >= 2`
- `nobilityPoints >= 2`
- `nobilityPoints >= 1`
- `housePoints >= 2`
## 4.6 Ableitung der Zielstufe
Vorschlag:
- `targetCertificate = 1`, wenn `certificateScore < 1.2`
- `targetCertificate = 2`, wenn `certificateScore >= 1.2`
- `targetCertificate = 3`, wenn `certificateScore >= 2.1`
- `targetCertificate = 4`, wenn `certificateScore >= 3.0`
- `targetCertificate = 5`, wenn `certificateScore >= 4.0`
- `targetCertificate = 1`, wenn `certificateScore < 0.9`
- `targetCertificate = 2`, wenn `certificateScore >= 0.9`
- `targetCertificate = 3`, wenn `certificateScore >= 1.8`
- `targetCertificate = 4`, wenn `certificateScore >= 2.8`
- `targetCertificate = 5`, wenn `certificateScore >= 3.8`
Danach werden die Mindestanforderungen geprüft.
@@ -330,6 +338,13 @@ Für jeden Spieler mit `falukant_user`:
- `falukant_user.certificate` um genau `+1` erhöhen
9. Event an UI senden
Balancing-Hinweis für den Daemon:
- Wenn ein Spieler bereits regelmäßig produziert und verkauft, soll Zertifikat `2` früh stabil erreichbar sein.
- Zertifikat `3` soll bei solider Produktionspraxis und mittlerem Wissen ebenfalls ohne hohen Adels- oder Amtsstatus erreichbar sein.
- Hohe gesellschaftliche Faktoren sollen vor allem Zertifikat `4` und `5` deutlich erleichtern, nicht Zertifikat `2` und `3` künstlich blockieren.
- Reine Verlustphasen in der Geldhistorie sind kein eigener Gegenfaktor, solange kein echter Bankrottfall vorliegt.
## 6. Event-Kommunikation zwischen Daemon und UI
## 6.1 Neues Event