Actualizar un script

Encuentra lo que está desactualizadoCopy Anchor Link

El aviso de la consola solo cubre scripts iniciados y no ignorados, así que revisa cada carpeta:

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

• Compara versiones como ai-core: quita una v inicial, compara los números separados por puntos, ignora los sufijos de pre-release. Sin release no hay nada que actualizar.
• Sin gh: curl -s -H "Accept: application/vnd.github+json" https://api.github.com/repos/<owner>/<name>/releases/latest (60 peticiones por hora por IP, compartidas con la comprobación de ai-core).
• Un script en updates.ignore solo se actualiza cuando el dueño lo nombra.
• Una carpeta con versión por encima de la última release, o un clon con commits después del último tag, no está desactualizada: sáltala, nunca muevas una carpeta hacia atrás.
• packages/ no tiene línea repository: compara la versión de cada package.json con npm. Actualiza primero los paquetes cuando una nueva release de script necesite una versión que las copias locales no tienen.

Lee las notas de versión y consigue el visto buenoCopy Anchor Link

Lee las notas de cada versión entre la actual y la última (gh release view <tag> --repo <repo> --json body,assets,url): cambios incompatibles, versiones de paquetes requeridas, migraciones, líneas de cfg nuevas (ensure, add_convar_permission, ACE), nombres provide nuevos, pasos manuales.

Muestra la lista al dueño y espera su visto bueno. Actualiza en orden de dependencias: paquetes, ai-mysql, ai-core, ai-lib y luego el resto.

Descarga el upstream viejo y el nuevoCopy Anchor Link

Para cada script, dos carpetas nuevas y vacías fuera del servidor (por ejemplo update/<name>/old y update/<name>/new):

gh release download <tag> --repo <owner>/<name> --archive zip --dir update/<name>/new     # código fuente del tag
gh release download <tag> --repo <owner>/<name> --pattern '*.zip' --dir update/<name>/new # un asset de la release, si lo hay
unzip -q update/<name>/new/*.zip -d update/<name>/new/x

• Prefiere un asset de la release cuando la release tenga uno; si no, el código fuente del tag (incluye el dist/ y el fxmanifest.lua con commit). La carpeta superior del zip de código es <owner>-<name>-<sha>/.
• El upstream viejo es el tag de la versión que usa el servidor (el estilo de los tags se ve con gh release list --repo <owner>/<name>). Siempre se puede descargar, así que la comparación de tres vías siempre tiene su base.
• Nada en estas carpetas se ejecuta, instala ni compila.

Haz la copia de seguridadCopy Anchor Link

• Copia toda la carpeta del script excepto node_modules a update/<name>/ours (en Windows robocopy "<src>" "<dst>" /E /XD node_modules; los códigos de salida de robocopy menores que 8 indican éxito). Esto es "el nuestro" para la fusión y el camino de vuelta.
• Los archivos que git ignora solo existen en esta copia: data/secrets.json, data/*.json.bak. En un clon de git, git ls-files --others --ignored --exclude-standard los lista.
• Los cambios sin commit de un clon (git status --porcelain) también son cambios del servidor. Díselo al dueño; haz commit solo si lo pide.

Fusiona archivo por archivoCopy Anchor Link

Aplica el modelo de tres vías a viejo, nuestro y nuevo, y escribe el resultado en la carpeta del script:

El contenido del panel (data/*.json) es el contenido vivo del servidor, editado en el panel; la release solo trae valores por defecto.

• Mismo esquema (el nuevo schema.ts o loader lee los mismos campos): conserva el nuestro tal cual. Un archivo que añade la nueva versión: toma el que viene.
• Esquema cambiado: busca la migración propia del script al arrancar (notas de versión, una migración llamada al arrancar). Si existe, deja el nuestro en su sitio; se convierte al arrancar. Si no, conviértelo a mano siguiendo el nuevo loader y el esquema: mismos nombres de campo, tipos y formato de id que el archivo que viene, cada valor conservado, campos nuevos con el valor por defecto que viene, campos eliminados quitados e informados. Comprueba que cada archivo se pueda parsear.

Base de datos. Cada script crea sus tablas desde sql/main.sql al arrancar: crea las tablas que faltan y añade las columnas que faltan, y nunca borra, renombra ni cambia una columna ni añade una clave. Compara el sql/main.sql viejo y el nuevo:

• Tablas y columnas nuevas: las aplica el reinicio.
• Un tipo de columna cambiado, un índice o clave nuevos, una columna renombrada o borrada: la release debe traer su propia migración (notas de versión, código de servidor), que se ejecuta al arrancar; revisa el log. Si no la trae, escribe el SQL, enséñaselo al dueño, haz copia de las tablas afectadas y ejecútalo solo con su visto bueno.

Archivos cfg fuera de la carpeta.

• server.cfg: un script nuevo recibe su línea ensure en orden de dependencias; uno eliminado la pierde (pregunta primero).
• env.cfg y env.example.cfg: un script que empieza a usar la base de datos necesita add_convar_permission <resource> read mysql_connection_string.
• permission.cfg: las líneas ACE que piden las notas de versión.
• security.cfg: nunca se relaja.

Compila, reinicia, revisaCopy Anchor Link

1. bun install en la raíz del servidor cuando cambie algún package.json.

2. En cada script actualizado: bun run typecheck, bun run lint, bun run build (o bun tools/run.ts build ai-x ai-y desde la raíz del servidor). Compila siempre: dist/ debe salir del código fusionado. Corrige los errores en los cambios del servidor que pasaste; un error en código de upstream sin tocar se informa, no se parchea.

3. Compara el resultado con el upstream nuevo: diff -r --strip-trailing-cr -x node_modules -x dist -x data update/<name>/new/x/<top> "<script folder>". Cada diferencia que quede debe ser uno de los cambios del servidor.

4. Haz refresh y reinicia:

   Copy Text

   bun tools/rcon.ts --log ../default/logs/fxserver.log --wait 3 "refresh"
   bun tools/restart.ts --from ai-inventory   # un solo script
   bun tools/restart.ts                       # tras actualizar ai-core, ai-lib, ai-mysql o los paquetes

   bun tools/restart.ts reinicia ai-core, hace ensure de cada ai-* que va después y comprueba que cada uno arrancó. Los scripts de terceros que dependen de ai-mysql se detienen con él: vuelve a hacer ensure de ellos por su nombre. Una línea provide nueva necesita un arranque completo del servidor: bun tools/rcon.ts "quit \"<reason>\"".

5. Lee el log de la consola buscando SCRIPT ERROR, Failed to load script, [client error], errores de carga o validación del panel y errores de base de datos, no solo Started resource. El aviso is outdated debe desaparecer tras la siguiente comprobación del script.

Empareja la entrega con lo instaladoCopy Anchor Link

• Cada carpeta de primer nivel con un fxmanifest.lua (o __resource.lua) es un recurso; una carpeta [category] contiene varios. Descomprime los zips en una carpeta nueva y vacía y no ejecutes nada desde ahí.
• Encuentra la copia instalada por nombre de carpeta dentro de resources/ (por ejemplo find resources -maxdepth 3 -type d -name <name>). Conserva la ubicación instalada, no la categoría de la entrega. Ninguna coincidencia o varias: pregunta al dueño. Un script que aún no está instalado solo se instala si el dueño lo dice.
• Una carpeta ai-* en la entrega no sigue este procedimiento: los scripts ai-* se actualizan desde GitHub (arriba). Pregunta al dueño qué es esa carpeta.
• Lee los dos manifiestos: version, files, scripts, dependencies, provide, escrow_ignore, ai_replaces. Una versión que baja, o una entrega a la que le faltan archivos que tiene la copia instalada, puede ser un build más viejo: compara e informa en vez de instalar.
• Dependencias nuevas: a oxmysql lo responde ai-mysql (nunca instales oxmysql junto a él); ox_lib y otras librerías las instala el dueño; una dependencia de algo que ai-core reemplaza (es_extended, qb-core, qbx_core, pma-voice, ox_inventory...) ya está cubierta.
• Muestra la lista emparejada (nombre, ruta, versión actual -> nueva) y espera el visto bueno.

Haz la copia de seguridadCopy Anchor Link

• Copia toda la carpeta instalada a una carpeta de copia fuera del servidor (robocopy "<src>" "<dst>" /E). Para una carpeta que ningún repositorio git sigue, esta copia es la única de la versión del servidor.
• Si git sigue la carpeta: git status --porcelain -- <path> muestra los cambios sin commit (cuentan como el nuestro; díselo al dueño) y git ls-files --others --ignored --exclude-standard -- <path> muestra los archivos de ejecución que git ignora (JSON guardado, cachés), que están en la copia.

Encuentra los cambios del servidorCopy Anchor Link

Consigue el upstream viejo, en este orden:

1. El dueño aún tiene el zip o la carpeta vieja del vendedor.
2. Un script de código abierto en GitHub: la release o el tag de la versión instalada.
3. El historial de git, cuando la carpeta está seguida: el commit que puso la version instalada (git log -S"version '<old>'" -- <path>/fxmanifest.lua). Si ese commit también volvió a aplicar personalizaciones anteriores, sus archivos de config cuentan como el nuestro y la versión de fábrica pura está un commit antes.
4. Nada de eso: compara el nuestro directamente con la nueva versión y dilo en el informe.

Después lee cada diferencia viejo -> nuestro (las ediciones del servidor: configs, locales/* o languages/*, archivos editables, data/*.json, fxmanifest.lua, SQL, imágenes, sonidos, archivos de stream, parches de código) y viejo -> nuevo (los cambios del vendedor: archivos añadidos y eliminados, claves renombradas, secciones movidas, funciones editables cambiadas). En un script con escrow (hay .fxap) solo se pueden leer y editar los archivos de escrow_ignore; una edición en un archivo que la nueva versión pone bajo escrow no se puede pasar y se informa.

Instala la nueva versiónCopy Anchor Link

Borra por completo la carpeta instalada y luego copia la carpeta nueva en la misma ruta, archivos ocultos (.fxap) incluidos. Los restos viejos son errores; la versión vieja queda en la copia. Restaura los archivos de ejecución copiados solo si la nueva versión los sigue usando con el mismo formato; si no, conviértelos o descártalos e infórmalo.

Vuelve a aplicar los cambios del servidorCopy Anchor Link

Para cada edición, encuentra dónde vive ese ajuste en la nueva versión y escribe ahí el valor, en el nuevo formato:

• Misma clave, mismo archivo: pon el valor en el archivo nuevo; conserva sus comentarios y su disposición.
• Clave renombrada o movida: encuentra la clave nueva leyendo el código que la usa (busca el nombre viejo, su comentario, su valor por defecto, su clave de texto) y convierte el valor a la nueva forma.
• Config movida a un archivo de datos (JSON que edita el panel propio del script): lee el nuevo loader y el archivo que viene, escribe los valores viejos exactamente en ese esquema (nombres de campo, tipos, formato de id, sangría) y comprueba que se pueda parsear. No confíes en un conversor que el script podría ejecutar.
• Los archivos de datos existentes del servidor: pásalos, conviértelos campo por campo si el esquema cambió, nunca los reemplaces por el ejemplo del vendedor.
• Opción eliminada: ningún código la lee ya (una búsqueda lo confirma): quítala e infórmala con el valor viejo.
• Archivos editables (client/editable.lua, server/editable.lua...): parte del archivo nuevo y vuelve a aplicar cada cuerpo de función cambiado, adaptado a una firma o un valor de retorno distintos; las funciones nuevas mantienen su versión por defecto.
• Idiomas: conserva la redacción del servidor en cada clave que sigue existiendo; añade las claves nuevas a cada archivo de idioma que usa el servidor, traducidas con el tono de los textos existentes; quita las claves eliminadas; sigue los placeholders cambiados.
• fxmanifest: el nuevo, más solo los añadidos propios del servidor que sigan teniendo sentido. Nunca cambies version.
• SQL (*.sql, carpetas de instalación): compara viejo y nuevo; las tablas, columnas e índices nuevos van al informe como SQL que ejecuta el dueño. Nada se ejecuta sin su visto bueno.
• Credenciales (tokens de bot, claves de API, URL de webhooks en las configs): nunca las muestres. Pásalas desde la copia; si no es posible, deja el nuevo valor por defecto y lista el archivo y la clave para el dueño.
• Assets (stream/, imágenes, sonidos): los del vendedor, más los archivos que añadió el servidor y que se siguen usando.
• Coordenadas, items, precios, textos y comportamiento se pasan tal cual; no cambia nada fuera de las ediciones propias del servidor.

Comprueba la compatibilidad con ai-coreCopy Anchor Link

El script puede ser uno con los que habla ai-core. Encuentra cada lugar que lo nombra:

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

• Para cada export, event y callback que usa un adapter, revisa la nueva versión: sigue ahí, mismos argumentos, misma forma de retorno, mismo momento. En código con escrow, revisa los archivos legibles y la documentación del vendedor, y lista lo que no se puede verificar.
• Una incompatibilidad se corrige solo en el archivo del adapter (una traducción fina), subiendo su versión probada; después typecheck, lint y build de ai-core y reinicio (bun tools/restart.ts).
• Una línea ai_replaces o provide nueva puede hacer que ai-core rechace conexiones mientras un sustituto ai-* siga en marcha (ver Reemplazar un script ai-*): nombra la carpeta que el dueño debe quitar.
• Actualiza docs/compat/<script>.md (versión probada, estado, config o parche exactos, límites conocidos); un script soportado sin nota recibe una.

Verifica y reiniciaCopy Anchor Link

• Compara el resultado instalado con la nueva versión: cada diferencia es un cambio del servidor y no queda ningún archivo viejo que la nueva versión no traiga (aparte de los archivos de ejecución restaurados).
• El Lua editado se puede parsear, el JSON también, y cada clave de config ajustada existe en el código nuevo.
• Salvo que haya SQL esperando al dueño: bun tools/rcon.ts --log ../default/logs/fxserver.log --wait 3 "refresh", después lo mismo con "ensure <name>", y lee el log buscando SCRIPT ERROR, Failed to load script y los errores propios del script. Los scripts que dependen de él y se detuvieron vuelven a arrancarse.