Fremde Mods anbinden

Ein anderer Mod kann Gebäude und Waren mitbringen, die sich an Production Revamp anlehnen — ohne eine einzige Zeile Lua. Das ist der entscheidende Punkt dieser Schnittstelle: sobald ein Mod auch nur eine Lua-Datei enthält, ist er nicht mehr konsolenfähig. Ein reiner Placeable- oder Frucht-Mod würde damit alle Konsolenspieler verlieren, nur um sich anzumelden.

Beides läuft über eine Datei revamp_extension.xml im Wurzelverzeichnis des fremden Mods. Revamp sucht sie selbst in allen geladenen Mods; ist Revamp nicht installiert, liest sie niemand und der Mod läuft ganz normal weiter.

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<revampExtension>
    <storeItems>
        <storeItem xmlFilename="SmallUndergroundStorageRevamp.xml"/>
    </storeItems>
    <fillTypes>
        <fillType name="MY_CROP" like="WHEAT" addToStorage="true"/>
    </fillTypes>
</revampExtension>

Eigene Gebäude anmelden

Ein Gebäude, das einen Revamp-Placeable-Typ benutzt, kann nicht einfach als <storeItem> in der modDesc des fremden Mods stehen. Ohne Revamp kennt das Spiel den Typ nicht und schreibt Unknown type '...' ins Log — bei jedem Spieler dieses Mods, auch wenn er mit Revamp nie etwas zu tun hatte.

Deshalb wird das Store-Item nicht in der fremden modDesc deklariert, sondern von Revamp zur Laufzeit angemeldet. Ist Revamp nicht da, meldet niemand etwas an und die Placeable existiert für das Spiel schlicht nicht: sie fehlt im Baumenü, ohne eine Meldung im Log.

Attribut	Bedeutung
storeItem#xmlFilename	Pfad zur Placeable-XML, relativ zum Wurzelverzeichnis des anmeldenden Mods

Beliebig viele Einträge. Revamp meldet jedes davon so an, als käme es aus der modDesc des fremden Mods — mit dessen Umgebung, damit seine eigenen $l10n_-Texte, Bilder und Placeable-Typen greifen.

Zu beachten:

• Der Placeable-Typ braucht den vollen Namen mit Mod-Präfix, also FS25_0_ProductionRevamp.RevampSilo.
• Eine <dependency> in der modDesc ist bei diesem Weg nicht nötig und auch nicht erwünscht — das Gebäude soll ja gerade optional sein.
• Nennt die Anmelde-Datei eine XML, die es nicht gibt, meldet Revamp das beim Laden mit Dateiname und Modname im Log.

Kommt mindestens ein Store-Item durch, steht eine Zusammenfassung im Log:

Info: Production Revamp: added 1 store items from 1 mods

Eigene Waren an vorhandenen Stellen anmelden

Zuerst prüfen: dafür braucht es oft gar kein Revamp

Führt eine Stelle ihre Fülltypen als Kategorie (fillTypeCategories="GRAIN"), reicht die eigene fillTypes.xml des Mods. Eine Kategorie, die es schon gibt, wird dabei ergänzt und nicht abgelehnt:

<fillTypeCategories>
    <fillTypeCategory name="GRAIN">MY_CROP</fillTypeCategory>
    <fillTypeCategory name="REVAMP_GRAIN">MY_CROP</fillTypeCategory>
</fillTypeCategories>

Damit nimmt jede Abladestelle, jedes Silo und jedes Revamp-Rezept, das die Kategorie benutzt, die neue Ware automatisch an. Das ist auch der einzige Weg, eine fremde Ware in ein Rezept zu bekommen — die Anmeldung unten kann das ausdrücklich nicht.

Wofür die Anmeldung da ist

Für den Rest: Stellen, die ihre Fülltypen namentlich aufzählen (fillTypes="WHEAT BARLEY OAT"), und davon gibt es auf den Karten reichlich. Dafür meldet der Mod seine Ware mit einem Referenz-Fülltyp an — „überall, wo Weizen angenommen wird, nimm auch meine Frucht an“.

Attribut	Vorgabe	Bedeutung
name	–	Pflicht. Der eigene Fülltyp
like	–	Pflicht. Vorhandener Fülltyp als Bezugspunkt: wo dieser angenommen wird, wird künftig auch der eigene angenommen
addToStorage	false	Zusätzlich in Lager aufnehmen, die den Referenz-Fülltyp aus einer Gesamtkapazität bedienen

Wo es greift und wo nicht

Stelle	Verhalten
Verkaufsstelle ohne eigenes Lager	nimmt die Ware an und verkauft sie, Preis kommt aus der Ware selbst
Silo mit Gesamtkapazität	nimmt sie auf, aber nur mit addToStorage="true"
Lager mit fest zugeteilten Einzelmengen je Ware	bleibt unangetastet — dort wäre keine Menge vorgesehen, die der Kartenbauer je eingeplant hat
Produktionsstätten und Fabriken	nie, auch wenn sie den Referenz-Fülltyp verarbeiten: eine Produktion kann nur, was in ihren Rezepten steht
Tierställe	nie: der Stall würde die Ware zwar lagern, gefressen wird aber nur, was das Futtersystem kennt

Zu wissen ist außerdem: wird eine Ware irgendwo angenommen, wo kein Lagerplatz für sie da ist, kommt beim Abladen schlicht nichts an. Wer addToStorage weglässt, meldet seine Ware also nur zum Verkaufen an.

Zeitpunkt

• Die Anmelde-Datei wird beim Laden der Store-Items gelesen, also noch vor den Fülltypen. Die Namen werden deshalb erst aufgelöst, wenn alle Fülltypen geladen sind, auch die anderer Mods.
• Die Stellen selbst werden ergänzt, wenn sie sich beim Spiel anmelden. Das gilt gleichermaßen für die Stellen der Karte und für alles, was später im laufenden Spiel gebaut wird.
• Die Reihenfolge der Mods spielt keine Rolle.

Prüfen, ob die Anmeldung angekommen ist

Im Log steht eine Zeile:

Production Revamp: added 1 fill types to existing stations

Mit eingeschaltetem Debug-Schalter kommt je Stelle und je Lager eine eigene Zeile dazu — hilfreich vor allem bei Silos, weil man einem gebauten Silo nirgends ansehen kann, was es annimmt:

RevampDebug: loadStorage(): MILK in ein Lager mit 500000 l Gesamtkapazitaet aufgenommen (placeable.silo.storages.storage(0))
RevampDebug: addUnloadingStation(): Getreide Flusssilo nimmt jetzt auch MILK an

Fehler in der Anmeldung (unbekannter Fülltyp, unbekannter Referenz-Fülltyp, Ware auf sich selbst bezogen) stehen ebenfalls im Log, mit Namen des anmeldenden Mods.

Erkennen, ob Revamp geladen ist

Braucht ein Mod das doch aus Lua heraus — weil er ohnehin schon Skripte enthält und deshalb nichts mehr zu verlieren hat:

local mod = g_modManager:getModByName("FS25_0_ProductionRevamp")
if mod ~= nil and g_modIsLoaded[mod.modName] then
    -- Revamp ist geladen
end

Der ModName muss dafür exakt FS25_0_ProductionRevamp lauten, siehe Kompatibilität.

Was ein solcher Mod danach aus Revamps Laufzeitdaten auslesen kann — Rezepte, Mix-Gruppen, Booster, Lagerstände —, steht unter Laufzeitdaten lesen.

Einen eigenen Knopf in den Verwalten-Dialog hängen

Die Knopfleiste des Produktionsmenüs hat sechs feste Plätze. Vanilla belegt davon bis zu fünf, Revamp kommt mit Verwalten und Auslagern dazu — ein siebter Knopf wird vom Spiel nicht mehr dargestellt und verschwindet kommentarlos. Welchen Mod es trifft, hängt allein an der Ladereihenfolge.

Revamp hält deshalb in seinem Verwalten-Dialog in jeder der beiden Knopfreihen einen Platz für einen fremden Mod bereit. Der Mod meldet seinen Knopf dort an, statt ihn in die volle Leiste zu setzen.

Die Anmeldung finden

Jeder Mod läuft in einer eigenen Umgebung. Revamps Tabellen sind von außen deshalb nur über dessen Mod-Umgebung zu sehen, die das Spiel unter dem ModNamen ablegt:

local revampEnvironment = _G["FS25_0_ProductionRevamp"]
local revampApi = revampEnvironment ~= nil and revampEnvironment.ProductionRevampApi or nil

Ist Revamp nicht installiert, bleibt revampApi schlicht nil und der eigene Mod läuft unverändert weiter.

Anmelden

revampApi.registerManageButton({
    modName   = "FS25_MeinMod",
    text      = g_i18n:getText("meinMod_buttonText"),
    scope     = revampApi.SCOPE.PRODUCTION_POINT,
    isVisible = function(productionPoint) return true end,
    callback  = function(productionPoint) MeinDialog.show(productionPoint) end
})

Feld	Vorgabe	Bedeutung
modName	–	Pflicht. Eigener Modname, taucht in Revamps Log-Meldungen auf
text	–	Pflicht. Fertige Beschriftung, bereits übersetzt
scope	–	Pflicht. SCOPE.PRODUCTION_POINT oder SCOPE.FILLTYPE, siehe unten
callback	–	Pflicht. Wird beim Klick gerufen, mit Produktionspunkt und bei SCOPE.FILLTYPE zusätzlich dem Fülltyp
isVisible	immer sichtbar	Entscheidet je Stätte bzw. je Ware, ob der Knopf erscheint. Gleiche Parameter wie callback

Der Rückgabewert ist true, wenn der Knopf angenommen wurde.

Die beiden Bereiche

scope sagt, worauf sich der Knopf bezieht. Daraus ergibt sich seine Reihe — den Aufbau des Dialogs muss der anmeldende Mod nicht kennen.

Bereich	Wo der Knopf steht	Wann er sichtbar ist
SCOPE.PRODUCTION_POINT	untere Reihe, neben Auslagern und Ansichtswechsel	in jeder Ansicht
SCOPE.FILLTYPE	obere Reihe, neben Kaufen und Verkaufen	nur in der Waren-Ansicht, und nur solange eine Ware markiert ist

Zeitpunkt

Die Anmeldung gehört in den Missionsstart des eigenen Mods, zum Beispiel in loadMap — beim Sourcen der eigenen Dateien sind noch nicht alle Mods geladen.

Wenn der Platz schon vergeben ist

Je Bereich nimmt Revamp genau einen Knopf an, denn je Reihe ist genau ein Platz frei. Meldet sich ein zweiter Mod für denselben Bereich an, wird er abgewiesen; registerManageButton gibt false zurück und im Log steht, welcher Mod den Platz bereits hat:

Error: Production Revamp: 'FS25_MeinMod' wants the manage dialog button for scope 'productionPoint', but 'FS25_AndererMod' already has it. Only one button per scope can be shown.

Der eigene Mod sollte darauf vorbereitet sein und in diesem Fall bei seinem bisherigen Weg bleiben.

Portierung aus dem LS22

• Store-Items meldeten fremde Mods dort über eine eigene revamp_check.lua an, Fülltypen ebenfalls über eine eigene Lua-Datei. Beides gibt es nicht mehr — die Anmeldung ist rein deklarativ, aus dem Konsolengrund oben.
• Die Bedingungen der LS22-Fassung (Store-Item nur bei vorhandenen Fülltypen ein- oder ausblenden) gibt es derzeit nicht. Dass die Datei überhaupt gelesen wird, ist bereits die Bedingung „Revamp ist installiert“. Weitere Bedingungen können später ergänzt werden, ohne dass sich an bestehenden Anmeldungen etwas ändert.