Deutsch Architektur und Tests

Architektur und Tests

Warum modular?

In Bitburner bestimmt jede verwendete Netscript-API den RAM-Preis einer Datei. Würde ein einziges Script alle APIs importieren, könnte es auf kleinen Home-Servern nie starten. autoDoIt trennt daher Planung, Aufgaben und Worker.

Dateiaufbau

autoDoIt.js              kleiner Scheduler
core/                    Konfiguration, Fähigkeiten, Status, Übersetzung
lib/                     reine Auswahl-, Budget- und Hilfslogik
tasks/                   kurze normale Managementaufgaben
special/                 BitNode-/Source-File-abhängige Systeme
workers/                 minimale dauerhafte Ausführungsdateien
ui/                      Control Center und Overview-Erweiterung
tools/                   Selbsttest und Auto-Updater
git-pull.js              vollständiger Downloader/Updater
git-pull-lite.js         RAM-sparender Downloader
runtime-manifest.txt     verbindliche Liste aller Laufzeitdateien
version.txt              Vergleichsmarker für Updates
tests/                   externe Node-Tests

Scheduler

autoDoIt.js importiert keine teuren System-APIs. Jeder Takt:

1. aktuellen Home-RAM und dynamisches Ziel bestimmen
2. Betriebsphase auswählen
3. unpassende BitNode-/API-Aufgaben ausfiltern
4. tatsächlichen RAM-Preis der verbleibenden Datei prüfen
5. fällige Aufgaben nach Phasenpriorität sortieren
6. nur die erlaubte Anzahl starten

Exklusive Aufgaben wie Casino oder bestimmte SF‑1-Abläufe blockieren kurzzeitig andere Managementstarts. Laufende Hacking-Worker auf anderen Servern bleiben davon unberührt.

Aufgaben und Worker

Normale Aufgaben führen einen Durchlauf aus und beenden sich. Dadurch liegt ihr API-RAM nur während echter Arbeit im Speicher. Dauerhafte Worker sind extrem klein und erhalten Ziel/Modus als Argument.

Große Verwaltungsbereiche laufen als kleine Koordinatoren mit exklusiven Phasen-Workern. Beispielsweise teilen Fraktionen Planung und Arbeit, Bladeburner Grundzustand, Skills und Aktion und Aktien Zugang und Handel. Der Scheduler startet pro Gruppe höchstens eine Phase; das dynamische RAM-Ziel rechnet deshalb ebenfalls nur mit dem größten Worker der Gruppe.

Sondersysteme wie IPvGO oder Darknet dürfen länger laufen, aber nur in einem passenden BitNode beziehungsweise bei vorhandener Source-File-Fähigkeit.

Statuskommunikation

Module schreiben strukturierte Ereignisse in Datendateien. Dashboard und Overview lesen diese günstigen Zustände, statt alle teuren APIs selbst abzufragen. Benachrichtigungen besitzen Cooldowns, damit dieselbe Voraussetzung nicht das Terminal oder Toast-System flutet.

Updatesicherheit

runtime-manifest.txt ist die Quelle für alle benötigten Laufzeitdateien. Der Updater:

1. lädt die Remote-Version und das Manifest
2. lädt jede Datei
3. validiert erwartete Marker
4. führt auf Wunsch den Selbsttest aus
5. startet den Scheduler mit bisherigen Argumenten neu

Eine fehlgeschlagene Remote-Prüfung ersetzt keine funktionierende lokale Installation.

Externe Tests

Im Repository:

node --test tests/*.test.mjs

Die Tests prüfen unter anderem:

• Schedulerphasen und Prioritäten
• Netzwerk- und Portlogik
• Hacking-Zielauswahl
• Budgets für Home, Cloudserver und Hacknet
• Fraktions-/Augmentationsauswahl
• Phasenisolation großer Manager und gemeinsamer Fraktionsplan
• RAM-Zielberechnung mit dem Maximum statt der Summe exklusiver Worker
• BitNode-Route und Source-File-Projektion
• Coding-Contract-Löser
• Darknet-Passwortmodelle und Worker-Aufteilung
• Casino-Hilfslogik
• v3-API-Namen für Corporation und Bladeburner
• Importierbarkeit sämtlicher Laufzeitmodule
• Updater-Manifest und Neustartverhalten

In-Game-Selbsttest

run tools/self-test.js

Er ergänzt die externen Tests um Dinge, die Node nicht nachbilden kann:

• Bitburners echten RAM-Analyzer
• Dateien auf home
• Netzwerk des aktuellen Saves
• Source-File-/BitNode-API-Zugänge

Der Selbsttest kauft nichts, installiert keine Augmentations und beendet keinen BitNode.

Grenzen

Sichtbare UI-Automation (Casino und ausdrücklich erlaubte SF‑1-Schritte) kann durch Änderungen am Bitburner-Layout betroffen sein. Unbekannte Coding-Contract-Typen werden ohne Versuch übersprungen, damit keine Belohnung verloren geht.

Urheberrecht und Mitarbeit

Fehlermeldungen, Testergebnisse und Verbesserungsvorschläge sind willkommen. Der Quellcode besitzt keine freie Weiterverwendungs- oder Weiterveröffentlichungslizenz. Persönliche Nutzung in Bitburner ist erlaubt; Kopieren, Verteilen, Einbinden in andere Projekte oder Veröffentlichen veränderter Versionen benötigt die vorherige ausdrückliche Erlaubnis von ame824.