Ajustes del framework

QBCore y ESX#

Solo se admiten determinadas estructuras y campos indexados. Columnas ausentes o identificadores personalizados pueden bloquear consultas. Una respuesta vacía o no compatible no prueba que la base esté vacía.

Flujos personalizados#

Prueba personajes, trabajos, teletransportes y garajes en un servidor de pruebas. Valida permisos en el servidor y concede excepciones limitadas desde código fiable.

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.

1. Compara un personaje de prueba con efectivo, banco, trabajo y vehículo conocidos.
2. Con ox_inventory, compara un inventario online pequeño. Respeta truncamientos; no esperes stashes o metadatos arbitrarios.
3. Ante fallo API, revisa inicio y versión. Una API inaccesible significa propiedad de arma desconocida, no ausencia demostrada.

• Puente de base de datos (Tosun Connect)

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.

• Exports y confianza
• Seguridad oficial de eventos

Interpretar nombres de configuración y de core detectado#

La configuración AC y el conector usan etiquetas distintas: QBCore se configura con qb, pero el estado del puente informa qbcore. Qbox usa qbox y el recurso qbx_core activo. Interprete cada etiqueta en su contexto en vez de ajustarla al nombre de carpeta. La configuración automática puede reconocer vrp u ox_core y asignar una etiqueta, pero no crea un adaptador compatible de personajes o economía para el puente. En un core no compatible, elegir standalone explícitamente para protección general evita confundir un nombre detectado con una integración completa.

1. Compruebe configs/anticheat_config.lua y el core realmente activo; conserve una elección intencionada y el orden de dependencias.
2. Si el panel muestra otras capacidades, revise recursos core y salud del puente antes de cambiar nombres a ciegas.
3. No arranque qb-core, qbx_core y es_extended juntos solo para obtener otra etiqueta de estado.

Crear pruebas de aceptación según roles reales#

Separe pruebas de jugadores normales, policía u otros empleos y personal. El personal puede tener exenciones legítimas; pruebe también con personajes normales. Cubra entrada, selección de personaje, muerte y reanimación, viviendas, garajes, armas de inventario y recompensas reales de empleos. Anote destino esperado, efecto en objetos o cuenta y registro observado. Pruebe cancelación y finalización de menús y actividades. Un inicio sin errores no demuestra que un inventario modificado, banco o selector de personajes use las API esperadas por la integración.

1. Repita la misma serie pequeña antes y después de actualizar core o inventario, cambiando un componente cada vez.
2. Registre versiones, recurso que llama y rol del jugador cuando falle; proteja los datos identificativos.
3. Reconecte tras reinicio o cambio de personaje y compruebe que termina la exención temporal, sin limitarse al personal exento.

Asignar responsabilidades de scripts propios#

Separe detección de reglas pertenecientes a scripts del juego. AC no conoce destinatarios permitidos de transferencias propias, límites de recompensas ni propietarios de casas. Cada recurso debe validar jugador, permiso y estado del servidor antes de modificar dinero, objetos o posición. Las comprobaciones de armas usan API compatibles; una API indisponible significa resultado desconocido, no prueba de arma generada. Si las consultas fallan por columnas o índices distintos, investigue compatibilidad aparte de sanciones. No castigue jugadores por errores de integración ni sustituya un adaptador ausente por exenciones amplias.

1. Asigne un responsable del adaptador de framework o inventario y responsables claros de cada acción personalizada.
2. Reproduzca una acción permitida y una ruta de permiso rechazada mediante validaciones propias del script.
3. Separe protección AC general del puente de base de datos del panel (Tosun Connect); tablas propias requieren integración revisada.

Separar inventario de armas y detalle del personaje#

Framework e inventario pueden diferir: QBCore administra personajes y dinero, ox_inventory objetos. La comprobación de armas prioriza ox_inventory activo, y después API compatibles QBCore/Qbox o ESX. Detalle del panel es otra operación del puente. Ver un objeto no confirma misma fuente, hora y formato de toda comprobación. Cambiar una etiqueta no sincroniza armerías propias.

Loadout ESX y cantidad de inventario por objetos son conceptos distintos. nil, error o datos inesperados no prueban ausencia. Verifique método compatible y registre entrega, acción normal, proveedor y resultado. AllowWeapon revisado puede cubrir armas legítimas concedidas por el servidor fuera del inventario con alcance necesario. Es una revisión de compatibilidad, no promesa de resolver cualquier error de detección.

Tratar migración de core como más que renombrar tablas#

Pasar entre QBCore y ESX no es solo una etiqueta. El puente usa players/citizenid en QBCore y users/identifier en ESX. Sesión antigua o nombre visible no identifica personaje migrado. Dinero, vehículos, inventario y reglas pueden variar. No renombre tablas de producción solo para consultas. La migración corresponde al plan del servidor; AC no convierte datos perdidos.

En entorno separado seleccione personaje y vehículo conocidos. Anote core, identidad persistente, cuenta cash/bank y estado en línea antes de leer. Error de esquema o índice no prueba pérdida; el responsable revisa compatibilidad. La edición de saldos desde el panel está activa por defecto; no la use hasta la aceptación. Para bloquearla, use el modo manual: set tosun_db_bridge_manual "1" y set tosun_db_bridge_enabled "1" en server.cfg, sin tosun_db_bridge_money_write. Repita selección de personaje y operaciones normales de inventario. Acepte datos correctos para personaje correcto, no únicamente recurso iniciado.