Guías FiveM: Frameworks, Integración y Pruebas de Instalación
Compara nombres y datos para QBCore, ESX, Standalone, vRP y OX/Qbox. Tiempo depende de scripts propios y pruebas.
Respuesta corta: Identifica core e inventario, después elige valor AC y pruebas.
Instalación y compatibilidad
| Base | Campo framework AC | Datos admitidos | Guía |
|---|---|---|---|
| QBCore | qb | players / citizenid; índices compatibles | Guía de instalación → |
| ESX | esx | users / identifier; índices compatibles | Guía de instalación → |
| Standalone | standalone | Datos propios no soportados por puente | Guía de instalación → |
| vRP / vRPex | standalone: controles generales | Economía/personajes vRP propios no soportados | Guía de instalación → |
| Qbox / ox_core | qbox / standalone | Qbox compatible; ox_core puro no soportado | Guía de instalación → |
Elegir la instalación real
qb-core → qb; es_extended → esx; qbx_core → qbox. standalone general para custom/vRP. ox_inventory no es core; revisa ox_core aparte. Verifica auto en consola.
El perfil no crea reglas de eventos
Descubrir evento/framework no valida precio, cantidad, ubicación o permisos. Tiendas, trabajos, recompensas e inventarios propios necesitan validación servidor. Movimiento normal no exige log de detección. Lectura, rechazo por permiso y detección se prueban por separado.
Identificar framework e inventario por separado
Localiza el recurso del estado del jugador: qb-core, qbx_core o es_extended. Revisa aparte inventario y cambios de API. El nombre del framework no garantiza compatibilidad con cada banco o inventario externo. Conserva dependencias y no inicies cores competidores para resolver errores.
Edita el campo existente: qb para QBCore, qbox para Qbox; son valores, no carpetas. auto permite detectar. Comprueba el modo en el inicio y GetStatus desde código servidor. El puente detecta recursos core activos por separado y puede indicar una dependencia sin iniciar.
-- Edita el campo existente, no toda la tabla.
ts.Framework.framework = "qb"
-- Otros valores compatibles: "esx", "qbox", "auto", "standalone"
Comprobar datos del personaje
Las lecturas usan citizenid en QBCore/Qbox e identifier en ESX. El ID temporal del servidor no sustituye al identificador del personaje. Se necesitan columnas e índices compatibles; las estructuras propias pueden rechazarse.
- Compara un personaje de prueba con efectivo, banco, trabajo y vehículo conocidos.
- Con ox_inventory, compara un inventario online pequeño. Respeta truncamientos; no esperes stashes o metadatos arbitrarios.
- Ante fallo API, revisa inicio y versión. Una API inaccesible significa propiedad de arma desconocida, no ausencia demostrada.
Probar flujos reales
La detección no conoce los permisos, ubicación, precios o recompensas de cada evento personalizado. Tu script debe verificarlos en servidor. Elegir un perfil no asegura eventos de dinero/items inseguros. Valida source y sesión antes de integrar.
Standalone/vRP pueden usar controles generales apropiados, pero el puente no promete sus esquemas propios. Explica límites en lugar de usar tablas ajenas. Repite pruebas tras actualizar core, inventario o trabajos.
Registra core e inventario exactos. Tras reiniciar core reconecta al personaje antes de juzgar la API online. No cambies estructura del banco y sanción a la vez: separarlos permite diagnosticar y restaurar.
- Cambiar personaje o revivir no deja exenciones permanentes.
- Casa, garaje y cárcel llaman MarkTeleport justo antes del movimiento.
- Armas de arena sin inventario usan AllowWeapon corto desde un recurso servidor autorizado.
- Prueba policía, herramientas, tiendas y recompensas grandes con registros antes de aumentar sanciones.
Medir una referencia comparable
Perfila una sesión representativa antes de cambiar ajustes. Anota jugadores, artifact, versiones y actividad. Rol tranquilo, garajes llenos y combate generan cargas distintas. Tras un cambio compara el mismo escenario. CPU, hitches y consultas sirven más que prometer FPS fijos.
Los comandos registran una muestra limitada. Espera el final y revisa recurso e hilo de cada pico. No atribuyas todo hitch al anticheat. Guarda en privado valor exacto y comparación; una muestra corta no cubre toda hora punta.
profiler record 500
profiler status
profiler view
tosunac_doctor
Actualización, recuperación y soporte
Repite las pruebas al cambiar core, inventario, trabajos o AC. No cambies esquema, sanción y versión simultáneamente. Si falla lo nuevo, restaura recurso y ajustes guardados en mantenimiento; evalúa pérdida de datos antes de restaurar el banco. A soporte proporciona versiones de artifact/core/inventario/AC, recurso, pasos, hora y primer error limpio. No publiques identificadores, licencias, contraseñas o tokens.
Detalles relacionados
Documentación de instalación · Puente de base de datos · Exports del servidor
Preguntas frecuentes
¿Solo ajuste panel al cambiar core?
No. API, inventario, IDs, esquema y eventos cambian; respalda y repite pruebas.
¿Sin datos significa AC apagado?
No. Permisos/esquema del puente y controles generales son distintos.
¿Varios servidores?
Revisa cuota de plan y licencia individual, prueba cada instalación.