Architektur

Grundprinzip

"Modular" bedeutet hier nicht, dass Spieler einzelne Revamp-Funktionen an- oder abwählen können, sondern dass die fachlichen Bereiche im Code so getrennt sind, dass an einem Modul gearbeitet werden kann, ohne die anderen verstehen zu müssen. Unabhängig davon soll ein Server-Admin bestimmte Bereiche (z. B. das Verteilsystem) zur Laufzeit ein- oder ausschalten können.

Debug-Ausgabe zuerst, Anzeige-Entscheidung danach

Die Anzeige einer Funktion ist kein separater, nachgelagerter Schritt, sondern gehört zum Bau der Funktion selbst: Beim Schreiben einer Funktion zuerst Debug-Ausgaben ins Log (nach Achims Konvention aus den anderen Mods: Revamp.Debug-Flag, Revamp.DebugText(text, ...)/Revamp.DebugTable(text, myTable, maxDepth), Präfix "RevampDebug: ", Ausgabe über ein schlichtes print — ein Logging.info-Wrapper bringt gegenüber print mit eigenem Präfix keinen Mehrwert). Erst wenn die Funktion nachweislich funktioniert, wird entschieden, wie sie am besten angezeigt wird — nicht vorher und nicht als eigene, spätere Phase.

Module

Modul	Inhalt
Recipe Core	Mix-Gruppen, alternative FillTypes, Wertigkeiten, FillTypeCategories, Booster, Rezept-Umschalten (siehe unten, Later)
Distribution	Priorisiertes Verteilen, Ausgangsmodi (Verkaufen/Verteilen/Auslagern/Einlagern), Kosten fürs Verteilen separat in der Statistik ausweisen
Storage Extension	Lose Ware/Ballen/Paletten im selben Lager, Füllstand-Objektdarstellung, manueller Paletten-/Ballenspawn/-Auslagern aus der Produktion (Pendant zu PSC, siehe Kompatibilität)
Buy/Sell & Pricing	Zukauf/Verkauf im Produktionsmenü
Production Modifiers	Variable Produktionsgeschwindigkeit ("Kurzarbeit"), wirkt auf die gesamte Produktionslinie
Display/Visualization	Nur das, was unabhängig von einzelnen Funktionen ist: Anzeige ob eine Produktion parallel oder verteilt läuft (II/Y), Anzeige der Produktionskosten, Anzeige der Gebäude-/Unterhaltskosten. Die Anzeige jeder einzelnen Funktion (Rezepte, Booster, Wetter-Status, …) entsteht dagegen zusammen mit der jeweiligen Funktion selbst, siehe oben
Settings	Eigenes Einstellungsmenü, inklusive Admin-Schalter pro Modul
Ingame-Help	Referenziert die anderen Module

Datei-Konventionen

• Ein Modul = eine Lua-Datei
• Multiplayer-Events liegen gesammelt in scripts/events/, pro Event eine eigene Datei, unabhängig davon zu welchem Modul das Event fachlich gehört
• Keine local function in Mod-Lua-Code — alles als Feld auf einer globalen Tabelle, damit Utils.overwrittenFunction/appendedFunction von außen greifen kann

Kopplungsregeln

• Recipe Core ist die einzige harte Abhängigkeit für die anderen Module
• Module untereinander (Distribution, Storage Extension, Display, …) kennen sich nicht direkt
• Berührungspunkte zwischen Modulen sind nur in den Dialogen/der UI erlaubt
• Jedes Modul prüft seinen eigenen Admin-Schalter aus dem Settings-Modul selbst, statt Code-Pfade zu löschen

Dialog-Strategie

Die eigentliche Rezeptanzeige (Recipe Core: Mix-Gruppen, Booster, Wetter-Status) bleibt im erweiterten Original-Produktionsdialog, solange er alle Möglichkeiten übersichtlich und bedienbar zeigen kann — kein Ersatzdialog "auf Vorrat". Module mit echter Bedienung (Einstellungen mit Reglern u. ä.) bekommen eigene Sub-Dialoge; das ist bereits durch PSC/PST vorgezeichnet, die für Storage-Verwaltung und Kauf/Verkauf jeweils eigene Dialoge (ProductionStorageDialog, ProductionBuyGoodsDialog) statt Erweiterungen des Produktionsmenüs verwenden.

Ein eigener Ersatz für den Produktionsdialog selbst kommt erst infrage, wenn eine konkrete Grenze erreicht wird, z. B.:

• Ein Rezept mit vielen Mix-Gruppen/Alternativen sprengt die Zeilen-/Zellhöhe der Liste trotz Anpassung
• Ein Modul braucht eine Interaktion, die keine Listenzelle abbilden kann (Schieberegler, visuelle Prozent-Verteilung o. ä.)

Recipe Core: Rezept-Umschalten ("Kombinieren"), Later

Der FeedMixer im 22er konnte zwischen pro Karte unterschiedlich definierten Rezepten umschalten, ohne dass jede Variante eine eigene Produktionslinie mit eigener Lager-/FillType-Reservierung brauchte (eine Linie wird für die jeweils aktive Variante neu konfiguriert, FillTypes werden bei Wechsel um- statt dauerhaft angemeldet). Das Prinzip soll später auch für frei geschriebene Modder-Rezepte nutzbar sein, nicht nur für Futtermischer — ist aber kein Nahziel: hohe Komplexität durch die vielen möglichen Kombinationen, daher auf die Later-Liste statt Todo.

Siehe auch Kompatibilität für das optionale Ladesystem und die Kompatibilität zu bestehenden Begleit-Mods.