No hay un ganador universal oficial entre ESX, QBCore y Qbox. Elige el framework cuya receta actual, APIs y recursos compatibles coincidan con las características requeridas de tu servidor, los datos existentes y las habilidades del equipo. Si ya operas un stack estable específico de un framework, permanecer en ese ecosistema suele ser la primera opción a evaluar porque la migración afecta más que la carpeta central.
Guía rápida de decisión
| Punto de partida | Primer framework a evaluar | Motivo para verificar |
|---|---|---|
| Servidor ESX existente | ESX Legacy | Conserva datos específicos de ESX, eventos, exports y conocimiento de recursos cuando los requisitos actuales aún se cumplen. |
| Servidor QBCore existente | QBCore | Evita la conversión a menos que otro framework resuelva un requisito documentado que lo justifique. |
| Nueva construcción orientada a QB | QBCore o Qbox | Compara las dos recetas oficiales, los recursos seleccionados, el modelo de API y la compatibilidad exacta con terceros. |
| Equipo de QBCore considerando Qbox | Qbox con auditoría de puente | El puente QB ayuda a muchos recursos, pero las excepciones documentadas aún requieren verificaciones a nivel de recurso. |
| Sin requisito de framework de rol | Recursos independientes | Independiente describe un patrón de dependencia; confirma si realmente no es necesario un framework completo. |
Qué hace un framework de FiveM
Cfx.re describe los frameworks como bases que facilitan la construcción de recursos del servidor. Un framework de rol generalmente establece patrones compartidos para datos de jugador y personaje, trabajos, objetos, dinero, comandos, permisos y comunicación entre recursos. Las características exactas visibles para los jugadores dependen de la receta completa y los recursos instalados, no solo del nombre del framework central.
Esta distinción evita una comparación engañosa. Los sistemas de inventario, vivienda, teléfonos, banca o vehículos pueden ser recursos separados y pueden reemplazarse. Una marca de verificación junto a un nombre de framework no prueba qué implementación, versión o integración ejecutará un servidor de producción.
ESX Legacy
ESX Legacy es un framework de rol de código abierto con su núcleo actual publicado por la organización oficial de ESX. El tutorial oficial para servidores nuevos utiliza la plantilla de txAdmin de ESX Legacy. La documentación de instalación manual incluye oxmysql, spawnmanager, importación de base de datos, núcleo y recursos adicionales, exclusiones y orden de inicio.
ESX es la primera opción a evaluar cuando un servidor existente ya tiene datos de jugador, recursos y procedimientos de equipo específicos de ESX. Es una observación sobre el riesgo de migración, no una afirmación de participación de mercado. Para una construcción nueva, inspecciona la receta actual y verifica que cada producto requerido sea compatible con la versión exacta de ESX, el inventario, la biblioteca de base de datos, los exports y los eventos.
QBCore
Oficial de QBCore qb-core expone un Objeto Central con funciones, datos de jugador, datos compartidos, configuración y comandos. Las definiciones compartidas incluyen trabajos, pandillas, objetos y vehículos. La instalación oficial de Windows utiliza la receta popular del Framework QBCore en txAdmin, y la receta despliega una base de datos y un conjunto de recursos más amplio, no solo la carpeta central.
QBCore es un candidato para una construcción nueva o existente del ecosistema QB cuando sus APIs documentadas y recursos compatibles cubren los requisitos del servidor. No se debe inferir que cada recurso con la etiqueta QBCore soporta todas las versiones del núcleo o inventarios de reemplazo. Registre las exportaciones, dependencias, SQL y orden de inicio requeridos para la pila exacta.
Qbox
La introducción oficial de Qbox registra que Qbox comenzó en 2022 a partir de QBCore y ahora tiene sus propias APIs y recursos centrales. Qbox mantiene un puente de compatibilidad QB para muchos recursos QBCore correctamente escritos. Su documentación también nombra excepciones, incluyendo recursos que dependen de acceso directo a la base de datos, archivos centrales internos o comportamiento no soportado.
La instalación oficial de Qbox utiliza una receta popular de QBox en txAdmin. Para una migración desde QBCore, la guía de conversión cubre diferencias de configuración, grados numéricos de trabajos y pandillas, inventario y conversión de base de datos, y reemplazo incremental de API. Por lo tanto, Qbox es una elección deliberada de framework con una auditoría de compatibilidad, no simplemente un cambio que hace que cada script de QBCore funcione sin modificaciones.
Dimensiones de comparación que puede verificar
| Dimensión | Pregunta | Evidencia |
|---|---|---|
| Ruta de instalación | ¿Existe una receta oficial actual y documentación completa? | Documentación oficial y repositorio de recetas en la fecha revisada. |
| Recursos requeridos | ¿Qué base de datos, biblioteca, inventario y recursos de soporte están seleccionados? | Archivos de receta, manifiestos y declaraciones de dependencias. |
| Compatibilidad de API | ¿Qué exportaciones, eventos, objetos y campos de datos llaman los scripts requeridos? | Fuente del recurso, manifiestos y documentación oficial de API. |
| Modelo de datos | ¿Qué identificadores, grados, cuentas y relaciones deben conservarse? | Inventario de esquemas y mapeo de migración probado. |
| Operaciones | ¿Puede el equipo actualizar, diagnosticar y revertir la pila? | Runbooks, copias de seguridad y un ejercicio de recuperación por etapas. |
| Rendimiento | ¿Cómo se comporta la pila exacta bajo acciones representativas? | Profiler, resmon y registros de base de datos de pruebas controladas repetidas. |
Lista de verificación de decisiones
- Enumere las funciones requeridas para el jugador. Nombrar los requisitos exactos de trabajos, economía, inventario, vivienda, teléfono, vehículo, administración e integración.
- Inventariar las dependencias existentes. Registrar las versiones del framework, manifiestos, tablas de base de datos, exports, eventos y cambios personalizados del núcleo.
- Mapear el soporte de recursos. Para cada recurso requerido, confirmar el framework y la versión que realmente soporta, incluyendo puentes y sistemas de reemplazo.
- Verificar el conocimiento del equipo. Incluir las APIs, lenguajes, modelo de base de datos y herramientas operativas que los mantenedores pueden diagnosticar.
- Estimar la migración a partir de la evidencia. Contar los dominios de datos reales y las integraciones; no usar una tabla genérica de horas o costos.
- Construir un stack de prueba representativo. Usar la receta oficial, los recursos seleccionados y una copia saneada de datos realistas.
- Definir la aceptación y la reversión. Decidir qué debe funcionar y cómo restaurar los archivos consistentes anteriores y la base de datos.
La migración afecta a todo el modelo del servidor.
Cambiar de framework puede implicar identidades, personajes, dinero, trabajos, bandas, inventario, vehículos, garajes, viviendas, teléfonos, banca, cuentas de sociedad, permisos y eventos personalizados. Las relaciones de datos importan: crear un nuevo identificador de personaje sin mapear todos los registros relacionados puede dejar activos o permisos huérfanos.
No ejecutar un fragmento SQL de conversión genérico contra producción. Comenzar con un inventario de esquema y recursos, diseñar una conversión idempotente contra una copia de prueba, validar los recuentos de registros y las relaciones, y ensayar la reversión. Los scripts específicos del framework pueden necesitar un puente oficial, un modo multi-framework documentado o cambios de código. Los scripts de ESX no son automáticamente portables a QBCore o Qbox, y el puente QB de Qbox no es universal.
Cómo hacer benchmarking de tu propio stack
Si el rendimiento influye en la elección, comparar builds controlados en lugar de repetir una clasificación. Usar el mismo host o hardware equivalente aislado, el artefacto de FXServer, la versión de la base de datos, el volumen de datos y las acciones de jugador representativas. Mantener el conjunto de recursos funcionalmente comparable y declarar cada diferencia intencional.
- Calentar cada servidor de manera consistente y capturar el comportamiento inactivo.
- Repetir las mismas acciones de carga de personaje, inventario, trabajo, vehículo y economía.
- Recopilar evidencia del profiler de FiveM o resmon, además de consultas lentas de la base de datos y métricas del sistema.
- Ejecutar múltiples muestras e informar distribuciones o rangos, no un solo número mejor.
- Inspeccionar errores, corrección de datos y comportamiento de reconexión junto con los tiempos.
- Conservar la configuración y los registros sin procesar para que otro revisor pueda reproducir la conclusión.
Un benchmark de un núcleo con diferentes recursos no aísla el framework. Un resultado de un servidor vacío sintético no prueba la capacidad de producción. Publicar solo conclusiones respaldadas por la configuración registrada y la evidencia sin procesar.
Recomendación práctica
- Elegir ESX cuando los recursos actuales de ESX, los datos y el conocimiento del equipo satisfacen mejor los requisitos y la migración no tiene un beneficio comprobado.
- Elegir QBCore cuando la receta oficial de QB y el ecosistema documentado se ajustan a un nuevo build o a un servidor QB existente.
- Elegir Qbox cuando el equipo desea deliberadamente la receta y las API actuales de Qbox y puede completar una auditoría de puente o migración de QB.
Abra las guías de framework dedicadas para la instalación oficial actual y el límite de compatibilidad. Luego, haga coincidir los recursos comerciales con la pila exacta elegida en lugar de tratar una etiqueta de categoría amplia como prueba final.
Guías detalladas de framework
Continúe con la instalación exacta y el límite de compatibilidad para ESX Legacy, QBCore o la Pila Qbox y Ox.