4.5 KiB
Falukant: Daemon-Handoff (YpDaemon)
Technische Abstimmung mit dem Übergabedokument im Backend-Projekt (FALUKANT_LOVERS_DAEMON_SPEC.md / FALUKANT_LOVERS_TECHNICAL_CONCEPT.md).
Abweichungen / Zuordnung
| Handoff / Backend | YpDaemon |
|---|---|
relationship_state.marriage_satisfaction (Ehe) |
relationship.marriage_satisfaction für Zeilen mit relationship_type ∈ married, engaged, wooing |
months_underfunded |
Spalte months_underfunded (Migration 001; Legacy: 002 benennt consecutive_underpayment_months um) |
Idempotenz last_daily_processed_at / last_monthly_processed_at |
Gesetzt von FalukantFamilyWorker pro Liebschaft |
Ticks
- Daily: nur Zeilen mit
(last_daily_processed_at IS NULL OR last_daily_processed_at::date < CURRENT_DATE); danachlast_daily_processed_at = NOW(). - Monthly: nur Zeilen mit
(last_monthly_processed_at IS NULL OR date_trunc('month', last_monthly_processed_at) < date_trunc('month', CURRENT_TIMESTAMP)); nach Kosten/Unterversorgunglast_monthly_processed_at = NOW().
Hinweis: Der Worker nutzt weiterhin Wandzeit (24 h / 30 Tage) als Intervall; die Idempotenz über die Zeitstempel verhindert Doppelverarbeitung bei Neustarts am selben Tag/Monat.
WebSocket-Events (UI)
Pro betroffener falukant_user.id werden über den MessageBroker (Broadcast an alle WS-Clients) gesendet:
| Event | Payload (Beispiel) | Wann |
|---|---|---|
falukantUpdateFamily |
{"event":"falukantUpdateFamily","user_id":N,"reason":"…"} |
Familie/Liebe relevant |
falukantUpdateStatus |
{"event":"falukantUpdateStatus","user_id":N} |
Immer gleich mit falukantUpdateFamily (Refresh) |
children_update |
{"event":"children_update","user_id":N} |
Kind aus Liebschaft |
falukant_family_scandal_hint |
{"event":"falukant_family_scandal_hint","relationship_id":…} |
Skandal (ohne user_id) |
reason bei falukantUpdateFamily: daily, monthly, scandal, lover_birth.
Die UI kann auf falukantUpdateFamily filtern und nach reason unterscheiden; falukantUpdateStatus wie bisher für allgemeinen Daten-Refresh nutzen.
Detaillierte UI-Anleitung (Payloads, Handler, Checkliste): FALUKANT_UI_WEBSOCKET.md
Altersregeln (Spec-Erweiterung, im Daemon umgesetzt)
min_age_years = jüngeres Alter beider Partner in ganzen Jahren (LEAST(…/365, …/365) aus birthdate).
| Bereich | Ansehen (zusätzl. zur Basisformel, Spec 5a) | Ehezufriedenheit (Spec §3 neg.) | Skandalrisiko (+ %, exkl. Stufen) |
|---|---|---|---|
| ≤ 13 | −1,5 / Tag | −1 / Tag bei aktiver Berührung | +6 % |
| ≤ 15 | −0,8 / Tag | −1 / Tag (zusätzlich zu anderen Malus) | +3 % |
| ≤ 17 | −0,3 / Tag | — | +1 % |
| ≥ 18 | 0 | — | 0 |
Zusätzlich: wenn min_age_years ≤ 15 und visibility ≥ 50: weiterer Ansehens-Malus −0,5 / Tag.
Ehe-Malus „≤ 15“ gilt pro Ehe, wenn irgendeine berührende Liebschaft dieses Altersprofils hat.
Migrationen
migrations/001_falukant_family_lovers.sql- Optional:
migrations/002_falukant_family_rename_legacy_columns.sqlbei Altbestand migrations/003_falukant_family_marriage_buffs.sql— Ehe-Buffs (marriage_gift_buff_days_remaining,marriage_pending_feast_bonus,marriage_house_supply,marriage_no_lover_bonus_counter); Daily-Tick schreibt Zufriedenheit + Zähler viaQUERY_UPDATE_MARRIAGE_STATE_AND_BUFFS.
Ehe-Buffs (Daemon)
- Geschenk: Backend setzt
marriage_gift_buff_days_remaining(z. B. 5); Daemon +1 Zufriedenheit/Tag, Zähler −1. - Fest:
marriage_pending_feast_bonuseinmalig (typ. +2…+5, max. 5 pro Tick) beim Daily verbrauchen. - Haus:
marriage_house_supply ≥ 65und keine berührende Liebschaft: alle 4 Tage +1 Zufriedenheit (marriage_no_lover_bonus_counter).
Ansehen (Daily)
- Ranggruppe 3: Reputations-Multiplikator 0,7 nur bei „geordneter“ Liebschaft (
order_ok: u. a. Unterhalt ≥ 65, Diskretion ≥ 60, Sichtbarkeit ≤ 35, höchstens eine Mätresse im Umfeld des Paares); sonst 1,0; bei Skandal 1,5. - Zwei sichtbare Liebschaften (
visibility ≥ 60, mindestens zwei Beziehungen pro Charakter): zusätzlich −4 Ansehen (einmal pro Person/Tag). - Zufall: selten Gerücht −3 oder Tadel −5 (niedrige Wahrscheinlichkeit) für Charaktere mit Liebschaftsbezug.