Todo script traz a mesma camada de bridges. Ela detecta o que roda no seu servidor, escolhe um target e diz qual foi. Nada para instalar, nada para corrigir, e os arquivos que fazem o trabalho podem ser lidos.
ESX, QBCore e vRP têm um ramo dedicado, testado em cima dos exports reais. O modo standalone não precisa de framework nenhum, e custom é um ramo vazio que você mesmo preenche. Qbox e ox_core passam pelo caminho standalone ou custom em vez de um target testado, e dizemos isso em vez de alegar um suporte que não verificamos.
A detecção roda na inicialização e sonda o export real, não apenas se o recurso está iniciado. Um framework que sobe depois de nós não nos prende para sempre: o bridge tenta de novo, depois desiste e cai para standalone. Cada bridge levanta uma flag Ready, e o resto do recurso espera essa flag em vez de um atraso adivinhado. Um Wait adivinhado já fez com que nenhum item de roupa fosse registrado em um 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 | customColoque Config.Debug = true e reinicie. O console imprime uma linha por categoria de bridge nomeando o target escolhido. Volte para false quando as linhas baterem com o seu servidor, porque os comandos de diagnóstico que isso libera custam um engasgo de frame.
Troque auto pelo nome que quiser. A detecção é então pulada por completo nessa categoria, o que é útil em um ambiente muito modificado onde a sondagem dá a resposta errada. As cinco categorias são independentes: você pode forçar o framework e deixar as notificações em auto.
Cada arquivo de bridge tem um ramo custom com um comentário indicando onde plugar o seu próprio código. Ele nunca é escolhido automaticamente, apenas quando você o nomeia, porque um fallback que caísse em silêncio num ramo vazio seria pior do que um que cai em standalone.
Uma dependência dura no manifesto, aquela linha @vrp/lib/utils.lua que se vê em todo lugar, impede o recurso de iniciar em qualquer servidor sem vRP. O bridge fala então direto com o barramento de eventos do vRP. O benefício secundário é real: as diferenças de convenção entre forks vivem nesse helper, então ir direto elimina todas. vRP 2 e vRP 0.5 não são suportados, e o recurso avisa no console em vez de se comportar mal em silêncio.
Roda, pelo caminho standalone ou custom, mas não por um ramo que testamos. Qbox é próximo o bastante do QBCore para que forçar qbcore funcione na maioria das builds. Preferimos escrever isso a alegar um suporte não verificado.
Nada quebra. A detecção tenta de novo em vez de fixar uma resposta errada na primeira olhada, e o recurso espera a flag Ready do bridge antes de tocar em qualquer coisa. Um recurso que não está instalado é descartado na hora, para que outros servidores não paguem a espera.
Sim, foram feitos para isso. Cada um é dono da sua metade do único slot de decoração do ped e devolve o resto após um redraw. O que você não deve fazer é rodar os recursos separados e o pacote ao mesmo tempo, e o console avisa na inicialização se for o caso.
Não. bridges/compat.lua fornece uma implementação nativa do que usamos, então o ox_lib é aproveitado quando está presente e substituído quando não está. Nada no manifesto depende dele.
