Cómo evaluar, probar y mantener scripts de FiveM

¿Estás probando un script gratuito?

Los scripts gratuitos son útiles para comprobaciones rápidas. Para servidores de producción, compare los paquetes completos para servidores o los scripts de pago con mantenimiento, teniendo en cuenta el framework y el caso de uso.

Esta guía sencilla sobre el mantenimiento de scripts de FiveM está dirigida a propietarios de servidores, desarrolladores y responsables de control de calidad. Obtendrás una "Ciudad de Pruebas" similar a la de producción en Docker, una lista de verificación de aceptación que puedes ejecutar de principio a fin, un modelo cuantitativo de puntuación de riesgos y una rúbrica de verificación de proveedores que te evitará dolores de cabeza.

Resumen

• Girar hacia arriba Ciudad de pruebas (Docker) to isolate and benchmark any script safely.
• Ejecutar el Lista de verificación de aceptación Antes de que un centavo cambie de manos.
• Utilice el Puntuación de riesgo (0–100) Para decidir enviar/retener/rechazar.
• Vendedores de veterinarios con el Rúbrica del proveedor (no te saltes esto).
• Si va a comprar, prefiera tiendas con buena reputación: vea nuestras recomendaciones: Las mejores tiendas de Tebex.

---

Parte 1: “Test City” (Docker) para un control de calidad de scripts seguro y repetible

Lo que obtienes

• FXServer en contenedores + MariaDB (+ Administrador)
• Clean servidor.cfg con oxmysql y recursos básicos
• Montado en enlace recursos/personalizados donde colocas el script bajo prueba
• Nombres/puertos de red deterministas para cadenas de bases de datos simples

Descargar test-city.zip (Github)

Modo de empleo:

1. Descomprimir → ciudad de prueba de cd
2. Copiar .env.ejemplo a .env y establece tu CLAVE DE LICENCIA (y credenciales de DB si lo desea).
3. Gota oxmysql en datos del servidor/recursos/[independiente]/oxmysql/.
4. Poner el guión a prueba en datos del servidor/recursos/personalizado/ / y añadir asegurar a servidor.cfg.
5. docker compose compilación && docker compose up -d → Conectarse a través de Conexión Directa a host local:30120.

Prerrequisitos: Docker + Docker Compose, una clave de licencia cfx y una oxmysql Copia de recursos (colocar en datos del servidor/recursos/[independiente]/oxmysql).

Diseño de carpetas

test-city/ ├─ docker-compose.yml ├─ fxserver/ │ ├─ Dockerfile │ └─ entrypoint.sh ├─ server-data/ │ ├─ server.cfg │ └─ recursos/ │ ├─ [independiente]/oxmysql/ # coloque oxmysql aquí │ └─ personalizado/ # ponga el script bajo prueba aquí (por ejemplo, myscript/) └─ .env

.env (ejemplo)

LICENSE_KEY=changeme_cfx_license_key MYSQL_DATABASE=fivem MYSQL_USER=fivem MYSQL_PASSWORD=fivempw MYSQL_ROOT_PASSWORD=rootpw FX_ARTIFACT_URL=https://runtime.fivem.net/artifacts/fivem/build_proot_linux/master/LATEST.tar.xz # Sugerencia: reemplace con una URL de artefacto específica en la que confíe para la reproducibilidad.

docker-compose.yml

version: "3.9"

networks:
  testcity:

volumes:
  db_data:

services:
  db:
    image: mariadb:10.11
    restart: unless-stopped
    environment:
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
    command: >
      --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
      --innodb_buffer_pool_size=256M
    volumes:
      - db_data:/var/lib/mysql
    networks: [testcity]

  adminer:
    image: adminer:4
    restart: unless-stopped
    ports:
      - "8080:8080"
    networks: [testcity]
    depends_on: [db]

  fxserver:
    build:
      context: ./fxserver
      args:
        FX_ARTIFACT_URL: ${FX_ARTIFACT_URL}
    restart: unless-stopped
    environment:
      LICENSE_KEY: ${LICENSE_KEY}
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    depends_on: [db]
    networks: [testcity]
    ports:
      - "30120:30120/udp"
      - "30120:30120/tcp"
      - "40120:40120/tcp" # txAdmin (optional)
    volumes:
      - ./server-data:/opt/fivem/server-data

fxserver/Dockerfile

FROM debian:bookworm-slim

ARG FX_ARTIFACT_URL
ENV DEBIAN_FRONTEND=noninteractive

RUN apt-get update && apt-get install -y --no-install-recommends 
    xz-utils curl ca-certificates tini bash && 
    rm -rf /var/lib/apt/lists/*

# Fetch & extract FXServer artifact (URL provided via build-arg)
RUN mkdir -p /opt/fivem && 
    curl -fsSL "$FX_ARTIFACT_URL" -o /opt/fivem/fx.tar.xz && 
    tar -xJf /opt/fivem/fx.tar.xz -C /opt/fivem && 
    rm -f /opt/fivem/fx.tar.xz

# Non-root
RUN useradd -ms /bin/bash fivem
USER fivem

WORKDIR /opt/fivem
COPY --chown=fivem:fivem ../server-data /opt/fivem/server-data
COPY --chown=fivem:fivem entrypoint.sh /entrypoint.sh

ENTRYPOINT ["/usr/bin/tini","--"]
CMD ["/bin/bash","/entrypoint.sh"]

fxserver/entrypoint.sh

#!/usr/bin/env bash set -euo pipefail # Proporcione la cadena de la base de datos para oxmysql mediante server.cfg (ya configurado). # simplemente asegúrese de que la base de datos sea accesible antes del arranque para evitar errores de spam. echo "Esperando base de datos..." until nc -z db 3306; do sleep 1; done echo "Base de datos lista." # Ejecute FXServer con nuestro server.cfg. # La mayoría de los artefactos de Linux incluyen un archivo run.sh en la raíz de artefactos. exec bash /opt/fivem/run.sh +exec /opt/fivem/server-data/server.cfg

Si su artefacto utiliza una ruta de inicio diferente, ajuste la última línea en consecuencia (por ejemplo, /opt/fivem/alpine/opt/cfx-server/run.sh).

datos del servidor/server.cfg (agil, listo para pruebas)

# ---------- Identity ----------
sv_licenseKey "%LICENSE_KEY%"            # injected by env in entrypoint command or replace manually
sv_hostname "Test City — Script QA"
sets tags "qa,testing,fivemx"
sv_maxclients 2
onesync on
sv_scriptHookAllowed 0
sv_enforceGameBuild 3095

# ---------- Networking ----------
endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

# ---------- Database (oxmysql) ----------
set mysql_connection_string "mysql://%MYSQL_USER%:%MYSQL_PASSWORD%@db:3306/%MYSQL_DATABASE%?charset=utf8mb4"

# ---------- Core / Base resources ----------
ensure mapmanager
ensure chat
ensure spawnmanager
ensure sessionmanager
ensure hardcap
ensure baseevents

# ---------- Datastore ----------
ensure oxmysql

# ---------- Under test ----------
# Drop your script folder into resources/custom/<scriptname> and enable here:
# ensure myscript

# ---------- QA helpers ----------
# Verbose logging in dev
setr con_minSeverity info

# Enable txAdmin panel (optional)
setr txAdminPort 40120

Habilite su script: copiarlo en datos del servidor/recursos/personalizado/myscript/ y añadir asegurar mi script al bloque inferior.

Ejecútalo

cd test-city docker compose build docker compose up -d # Administrador en http://localhost:8080 (servidor: db, usuario: fivem, contraseña: fivempw) # Conectar el cliente FiveM → Conexión directa: your-docker-host:30120

---

Parte 2: Lista de verificación de aceptación del guion (no omitir)

Usa esto siempre. Cópialo en tu rastreador y marca los elementos.

A. Pre-vuelo (antes de la instalación)

• Tipo de fuente: Código abierto / parcialmente abierto / solo depósito en garantía.
• Dependencias enumeradas: marco (ESX/QBCore/QBOX), biblioteca de buey, oxmysql, Polizona, etc.
• fxmanifest.lua: lua54 'sí', correcto juego 'gta 5', versión fx no antiguo
• Documentos: Pasos de instalación, ejemplos de configuración, permisos, configuraciones regionales, conflictos conocidos.
• Licencia/Condiciones de servicio: derechos de uso, política de reembolso, actualizaciones, canal de soporte.

B. Instalabilidad

• No hay errores de consola en asegurar: cero rastros de pila o spam de activos faltantes.
• No nativos depreciados correo basura.
• La configuración se carga limpia: Sin errores de sintaxis JSON/Lua.
• Migraciones de bases de datos: Crea tablas una vez; los reinicios no las vuelven a aplicar ni las interrumpen.

C. Funcional

• Centro flows work: Camino feliz probado (por ejemplo, compra, flujo de trabajo, elaboración).
• Casos extremos: entradas incorrectas, permisos faltantes, cantidades fuera de rango.
• Localización: No se permiten cadenas codificadas si se prometen configuraciones regionales.
• Permisos: Comandos de personal/administración restringidos; sin acceso libre del lado del cliente.

D. Rendimiento (cliente y servidor)

• resmón: inactivo ≤ 0,10 ms, activo ≤ 0,50 ms (cliente).
• Estado de tictac del servidor: sin advertencias de enganche prolongado bajo uso normal.
• Consultas de base de datos: Sin bucles estrechos; se utilizan declaraciones preparadas; mínimo N+1.

E. Seguridad

• Validación del lado del servidor: Cada evento del servidor se valida fuente, permisos y tipos de entrada.
• No hay confianza en el cliente: Los cambios de dinero/inventario solo provienen de la lógica del servidor.
• Sin evaluacióncadena de carga/código remoto patrones.
• Anti-abuso: límites de velocidad/limitaciones en puntos finales con spam.
• Integridad del depósito en garantía: No hay puertas traseras en cargadores de configuración sin depósito.

Buen patrón de evento (ejemplo):

RegisterNetEvent('myscript:buy', function(item, amount) local src = source if type(item) ~= 'string' or type(amount) ~= 'number' or amount < 1 then return end if not HasPermission(src, 'shop.buy') then return end local xPlayer = GetPlayer(src) -- adaptador de framework if not xPlayer then return end -- validar precio del lado del servidor, verificar límites de inventario, hacer DB en una transacción end)

F. Compatibilidad y limpieza

• Adaptadores de marco presentes (ESX/QBCore/QBOX) o claramente declarado como no compatible.
• Sin fugas globales, nombres de eventos únicos, sin suposiciones sobre nombres de recursos.
• Desinstalar limpio: Eliminar el recurso no daña a los demás.

---

Parte 3: Modelo de puntuación de riesgo cuantitativo (0-100)

Utilice esto para decidir “enviar/retener/rechazar”. Cuanto más bajo, mejor.

Factor	Peso	Cómo puntuar (0=bueno → 5=malo)
Actuación	0.20	resmón idle: 0=≤0.10ms, 1=≤0.20, 3=≤0.50, 5=>0.50; spikes add +1
Seguridad	0.25	0=todos validados por el servidor + límites de velocidad; 3=algunas brechas; 5=confía en el cliente / eventos inseguros
Estabilidad	0.15	0=sin errores; 3=advertencias ocasionales; 5=errores/fallos frecuentes
Compatibilidad	0.10	0=adaptadores/pruebas; 3=solo un marco; 5=rompe dependencias comunes
Mantenibilidad	0.10	0=documentación/registro de cambios/versiones semánticas; 5=sin documentación/abandonado
Cadena de suministro/Proveedor	0.20	0=con buena reputación, historial, reembolsos; 5=desconocido, sin política

Fórmula

Puntuación de riesgo = 100 * Σ(peso_i * (puntuación_i / 5))

Bandas y acciones

• 0–24 (Bajo): Enviar a puesta en escena, supervisar.
• 25–49 (moderado): Se requieren correcciones antes del lanzamiento.
• 50–74 (Alto): Retener; solicitar parches al proveedor o reemplazar.
• 75–100 (crítico): Rechazar.

Ejemplo

• Rendimiento=1, Seg=3, Estabilidad=1, Compatibilidad=1, Mantenimiento=2, Proveedor=1
• Riesgo = 100*(.2*.2 + .25*.6 + .15*.2 + .1*.2 + .1*.4 + .2*.2) = 34 → Moderado

---

Parte 4 — Rúbrica de evaluación de proveedores (puntúe de 0 a 5, cuanto mayor sea la calificación, mejor)

Criterio	¿Qué aspecto tiene lo “bueno”?	Notas
Identidad y trayectoria	Marca clara, años de actividad, manejo consistente	Evite las tiendas de quemadores
Documentación	Instalar + configurar + permisos + solución de problemas	Las capturas de pantalla y los gifs ayudan
Actualizar cadencia	Registro de cambios, versiones semánticas, confirmaciones/lanzamientos recientes	Trimestral+ está bien
Calidad del soporte	Acuerdos de nivel de servicio (SLA) de tickets/Discord, soluciones reproducibles, no solo "reinicio"	Ejemplos de respuestas
Transparencia de los problemas	Problemas conocidos públicamente y hoja de ruta	Honestidad > perfección
Claridad sobre reembolsos y condiciones de servicio	Ventana de reembolso, condiciones, términos de la licencia	Sin patrones oscuros
Prueba de prueba	Vídeo de puesta en escena, métricas de rendimiento, lista de marcos	Aún mejor: servidor de demostración
Higiene de seguridad	Menciona comprobaciones del lado del servidor, sin claves sensibles, sin evaluación	Pregunte sobre las auditorías
Política de compatibilidad	ESX/QBCore/QBOX indicado, adaptadores, matriz de versiones	Construcciones respaldadas por el estado
Precios y valor	Aceptable por su complejidad, sin muros de pago por dependencias	Cuidado con las trampas de venta adicional

Puntuación de la rúbrica (0–50):

• 40–50: Fuerte — proveedor preferido
• 30–39: Aceptable — monitor
• 20–29: Débil: proceda con cautela
• <20: Evitar

Consejo profesional: Compara precios con mercados de confianza. Empieza aquí: Las mejores tiendas de Tebex.

---

Parte 5 — Manual de mantenimiento (después del envío)

1. Fijación de versiones: versiones de scripts de bloqueo + versiones de dependencia (por ejemplo, oxmysql, biblioteca de buey).
2. Puesta en escena primero: Todas las actualizaciones llegan Ciudad de pruebas; ejecute nuevamente la lista de verificación de aceptación.
3. Copias de seguridad y reversión: Instantánea de la base de datos + archivos de recursos antes de cada actualización. Mantener una Revertir.md con pasos exactos.
4. Prueba de humo CI (opcional, recomendada): Conexión de cliente sin cabeza + macro de comando para acceder a los flujos principales; analizar la consola del servidor en busca de errores.
5. Métricas operativas: Mantenga un registro simple por script: resmon promedio (inactivo/activo), recuento de errores/sesión, notas de incidentes.
6. Disciplina del registro de cambios: requerir registros de cambios del proveedor; mantener sus propias notas de integración.
7. Eventos programados para des-riesgo: Actualizar fuera de las horas pico; anunciar ventanas de mantenimiento.

---

Parte 6: Plantillas que puedes copiar

A. Plan de pruebas (por script)

# Script Test Plan — <name> <version>

## Context
Framework(s): ESX/QBCore/QBOX
Dependencies: oxmysql vX, ox_lib vY, PolyZone vZ
DB Migrations: yes/no
Escrow: yes/no

## Functional Cases
- [ ] Case 1:
- [ ] Case 2:
- [ ] Negative 1:

## Performance
resmon idle: ____ ms
resmon active: ____ ms (scenario: ______)

## Security Checks
- [ ] All server events validate source/perm/input
- [ ] Rate limits present
- [ ] No client-trusted money/inventory mutations

## Logs & Errors
Paste snippet (server + F8): 

## Result
Pass/Fail + Notes

B. Rollback.md (esqueleto)

# Rollback — <date> <script> <from→to>

1) Disable script: `stop <resource>`
2) Restore resource files from backup: <path>
3) Restore DB snapshot: <path/command>
4) Restart FXServer
5) Verify: console clean, perf normal, flows ok

C. Plantilla de problema

**Resumen** Qué sucedió vs. lo esperado, con marcas de tiempo. **Pasos de reproducción** 1) ... 2) ... **Entorno** Compilación del artefacto: Marco y versiones: Versión del script: Otras dependencias: **Registros** Consola del servidor: F8: **Adjuntos** Pantallas/video si es posible.

---

Cómo utilizar esta guía de forma eficiente

1. Ciudad de prueba de Bootstrap Una vez, mantenlo limpio.
2. Para cada guión candidato:
   • Caer en recursos/personalizados/, habilitar en servidor.cfg.
   • Ejecutar el Lista de verificación de aceptación.
   • Calcular el Puntuación de riesgo.
   • Verifique al vendedor con la Rúbrica del proveedor.
3. Si se aprueba, únase al escenario; si no, solicite correcciones o retírese.

---

¿Necesita más guías de pruebas? Consulta la sección