Uso simultáneo de ESX y QBCore: ¿Por qué no es viable?

Respuesta directa: No ejecutes ESX y QBCore como dos núcleos que controlen los datos de los mismos jugadores. Ambos pueden técnicamente iniciarse como recursos de FiveM, pero modelan la identidad, los trabajos, el dinero, el inventario, las devoluciones de llamada y los eventos de manera diferente. Sin un puente diseñado específicamente y una fuente de verdad declarada, el estado duplicado se vuelve inseguro y difícil de recuperar.

Por qué dos núcleos entran en conflicto

Dominio	Riesgo con dos autoridades	Control requerido
Identidad	Un jugador puede recibir registros ESX y QBCore no relacionados.	Una identidad canónica y mapeo explícito.
Dinero y trabajos	Las actualizaciones pueden divergir o aplicarse dos veces.	Un único responsable de las escrituras y reglas de conversión probadas.
Inventario	Los elementos, metadatos y semántica de almacenamiento difieren.	Una autoridad de inventario; adaptadores en el límite.
Eventos y callbacks	Acciones de juego similares pueden activar manejadores de framework no relacionados.	Adaptadores con espacio de nombres y revisados en lugar de duplicación global.
Dependencias	Un recurso puede detectar el core incorrecto o usar un API no compatible.	Pruebas exactas de dependencias y orden de inicio.

Qué es factible

Un servidor puede ejecutar un adaptador de compatibilidad para un recurso específico cuando el adaptador tiene un contrato limitado y un framework sigue siendo autoritativo. Qbox, por ejemplo, documenta un puente QB y sus límites. Eso es diferente de ejecutar dos economías y modelos de jugador completos uno al lado del otro.

Lista de verificación de decisiones

1. Determina qué núcleo controla la identidad, los trabajos, el dinero y el inventario.
2. Enumera los recursos heredados concretos que bloquean la migración.
3. Da prioridad a sustituir o portar cada recurso; usa un puente solo cuando su contrato esté documentado y pueda probarse.
4. Prueba las llamadas no autorizadas, las reconexiones, los reinicios y los fallos parciales de las dependencias.
5. Si ambos núcleos necesitan escribir en el mismo ámbito de datos, detente y rediseña la solución antes de pasar a producción.

Alcance y limitaciones

No hay una respuesta universal para cada fork o adaptador personalizado. Un puente cuidadosamente diseñado puede traducir una superficie API limitada, pero debe declarar la propiedad, el comportamiento de fallo y las reglas de persistencia. No interpretes “compatible con QB” como prueba de compatibilidad total QBCore en otro framework.

Fuentes primarias

• Cfx.re: Frameworks
• ESX: repositorio oficial de esx_core
• QBCore: repositorio oficial de qb-core
• Qbox: documentación oficial

• Qbox Preguntas frecuentes: Límites de compatibilidad QBCore
• Convars del puente de qbx_core de Qbox