Ein Skript aktualisieren

Finde, was veraltet istCopy Anchor Link

Die Warnung in der Konsole deckt nur gestartete, nicht ignorierte Skripte ab, also prüfe jeden Ordner:

cd "resources/[ai]"
for n in ai-*; do
  repo=$(sed -n 's#.*"repository": *"\(github:\|https://github.com/\)\([^"]*\)".*#\2#p' "$n/package.json" | sed 's#\.git$##')
  cur=$(sed -n 's#^  "version": *"\([^"]*\)".*#\1#p' "$n/package.json")
  latest=$(gh release view --repo "$repo" --json tagName --jq .tagName 2>/dev/null | sed 's#^v##')
  echo "$n $cur ${latest:-no-release}"
done

• Vergleiche Versionen wie ai-core: Entferne ein führendes v, vergleiche die Zahlen mit Punkten, ignoriere Pre-Release-Zusätze. Kein Release heißt: nichts zu aktualisieren.
• Ohne gh: curl -s -H "Accept: application/vnd.github+json" https://api.github.com/repos/<owner>/<name>/releases/latest (60 Anfragen pro Stunde und IP, geteilt mit ai-cores eigener Prüfung).
• Ein Skript in updates.ignore wird nur aktualisiert, wenn der Server-Besitzer es nennt.
• Ein Ordner mit einer Version über dem neuesten Release oder ein Clone mit Commits nach dem neuesten Tag ist nicht veraltet: Überspring ihn, setze einen Ordner nie zurück.
• packages/ hat keine repository-Zeile: Vergleiche jede package.json-Version mit npm. Aktualisiere die Pakete zuerst, wenn ein neues Skript-Release eine Version braucht, die die lokalen Kopien nicht haben.

Lies die Release Notes und hol dir das OkayCopy Anchor Link

Lies die Notes jeder Version zwischen der aktuellen und der neuesten (gh release view <tag> --repo <repo> --json body,assets,url): inkompatible Änderungen, nötige Paketversionen, Migrationen, neue cfg-Zeilen (ensure, add_convar_permission, ACE), neue provide-Namen, manuelle Schritte.

Zeig dem Server-Besitzer die Liste und warte auf sein Okay. Aktualisiere in Abhängigkeitsreihenfolge: Pakete, ai-mysql, ai-core, ai-lib, dann der Rest.

Lade altes und neues Upstream herunterCopy Anchor Link

Pro Skript zwei neue leere Ordner außerhalb des Servers (zum Beispiel update/<name>/old und update/<name>/new):

gh release download <tag> --repo <owner>/<name> --archive zip --dir update/<name>/new     # Quellcode des Tags
gh release download <tag> --repo <owner>/<name> --pattern '*.zip' --dir update/<name>/new # ein Release-Asset, falls vorhanden
unzip -q update/<name>/new/*.zip -d update/<name>/new/x

• Nimm lieber ein Release-Asset, wenn das Release eins hat; sonst den Quellcode des Tags (er enthält das committete dist/ und fxmanifest.lua). Der oberste Ordner der Quellcode-Zip ist <owner>-<name>-<sha>/.
• Altes Upstream ist der Tag der Version, die der Server nutzt (das Tag-Schema zeigt gh release list --repo <owner>/<name>). Er lässt sich immer herunterladen, also hat der Drei-Wege-Vergleich immer seine Basis.
• Nichts in diesen Ordnern wird gestartet, installiert oder gebaut.

SichernCopy Anchor Link

• Kopiere den ganzen Skript-Ordner ohne node_modules nach update/<name>/ours (unter Windows robocopy "<src>" "<dst>" /E /XD node_modules; robocopy-Exit-Codes unter 8 bedeuten Erfolg). Das ist "unseres" für das Zusammenführen und der Weg zurück.
• Von git ignorierte Dateien gibt es nur in dieser Kopie: data/secrets.json, data/*.json.bak. In einem git-Clone listet git ls-files --others --ignored --exclude-standard sie auf.
• Nicht committete Änderungen in einem Clone (git status --porcelain) sind auch Änderungen des Servers. Sag es dem Server-Besitzer; committe sie nur, wenn er darum bittet.

Datei für Datei zusammenführenCopy Anchor Link

Wende das Drei-Wege-Modell auf alt, unseres und neu an und schreibe das Ergebnis in den Skript-Ordner:

Panel-Inhalt (data/*.json) ist der Live-Inhalt des Servers, im Panel bearbeitet; das Release bringt nur Standards mit.

• Gleiches Schema (das neue schema.ts oder der Loader liest dieselben Felder): Behalte unseres, wie es ist. Eine Datei, die die neue Version neu mitbringt: Nimm die ausgelieferte.
• Geändertes Schema: Such nach der skripteigenen Migration beim Start (Release Notes, eine beim Start aufgerufene Migration). Gibt es eine, lass unseres liegen; sie wandelt beim Start um. Gibt es keine, wandle von Hand nach dem neuen Loader und Schema um: dieselben Feldnamen, Typen und dasselbe ID-Format wie die ausgelieferte Datei, jeder Wert bleibt, neue Felder mit dem ausgelieferten Standard, entfernte Felder gestrichen und gemeldet. Prüfe, dass jede Datei parst.

Datenbank. Jedes Skript legt seine Tabellen beim Start aus sql/main.sql an: Es erstellt fehlende Tabellen und fügt fehlende Spalten hinzu, und es löscht, benennt oder ändert nie eine Spalte und fügt nie einen Key hinzu. Vergleiche alte und neue sql/main.sql:

• Neue Tabellen und Spalten: Der Neustart legt sie an.
• Ein geänderter Spaltentyp, ein neuer Index oder Key, eine umbenannte oder gelöschte Spalte: Das Release muss seine eigene Migration mitbringen (Release Notes, Server-Code), die beim Start läuft; prüfe das Log. Tut es das nicht, schreib das SQL, zeig es dem Server-Besitzer, sichere die betroffenen Tabellen und führe es nur mit seinem Okay aus.

Cfg-Dateien außerhalb des Ordners.

• server.cfg: Ein neues Skript bekommt seine ensure-Zeile in Abhängigkeitsreihenfolge; ein entferntes verliert sie (vorher fragen).
• env.cfg und env.example.cfg: Ein Skript, das neu die Datenbank nutzt, braucht add_convar_permission <resource> read mysql_connection_string.
• permission.cfg: die ACE-Zeilen, die die Release Notes verlangen.
• security.cfg: nie gelockert.

Bauen, neu starten, prüfenCopy Anchor Link

1. bun install im Server-Hauptordner, wenn sich eine package.json geändert hat.

2. In jedem aktualisierten Skript: bun run typecheck, bun run lint, bun run build (oder bun tools/run.ts build ai-x ai-y im Server-Hauptordner). Immer bauen: dist/ muss aus dem zusammengeführten Quellcode kommen. Behebe Fehler in den übertragenen Änderungen des Servers; ein Fehler in unverändertem Upstream-Code wird gemeldet, nicht geflickt.

3. Vergleiche das Ergebnis mit dem neuen Upstream: diff -r --strip-trailing-cr -x node_modules -x dist -x data update/<name>/new/x/<top> "<script folder>". Jeder verbleibende Unterschied muss eine Änderung des Servers sein.

4. Refreshen und neu starten:

   Copy Text

   bun tools/rcon.ts --log ../default/logs/fxserver.log --wait 3 "refresh"
   bun tools/restart.ts --from ai-inventory   # ein Skript
   bun tools/restart.ts                       # nach einem Update von ai-core, ai-lib, ai-mysql oder den Paketen

   bun tools/restart.ts startet ai-core neu, führt ensure für jedes ai-* danach aus und prüft, dass jedes gestartet ist. Drittanbieter-Skripte, die von ai-mysql abhängen, stoppen mit ihm: Starte sie per Name wieder mit ensure. Eine neue provide-Zeile braucht einen kompletten Serverstart: bun tools/rcon.ts "quit \"<reason>\"".

5. Lies das Konsolen-Log auf SCRIPT ERROR, Failed to load script, [client error], Lade- oder Validierungsfehler des Panels und Datenbankfehler, nicht nur auf Started resource. Die Warnung is outdated muss nach der nächsten Prüfung des Skripts weg sein.

Ordne die Lieferung dem Installierten zuCopy Anchor Link

• Jeder oberste Ordner mit einer fxmanifest.lua (oder __resource.lua) ist eine Ressource; ein [category]-Ordner enthält mehrere. Entpacke Zips in einen neuen, leeren Ordner und starte von dort nichts.
• Finde die installierte Kopie per Ordnername in resources/ (zum Beispiel find resources -maxdepth 3 -type d -name <name>). Behalte den installierten Ort, nicht die Kategorie der Lieferung. Kein Treffer oder mehrere: Frag den Server-Besitzer. Ein noch nicht installiertes Skript wird nur installiert, wenn der Server-Besitzer es sagt.
• Ein ai-*-Ordner in der Lieferung gehört nicht zu diesem Ablauf: ai-*-Skripte werden von GitHub aktualisiert (oben). Frag den Server-Besitzer, was der Ordner ist.
• Lies beide Manifeste: version, files, Skripte, dependencies, provide, escrow_ignore, ai_replaces. Eine Version, die sinkt, oder eine Lieferung, der Dateien der installierten Kopie fehlen, kann ein älterer Build sein: Vergleiche und melde, statt zu installieren.
• Neue Abhängigkeiten: oxmysql beantwortet ai-mysql (installiere nie oxmysql daneben); ox_lib und andere Bibliotheken installiert der Server-Besitzer; eine Abhängigkeit von etwas, das ai-core ersetzt (es_extended, qb-core, qbx_core, pma-voice, ox_inventory...), ist schon erfüllt.
• Zeig die zugeordnete Liste (Name, Pfad, aktuelle -> neue Version) und warte auf das Okay.

SichernCopy Anchor Link

• Kopiere den ganzen installierten Ordner in einen Backup-Ordner außerhalb des Servers (robocopy "<src>" "<dst>" /E). Für einen Ordner, den kein git-Repository verfolgt, ist dieses Backup die einzige Kopie der Server-Version.
• Verfolgt git den Ordner: git status --porcelain -- <path> zeigt nicht committete Änderungen (sie zählen als unseres; sag es dem Server-Besitzer), und git ls-files --others --ignored --exclude-standard -- <path> zeigt von git ignorierte Laufzeitdateien (gespeichertes JSON, Caches), die im Backup sind.

Finde die Änderungen des ServersCopy Anchor Link

Hol dir das alte Upstream in dieser Reihenfolge:

1. Der Server-Besitzer hat die alte Zip oder den alten Ordner des Anbieters noch.
2. Ein Open-Source-Skript auf GitHub: das Release oder der Tag der installierten Version.
3. Die git-Historie, wenn der Ordner verfolgt wird: der Commit, der die installierte version gesetzt hat (git log -S"version '<old>'" -- <path>/fxmanifest.lua). Hat dieser Commit auch frühere Anpassungen wieder eingespielt, zählen seine Config-Dateien als unseres, und der reine Auslieferungsstand liegt einen Commit davor.
4. Nichts davon: Vergleiche unseres direkt mit der neuen Version und sag das im Bericht.

Lies dann jeden Unterschied alt -> unseres (die Bearbeitungen des Servers: Configs, locales/* oder languages/*, editierbare Dateien, data/*.json, fxmanifest.lua, SQL, Bilder, Sounds, Stream-Dateien, Code-Patches) und alt -> neu (die Änderungen des Anbieters: hinzugefügte und entfernte Dateien, umbenannte Schlüssel, verschobene Abschnitte, geänderte editierbare Funktionen). In einem Escrow-Skript (.fxap vorhanden) lassen sich nur die Dateien in escrow_ignore lesen und bearbeiten; eine Bearbeitung in einer Datei, die die neue Version escrowt, kann nicht übertragen werden und wird gemeldet.

Installiere die neue VersionCopy Anchor Link

Lösche den installierten Ordner komplett und kopiere dann den neuen Ordner an denselben Pfad, versteckte Dateien (.fxap) eingeschlossen. Alte Reste sind Fehler; die alte Version bleibt im Backup. Hol gesicherte Laufzeitdateien nur zurück, wenn die neue Version sie im selben Format nutzt; sonst wandle sie um oder lass sie weg und melde es.

Spiel die Änderungen des Servers wieder einCopy Anchor Link

Finde für jede Bearbeitung, wo diese Einstellung in der neuen Version liegt, und schreib den Wert dort im neuen Format hin:

• Gleicher Schlüssel, gleiche Datei: Setze den Wert in der neuen Datei; behalte ihre Kommentare und ihr Layout.
• Umbenannter oder verschobener Schlüssel: Finde den neuen Schlüssel, indem du den Code liest, der ihn nutzt (such nach dem alten Namen, seinem Kommentar, seinem Standard, seinem Text-Schlüssel), und wandle den Wert in die neue Form um.
• Config in eine Datendatei verschoben (JSON, das das skripteigene Panel bearbeitet): Lies den neuen Loader und die ausgelieferte Datei, schreib die alten Werte in genau diesem Schema (Feldnamen, Typen, ID-Format, Einrückung) und prüfe, dass es parst. Verlass dich nicht auf einen Konverter, den das Skript vielleicht ausführt.
• Die bestehenden Datendateien des Servers: übertragen, Feld für Feld umwandeln, wenn sich das Schema geändert hat, nie durch das Beispiel des Anbieters ersetzen.
• Entfernte Option: Kein Code liest sie mehr (eine Suche bestätigt das): streichen und mit dem alten Wert melden.
• Editierbare Dateien (client/editable.lua, server/editable.lua...): Fang mit der neuen Datei an und spiel jeden geänderten Funktionsrumpf wieder ein, angepasst an eine geänderte Signatur oder einen geänderten Rückgabewert; neue Funktionen behalten ihren Standard.
• Sprachen: Behalte die Formulierung des Servers für jeden Schlüssel, den es noch gibt; ergänze neue Schlüssel in jeder Sprachdatei, die der Server nutzt, übersetzt im Ton der bestehenden Texte; streiche entfernte Schlüssel; folge geänderten Platzhaltern.
• fxmanifest: das neue, plus nur die eigenen Ergänzungen des Servers, die noch sinnvoll sind. version nie ändern.
• SQL (*.sql, Installationsordner): Vergleiche alt und neu; neue Tabellen, Spalten und Indizes kommen als SQL in den Bericht, das der Server-Besitzer ausführt. Nichts läuft ohne sein Okay.
• Zugangsdaten (Bot-Tokens, API-Schlüssel, Webhook-URLs in Configs): nie ausgeben. Aus dem Backup übertragen; geht das nicht, den neuen Standard lassen und Datei und Schlüssel für den Server-Besitzer auflisten.
• Assets (stream/, Bilder, Sounds): die des Anbieters, plus Dateien, die der Server hinzugefügt hat und die noch genutzt werden.
• Koordinaten, Items, Preise, Texte und Verhalten werden exakt übertragen; außer den eigenen Bearbeitungen des Servers ändert sich nichts.

Prüfe die Kompatibilität mit ai-coreCopy Anchor Link

Das Skript kann eines sein, mit dem ai-core spricht. Finde jede Stelle, die es nennt:

grep -rln "<name>" "resources/[ai]/ai-core/resource" "resources/[ai]/ai-core/bridge" docs/compat

• Prüfe für jeden Export, jedes Event und jeden Callback, den ein Adapter nutzt, die neue Version: noch da, gleiche Argumente, gleiche Rückgabeform, gleiches Timing. In Escrow-Code prüfst du die lesbaren Dateien und die Doku des Anbieters und listest auf, was sich nicht prüfen lässt.
• Eine Abweichung wird nur in der Adapter-Datei behoben (eine dünne Übersetzung), ihre getestete Version wird angehoben; dann typecheck, lint und build für ai-core und ein Neustart (bun tools/restart.ts).
• Eine neue ai_replaces- oder provide-Zeile kann dazu führen, dass ai-core Verbindungen ablehnt, solange ein ai-*-Ersatz noch läuft (siehe Ein ai-*-Skript ersetzen): Nenne den Ordner, den der Server-Besitzer entfernen muss.
• Aktualisiere docs/compat/<script>.md (getestete Version, Status, genaue Config oder Patch, bekannte Grenzen); ein unterstütztes Skript ohne Notiz bekommt eine.

Prüfen und neu startenCopy Anchor Link

• Vergleiche das installierte Ergebnis mit der neuen Version: Jeder Unterschied ist eine Änderung des Servers, und keine alte Datei bleibt, die die neue Version nicht mitbringt (zurückgeholte Laufzeitdateien ausgenommen).
• Bearbeitetes Lua parst, JSON parst, jeder gesetzte Config-Schlüssel existiert im neuen Code.
• Wenn kein SQL auf den Server-Besitzer wartet: bun tools/rcon.ts --log ../default/logs/fxserver.log --wait 3 "refresh", dann dasselbe mit "ensure <name>", und lies das Log auf SCRIPT ERROR, Failed to load script und die eigenen Fehler des Skripts. Skripte, die davon abhängen und gestoppt wurden, werden wieder gestartet.