Cada script lleva la misma capa de bridges. Detecta lo que corre en tu servidor, elige un target y te dice cuál. Nada que instalar, nada que parchear, y los archivos que hacen el trabajo se pueden leer.
ESX, QBCore y vRP tienen una rama dedicada, probada sobre los exports reales. El modo standalone no necesita ningún framework, y custom es una rama vacía que rellenas tú. Qbox y ox_core pasan por el camino standalone o custom en vez de por un target probado, y lo decimos en vez de afirmar un soporte que no hemos verificado.
La detección corre al arrancar y sondea el export real, no solo si el recurso está iniciado. Un framework que arranca después de nosotros no nos fija para siempre: el bridge reintenta, luego se rinde y cae a standalone. Cada bridge levanta una bandera Ready, y el resto del recurso espera esa bandera en lugar de un retraso adivinado. Un Wait adivinado ya provocó que ningún artículo de ropa se registrara en un servidor lento.
-- config/config.lua
Config.Framework = 'auto' -- auto | qbcore | esx | vrp | standalone | custom
Config.Notif = 'auto' -- auto | qbcore | esx | oxlib | okok | vrp | standalone | custom
Config.Interact = 'auto' -- auto | avenida_interact | ox_target | qb-target | standalone | custom
Config.Clothing = 'auto' -- auto | qb-clothing | illenium-appearance | fivem-appearance | esx_skin | vrp | standalone-table | custom
Config.Inventory = 'auto' -- auto | ox_inventory | qb-inventory | esx | standalone | customPon Config.Debug = true y reinicia. La consola imprime una línea por categoría de bridge nombrando el target elegido. Vuelve a false cuando las líneas coincidan con tu servidor, porque los comandos de diagnóstico que desbloquea cuestan un tirón de frame.
Sustituye auto por el nombre que quieras. La detección se salta entonces por completo para esa categoría, que es lo que interesa en una instalación muy modificada donde el sondeo da la respuesta equivocada. Las cinco categorías son independientes: puedes forzar el framework y dejar las notificaciones en auto.
Cada archivo de bridge lleva una rama custom con un comentario que indica dónde enganchar tu propio código. Nunca se selecciona automáticamente, solo cuando la nombras, porque un fallback que aterrizara en silencio en una rama vacía sería peor que uno que aterriza en standalone.
Una dependencia dura en el manifiesto, la línea @vrp/lib/utils.lua que se ve por todas partes, impide que el recurso arranque en cualquier servidor sin vRP. El bridge habla por tanto directamente con el bus de eventos de vRP. El beneficio secundario es real: las diferencias de convención entre forks viven en ese helper, así que ir directo las elimina todas. vRP 2 y vRP 0.5 no están soportados, y el recurso lo dice en consola en vez de comportarse mal en silencio.
Funciona, por el camino standalone o custom, pero no por una rama que probemos. Qbox está lo bastante cerca de QBCore como para que forzar qbcore funcione en la mayoría de builds. Preferimos escribirlo antes que afirmar un soporte sin verificar.
No se rompe nada. La detección reintenta en vez de fijar una respuesta equivocada a la primera, y el recurso espera la bandera Ready del bridge antes de tocar nada. Un recurso que no está instalado se descarta de inmediato, para que otros servidores no paguen la espera.
Sí, están hechos para eso. Cada uno posee su mitad de la única ranura de decoración del ped y devuelve el resto tras un redraw. Lo que no debes hacer es correr los recursos por separado y el pack al mismo tiempo, y la consola lo avisa al arrancar si lo haces.
No. bridges/compat.lua aporta una implementación nativa de lo que usamos, así que ox_lib se aprovecha cuando está y se sustituye cuando no. Nada en el manifiesto depende de él.
