Das Konzept der „Gläsernen Fabrik"
zielt darauf, die Fabrik nicht nur zu betreiben, sondern sie betriebswirtschaftlich analysierbar zu machen. Factory Ledger betrachtet die Fabrik als logistisches System, dessen Zustand und Dynamik objektiv messbar sind. Statt sich auf Beobachtungen im laufenden Spiel zu verlassen, ermöglicht das System eine strukturierte Offline-Analyse in externen Werkzeugen wie Excel. Die Fabrik wird damit zur gläsernen Fabrik: Jeder relevante Bestand, jede Bewegung und jede Investition ist vollständig dokumentiert und nachvollziehbar.
1.1 Warum Offline-Analyse?
Eine komplexe Fabrik lässt sich nicht zuverlässig „aus dem Bauch heraus" optimieren. Visuelle Eindrücke bleiben flüchtig, Zustände ändern sich permanent, und Ursache-Wirkungs-Zusammenhänge entziehen sich häufig der direkten Beobachtung. Die Offline-Analyse verfolgt daher drei klare Ziele:
- Zustand erfassen: Welche Bestände existieren 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 Produkten gebunden?
Factory Ledger liefert hierfür strukturierte Rohdaten, die bewusst außerhalb von Factorio ausgewertet werden. Das System ersetzt keine Planung und keine Entscheidungen, sondern schafft eine belastbare, datenbasierte Grundlage für deren Bewertung.
1.2 Die Elemente der Datenerfassung
Das System stützt sich auf drei Datentypen, die jeweils unterschiedliche Fragestellungen adressieren. Erst ihre Kombination ermöglicht eine vollständige Analyse der Fabrik.
- Anlagevermögen erfasst die installierte Infrastruktur, insbesondere Maschinen und logistische Objekte, einschließlich ihrer Kostenstruktur. Diese Daten entstehen primär aus der Blueprint-Analyse.
- Umlaufvermögen (Bestände) beschreibt den Zustand der Fabrik zu definierten Zeitpunkten. Es beantwortet die Frage, welche Mengen sich aktuell in Lagern, Maschinen und virtuellen Konten befinden.
- Transaktionen (TX) dokumentieren jede einzelne Warenbewegung zwischen Objekten und bilden damit die zeitliche Dynamik des Systems ab.
Damit diese Daten eindeutig auswertbar bleiben, müssen alle relevanten Objekte identifizierbar sein. Factory Ledger arbeitet deshalb mit festen Kennungen, die sowohl im Spiel als auch in den Exportdaten verwendet werden. Diese Identifikatoren bilden die Brücke zwischen der grafischen Darstellung in Factorio und der späteren Analyse mit externen Werkzeugen. Ohne eindeutige Identifizierbarkeit existiert keine belastbare Buchhaltung.
1.3 Ökonomische Bewertung der Produktion
Factory Ledger bewertet die Produktion nicht über eine fiktive Spielwährung, sondern direkt an der Quelle: durch die Quantifizierung realer physikalisch-logistischer Primärfaktoren.
Statt abstrakte Kostenwerte zu simulieren, erfasst das System alle Prozesse in harten Basiseinheiten wie Ressourcenaufwand, Zeitbedarf, Energieverbrauch und Flächennutzung. Diese objektive Datenbasis macht Fabrikprozesse unmittelbar bewertbar und vergleichbar. Sie bildet eine präzise Grundlage, die sich flexibel in individuelle Kostenmodelle überführen lässt, um Effizienz nach frei wählbaren Schwerpunkten zu gewichten.
Erfasst werden insbesondere:
- Energieaufwand: kumulierte Energie für Infrastruktur und Produktion
- Zeitaufwand: Durchlaufzeit vom Rohstoff bis zum Endproduke
- Flächenverbrauch: Platzbedarf (Footprint) der Infrastruktur
- Rohmaterialien: exakte Mengen der eingesetzten Grundressourcen
Diese Daten stellt das System über eine Blueprint-Analyse bereit. Sie dienen als Ausgangspunkt für individuelle betriebswirtschaftliche Bewertungen.
1.4 Betriebszustände und Buchhaltungslogik
Factory Ledger arbeitet nicht permanent im Aufzeichnungsmodus, sondern unterscheidet klar definierte Betriebszustände, die Buchhaltungsperioden realer Systeme entsprechen.
- Ein Simulationslauf (Run) kennzeichnet jeweils einen abgeschlossenen Analysezeitraum. Der Run-Name markiert eine zusammenhängende Buchhaltungsperiode und wird nach einem Reset explizit gesetzt.
- Das Protokoll lässt sich gezielt aktivieren oder deaktivieren. Nur bei aktivem Protokoll erfasst das System Warenbewegungen als Transaktionen (TX).
- Darüber hinaus trennt Factory Ledger strikt zwischen Beobachten und Messen. Sichtbare Anzeigen oder geöffnete Fenster implizieren keine Datenerfassung. Erst die aktive Protokollierung erzeugt buchhalterisch relevante Daten.
Diese Trennung ist zentral für saubere Analysen. Eine explizite Start-, Stopp- und Reset-Logik verhindert vermischte oder verfälschte Datensätze. Jeder Datensatz trägt eine eindeutige ID und einen Timestamp und bleibt damit eindeutig zuordenbar.
2. Systemarchitektur und Registrierung
Damit Factory Ledger logistische Abläufe erfassen kann, müssen die physischen Objekte der Fabrik dem System explizit bekannt sein. Diesen Vorgang bezeichnet das System als Registrierung. Nur registrierte Objekte gehen in Inventur, Transaktionsprotokolle und die spätere Offline-Analyse ein. Nicht registrierte Bereiche behandelt das System konsequent als „Außenwelt" oder als nicht auflösbaren Zwischenraum.
2.1 Registrierte Objekte
Factory Ledger unterscheidet strikt zwischen registrierten Objekten (bekannt, identifizierbar, auswertbar) und nicht registrierten Zonen (Blackbox, Außenwelt, Transit). Das System registriert keine vollständigen Produktionslinien, sondern gezielt die relevanten logistischen Knotenpunkte: Lager, Maschinen und Übergabeschnittstellen. Dieser Ansatz reduziert die Komplexität und entspricht der realen logistischen Definition von Systemgrenzen.
Die Registrierung erfolgt direkt in der Spielwelt über Hotkeys. Nach erfolgreicher Registrierung erscheint über dem Objekt ein Flying Text als visuelle Bestätigung. Für Maschinen und Kisten gilt: Maus über das Objekt bewegen und Shift + R drücken. Das System weist automatisch eine eindeutige Kennung zu, etwa C35 für eine Kiste oder M33 für eine Maschine. Diese Kennung bleibt ab diesem Zeitpunkt sowohl im Spiel als auch in allen Exportdaten sichtbar.
Zum Aufheben der Registrierung wird die Maus über das registrierte Objekt bewegt und Shift + U gedrückt. Das System entfernt das Objekt aus allen Auswertungen und trennt die zugehörigen Datenpfade konsequent von der Buchhaltungslogik.
- M-Nummern (z. B. M33): registrierte Maschinen,
- C-Nummern (z. B. C35): registrierte Kisten und Lager (Tanks bekommen T-Nummern),
- I-Nummern (z. B. I156): registrierte Inserter (Greifer).
Registrierte Objekte tragen dauerhaft sichtbare Marker. Diese Marker erfüllen zwei Funktionen. Erstens dienen sie der Orientierung im Spiel: Der Spieler erkennt sofort, welche Objekte Teil der Analyse sind. Zweitens sichern sie die eindeutige Identifikation im System. Jede Kennung (M-, C- oder I-Nummer) ist systemweit eindeutig. Diese Trennung ist keine kosmetische Maßnahme, sondern bildet die Grundlage der gesamten Buchhaltungslogik.
2.2 Inserter als Transaktionseinheiten („Buchhalter")
Inserter nehmen im System eine zentrale Sonderrolle ein. Nicht Maschinen und nicht Kisten erzeugen Transaktionen, sondern ausschließlich Inserter. Jede Warenbewegung entsteht durch einen Inserter, der ein Item aus einer Quelle entnimmt (TAKE) und an ein Ziel übergibt (GIVE).
Inserter fungieren damit als buchhalterische Akteure des Systems und implementieren die doppelte Buchhaltungslogik operativ. Ohne aktive Inserter existieren keine Transaktionen. Diese Entscheidung ist bewusst gewählt, da Inserter den physischen Akt des Materialtransfers direkt abbilden und damit die einzige Instanz darstellen, an der Buchhaltung und Materialfluss eindeutig zusammenfallen.
Inserter können systemisch aktiv oder inaktiv sein. Jeder Inserter ist zur Beginn inaktiv. 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 bildet die Grundlage für die farbliche Markierung der Inserter und für die Buchung auf die jeweiligen virtuellen Lagerkonten. Mit dem Hotkey Shift + R wechselt ein einfacher aktiver Inserter (gelb) in den Modus des Schnittstellen-Inserters (pink). Ein weiterer Druck auf Shift + R schaltet ihn in den WIP-Modus (grün). Mit Shift + U setzt das System den Inserter wieder auf einen einfachen aktiven Greifer zurück (gelb). Die korrekte Registrierung dieser Modi stellt die operative Schnittstelle zwischen Factorio und dem Buchhaltungssystem dar.
3. Doppelte Buchführung im Factory Ledger
In einer realen Fabrik ist nicht jeder Transportweg vollständig transparent. Materialien treten von außen in das System ein, bewegen sich über Förderbänder, verschwinden in Produktionsmaschinen oder verlassen die Fabrik wieder. Factory Ledger bildet diese Realität ab, indem es neben registrierten Objekten gezielt mit virtuellen Lagern arbeitet.
Diese virtuellen Lager stellen keine physischen Kisten dar, sondern buchhalterische Konten. Sie gewährleisten, dass das System jede Materialbewegung eindeutig verbucht – auch dann, wenn Teile des Weges nicht registrierbar sind.
3.1 Funktion der doppelten Buchführung
„RECEIVE" markiert den Eintritt von Material aus der Außenwelt, „TRANSIT" überbrückt nicht registrierbare Transportwege, „WIP" kennzeichnet laufende Produktionsprozesse und „SHIP" den Austritt von Waren aus dem System. Diese Konten bilden gemeinsam eine geschlossene logistische Kette, in der kein Material unkontrolliert verschwindet oder doppelt gezählt wird.
Diese Vollständigkeit beruht auf der konsequenten Anwendung einer doppelten Buchhaltungslogik auf jede Materialbewegung. Jede Transaktion besteht systemisch aus genau zwei untrennbaren Aktionen: einem „TAKE", der einen Artikel aus einer Quelle entnimmt, und einem „GIVE", der denselben Artikel an eine Senke übergibt. Physisch befindet sich das Item zwischen beiden Aktionen in der Hand des Inserters, buchhalterisch bleibt es jedoch jederzeit eindeutig verortet. Einen Zustand ohne Zuordnung zu Quelle oder Senke lässt das System nicht zu.
Zwischen zwei registrierten Objekten führt diese Logik zu einem Nullsummenspiel. Der TAKE reduziert den Bestand der Quelle, der GIVE erhöht den Bestand der Senke um exakt dieselbe Menge. Dieses Prinzip gilt auch bei Übergängen über nicht registrierte Transportwege. In diesen Fällen bucht das System TAKE oder GIVE nicht gegen ein physisches Objekt, sondern gegen ein virtuelles Lagerkonto. Unabhängig vom konkreten Pfad verschiebt sich Material stets von einem Konto auf ein anderes, die Gesamtbilanz bleibt ausgeglichen.
Eine Ausnahme bildet das virtuelle Lager WIP (Work in Progress). WIP repräsentiert keine Umschlagbewegung, sondern eine Transformation. Beim Eintritt in WIP entnimmt ein TAKE Material aus einem registrierten Objekt und verbucht es als „in Arbeit". Ab diesem Zeitpunkt greift die Nullsummenlogik nicht mehr, da das Material nicht unverändert an anderer Stelle erscheint. Die Produktion verarbeitet es und überführt es in ein anderes Produkt, das erst später durch einen GIVE wieder in die Bestandslogik eingeht.
Genau hierfür ist WIP erforderlich. Es macht sichtbar, dass Material zwar aus dem Lagerbestand abgeflossen ist, jedoch noch nicht als fertiges Produkt vorliegt. Das System bildet damit korrekt ab, dass Rohstoffe gebunden und transformiert werden, bevor neue Bestände entstehen. Ohne WIP erschienen diese Vorgänge entweder als Verluste oder führten zu unzulässigen Doppelzählungen. Durch die Kombination aus TAKE- und GIVE-Buchungen und die gezielte Aufhebung der Nullsummenlogik im Fall von WIP entsteht ein konsistentes Modell, in dem jede Bewegung nachvollziehbar und jede Abweichung erklärbar bleibt.
3.2 Vier virtuelle Lager-Konten
Registriert werden können nur Maschinen, Kisten und Inserter. Alles außerhalb der Fabrik ist nicht registrierbar. Zudem ist eine Registrierung von Förderbändern nicht oder zumindest nur schwer möglich, 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 Kisten 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.
Virtuelle Lager sind keine alternativen Ablageorte, sondern bewusst aufeinander abgestimmte Bestandteile eines geschlossenen logistischen Modells. Sie strukturieren den Materialfluss innerhalb des betrachteten Systems und stellen sicher, dass jede Warenbewegung eindeutig und widerspruchsfrei erfasst wird.
4. Der Materialfluss am Praxisbeispiel
Um die zuvor beschriebene Logik der Registrierung, der Inserter-Transaktionen und der virtuellen Lager nachvollziehbar darzustellen, erläutert das folgende Kapitel ein konkretes Referenz-Setup. Als Beispiel dient die Produktion grüner Schaltkreise. Dieser Prozess kombiniert einfache Transportvorgänge mit echten Transformationsprozessen und bildet damit alle relevanten Aspekte der Buchhaltungslogik ab.
Der Materialfluss beginnt mit der Anlieferung von Kupfererz aus der Außenwelt. Das Erz erreicht die Fabrik über einen nicht registrierten Transportweg. Inserter I156 entnimmt das Erz (TAKE); systemisch ordnet das System diese Entnahme dem virtuellen Lager RECEIVE zu. Anschließend legt der Inserter das Erz per GIVE in die Kiste C35, die als Eingangslager fungiert. Mit diesem Schritt ist das Material buchhalterisch im System angekommen und als Bestand verfügbar.
Aus dem Eingangslager entnimmt Inserter I157 das Erz und führt es dem registrierten Ofen M33 zu. Da sowohl der Inserter als auch der Ofen registriert sind, handelt es sich um eine interne Umbuchung, die als Nullsummenspiel abläuft. Während der Ofen das Material zur Verarbeitung übernimmt, reduziert sich der Erzbestand in der Kiste entsprechend.
Nach Abschluss der Verhüttung entnimmt Inserter I158 die entstandenen Kupferplatten aus der Maschine und legt sie in die Ausgangskiste C36. Auch dieser Vorgang bleibt vollständig innerhalb des registrierten Systems und erzeugt eine ausgeglichene Buchung aus TAKE und GIVE. Zu diesem Zeitpunkt liegt das ursprüngliche Erz vollständig in Form von Kupferplatten vor. Virtuelle Lager sind hierfür nicht erforderlich, da Quelle und Senke jederzeit eindeutig identifizierbar bleiben.
Anschließend verlassen die Kupferplatten den direkt beobachtbaren Bereich. Inserter I158 entnimmt die Platten aus der Kiste C36 und legt sie auf ein nicht registriertes Förderband. Der TAKE erfolgt aus einem registrierten Objekt, ein zugehöriger GIVE zu einem registrierten Ziel existiert jedoch nicht. Das System schreibt die Übergabe stattdessen dem virtuellen Lager TRANSIT gut. Die Platten befinden sich nun im Transport, sind damit nicht verfügbar, bleiben aber buchhalterisch sichtbar.
Am Ende des Förderbandes nimmt Inserter I166 die Platten auf und legt sie in den registrierten Eingangspuffer C39 der Kabelherstellung. Dieser Vorgang bildet das spiegelbildliche Gegenstück: Der TAKE erfolgt aus dem virtuellen Lager TRANSIT, der GIVE in C39. Damit ist der Transport abgeschlossen, das Material wieder vollständig im System verortet und der Transitbestand entsprechend reduziert.
Die eigentliche Kabelproduktion interpretiert das System als Value Added Service der Logistik. Am Ausgang der Kabelherstellung legt Inserter I180 die produzierten Kupferkabel in das Schnittstellenlager C39. Von dort entnimmt ein weiterer Inserter die Kabel (TAKE) und übergibt sie per GIVE an ein Förderband der Produktion. Die Kabel befinden sich damit im Work-in-Progress (WIP).
Eisenerze durchlaufen einen analogen Prozess und werden ebenfalls zu Eisenplatten verhüttet. Das System bucht diese Platten direkt ins WIP. Aus Eisenplatten und Kupferkabeln, beide im WIP, entstehen in einer nicht registrierten Maschine die grünen Schaltkreise. Inserter I175 entnimmt die fertigen Schaltkreise aus der Produktionsmaschine (TAKE) und legt sie in das Schnittstellenlager C41 (GIVE).
Den letzten Abschnitt des Materialflusses bildet der Versand. C41 fungiert zugleich als Ausgangslager. Inserter I176 entnimmt die fertigen grünen Schaltkreise aus dem Lager (TAKE) und übergibt sie an einen nicht registrierten Abtransport (GIVE). Der TAKE reduziert den Bestand des Ausgangslagers, der GIVE wird dem virtuellen Lager SHIP zugeordnet. Mit diesem Schritt verlässt das Produkt das System endgültig und geht als Warenausgang in die Buchhaltung ein.
Dieses Praxisbeispiel zeigt, dass sich der gesamte Materialfluss lückenlos aus TAKE- und GIVE-Bewegungen zusammensetzt. Interne Bewegungen gleichen sich aus, Transportlücken schließt das virtuelle Lager TRANSIT, Produktionsprozesse löst das System über WIP korrekt auf, und externe Schnittstellen grenzt es sauber über RECEIVE und SHIP ab. Das Beispiel dient damit nicht nur der Illustration, sondern auch als Referenzmodell.
 |
Zentrales Element ist das Protokollfenster, von dem aus alle weiteren Funktionen erreichbar sind. |
5. Daten-Auswertung und Inventur
Nachdem die Fabrik registriert und der Materialfluss logisch definiert ist, stellt Factory Ledger eine Reihe von Dialogen bereit, über die der Nutzer auf die erfassten Daten zugreift. 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 das Protokollfenster, von dem aus alle weiteren Funktionen erreichbar sind. Ergänzend stellt das System spezialisierte Dialoge für Transaktionen, Reset-Vorgänge und die Analyse des Anlagevermögens im Blueprint-Kontext bereit.
5.1 Das Protokollfenster – zentrale Arbeitsoberfläche
Mit Shift + B öffnet der Nutzer das Protokollfenster. Es fungiert als zentrale Arbeitsoberfläche des Factory Ledgers und ist bewusst als einheitlicher Einstiegspunkt konzipiert. Von hier aus sind sowohl Zustandsdaten als auch weiterführende Funktionen zugänglich. Beim Öffnen zeigt das Fenster standardmäßig die Ergebnisse der regelmäßig durchgeführten Inventuren an.
Das Protokollfenster ist kein reines Ereignislog, sondern eine kontrollierte Sicht auf den jeweils relevanten Ausschnitt der gespeicherten Daten. Während des Betriebs dient es dem Überblick und der Plausibilitätskontrolle der Datenerfassung. Die vollständige zeitliche Tiefe der Daten stellt das Fenster bewusst nicht dar; diese erschließt sich ausschließlich über den Export und die anschließende Offline-Auswertung.
5.2 Inventuransicht – Momentaufnahme des Systemzustands
In der Grundansicht des Protokollfensters zeigt Factory Ledger die Inventur-Snapshots an. Das System erzeugt diese Inventuren automatisch in festen Zeitabständen. Jede Inventur bildet eine vollständige Momentaufnahme des Systems ab.
Erfasst werden alle registrierten Kisten, der Zustand der Maschinen sowie die Bestände der virtuellen Lagerkonten. Die Inventur beschreibt damit stets den Zustand der Fabrik zu einem eindeutig definierten Zeitpunkt. Sie beantwortet die Frage, welche Mengen an welchen Orten gebunden sind, nicht jedoch, auf welchem Weg sie dorthin gelangt sind. Gerade in Verbindung mit den virtuellen Lagern liefert 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, bildet das Transaktionsfenster die zeitliche Dynamik des Systems ab. Der Nutzer öffnet es über den Schalter TX im Protokollfenster. Das Fenster listet alle erfassten Warenbewegungen in zeitlicher Reihenfolge auf und macht damit den Verlauf der Materialflüsse nachvollziehbar.
Jede Zeile im Transaktionsfenster entspricht genau einer Bewegung eines registrierten Inserters. Sie dokumentiert die beteiligten Objekte sowie das bewegte Item. Das Fenster dient damit der Beobachtung des laufenden Materialflusses und der Plausibilitätsprüfung der logistischen Schnittstellen. Der Nutzer erkennt unmittelbar, ob Inserter wie vorgesehen arbeiten und ob TAKE- und GIVE-Beziehungen korrekt greifen.
Das Transaktionsfenster ist ausdrücklich kein Analysewerkzeug. Es fungiert als Sichtfenster auf den operativen Betrieb. Die Auswertung größerer Zeiträume und komplexer Zusammenhänge erfolgt auch hier ausschließlich über den Export und die anschließende Offline-Analyse.
5.4 Reset-Dialog – definierte Neustarts für saubere Analysen
Für belastbare Auswertungen ist es häufig erforderlich, Factory Ledger in einen definierten Ausgangszustand zu versetzen. Zu diesem Zweck stellt das System einen eigenen Reset-Dialog bereit. Der Nutzer erreicht ihn direkt über das Protokollfenster und kann damit Datenerfassung, Buchhaltungsperioden und Analysezeiträume kontrolliert neu starten.
Ein Reset löscht nicht die physische Fabrik, sondern setzt gezielt die erfassten Daten zurück. Inventuren und Transaktionen lassen sich vollständig entfernen, sodass eine neue Buchhaltungsperiode beginnt. Gegenstände in Kisten oder Maschinen, die erhalten bleiben sollen, können vorab als geschützt markiert werden. Ebenso lassen sich die Listen registrierter Objekte (Kisten, Maschinen, Protected) gezielt zurücksetzen.
Auf diese Weise schafft das System reproduzierbare Startbedingungen, etwa um das Hochfahren einer Produktion kontrolliert zu analysieren. Reset ist damit kein Notfallwerkzeug, sondern ein bewusst eingesetztes Instrument zur Strukturierung von Messphasen und zum Vergleich unterschiedlicher Szenarien.
5.5 Blueprint-Analyse – Zugriff auf Anlagevermögen und Stammdaten
Neben den laufenden Betriebsdaten stellt Factory Ledger eine zusätzliche Auswertungsfunktion im Kontext des Blueprint-Dialogs von Factorio bereit. Innerhalb dieses Dialogs steht ein eigener Schalter zur Verfügung, über den der Nutzer eine Analyse des markierten Aufbaus auslöst. Diese Analyse erschließt insbesondere das Anlagevermögen und die zugehörigen Stammdaten unabhängig vom aktuellen Betriebszustand.
Diese Analyse erzeugt weder Protokolle noch Transaktionen, sondern liefert eine reine Momentaufnahme des Anlagevermögens. Sie weist sowohl die benötigte Infrastruktur als auch eine vollständige Liste der verwendeten Items aus. Auf dieser Basis lassen sich Stammdaten ableiten, Kostenmodelle aufbauen oder unterschiedliche Layouts systematisch vergleichen. Die Blueprint-Analyse ergänzt damit die laufende Buchhaltung um eine statische Bewertung der installierten Basis.
Résumé
Der Factory Ledger ist ein Instrument zur strukturierten Messung der Abläufe in einer Factorio-Fabrik. Durch die klare Trennung von Registrierung, Materialflusslogik, Zustandsaufnahmen und Transaktionen wird die Fabrik zu einem nachvollziehbaren logistischen System. Bestände, Bewegungen und Investitionen sind eindeutig identifizierbar und in einer konsistenten Buchhaltungslogik zusammengeführt.
Dieser Beitrag beschreibt das zugrunde liegende Systemverständnis sowie 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 direkt 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
- Get Factory Ledger in the factorio mod portal and on GitHub
Anhang: Technische Details und Systemkonfiguration
Dieser Anhang ergänzt die Beschreibung des Factory Ledgers um technische Hinweise zur internen Datenverwaltung sowie zur sinnvollen Konfiguration zentraler Parameter für Kurzzeit- und Langzeitanalysen. Für das grundlegende Verständnis des Systems sind diese Aspekte nicht zwingend erforderlich. Sie werden jedoch relevant, sobald größere Datenmengen anfallen oder mehrere Auswertungszyklen miteinander verglichen werden sollen.
A.1 Speicherverwaltung und Ringpuffer-Logik
Zur Begrenzung des Speicherverbrauchs innerhalb der laufenden Factorio-Simulation verwendet Factory Ledger für Transaktionen eine Ringpuffer-Struktur. Statt Ereignisse unbegrenzt im Arbeitsspeicher zu sammeln, definiert das System eine feste maximale Anzahl an Transaktionen, die gleichzeitig vorgehalten werden. Diese Kapazität wird über die Mod-Einstellungen beim Start der Simulation festgelegt und lässt sich an die gewünschte Analyseauflösung anpassen.
Sobald die definierte Kapazität erreicht ist, überschreibt der Ringpuffer schrittweise die ältesten Einträge mit neuen Transaktionen. Der Speicherbedarf bleibt dadurch konstant, unabhängig von der Laufzeit der Simulation. Um dennoch eine konsistente externe Auswertung zu ermöglichen, vergibt das System für jede Transaktion 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 Dubletten oder Mehrdeutigkeiten zu erzeugen.
A.2 Optimierung der Inventurintervalle
Die Inventur des Factory Ledgers basiert auf periodischen Snapshots des Systemzustands. Die Wahl des Inventurintervalls beeinflusst unmittelbar sowohl die entstehende Datenmenge als auch die Systemlast während der Simulation. Das Intervall lässt sich über die Einstellungen konfigurieren und sollte bewusst gewählt werden.
Ein langes Intervall reduziert die Anzahl der erzeugten Inventurdatensätze und schont Speicher und Exportvolumen. Zustandsänderungen zwischen zwei Inventuren müssen in diesem Fall stärker aus den Transaktionsdaten rekonstruiert werden. Ein kurzes Intervall erhöht dagegen die zeitliche Auflösung erheblich, da sehr häufig vollständige Bestandsaufnahmen erzeugt werden. Dies ermöglicht detaillierte Analysen, führt jedoch zu großen Datenmengen und erhöhtem Rechenaufwand, da bei jeder Inventur alle registrierten Kisten und Maschinen ausgelesen werden.
In der Praxis stellt die Wahl des Inventurintervalls daher stets 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 reibungslosen Import ermöglicht.
Viele Informationen erscheinen im Format Bezeichnung=Wert, etwa zur Kennzeichnung von Maschinenzuständen oder Metadaten. Diese Struktur erlaubt eine einfache Weiterverarbeitung mit Standardfunktionen von Excel oder über die Funktion „Text in Spalten". Inventur- und Transaktionsdaten folgen dabei einer konsistenten Struktur, sodass Zeitstempel, Objektkennungen und Statusinformationen direkt miteinander verknüpft 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 Erweiterungen kein freier Zugriff auf das Dateisystem gestattet. Factory Ledger legt daher alle Exporte ausschließlich im vorgesehenen Script-Output-Ordner ab.
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 Typkennzeichnung, etwa für Inventur- oder Transaktionsdaten, als auch einen Zeitstempel. Dadurch verhindert das System, dass bestehende Dateien bei mehrfachen Exporten unbeabsichtigt überschrieben werden.
A.5 Multiplayer-Fähigkeit
Factory Ledger ist so ausgelegt, dass er auch in einer Multiplayer-Umgebung stabil und konsistent arbeitet. Systemweit existieren stets eine gemeinsame Registrierungsliste sowie ein zentraler Datenbestand für Inventuren und Transaktionen. Das System erfasst alle Aktionen unabhängig davon, 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 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. Factory Ledger ist entsprechend vollständig in englischer Sprache lokalisiert. Zusätzlich steht eine vollständige deutsche Lokalisierung zur Verfügung, 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.
Kommentare
Kommentar veröffentlichen