Arknights Endfield Basisbau-Leitfaden Fabrikautomatisierung und Produktion

Arknights: Endfield Base-Building ist dein langfristiger Progressionsmotor, und der AIC (Automated Industry Complex) ist der Ort, an dem dieser Motor entweder sauber laeuft oder in staendige manuelle Fixes kollabiert. Dieser Guide erklaert Factory-Automation und Produktion mit einer Prioritaet: Zuverlaessigkeit. Du lernst, wie das PAC- und Depot-Output-System den Item-Flow wirklich steuert, wie du ein Power-Network baust, das sauber mit Relay Towers und Cable-Limits skaliert, wie du Conveyors so designst, dass Lines nicht jammen, und wie du Produktion mit modularen Blocks und Blueprints skalierst, statt deine ganze Base jedes Mal neu zu bauen, wenn du ein neues Tier freischaltest.

Die Kernidee ist simpel. Stabile Produktion kommt aus drei Entscheidungen, die du frueh triffst und spaeter konsistent beibehaeltst: eine lesbare Power-Spine mit genug Margin, ein sauberes Item-Routing-Modell, das auf PAC-Output-Ports basiert, die kurze Conveyor-Runs speisen, und Production-Modules, die du duplizieren kannst, ohne die ganze Base neu zu verkabeln. Wenn du zuerst um diese Constraints herum baust, hoert dein AIC auf, ein Puzzle zu sein, und wird zu einer vorhersehbaren Maschine, die dein Crafting und deine Upgrades fuettert, waehrend du Story und Combat spielst.

Der AIC-Production-Loop und warum die meisten Bases stallen

Jede Production-Chain in Endfield ist dasselbe Muster, nur auf verschiedenen Tiers. Du extrahierst Raw-Resources, bewegst sie in Storage, gibst spezifische Items an Maschinen aus, verarbeitest sie zu Intermediates und konsumierst Intermediates, um End-Products zu bauen. Der haeufige Fehler ist, das wie ein riesiges Belt-Network zu behandeln, in dem alles ueberallhin geht. Dieser Ansatz fuehlt sich am Anfang flexibel an und wird spaeter unfixbar, weil du, wenn ein Input fehlt, nicht mehr erkennen kannst, ob das Problem Supply, Routing oder ein Downstream-Jam ist.

Der zuverlaessige Ansatz ist layered und modular. Denk in Layers: Raw-Intake, Refinement, Components, dann End-Products. Jede Layer sollte eine klare Source haben, ein klares Set an Outputs und einen klaren Punkt, an dem du Kapazitaet erweitern kannst, indem du ein weiteres Module hinzufuegst statt deine Belts herauszureissen. Sobald du das layered Model uebernimmst, wird Troubleshooting mechanisch: du findest das erste leere Belt-Segment oder den ersten vollen Output, der nicht weiter kann, und fixst diese eine Layer, statt random ueberall Maschinen hinzustellen.

PAC-Output-Ports und Depot-Control sind das echte Automation-System

Automation startet am PAC, nicht an der Maschine. Der PAC hat Output-Ports, die du so konfigurieren kannst, dass sie ein bestimmtes Item aus deinem Depot ausgeben, und wenn du einen Conveyor-Belt an einen konfigurierten Output-Port anschliesst, speist er dieses Item in deine Production-Line, solange das Depot Stock hat und der Output nicht backed up ist. Das Tutorial-Level-Design ist explizit: du willst Materials nicht manuell in Maschinen schleppen als Default-Workflow, du willst, dass der PAC Items auf Belts pusht und die Line laufen laesst. Das ist der Unterschied zwischen einem AIC, das skaliert, und einem AIC, das fuer immer nur eine kleine Crafting-Ecke bleibt.

Dieselbe Logik gilt fuer Outpost-Setups mit Sub-PACs: behandle Ports als Source of Truth fuer das, was ein Module erhaelt, und halte Routing kurz und lesbar, damit der Flow vorhersehbar bleibt.

Die praktische Konsequenz ist, dass du deine Base um Ports und kurze Runs herum designen solltest. Teile Ports nach Kategorie ein und halte jeden Belt lesbar. Denk daran, dass Ports eine begrenzte Ressource sind, also widme sie zuerst kritischen High-Traffic-Inputs. Wenn eine Line stoppt, sollte deine erste Frage sein: gibt der PAC das korrekte Item aus, und bewegt der Belt es. Wenn die Antwort nein ist, liegt der Fix bei der Output-Assignment oder beim Belt-Segment. Wenn die Antwort ja ist, liegt der Fix downstream an der Maschine oder an einem Output-Jam. Diese eine Gewohnheit macht Debugging von Raten zu einer Checkliste.

Throughput und Buffers: warum perfekt enge Chains scheitern

Factory-Chains scheitern in echten Sessions, weil Demand nicht perfekt synchron ist. Eine Maschine beendet ein Batch, eine andere Maschine verarbeitet noch, eine dritte ist idle, weil eine Komponente spaet ankam, und ploetzlich wird eine Chain, die auf Papier perfekt aussah, instabil. Die Loesung ist nicht, die Chain in etwas Komplexeres umzubauen. Die Loesung ist, fuer Buffer-Verhalten zu designen: Basics und Schluessel-Intermediates mit Ueberschuss produzieren, Lines simpel halten und End-Products nicht overbuilden, bevor deine Intermediate-Layer komfortabel vor Demand liegt.

Wenn eine Chain stallt, fuege nicht zuerst mehr End-Product-Maschinen hinzu. Folge der Chain rueckwaerts, bis du das erste leere Belt-Segment findest, und erhoehe nur diese Stage. In der Praxis sind die meisten Stalls ein fehlendes Intermediate, das mehrere End-Products speist. Fix die Intermediate-Layer einmal, und die ganze Base wird stabil. Versuchst du es am Ende zu fixen, jagst du denselben Mangel fuer immer.

Power und Infrastructure, die ohne Rewiring skaliert

Power ist die erste harte Wand, weil jede Expansion Load hinzufuegt. Wenn du Produktion erweiterst, ohne das Grid zu erweitern, bekommst du random Offline-Cluster und verlierst mehr Zeit mit Debugging als du durch neue Maschinen gewinnst. Die zuverlaessige Strategie ist, zuerst eine Power-Spine zu bauen und dann in Production-Modules zu verzweigen. Eine Power-Spine ist eine Backbone-Route aus Relay Towers und Kabeln, die du erwartest, langfristig zu behalten, waehrend die Base waechst, waehrend Production-Blocks als Branches anbinden, die du erweitern oder verschieben kannst, ohne das ganze Grid zu brechen.

Endfield erzwingt ausserdem Cable-Length-Constraints, abhaengig davon, wo das Kabel startet. Das bedeutet, du kannst Power nicht wie ein unendliches Verlaengerungskabel behandeln. Du musst Relay Towers in sinnvollen Abstaenden setzen und in Steps expandieren. Das ist kein Busywork. Das ist die intendierte Scaling-Constraint, und wenn du sie frueh respektierst, werden kuenftige Expansions Routine statt Schmerz.

Relay-Tower-Cable-Limits und saubere Expansion-Steps

Das Spiel unterscheidet Cable-Reach je nach Source: Kabel vom Automation-Core und vom Relay Tower koennen bis zu 80 Meter reichen, waehrend Kabel, die von Electric Pylons starten, 30 Meter erreichen. Das ist wichtig, weil der schnellste Weg, deine Base zu brechen, ist, zu weit von einer schwachen Source zu extend-en und dich dann zu wundern, warum ein neues Module nie hochfaehrt. Bau deine Spine so, dass lange Runs vom Automation-Core oder einem Relay Tower ausgehen, und nutze kurze Pylon-Runs nur fuer den letzten lokalen Hop innerhalb eines Modules. Wenn du mit 80m-Relay-Spacing im Kopf baust, haeltst du Expansions vorhersehbar und vermeidest Dead-Zones, die spaeter Rework erzwingen.

Expansion sollte in einer festen Reihenfolge passieren. Zuerst Power-Margin hinzufuegen. Dann Miners oder Refinement. Dann Components. Erst danach neue End-Product-Lines. Wenn du alles auf einmal hinzufuegst und das Grid faellt, lernst du nicht, welche Aenderung den Fail verursacht hat, und du verschwendest Zeit damit, Maschinen zu loeschen statt das Network-Design zu fixen.

Power-Debugging-Order, die wasted Time verhindert

Wenn Produktion stoppt, check zuerst Power. Eine Maschine ohne Strom sieht aus wie ein Input-Shortage, ist es aber nicht. Nach Power check PAC-Output-Config und Belt-Motion. Erst dann check Machine-Recipe und Output-Path. Diese Reihenfolge funktioniert, weil Power global ist, Output-Ports der Haupt-Flow-Choke-Point sind und Machine-Issues lokal sind. Debuggst du in der umgekehrten Reihenfolge, verschwendest du Zeit mit Belts verschieben und Recipes neu zuweisen, waehrend das echte Problem eine gebrochene Relay-Chain ist.

Wenn du Infrastructure bewegen musst, mach es chirurgisch. Halte die Spine stabil und passe nur den Branch an, der das failing Module speist. Eine Base, die lesbar bleibt, skaliert immer schneller als eine Base, die zu einem Maze aus Kabeln und Belts wird.

Conveyors, Routing und jam-proof Production-Lines

Belts failen nicht, weil Belts schwer sind. Belts failen, weil Routing unlesbar wird. Das zuverlaessigste Belt-System in Endfield sind kurze Runs von einem dedizierten PAC-Output-Port in ein einzelnes Module, dann ein klarer Output-Path zurueck in Storage oder zum naechsten Module. Wenn du versuchst, einen Belt-Bus ueber viele unzusammenhaengende Recipes zu teilen, erzeugst du stille Failure-Modes: das falsche Item geht in einen Split, ein Output backed up und blockiert einen kritischen Input, oder eine Line sieht gefuettert aus, wird aber in Wahrheit von einem konkurrierenden Consumer ausgehungert.

Dein Ziel ist nicht maximale Kompaktheit. Dein Ziel ist maximale Klarheit. Klarheit ist, was dich Issues in Sekunden fixen laesst und die Factory online haelt. Kompakte Builds sehen oft beeindruckend aus und kollabieren dann, wenn du ein Recipe aendern oder ein extra Intermediate hinzufuegen musst.

Modules, Ports und kurze Runs schlagen einen riesigen Belt-Bus

Baue Modules, die du in einem Satz beschreiben kannst: dieser Block macht aus Raw Ore refined Basics, dieser Block macht aus Basics Components, dieser Block macht aus Components ein End-Product. Jedes Module bekommt dedizierte Input-Belts von spezifischen PAC-Outputs und einen sauberen Output-Path. Wenn du mehr Throughput brauchst, duplizierst du das Module und speist es auf dieselbe Weise. Das ist Scaling. Einen Belt ueber die ganze Base zu ziehen und ueberall reinzutappen ist kein Scaling, es ist eine kuenftige Troubleshooting-Falle.

Wenn du zusaetzliche Flexibilitaet willst, koennen Systeme wie Depot Bus Port und Depot Bus Section (oft als Teil der Wuling Depot Bus-Progression freigeschaltet) helfen, Routing zu standardisieren, aber das Prinzip bleibt gleich: Ports und Routing so erweitern, dass der Flow lesbar und modular bleibt. Ein flexibles Port-System hilft nur, wenn die Lines verstaendlich bleiben und genug isoliert sind, dass eine Aenderung nicht alles bricht.

Die drei Jam-Patterns und der eine Fix, der meistens funktioniert

Die meisten Jams sind eines von drei Patterns. Erstens: Output hat keinen Weg, daher stoppen Maschinen und es sieht wie ein Input-Problem aus. Zweitens: zwei Consumer kaempfen um einen Input-Stream und beide werden instabil. Drittens: eine falsche Routing-Entscheidung injiziert das falsche Item in eine Line und die ganze Downstream-Chain wird Muell. Der Fix ist meist derselbe: das Module isolieren, Routing kuerzen, einen Port fuer den kritischen Input dedizieren und sicherstellen, dass Outputs einen klaren Path zurueck in Storage oder zur naechsten Stage haben.

Wenn du Modules getrennt haeltst, werden Jams zu lokalen Events. Wenn du ein shared Mega-Network baust, wird ein Jam zu einem Base-weiten Outage. Zuverlaessigkeit kommt aus Containment, nicht aus Cleverness.

Was du zuerst automatisierst: eine Prioritaetsreihenfolge, die korrekt bleibt

Fruehe Automation geht nicht darum, jedes Recipe zu jagen. Es geht darum, wiederholte manuelle Chores zu entfernen und Inputs zu stabilisieren, die alles andere freischalten. Die sicherste Reihenfolge ist immer: Raw-Intake zuerst, Refinement zweitens, High-Demand-Intermediates drittens und erst dann eine End-Product-Convenience-Line, die dir jede Session Zeit spart. Diese Sequenz verhindert das klassische Problem, dass du eine coole End-Product-Chain baust, die staendig stallt, weil die Intermediate-Layer unterbaut ist.

Die Tabelle unten ist ein Framework, keine starre Checkliste. Deine genauen Recipe-Namen variieren je nach Progression, aber die Logik aendert sich nicht. Wenn du dieser Reihenfolge folgst, fuehlst du deine Base mit jeder Expansion stabiler werden, statt fragiler zu werden.

Die Regel, die die meisten Rebuilds verhindert

Skaliere End-Products nicht, bis Intermediates komfortabel ueberproduziert sind. Wenn dir eine Component ausgeht, ist mehr End-Product-Maschinen hinzufuegen niemals die Loesung. Die Loesung ist upstream: mehr Extraction, mehr Refinement oder das Intermediate-Module duplizieren. Diese eine Regel ist der Grund, warum modulare Factories muhelos wirken, waehrend improvisierte Factories sich wie staendiges Firefighting anfuehlen.

Sobald die Intermediate-Layer stabil ist, werden End-Products einfach. Du kannst eine Line hinzufuegen, beobachten und dann eine weitere hinzufuegen. Ohne Stabilitaet ist jede neue End-Product-Line nur eine weitere Art, denselben Mangel wieder offenzulegen.

Blueprints und Scaling: wiederhole was funktioniert

Blueprints existieren, weil Endfield will, dass du ueber Repetition skalierst, nicht ueber Reinvention. Du kannst ein AIC-Layout speichern und anderswo wiederverwenden, und Spieler teilen Blueprint-Codes gezielt, um Base-Building zu beschleunigen. Entscheidend ist, wie du sie nutzt. Ein Blueprint ist am besten als Module: ein bewaehrter Refinery-Block, ein bewaehrter Component-Block oder ein bewaehrtes Power-Segment. Wenn du mehr Throughput brauchst, stempelst du das Module erneut und verbindest es mit derselben Power-Spine und derselben Port-Logik.

Blueprints halten deine Base auch konsistent. Konsistenz macht das Balancing von Power und Throughput vorhersehbar. Wenn jeder neue Block anders erfunden wird, wird deine Base unmoeglich zu verstehen. Wenn jeder neue Block eine Kopie von etwas ist, das du schon getestet hast, wird Scaling zur Routine.

Ein Workflow, der verhindert, dass Blueprints deine Base brechen

Baue ein Module zuerst manuell und lass es lange genug laufen, um zu beweisen, dass es in echtem Play stabil ist. Speichere es als Blueprint. Dupliziere es nur, wenn du Kapazitaet brauchst. Wenn du ein Blueprint von jemand anderem importierst, behandle es als Template und validiere es gegen dein aktuelles Power-Budget und deine freigeschaltete Tech. Ein Build, der fuer eine Progression-Stage perfekt ist, kann in einer anderen Stage fragil oder nicht unterstuetzt sein. Zuverlaessigkeit kommt aus Testing und inkrementeller Expansion, nicht daraus, das groesste Layout zu kopieren, das du finden kannst.

Wenn nach dem Stempeln eines Blueprints etwas bricht, panic-rebuild nicht. Nutze dieselbe Debugging-Order: Power, Ports, Belts, Machines. Blueprints beschleunigen Construction, aber sie ersetzen kein klares Routing-Modell.

Conclusion

Arknights: Endfield Factory-Automation ist ein Reliability-Game, das auf drei Saeulen basiert: eine skalierbare Power-Spine mit Relay Towers und respektierten Cable-Limits, ein Routing-Modell, in dem PAC-Output-Ports kurze, lesbare Conveyor-Runs speisen, und modulare Production-Blocks, die du mit Blueprints duplizieren kannst. Automatisiere zuerst Raw-Intake und Refinement, stabilisiere Intermediates und fuege End-Product-Lines erst hinzu, wenn die Base bei Components komfortabel vorne liegt. Wenn du fuer Klarheit und Containment designst, bleibt dein AIC online und treibt leise deine Progression, waehrend du den Rest des Games spielst.