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:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user