Factorio Logistik-Controlling & Analyse

Die Fabrik wird nicht als Spielszene, sondern als logistisches System mit Buchhaltungslogik verstanden. Das Grundverständnis stellt diese Anleitung vor: Registrierung, Logik, Auswertung und Export sind keine Selbstzwecke, sondern Werkzeuge zur kontrollierten Analyse.

1. Das Konzept: Die „Gläserne Fabrik“

Das Ziel des Factory Ledgers ist es, die Fabrik nicht nur spielerisch zu betreiben, sondern sie betriebswirtschaftlich analysierbar zu machen. Die Fabrik wird als logistisches System verstanden, dessen Zustand und Dynamik objektiv messbar sind.

Im Gegensatz zur reinen Beobachtung im laufenden Spiel ermöglicht Factory Ledger die strukturierte Offline-Analyse der Fabrik in externen Programmen (z. B. Excel). Die Fabrik wird damit zu einer „gläsernen Fabrik“: Jeder relevante Bestand, jede Bewegung und jede Investition ist nachvollziehbar dokumentiert. 

1.1 Warum Offline-Analyse?

Eine komplexe Fabrik lässt sich nicht zuverlässig „aus dem Bauch heraus“ optimieren. Visuelle Eindrücke sind flüchtig, Zustände ändern sich ständig, und Ursache-Wirkungs-Zusammenhänge bleiben oft verborgen. Die Offline-Analyse verfolgt drei Ziele:

• Zustand erfassen: Was befindet sich zu einem definierten Zeitpunkt tatsächlich in der Fabrik?
• Bewegung verstehen: Wie fließen Materialien durch das System?
• Kosten bewerten: Welche Ressourcen sind in Infrastruktur und Produkte gebunden?

Der Factory Ledger liefert hierfür strukturierte Rohdaten, die bewusst außerhalb von Factorio ausgewertet werden. Sie ersetzt keine Planung, sondern schafft eine belastbare Entscheidungsgrundlage.

1.2 Die drei Säulen der Datenerfassung

Das System stützt sich auf drei Datentypen, die unterschiedliche Fragestellungen beantworten:

1. Anlagevermögen: Erfasst die installierte Infrastruktur (Maschinen, Logistikobjekte) und deren Kostenstruktur. Diese Daten entstehen primär aus der Blueprint-Analyse.
2. Umlaufvermögen (Bestände): Beschreiben den Zustand der Fabrik zu definierten Zeitpunkten: Welche Mengen befinden sich aktuell in Lagern, Maschinen und virtuellen Konten?
3. Transaktionen (TX): Dokumentieren jede einzelne Warenbewegung zwischen Objekten. Sie bilden die zeitliche Dynamik des Systems ab.

Erst die Kombination dieser drei Säulen ermöglicht eine vollständige Analyse der Fabrik.

1.3 Das Prinzip der Identifizierbarkeit

Damit Daten eindeutig auswertbar sind, müssen alle relevanten Objekte identifizierbar sein. Factory Ledger arbeitet daher mit festen Kennungen, die sowohl im Spiel als auch in den Exportdaten verwendet werden:

• M-Nummern (z. B. M33): Registrierte Maschinen
• C-Nummern (z. B. C35): Registrierte Container und Lager (Tanks bekommen T-Nummern)
• I-Nummern (z. B. I156): Registrierte Inserter (Greifer)

Diese Kennungen bilden die Brücke zwischen der grafischen Darstellung in Factorio und der späteren Analyse in externen Werkzeugen. Ohne Identifizierbarkeit gibt es keine belastbare Buchhaltung. 

1.4 Die vier Kostenfaktoren der Analyse

Factory Ledger rechnet nicht mit einer fiktiven Spielwährung, sondern mit realen, physikalisch-logistischen Größen, die sich flexibel in eigene Kostenmodelle überführen lassen:

• Energieaufwand: Kumulierte Energie für Infrastruktur und Produktion
• Zeitaufwand: Dauer vom Rohstoff bis zum Produkt
• Flächenverbrauch: Platzbedarf (Footprint) der Infrastruktur
• Rohmaterialien: Exakte Mengen der eingesetzten Grundressourcen

Diese Daten werden über eine Blueprint-Analyse bereitgestellt und dienen als Grundlage für individuelle betriebswirtschaftliche Bewertungen. 

1.5 Betriebszustände und Buchhaltungslogik

Factory Ledger arbeitet nicht permanent „automatisch“, sondern kennt klare Betriebszustände, vergleichbar mit Buchhaltungsperioden in realen Systemen.

• Simulationslauf (Run): Jeder Analysezeitraum wird durch einen Run-Namen gekennzeichnet. Dieser Name markiert eine zusammenhängende Buchhaltungsperiode. Nach einem Reset wird er gesetzt.
• Protokoll aktiv/inaktiv: Die Aufzeichnung kann gezielt ein- und ausgeschaltet werden. Nur bei aktivem Protokoll werden Warenbewegungen als TX erfasst.
• Beobachten vs. Messen: Offene Fenster oder sichtbare Anzeigen bedeuten nicht automatisch, dass gemessen wird. Factory Ledger trennt bewusst zwischen: dem Beobachten des Systems und dem aktiven Erfassen von Buchungsdaten

Diese Trennung ist zentral für saubere Analysen: Eine bewusste Start-, Stopp- und Reset-Logik verhindert verfälschte Datensätze. Jeder Dat4ensatz ist über ein ID eindeutig und wird mit Timestamp gespeichert.

2. Systemarchitektur & Registrierung

Damit der factory ledger logistische Abläufe erfassen kann, müssen die physischen Objekte der Fabrik dem System explizit bekannt gemacht werden. Dieser Vorgang wird als Registrierung bezeichnet. Nur registrierte Objekte sind Bestandteil der Inventur, der Transaktionsprotokolle und der späteren Offline-Analyse. Nicht registrierte Bereiche gelten systemisch als „Außenwelt“ oder als nicht auflösbarer Zwischenraum.

2.1 Grundprinzip der Registrierung

Factory Ledger unterscheidet zwischen registrierten Objekten (bekannt, identifizierbar, auswertbar) und nicht registrierten Zonen (Blackbox, Außenwelt, Transit). Registriert werden nicht ganze Produktionslinien, sondern gezielt die relevanten logistischen Knotenpunkte: Lager, Maschinen, Übergabeschnittstellen. Dieser Ansatz reduziert Komplexität und entspricht der realen logistischen Betrachtung von Systemgrenzen.

Die Registrierung erfolgt direkt in der Spielwelt über Hotkeys. Nach erfolgreicher Registrierung erscheint ein Flying Text über dem Objekt als visuelle Bestätigung:

1. Maschinen und Container: Maus über das Objekt bewegen → Shift + R drücken. Das System weist automatisch eine eindeutige Kennung zu. Z.B. C35 für einen Container oder M33 für eine Maschine. Diese Kennung ist ab sofort sowohl im Spiel als auch in allen Exportdaten sichtbar.
2. Registrierung aufheben Maus über das registrierte Objekt → Shift + U drücken. Das Objekt wird aus allen Auswertungen entfernt. Alle zugehörigen Datenpfade werden systemisch getrennt.

Registrierte Objekte werden dauerhaft visuell markiert. Diese Marker erfüllen zwei Funktionen: Orientierung im Spiel, der Spieler erkennt sofort, welche Objekte Teil der Analyse sind, und Eindeutige Zuordnung in den Exportdaten. Jede Kennung (M-, C-, I-Nummer) ist systemweit eindeutig.

• M-Nummern: Produktions- und Verarbeitungsmaschinen
• C-Nummern: Container, Lager, Puffereinheiten
• I-Nummern: Inserter (Greifer)

Diese Trennung ist keine kosmetische Entscheidung, sondern Grundlage der Buchhaltungslogik.

2.2 Inserter als Transaktionseinheiten („Buchhalter“)

Inserter nehmen im System eine zentrale Sonderrolle ein. Nicht Maschinen und nicht Container erzeugen Transaktionen – sondern ausschließlich Inserter.  

Jede Warenbewegung entsteht durch einen Inserter, der ein Item von einer Quelle (TAKE) zu einem Ziel (GIVE) bewegt. Inserter sind damit die buchhalterischen Akteure des Systems ()doppelte Buchhaktung). Ohne aktive Inserter gibt es keine Transaktionen Diese Logik ist bewusst gewählt, da Inserter die physische Realität des Materialtransfers abbilden.

Inserter können systemisch aktiv oder inaktiv sein. jeder Inserter ist zur Beginn inaktive  Factory Ledger System analysiert registrierte Lager und Maschinen und aktiviert angrenzende Inserter automatisch. 

• Zwischen zwei registrierten Objekten →
  interner Logistik-Greifer (TAKE  → GIVE)
• Von nicht registriert zu registriert → 
• Wareneingang (RECEIVE) an Außengrenze
• interner Wareneingang (TRANSIT) 
• Von registriert zu nicht registriert → 
• Versand (SHIP) an Außengrenze
• interner Warenausgang (TRANSIT)
• Übergabe an/Eingang aus nicht registrierte Produktion → 
• Work in Progress (WIP)

Diese Einordnung ist die Grundlage für die farbliche Markierung der Inserter und für die Buchung auf die entsprechenden virtuellen Lagerkonten. Mit dem Hotkey Shift + R wird aus einem einfachen aktiven Inserter (gelb) ein Schnitstellen-Inserter (pink). Noch einmal Shift + R und der Inserter wird ein WIP-Inserter (grün). Shift + U mach dann wieder einen einfachen aktiven Greifer draus (gelb).

Die korrekte Registrierung ist die operative Schnittstelle zwischen Factorio und Buchhaltungssystem.

Doppelte Buchhaltung im Factory Ledger

In einer realen Fabrik ist nicht jeder Transportweg vollständig transparent. Materialien kommen von außen, laufen über Förderbänder, verschwinden in Produktionsmaschinen oder verlassen das System wieder. Factory LEdger trägt diesem Umstand Rechnung, indem sie neben den registrierten Objekten mit virtuellen Lagern arbeitet. Diese virtuellen Lager sind keine physischen Container, sondern buchhalterische Konten. Sie stellen sicher, dass jede Bewegung eines Items eindeutig verbucht wird – selbst dann, wenn Teile des Weges nicht registrierbar sind.

Vier virtuellen Lager-Konten

Man kann nur Maschinen, Kisten und Inserter registrieren. Alles außerhalb der Fabrik ist nicht registrierbar. Zudem kann man Förderbänder nicht oder zumindest schwer registrieren, was an der internen Implementierung in Factorio liegt. Ohne virtuelle Lager würden Materialien in diesen Bereichen buchhalterisch verschwinden oder aus dem Nichts auftauchen.

Virtuelles Lager	Bedeutung
RECEIVE	Wareneingang aus der Außenwelt
TRANSIT	Transport über nicht registrierte Wege
WIP	Material in der Produktion in Bearbeitung
SHIP	Warenausgang aus dem System

Diese Konten bilden zusammen eine vollständige logistische Kette vom Eingang bis zum Versand.

• RECEIVE – Wareneingang: RECEIVE repräsentiert den Eintrittspunkt von Material in das registrierte System.
• Wann wird RECEIVE gebucht? Ein Inserter entnimmt Items aus einer nicht registrierten Quelle, Das Ziel ist ein registrierter Container oder eine Maschine
• Bedeutung für die Analyse: RECEIVE entspricht klassisch dem Wareneingang. Das Material erhöht den Bestand aus einer externen Quelle. Hestellkosten entstehen außerhalb des betrachteten Systems
  
  
• TRANSIT – Logistischer Zwischenraum: TRANSIT wird genutzt, wenn Material einen nicht auflösbaren Transportweg durchläuft.
• Typischer Fall: Ein Inserter legt Items auf ein Förderband aber Förderbänder sind nicht registrierbar. Das Material ist unterwegs, aber nicht lagernd
• Buchungslogik:  
• Übergabe auf Band → Buchung auf TRANSIT mit GIVE.
• Entnahme vom Band durch nächsten Inserter → Abgang aus TRANSIT mit TAKE
• Bedeutung für die Analyse: TRANSIT macht gebundene Mengen sichtbar, die unterwegs sind. Das hilft bei Transportverzögerungen, Stau- und Durchsatzprobleme. Ohne TRANSIT wäre dieser Teil des Systems unsichtbar.
  
  
• WIP – Work in Progress (Produktion): WIP steht für Material, das sich in Bearbeitung befindet, dann hat das Materialmanagement darüber keine Kontrolle. Damit wird sichtbar, wie viel Material sich aktuell „in der Produktion befindet“.
• Wann wird WIP gebucht? Ein Inserter entnimmt Material aus einem registrierten Lager. Das Ziel ist der Produktionsbereich in dem keine individuell registrierten Kisten und Maschinen stehen Das System interessiert sich hier bewusst nicht für den internen Produktionsprozess, sondern nur für die Übergabe.
• Bedeutung für die Analyse: WIP entspricht klassisch dem Vorgang, dass halbfertige Waren in die Produktion gehen und dort zu Endprodukten verarbeitet werden. Das bedeutet gebundenes Kapital in nicht verfügbarem Bestand.
  
  
• SHIP – Versand: SHIP markiert den Austritt von Material aus dem registrierten System.
• Wann wird SHIP gebucht? Ein Inserter entnimmt Items aus einem registrierten Objekt (TAKE). Das Ziel ist eine nicht registrierte Senke (GIVE).
• Typische Beispiele: Übergabe an ein Versandband. Einspeisung in ein externes Logistiknetz.
• Bedeutung für die Analyse: SHIP entspricht Warenausgang an Kunde, Absatz und ist Abschluss der logistischen Kette. Material, das hier gebucht wird, verlässt die Bilanz der Fabrik. 

Funktion der Doppelten Buchführung

Virtuelle Lager sind keine alternativen Ablageorte, sondern bewusst aufeinander abgestimmte Bestandteile eines geschlossenen logistischen Modells. Sie strukturieren den Materialfluss vom Eintritt in das betrachtete System bis zu dessen Verlassen und stellen sicher, dass jede Warenbewegung eindeutig und widerspruchsfrei erfasst werden kann. „RECEIVE” markiert den Eintritt von Material aus der Außenwelt, „TRANSIT” überbrückt nicht registrierbare Transportwege, „WIP” bildet den Übergang in laufende Produktionsprozesse ab und „SHIP” kennzeichnet den Austritt von Waren aus dem System. Gemeinsam bilden diese Konten eine vollständige logistische Kette, innerhalb derer kein Material unkontrolliert verschwindet oder doppelt gezählt wird.

Grundlage dafür ist die konsequente Anwendung einer doppelten Buchhaltungslogik auf jede Materialbewegung. Jede Transaktion besteht systemisch immer aus genau zwei untrennbaren Bewegungsarten: einem „TAKE”, bei dem ein Item aus einer Quelle entnommen wird, und einem „GIVE”, bei dem dieses Item an eine Senke übergeben wird. Zwischen diesen beiden Schritten befindet sich das Item physisch in der Hand des Inserters, buchhalterisch ist es jedoch jederzeit eindeutig verortet. Es existiert kein Zustand, in dem ein Item keiner Quelle und keiner Senke zugeordnet ist.

Bei Bewegungen zwischen zwei registrierten Objekten führt diese Logik zu einem Nullsummenspiel. Der „TAKE” reduziert den Bestand der Quelle, der anschließende „GIVE” erhöht den Bestand der Senke um exakt dieselbe Menge. Auch bei Übergängen über nicht registrierte Transportwege bleibt dieses Prinzip erhalten. In diesem Fall erfolgt der Take oder der Give nicht gegen ein physisches Objekt, sondern gegen eines der virtuellen Lagerkonten. Unabhängig vom konkreten Pfad bleibt die Bilanz ausgeglichen, da Material stets nur von einem Konto auf ein anderes verschoben wird.

Der entscheidende Sonderfall ist das virtuelle Lager WIP (Work in Progress). WIP bildet keine reine Umschlagbewegung ab, sondern eine Transformation. Beim Übergang in WIP wird Material durch einen Take aus einem registrierten Objekt entnommen und als „in Arbeit befindlich“ verbucht. Ab diesem Zeitpunkt greift die Nullsummenlogik nicht mehr, da das entnommene Material nicht unverändert an anderer Stelle wieder auftaucht. Es wird innerhalb der Produktion verarbeitet und in ein anderes Produkt überführt, das erst zu einem späteren Zeitpunkt durch einen GIVE wieder in die Bestandslogik eingeht.

Genau deshalb ist das virtuelle Lager WIP notwendig. Es macht sichtbar, dass das Material zwar aus dem Lagerbestand verschwunden ist, aber noch nicht als fertiges Produkt zur Verfügung steht. Damit wird buchhalterisch korrekt abgebildet, dass Rohstoffe gebunden und transformiert werden, bevor neue Bestände entstehen. Ohne WIP würden diese Vorgänge entweder als Verluste erscheinen oder zu unzulässigen Doppelzählungen führen. Durch die Kombination aus TAKE- und GIVE-Buchungen sowie die gezielte Auflösung der Nullsummenlogik im Fall von WIP entsteht ein konsistentes Modell. Über alle registrierten Objekte und virtuellen Lager hinweg bleibt jede Bewegung nachvollziehbar und jede Abweichung erklärbar. 

Dadurch wird genau gewährleistet, dass kein Artikel doppelt auftaucht oder verloren geht – selbst dann nicht, wenn Teile des Materialflusses physisch nicht direkt beobachtbar sind.

4. Der Materialfluss am Praxisbeispiel

Um die zuvor beschriebene Logik der Registrierung, der Inserter-Transaktionen und der virtuellen Lager greifbar zu machen, wird sie im Folgenden an einem konkreten Referenz-Setup erläutert. Als Beispiel dient die Produktion grüner Schaltkreise, da sie sowohl einfache Transportvorgänge als auch echte Transformationsprozesse umfasst und damit alle relevanten Aspekte der Buchhaltungslogik abbildet.

Der Materialfluss beginnt mit der Anlieferung von Kupfererz aus der Außenwelt. Das Erz erreicht die Fabrik über einen nicht registrierten Transportweg und wird vom Inserter I156 genommen (TAKE)  Systemisch wird die Entnahme  em virtuellen Lager RECEIVE zugeordnet. Das Erz wird schließend durch einen GIVE in die Kiste C35 gelegt, die als Eingangslager fungiert. Mit diesem Schritt ist das Material buchhalterisch im System angekommen und als Bestand verfügbar.

Aus diesem Eingangslager wird das Erz durch einen weiteren Inserter I157 entnommen (TAKE) und dem registrierten Ofen M33 zugeführt (GIVE). Da beide Objekte registriert sind, handelt es sich um eine interne Umbuchung, die vollständig als Nullsummenspiel abläuft. Der Erzbestand im Container sinkt, während die Maschine das Material zur Verarbeitung übernimmt.

Nach Abschluss der Verhüttung werden die entstandenen Kupferplatten aus der Maschine entnommen mit I158 und in die Ausganghskiste C36 gelegt. Auch dieser Schritt bleibt vollständig innerhalb des registrierten Systems und erzeugt eine ausgeglichene Buchung aus TAKE und GIVE. Zu diesem Zeitpunkt ist das Erz vollständig in Platten transformiert worden, ohne dass virtuelle Lager benötigt wurden, da Quelle und Senke jederzeit eindeutig identifizierbar waren.

Eine kleine Produktion: Erz wird angeliefert und kommt über die Inbound-InserterI156 und I170 in die Fabrik. Nach der Verarbetung zu einfachen Produkten begen die beiden Schnittstellen-Inserter I179 und I182 Eisenplatten und Kabel an die Produktion ins WIP. Die fertigen grünen Schaltkreise werden von InserterI175 der Produktion entnommen und der Versand-Inserter I176 schickt sie raus.

Im nächsten Abschnitt des Materialflusses verlassen die Kupferplatten jedoch den direkt beobachtbaren Bereich. Inserter I158 entnimmt die Platten aus der Kiste Container und legt sie auf ein Förderband, das nicht registriert werden kann. Der TAKE erfolgt aus einem registrierten Objekt, der zugehörige GIVE kann jedoch keinem registrierten Ziel zugeordnet werden. Stattdessen wird die Übergabe systemisch dem virtuellen Lager TRANSIT gutgeschrieben. Die Platten gelten nun als unterwegs, sind also weder im Lagerbestand noch in der Produktion verfügbar, bleiben aber buchhalterisch sichtbar.

Am Ende des Förderbandes nimmt ein weiterer Inserter I166 die Platten wieder auf und legt sie in einen registrierten Eingangspuffer C39 der Kabelherstellung. Dieser Vorgang stellt den spiegelbildlichen Gegenpart dar. Der TAKE erfolgt aus dem virtuellen Lager TRANSIT, der GIVE in C39. Damit ist der Transport abgeschlossen und das Material wieder vollständig im System verortet. Der Transitbestand wird entsprechend reduziert.

Die eigentliche Kabelproduktion Aus den Kupferplatten wird als Value Added Service der Logistik aufgefasst. An deren Ausgang der Inserter I180 die Kabel in die Kiste C39 legt. C39 ist das SchnittstellenlagerInstert entnimmt die Kabel (TAKE) und legt (GIVE) sie auf ein Band der Produktion. Die Kabel befinden sich nun im WIP.

Eisenerze werden ebenfalls zu Platten verhüttet. Diese werden dann direkt ins WIP gebucht. Aus Eisenplatten und Kupferkabel beide in WIP werden in einer nicht registrierten Maschine die grünen Schaltkreise hergestellt. Fertige Schaltkreise werden vom Schnittstellen-Inserter I175 der Produktionsmaschine entnpommen (TAKE) in das Schnittstellen-Lager C41 gelegt (GIVE).

Der letzte Abschnitt des Materialflusses entspricht dem Versand. C41 dient zudem auch als Ausgangslager. Die fertigen grünen Schaltkreise werden Ausgangslager mit I176 entnommen (TAKE) und an einen nicht registrierten Abtransport übergeben (GIVE). TAKE reduziert den Bestand des des Ausgangslagers, GIVE wird dem virtuellen Lager SHIP zugeordnet. Mit diesem Schritt verlässt das Produkt das System endgültig und wird als Warenausgang verbucht.

Dieses Praxisbeispiel zeigt, dass sich der gesamte Materialfluss lückenlos aus TAKE- und GIVE-Bewegungen zusammensetzt. Interne Bewegungen gleichen sich aus, Transportlücken werden über TRANSIT geschlossen, Produktionsprozesse über WIP korrekt aufgelöst und externe Schnittstellen über RECEIVE und SHIP sauber abgegrenzt. Das Beispiel dient damit nicht nur der Illustration, sondern auch als Referenzmodell.

5. Daten-Auswertung und Inventur

Nachdem die Fabrik registriert und der Materialfluss logisch definiert ist, stellt der Factory Ledger eine Reihe von Dialogen zur Verfügung, über die der Nutzer auf die erfassten Daten zugreifen kann. Diese Dialoge dienen nicht der eigentlichen Analyse, sondern dem strukturierten Zugriff auf Zustände, Bewegungen und Bewertungsinformationen. Sie bilden die operative Schnittstelle zwischen der laufenden Simulation und der späteren Offline-Auswertung.

Zentrales Element ist dabei das Protokollfenster, von dem aus alle weiteren Funktionen erreichbar sind. Ergänzt wird es durch spezialisierte Dialoge für Transaktionen, Reset-Vorgänge und die Analyse des Anlagevermögens im Blueprint-Kontext.

5.1 Das Protokollfenster: Die zentrale Arbeitsoberfläche

Shift + B öffnet Protokollfenster. Es ist die zentrale Arbeitsoberfläche des Factory Ledgers. Es ist bewusst als einheitlicher Einstiegspunkt konzipiert, über den sowohl Zustandsdaten als auch weiterführende Funktionen erreichbar sind. Beim Öffnen zeigt das Fenster standardmäßig die Ergebnisse der regelmäßig durchgeführten Inventuren an.

Das Protokollfenster ist dabei kein reines Ereignislog, sondern die kontrollierte Ansicht auf den aktuell relevanten Ausschnitt der gespeicherten Daten. Es dient während des Betriebs dem Überblick und der Plausibilitätskontrolle der Datenerfassung. Die vollständige zeitliche Tiefe der Daten wird bewusst nicht im Fenster selbst dargestellt, sondern über den Export erschlossen.

5.2 Inventuransicht: Momentaufnahme des Systemzustands

In der Grundansicht des Protokollfensters werden die Inventur-Snapshots angezeigt. Diese Inventuren werden in festen Zeitabständen automatisch erzeugt und bilden jeweils eine vollständige Momentaufnahme des Systems. Erfasst werden alle registrierten Kisten, Zustand der Maschinen sowie zusätzlich die Bestände der virtuellen Lagerkonten.
Die Inventur beschreibt damit stets den Zustand der Fabrik zu einem definierten Zeitpunkt. Sie beantwortet die Frage, welche Mengen an welchem Ort gebunden sind, nicht jedoch, wie diese Mengen dorthin gelangt sind. Gerade in Verbindung mit den virtuellen Lagern erlaubt diese Ansicht einen vollständigen Überblick über das aktuell im System gebundene Material und Kapital.

5.3 Transaktionsfenster (TX): Bewegungen im Zeitverlauf

Während die Inventur den statischen Zustand beschreibt, liefert das Transaktionsfenster die zeitliche Dynamik des Systems. Es wird über den Schalter TX aus dem Protokollfenster heraus geöffnet und zeigt alle erfassten Warenbewegungen in zeitlicher Reihenfolge an.

Jede Zeile im Transaktionsfenster entspricht einer Bewegung eines registrierten Inserters und dokumentiert die beteiligten Objekte sowie das bewegte Item. Das Fenster dient damit der Beobachtung des laufenden Materialflusses und der Überprüfung, ob die logistischen Schnittstellen wie vorgesehen arbeiten. Es ist ausdrücklich nicht als Analysewerkzeug gedacht, sondern als Sichtfenster auf den operativen Betrieb. Die eigentliche Auswertung größerer Zeiträume erfolgt auch hier über den Export.

5.4 Reset-Dialog: definierte Neustarts für saubere Analysen

Für belastbare Auswertungen ist es häufig notwendig, den Factory Ledger in einen definierten Ausgangszustand zu versetzen. Zu diesem Zweck steht ein eigener Reset-Dialog zur Verfügung, der über das Protokollfenster erreichbar ist.

Reset löscht nicht die physische Fabrik, sondern setzt gezielt die erfassten Daten zurück. Inventuren und Transaktionen können vollständig entfernt werden, sodass eine neue Buchhaltungsperiode beginnt. Gegenstände in Kisten oder Maschinen, die nicht gelöscht werden sollen, können zuvor als geschützt markiert werden. Listen registrierter Objekte (Kisten, Maschinen, Protected) kann man gezielt löschen. 

Auf diese Weise lassen sich reproduzierbare Startbedingungen schaffen, etwa um das Hochfahren einer Produktion gezielt zu analysieren. Reset ist damit kein Notfallwerkzeug, sondern ein bewusstes Instrument zur Strukturierung von Messphasen und Vergleichsszenarien.

5.5 Blueprint-Analyse: Zugriff auf Anlagevermögen und Stammdaten

Neben den laufenden Betriebsdaten bietet der Factory Ledger eine zusätzliche Auswertungsfunktion im Kontext des Blueprint-Dialogs von Factorio. Innerhalb dieses Dialogs steht ein eigener Schalter zur Verfügung, mit dem eine Analyse des markierten Aufbaus ausgelöst wird.

Diese Analyse erzeugt kein Protokoll und keine Transaktionen, sondern liefert eine Momentaufnahme des Anlagevermögens. Ausgewiesen werden sowohl die benötigte Infrastruktur als auch eine vollständige Liste der verwendeten Items. Auf dieser Basis lassen sich Stammdaten ableiten, Kostenmodelle aufbauen oder verschiedene Layouts miteinander vergleichen. Die Blueprint-Analyse ergänzt damit die laufende Buchhaltung um eine statische Bewertung der installierten Basis.

Résumé

Der Factory Ledger ist das Instrument zum strukturierten Messen der Abläufe in einer Factorio-Fabrik. Durch trennen von Registrierung, Materialflusslogik, Zustandsaufnahmen und Transaktionen wird die Fabrik ein nachvollziehbares logistisches System. Bestände, Bewegungen und Investitionen werden eindeutig identifiziert und in einer konsistenten Buchhaltungslogik zusammengeführt.

Dieser Beitrag dokumentiert beschreibt das Verständnis der zugrunde liegenden Mechanik und die Bedienung des Factory Ledgers. Die Auswertung der erzeugten Daten ist nicht Bestandteil dieser Anleitung. Sie erfolgt außerhalb von Factorio typischerweise mit Excel und wird in separaten Beiträgen behandelt. Diese weiterführenden Analysen sind Teil begleitender Lehrmodule und bauen auf den hier beschriebenen Funktionen auf.

Ergänzende Beiträge

Using Factorio as a Logistics Simulation: Why I Built a Factory Logging & Analysis Mod

A Factorio Case Study in Industrial Efficiency: Storyline - Context of this Case Study is Goldratts Theory of Constraints.

Accounting Logic Must Not Follow Physics Too Closely: Physics ≠ Accounting ≠ Software, that´s not easy

Anhang: Technische Details und Systemkonfiguration

Dieser Anhang enthält ergänzende technische Hinweise zur internen Datenverwaltung des Factory Ledgers sowie zur sinnvollen Konfiguration der relevanten Parameter für Kurzzeit- und Langzeitanalysen. Die hier beschriebenen Aspekte sind für das grundlegende Verständnis des Systems nicht zwingend erforderlich, werden jedoch relevant, sobald größere Datenmengen erzeugt oder mehrere Auswertungszyklen miteinander verglichen werden sollen.

A.1 Speicherverwaltung und Ringpuffer-Logik

Zur Begrenzung des Speicherverbrauchs innerhalb der laufenden Factorio-Simulation nutzt der Factory Ledger für Transaktionen eine Ringpuffer-Struktur. Anstatt unbegrenzt Ereignisse im Arbeitsspeicher zu sammeln, wird eine feste maximale Anzahl an Transaktionen vorgegeben, die im Speicher gehalten werden kann. Diese Kapazität wird über die Mod-Einstellungen beim Start der Simulation festgelegt und kann je nach gewünschter Analyseauflösung angepasst werden.

Sobald die definierte Kapazität erreicht ist, beginnt der Ringpuffer damit, die ältesten Einträge schrittweise mit neuen Transaktionen zu überschreiben. Dadurch bleibt der Speicherbedarf konstant, unabhängig davon, wie lange die Simulation läuft. Um dennoch eine konsistente externe Auswertung zu ermöglichen, erhält jede einzelne Transaktion zusätzlich eine fortlaufende, eindeutige ID. Diese ID wird nicht zurückgesetzt, selbst wenn ältere Einträge im Puffer überschrieben werden. Auf diese Weise lassen sich exportierte Transaktionsdateien aus unterschiedlichen Zeitpunkten später lückenlos zusammenführen, ohne dass Dubletten oder Mehrdeutigkeiten entstehen.

A.2 Optimierung der Inventur-Intervalle

Die Inventur des Factory Ledgers basiert auf periodischen Snapshots des Systemzustands. Die Häufigkeit dieser Snapshots hat einen direkten Einfluss sowohl auf die entstehende Datenmenge als auch auf die Systemlast während der Simulation. Das Inventurintervall kann über die Einstellungen angepasst werden und sollte bewusst gewählt werden.

Ein langes Intervall reduziert die Anzahl der erzeugten Inventurdatensätze und schont damit Speicher und Exportvolumen. In diesem Fall müssen Zustandsänderungen zwischen zwei Inventuren stärker aus den Transaktionsdaten rekonstruiert werden. Ein kurzes Intervall erhöht dagegen die zeitliche Auflösung der Zustandsdaten erheblich, da sehr häufig vollständige Bestandsaufnahmen erzeugt werden. Dies kann für detaillierte Analysen sinnvoll sein, führt jedoch zu großen Datenmengen und erhöhtem Rechenaufwand, da bei jeder Inventur alle registrierten Container und Maschinen ausgelesen werden.

In der Praxis stellt die Wahl des Intervalls daher immer einen Kompromiss zwischen Datendichte und Systembelastung dar.

A.3 Workflow für die Excel-Auswertung

Die vom Factory Ledger erzeugten Exportdateien sind gezielt für die Weiterverarbeitung in Tabellenkalkulationsprogrammen wie Excel ausgelegt. Der Export erfolgt im CSV-Format mit Semikolon als Feldtrenner, was insbesondere in deutschsprachigen Excel-Umgebungen einen problemlosen Import ermöglicht.

Viele Informationen werden im Format Bezeichnung=Wert ausgegeben, etwa zur Kennzeichnung von Maschinenzuständen oder Metadaten. Diese Struktur erlaubt es, die Daten mit einfachen Excel-Funktionen oder über die Funktion „Text in Spalten“ weiter aufzubereiten und in separate Auswertungsspalten zu überführen. Inventurdaten und Transaktionsdaten folgen dabei einer konsistenten Struktur, sodass Zeitstempel, Objektkennungen und Statusinformationen direkt miteinander in Beziehung gesetzt werden können. Dadurch lassen sich beispielsweise Bestandsänderungen mit Maschinenzuständen oder Transaktionshäufungen korrelieren.

A.4 Dateipfade und Sicherheit (Sandboxing)

Aufgrund der Sicherheitsarchitektur von Factorio ist es Erweiterungen nicht gestattet, frei auf das Dateisystem zuzugreifen. Alle vom Factory Ledger erzeugten Exporte werden daher ausschließlich im dafür vorgesehenen Script-Output-Ordner abgelegt.

In einer Standardinstallation unter Windows befindet sich dieser Ordner im Benutzerverzeichnis von Factorio. Bei portablen oder ZIP-basierten Installationen liegt der Script-Output-Ordner direkt im write-Verzeichnis der jeweiligen Installation. Die Dateinamen enthalten sowohl eine Kennzeichnung des Typs, etwa für Inventur- oder Transaktionsdaten, als auch einen Zeitstempel. Dadurch wird verhindert, dass bestehende Dateien unbeabsichtigt überschrieben werden, wenn mehrere Exporte nacheinander durchgeführt werden.

A.5 Multiplayer-Fähigkeit

Der Factory Ledger ist so ausgelegt, dass er auch in einer Multiplayer-Umgebung stabil und konsistent arbeitet. Dabei existiert systemweit stets nur eine gemeinsame Registrierungsliste sowie ein zentraler Datenbestand für Inventuren und Transaktionen. Alle Aktionen werden unabhängig davon erfasst, welcher Spieler sie auslöst.

Eine Trennung der Daten nach einzelnen Spielern findet in der aktuellen Version bewusst nicht statt. Die Analyse betrachtet die Fabrik als eine gemeinsame logistische Einheit. Dieser Ansatz unterstützt insbesondere kooperative Spielszenarien, in denen mehrere Spieler gemeinsam an einer Fabrik arbeiten und dieselbe Datenbasis für die Analyse nutzen. Eine spielerbezogene Aufschlüsselung der Daten ist nicht vorgesehen und bleibt zukünftigen Erweiterungen vorbehalten.

A.6 Lokalisierung

Factorio verwendet Englisch als Standardsprache für Erweiterungen. Der Factory Ledger ist entsprechend vollständig in englischer Sprache lokalisiert. Zusätzlich wurde eine deutsche Lokalisierung implementiert, die alle Dialoge, Beschriftungen und Ausgaben abdeckt. Die Sprache richtet sich automatisch nach den Spracheinstellungen von Factorio. Inhaltlich sind beide Sprachversionen identisch, sodass Ausgaben und Exportdaten unabhängig von der gewählten Sprache konsistent bleiben.

Blog: , Seite:
Version: 1.4 April 2025, Kontakt: E-Mail Martin Wölker
Pirmasens, Germany, 2018-, ausgelesen am: , Licence CC BY