Aktualizacja skryptu

Znajdź, co jest nieaktualneCopy Anchor Link

Ostrzeżenie w konsoli obejmuje tylko uruchomione i nieignorowane skrypty, więc sprawdź każdy folder:

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

• Porównuj wersje jak ai-core: usuń początkowe v, porównaj liczby oddzielone kropkami, ignoruj przyrostki pre-release. Brak wydania oznacza, że nie ma czego aktualizować.
• Bez gh: curl -s -H "Accept: application/vnd.github+json" https://api.github.com/repos/<owner>/<name>/releases/latest (60 zapytań na godzinę na IP, wspólnych z własnym sprawdzaniem ai-core).
• Skrypt w updates.ignore aktualizuje się tylko wtedy, gdy właściciel go wymieni.
• Folder z wersją wyższą niż najnowsze wydanie albo klon z commitami po najnowszym tagu nie jest nieaktualny: pomiń go, nigdy nie cofaj folderu do starszej wersji.
• packages/ nie ma linii repository: porównaj wersję każdego package.json z npm. Najpierw zaktualizuj pakiety, gdy nowe wydanie skryptu wymaga wersji, której lokalne kopie nie mają.

Przeczytaj notatki wydania i uzyskaj zgodęCopy Anchor Link

Przeczytaj notatki każdej wersji między obecną a najnowszą (gh release view <tag> --repo <repo> --json body,assets,url): niezgodne zmiany, wymagane wersje pakietów, migracje, nowe linie cfg (ensure, add_convar_permission, ACE), nowe nazwy provide, kroki ręczne.

Pokaż właścicielowi listę i poczekaj na zgodę. Aktualizuj w kolejności zależności: pakiety, ai-mysql, ai-core, ai-lib, potem reszta.

Pobierz stary i nowy upstreamCopy Anchor Link

Dla każdego skryptu dwa nowe, puste foldery poza serwerem (na przykład update/<name>/old i update/<name>/new):

gh release download <tag> --repo <owner>/<name> --archive zip --dir update/<name>/new     # źródła tagu
gh release download <tag> --repo <owner>/<name> --pattern '*.zip' --dir update/<name>/new # asset wydania, jeśli jest
unzip -q update/<name>/new/*.zip -d update/<name>/new/x

• Wybierz asset wydania, gdy wydanie go ma; inaczej źródła tagu (zawierają zacommitowane dist/ i fxmanifest.lua). Górny folder zipa ze źródłami to <owner>-<name>-<sha>/.
• Stary upstream to tag wersji, której używa serwer (styl tagów pokazuje gh release list --repo <owner>/<name>). Zawsze da się go pobrać, więc porównanie trójstronne zawsze ma swoją bazę.
• Nic w tych folderach nie jest uruchamiane, instalowane ani budowane.

Zrób kopię zapasowąCopy Anchor Link

• Skopiuj cały folder skryptu bez node_modules do update/<name>/ours (w Windows robocopy "<src>" "<dst>" /E /XD node_modules; kody wyjścia robocopy poniżej 8 oznaczają sukces). To jest "nasz" do scalania i droga powrotu.
• Pliki ignorowane przez git istnieją tylko w tej kopii: data/secrets.json, data/*.json.bak. W klonie git listuje je git ls-files --others --ignored --exclude-standard.
• Niezacommitowane zmiany w klonie (git status --porcelain) to też zmiany serwera. Powiedz o nich właścicielowi; commituj je tylko na jego prośbę.

Scalaj plik po plikuCopy Anchor Link

Zastosuj model trójstronny do starego, naszego i nowego, a wynik zapisz w folderze skryptu:

Zawartość panelu (data/*.json) to żywa zawartość serwera, edytowana w panelu; wydanie przynosi tylko wartości domyślne.

• Ten sam schemat (nowy schema.ts albo loader czyta te same pola): zostaw nasz bez zmian. Plik, który dodaje nowa wersja: weź ten z wydania.
• Zmieniony schemat: poszukaj własnej migracji skryptu przy starcie (notatki wydania, migracja wywoływana przy starcie). Jeśli jest, zostaw nasz na miejscu; przekonwertuje go przy starcie. Jeśli nie ma, przekonwertuj ręcznie według nowego loadera i schematu: te same nazwy pól, typy i format id co plik z wydania, każda wartość zachowana, nowe pola z wartością domyślną z wydania, usunięte pola wyrzucone i zgłoszone. Sprawdź, że każdy plik się parsuje.

Baza danych. Każdy skrypt tworzy swoje tabele z sql/main.sql przy starcie: tworzy brakujące tabele i dodaje brakujące kolumny, a nigdy nie usuwa, nie zmienia nazwy ani typu kolumny i nie dodaje kluczy. Porównaj stary i nowy sql/main.sql:

• Nowe tabele i kolumny: restart je wprowadza.
• Zmieniony typ kolumny, nowy indeks albo klucz, przemianowana lub usunięta kolumna: wydanie musi przynieść własną migrację (notatki wydania, kod serwera), która uruchamia się przy starcie; sprawdź log. Jeśli nie przynosi, napisz SQL, pokaż go właścicielowi, zrób kopię dotkniętych tabel i uruchom go tylko za jego zgodą.

Pliki cfg poza folderem.

• server.cfg: nowy skrypt dostaje swoją linię ensure w kolejności zależności; usunięty ją traci (najpierw zapytaj).
• env.cfg i env.example.cfg: skrypt, który zaczyna używać bazy danych, potrzebuje add_convar_permission <resource> read mysql_connection_string.
• permission.cfg: linie ACE, których wymagają notatki wydania.
• security.cfg: nigdy nie luzowany.

Zbuduj, zrestartuj, sprawdźCopy Anchor Link

1. bun install w głównym folderze serwera, gdy zmienił się jakiś package.json.

2. W każdym zaktualizowanym skrypcie: bun run typecheck, bun run lint, bun run build (albo bun tools/run.ts build ai-x ai-y z głównego folderu serwera). Zawsze buduj: dist/ musi pochodzić ze scalonych źródeł. Popraw błędy w przeniesionych zmianach serwera; błąd w nietkniętym kodzie upstreamu trafia do raportu, nie jest łatany.

3. Porównaj wynik z nowym upstreamem: diff -r --strip-trailing-cr -x node_modules -x dist -x data update/<name>/new/x/<top> "<script folder>". Każda pozostała różnica musi być jedną ze zmian serwera.

4. Zrób refresh i restart:

   Copy Text

   bun tools/rcon.ts --log ../default/logs/fxserver.log --wait 3 "refresh"
   bun tools/restart.ts --from ai-inventory   # jeden skrypt
   bun tools/restart.ts                       # po aktualizacji ai-core, ai-lib, ai-mysql lub pakietów

   bun tools/restart.ts restartuje ai-core, robi ensure każdego ai-* po nim i sprawdza, że każdy wystartował. Skrypty innych firm zależne od ai-mysql zatrzymują się razem z nim: zrób im ponownie ensure po nazwie. Nowa linia provide wymaga pełnego startu serwera: bun tools/rcon.ts "quit \"<reason>\"".

5. Przeczytaj log konsoli pod kątem SCRIPT ERROR, Failed to load script, [client error], błędów ładowania lub walidacji panelu i błędów bazy danych, nie tylko Started resource. Ostrzeżenie is outdated musi zniknąć po następnym sprawdzeniu skryptu.

Dopasuj dostawę do zainstalowanych zasobówCopy Anchor Link

• Każdy folder najwyższego poziomu z fxmanifest.lua (albo __resource.lua) to zasób; folder [category] zawiera kilka. Rozpakuj zipy do nowego, pustego folderu i niczego z niego nie uruchamiaj.
• Znajdź zainstalowaną kopię po nazwie folderu w resources/ (na przykład find resources -maxdepth 3 -type d -name <name>). Zostaw zainstalowane miejsce, nie kategorię z dostawy. Brak dopasowania albo kilka: zapytaj właściciela. Skrypt, który nie jest jeszcze zainstalowany, instaluje się tylko na polecenie właściciela.
• Folder ai-* w dostawie nie idzie tą ścieżką: skrypty ai-* aktualizują się z GitHuba (wyżej). Zapytaj właściciela, czym jest ten folder.
• Przeczytaj oba manifesty: version, files, skrypty, dependencies, provide, escrow_ignore, ai_replaces. Wersja, która spada, albo dostawa bez plików, które ma zainstalowana kopia, może być starszym buildem: porównaj i zgłoś zamiast instalować.
• Nowe zależności: oxmysql obsługuje ai-mysql (nigdy nie instaluj oxmysql obok); ox_lib i inne biblioteki instaluje właściciel; zależność od czegoś, co ai-core zastępuje (es_extended, qb-core, qbx_core, pma-voice, ox_inventory...), jest już spełniona.
• Pokaż dopasowaną listę (nazwa, ścieżka, obecna -> nowa wersja) i poczekaj na zgodę.

Zrób kopię zapasowąCopy Anchor Link

• Skopiuj cały zainstalowany folder do folderu kopii poza serwerem (robocopy "<src>" "<dst>" /E). Dla folderu, którego nie śledzi żadne repozytorium git, ta kopia jest jedyną kopią wersji serwera.
• Jeśli git śledzi folder: git status --porcelain -- <path> pokazuje niezacommitowane zmiany (liczą się jako nasz; powiedz właścicielowi), a git ls-files --others --ignored --exclude-standard -- <path> pokazuje pliki robocze ignorowane przez git (zapisany JSON, cache), które są w kopii.

Znajdź zmiany serweraCopy Anchor Link

Zdobądź stary upstream w tej kolejności:

1. Właściciel nadal ma stary zip albo folder od dostawcy.
2. Skrypt open source na GitHubie: wydanie albo tag zainstalowanej wersji.
3. Historia git, gdy folder jest śledzony: commit, który ustawił zainstalowaną version (git log -S"version '<old>'" -- <path>/fxmanifest.lua). Jeśli ten commit ponownie nałożył też wcześniejsze dostosowania, jego pliki config liczą się jako nasz, a czysta wersja z wydania jest commit wcześniej.
4. Nic z tego: porównaj nasz bezpośrednio z nową wersją i napisz o tym w raporcie.

Potem przeczytaj każdą różnicę stary -> nasz (edycje serwera: configi, locales/* lub languages/*, pliki editable, data/*.json, fxmanifest.lua, SQL, obrazy, dźwięki, pliki stream, łatki kodu) i stary -> nowy (zmiany dostawcy: dodane i usunięte pliki, przemianowane klucze, przeniesione sekcje, zmienione funkcje editable). W skrypcie z escrow (jest .fxap) czytać i edytować można tylko pliki z escrow_ignore; edycji w pliku, który nowa wersja objęła escrow, nie da się przenieść i trafia ona do raportu.

Zainstaluj nową wersjęCopy Anchor Link

Usuń zainstalowany folder w całości, a potem skopiuj nowy folder w to samo miejsce, łącznie z ukrytymi plikami (.fxap). Stare resztki to błędy; stara wersja zostaje w kopii. Przywróć skopiowane pliki robocze tylko wtedy, gdy nowa wersja nadal używa ich w tym samym formacie; inaczej przekonwertuj je albo porzuć i zgłoś.

Nałóż ponownie zmiany serweraCopy Anchor Link

Dla każdej edycji znajdź, gdzie to ustawienie jest w nowej wersji, i wpisz tam wartość w nowym formacie:

• Ten sam klucz, ten sam plik: ustaw wartość w nowym pliku; zachowaj jego komentarze i układ.
• Przemianowany lub przeniesiony klucz: znajdź nowy klucz, czytając kod, który go używa (szukaj starej nazwy, jej komentarza, wartości domyślnej, klucza tekstu), i przekonwertuj wartość na nowy kształt.
• Config przeniesiony do pliku danych (JSON edytowany przez własny panel skryptu): przeczytaj nowy loader i plik z wydania, wpisz stare wartości dokładnie w tym schemacie (nazwy pól, typy, format id, wcięcia) i sprawdź, że się parsuje. Nie licz na konwerter, który skrypt może uruchomić.
• Istniejące pliki danych serwera: przenieś je, przekonwertuj pole po polu, jeśli schemat się zmienił, nigdy nie zastępuj ich przykładem dostawcy.
• Usunięta opcja: żaden kod już jej nie czyta (wyszukiwanie to potwierdza): usuń ją i zgłoś ze starą wartością.
• Pliki editable (client/editable.lua, server/editable.lua...): zacznij od nowego pliku i ponownie nałóż każde zmienione ciało funkcji, dopasowane do zmienionej sygnatury albo wartości zwracanej; nowe funkcje zostają domyślne.
• Języki: zachowaj sformułowania serwera dla każdego klucza, który nadal istnieje; dodaj nowe klucze do każdego pliku językowego, którego używa serwer, przetłumaczone w tonie istniejących tekstów; usuń usunięte klucze; idź za zmienionymi placeholderami.
• fxmanifest: nowy, plus tylko własne dodatki serwera, które nadal mają sens. Nigdy nie zmieniaj version.
• SQL (*.sql, foldery instalacyjne): porównaj stary i nowy; nowe tabele, kolumny i indeksy trafiają do raportu jako SQL do uruchomienia przez właściciela. Nic nie jest uruchamiane bez jego zgody.
• Dane dostępowe (tokeny botów, klucze API, adresy webhooków w configach): nigdy ich nie wypisuj. Przenieś je z kopii; jeśli się nie da, zostaw nową wartość domyślną i wypisz plik i klucz dla właściciela.
• Assety (stream/, obrazy, dźwięki): te od dostawcy plus pliki dodane przez serwer, które są nadal używane.
• Koordynaty, itemy, ceny, teksty i zachowanie są przenoszone dokładnie; poza własnymi edycjami serwera nic się nie zmienia.

Sprawdź zgodność z ai-coreCopy Anchor Link

Skrypt może być jednym z tych, z którymi rozmawia ai-core. Znajdź każde miejsce, które go wymienia:

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

• Dla każdego exportu, eventu i callbacku, którego używa adapter, sprawdź nową wersję: nadal jest, te same argumenty, ten sam kształt wyniku, ten sam moment. W kodzie z escrow sprawdź czytelne pliki i dokumentację dostawcy, a to, czego nie da się sprawdzić, wypisz.
• Niezgodność poprawia się tylko w pliku adaptera (cienkie tłumaczenie), podnosząc jego testowaną wersję; potem typecheck, lint i build ai-core oraz restart (bun tools/restart.ts).
• Nowa linia ai_replaces albo provide może sprawić, że ai-core odrzuca połączenia, dopóki działa zastępnik ai-* (zobacz Zastępowanie skryptu ai-*): podaj folder, który właściciel musi usunąć.
• Zaktualizuj docs/compat/<script>.md (testowana wersja, status, dokładny config albo łatka, znane ograniczenia); wspierany skrypt bez notatki dostaje ją.

Zweryfikuj i zrestartujCopy Anchor Link

• Porównaj zainstalowany wynik z nową wersją: każda różnica jest zmianą serwera i nie zostaje żaden stary plik, którego nowa wersja nie zawiera (poza przywróconymi plikami roboczymi).
• Edytowany Lua się parsuje, JSON się parsuje, każdy ustawiony klucz config istnieje w nowym kodzie.
• Jeśli żaden SQL nie czeka na właściciela: bun tools/rcon.ts --log ../default/logs/fxserver.log --wait 3 "refresh", potem to samo z "ensure <name>", i przeczytaj log pod kątem SCRIPT ERROR, Failed to load script i własnych błędów skryptu. Skrypty zależne od niego, które się zatrzymały, są uruchamiane ponownie.