No existe un ganador universal oficial entre ESX, QBCore y Qbox. Elige el framework cuya receta actual, APIs y recursos compatibles coincidan con las características de servidor requeridas, los datos existentes y las habilidades del equipo. Si ya operas una pila estable específica de un framework, permanecer en ese ecosistema suele ser la primera opción a evaluar porque la migración afecta a más que la carpeta principal.
Guía de decisión rápida
| Punto de partida | Primer framework a evaluar | Razón para verificar |
|---|---|---|
| Servidor ESX existente | ESX Legacy | Conserva los datos específicos de ESX, eventos, exportaciones y conocimiento de recursos cuando aún se cumplen los requisitos actuales. |
| 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 API y la compatibilidad exacta con terceros. |
| Equipo 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. |
| No se requiere framework de roleplay | Recursos Standalone | Standalone describe un patrón de dependencia; confirma si un framework completo es realmente innecesario. |
Qué hace un framework FiveM
Cfx.re describe los frameworks como cimientos que facilitan la construcción de recursos de servidor. Un framework de roleplay generalmente establece patrones compartidos para datos de jugadores y personajes, trabajos, elementos, 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 principal.
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 ser reemplazados. Una marca de verificación junto al nombre de un 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 roleplay de código abierto con su núcleo actual publicado por la organización oficial ESX. El tutorial oficial para nuevos servidores utiliza la plantilla txAdmin de ESX Legacy. La instalación manual documenta oxmysql, spawnmanager, importación de bases de datos, recursos principales y adicionales, exclusiones y orden de inicio.
ESX es la primera opción a evaluar cuando un servidor existente ya tiene datos de jugadores, recursos y procedimientos de equipo específicos de ESX. Esa es una observación de riesgo de migración, no una afirmación de cuota de mercado. Para una nueva instalación, inspecciona la receta actual y verifica que cada producto requerido sea compatible con la versión exacta de ESX, el inventario, la biblioteca de la base de datos, los exports y los eventos.
QBCore
El recurso oficial qb-core de QBCore expone un Core Object con funciones, datos de jugadores, datos compartidos, configuración y comandos. Las definiciones compartidas incluyen trabajos, bandas, objetos y vehículos. La instalación oficial para Windows utiliza la receta QBCore Framework de la sección de recetas populares de txAdmin, que despliega una base de datos y un conjunto más amplio de recursos, no solo la carpeta del core.
QBCore es una opción para una instalación nueva o existente del ecosistema QB cuando sus API documentadas y sus recursos compatibles cubren los requisitos del servidor. No deduzcas que todos los recursos con la etiqueta QBCore son compatibles con cada versión del núcleo o con cualquier inventario alternativo. Registra los exports, las dependencias, el SQL y el orden de inicio necesarios para esa combinación exacta de componentes.
Qbox
La introducción oficial de Qbox registra que Qbox comenzó en 2022 a partir de QBCore y ahora tiene sus propios API y recursos principales. Qbox mantiene un puente de compatibilidad QB para muchos recursos QBCore correctamente escritos. Su documentación también nombra excepciones, incluidos recursos que dependen de acceso directo a la base de datos, archivos internos del núcleo o comportamiento no compatible.
La instalación oficial de Qbox utiliza una receta popular de QBox en txAdmin. Para una migración de QBCore, la guía de conversión cubre las diferencias de configuración, los grados numéricos de trabajos y pandillas, la conversión de inventario y base de datos, y el reemplazo incremental de API. Por lo tanto, Qbox es una elección de framework deliberada con una auditoría de compatibilidad, no simplemente un interruptor que hace que cada script QBCore funcione sin cambios.
Dimensiones de comparación que puedes verificar
| Dimensión | Pregunta | Evidencia |
|---|---|---|
| Ruta de instalación | ¿Existe una receta oficial actual y documentación completa? | Documentos oficiales y repositorio de recetas en la fecha revisada. |
| Recursos requeridos | ¿Qué base de datos, biblioteca, inventario y recursos de soporte se seleccionan? | Archivos de receta, manifiestos y declaraciones de dependencia. |
| Compatibilidad API | ¿Qué exportaciones, eventos, objetos y campos de datos llaman los scripts requeridos? | Fuente de recursos, manifiestos y documentación oficial de API. |
| Modelo de datos | ¿Qué identificadores, grados, cuentas y relaciones deben preservarse? | Inventario de esquemas y mapeo de migración probado. |
| Operaciones | ¿Puede el equipo actualizar, diagnosticar y revertir la pila? | Manuales operativos, copias de seguridad y un ejercicio de recuperación en preproducción. |
| 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
- Enumera las funciones que necesitan los jugadores. Especifica los requisitos exactos de trabajos, economía, inventario, vivienda, teléfono, vehículos, administración e integraciones.
- Haz un inventario de las dependencias existentes. Registra las versiones de los frameworks, los manifiestos, las tablas de las bases de datos, los exports, los eventos y los cambios personalizados del núcleo.
- Documenta la compatibilidad de los recursos. Para cada recurso requerido, confirma el framework y la versión que realmente soporta, incluyendo puentes y sistemas de reemplazo.
- Verifica el conocimiento del equipo. Incluye las API, lenguajes, modelo de base de datos y herramientas operativas que los mantenedores pueden diagnosticar.
- Estima la migración a partir de la evidencia. Cuenta los dominios de datos e integraciones reales; no utilices una tabla genérica de horas o costos.
- Construye una pila de prueba representativa. Utiliza la receta oficial, los recursos seleccionados y una copia saneada de datos realistas.
- Define la aceptación y la reversión. Decide qué debe funcionar y cómo restaurar los archivos y la base de datos consistentes anteriores.
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 entre datos importan: crear un nuevo identificador de personaje sin asignar todos los registros relacionados puede dejar activos o permisos huérfanos.
No ejecutes un fragmento SQL de conversión genérico en producción. Empieza con un inventario del esquema y de los recursos, diseña una conversión idempotente sobre una copia de prueba, valida los recuentos de registros y las relaciones, y ensaya la reversión. Los scripts específicos de un framework pueden necesitar un puente oficial, un modo multiframework 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 medir el rendimiento de tu propio stack
Si el rendimiento influye en la elección, compara compilaciones controladas en lugar de repetir una clasificación. Utiliza el mismo host o hardware equivalente aislado, el mismo artefacto de FXServer, la misma versión de base de datos, el mismo volumen de datos y las mismas acciones representativas del jugador. Mantén el conjunto de recursos funcionalmente comparable e indica cada diferencia intencionada.
- Calienta cada servidor de forma consistente y captura el comportamiento en reposo.
- Repite las mismas acciones de carga de personaje, inventario, trabajo, vehículo y economía.
- Recopila evidencias del profiler de FiveM o de resmon, además de las consultas lentas de la base de datos y las métricas del sistema.
- Ejecuta varias muestras e informa de distribuciones o rangos, no de un único mejor número.
- Inspecciona los errores, la corrección de los datos y el comportamiento de reconexión junto con los tiempos.
- Conserva la configuración y los registros sin procesar para que otro revisor pueda reproducir la conclusión.
Una evaluación comparativa de un núcleo con diferentes recursos no aísla el framework. Un resultado de un servidor sintético vacío no prueba la capacidad de producción. Publica solo las conclusiones respaldadas por la configuración registrada y la evidencia sin procesar.
Recomendación práctica
- Elige ESX cuando los recursos, datos y conocimientos del equipo actuales de ESX satisfacen mejor los requisitos y la migración no tiene un beneficio probado.
- Elige QBCore cuando la receta oficial de QB y el ecosistema documentado se ajustan a una nueva instalación o a un servidor QB existente.
- Elige 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.
Abre las guías de framework dedicadas para la instalación oficial actual y el límite de compatibilidad. Luego, haz coincidir los recursos comerciales con la pila elegida exacta en lugar de tratar una etiqueta de categoría amplia como prueba final.
Guías detalladas del framework
Continúa con la instalación exacta y el límite de compatibilidad para ESX Legacy, QBCore o la pila Qbox y Ox.
Documentación de referencia
Cfx.re — frameworks · Fuente: docs.qbox.re · Fuente: qbcore-fivem/qb-core · Fuente: esx-framework/esx_core