Ordem ensure do server.cfg: a ordem correta de início de recursos para FiveM

Metade dos seus scripts gera erros nil na inicialização, mas funcionam quando você os reinicia manualmente. Esse padrão geralmente significa que os recursos iniciam na ordem errada. Este guia fornece uma ordem que funciona para ESX, QBCore e QBox, e explica ensure vs start, pastas de colchetes e duplicatas.

#Por que a ordem importa

Os recursos iniciam na ordem das linhas no server.cfg. Um script que lê o framework quando carrega recebe nil se o framework ainda não foi iniciado. O mesmo se aplica à camada de banco de dados e a bibliotecas como ox_lib. Você resolve isso colocando as camadas base no topo:

1. O banco de dados: oxmysql
2. A biblioteca: ox_lib
3. O framework: es_extended, qb-core ou qbx_core
4. O inventário
5. Tudo o resto

#Uma ordem que funciona

Para QBCore:

ensure oxmysql
ensure ox_lib
ensure qb-core
ensure ox_inventory
ensure [qb]

ensure [standalone]
ensure [mic]

Para QBox:

ensure oxmysql
ensure ox_lib
ensure qbx_core
ensure ox_inventory
ensure [qbx]
ensure [standalone]

Para ESX:

ensure oxmysql
ensure ox_lib
ensure es_extended
ensure ox_inventory
ensure [esx]
ensure [standalone]

Ajuste os nomes de categoria para suas próprias pastas. Se usar qb-inventory ou outro inventário em vez de ox_inventory, coloque aquele na mesma posição, logo após o framework (ou antes dele, se sua própria documentação disser assim).

Dica: mantenha recursos que você garante pelo nome (oxmysql, ox_lib, o framework, o inventário) em pastas que você não também garante como um colchete. Caso contrário, são garantidos duas vezes, veja Duplicatas abaixo. Muitas configurações colocam eles em uma pasta [core] que nunca é garantida como um todo.

Dica: sua receita txAdmin pode ter escrito sua própria ordem. Mantenha o que funciona e apenas adicione seus scripts abaixo das camadas base, em vez de reescrever o arquivo.

#ensure vs start

start my_script
ensure my_script

• start inicia um recurso se estiver parado.
• ensure o inicia se estiver parado e o reinicia se já estiver em execução.

Em um boot normal, nada está em execução, então se comportam de maneira semelhante. A diferença aparece quando você os executa no console ao vivo: ensure my_script é aquele que você deseja para recarregar um script que você acabou de editar. No server.cfg, use ensure em todos os lugares para que você só precise lembrar uma palavra. Para o outro lado, stop my_script o interrompe, e refresh faz o servidor examinar novamente a pasta resources em busca de manifestos novos ou alterados.

#Pastas de colchetes como categorias

Uma pasta cujo nome está entre colchetes não é um recurso. É uma categoria, e o FiveM procura dentro dela:

resources/
  [core]/
    ox_lib/
    oxmysql/
    qb-core/
  [qb]/
    qb-garages/
  [standalone]/
    my_other_script/
  [mic]/
    my_script/

ensure [qb] inicia todos os recursos dentro de [qb]. Isso mantém server.cfg curto, e é como a maioria dos pacotes de framework é distribuída. Duas coisas a saber:

• A ordem dentro de uma pasta de colchetes não é algo em que você deveria confiar. Se qb-garages precisar de qb-core, garanta qb-core em sua própria linha acima de ensure [qb], ou declare dependency 'qb-core' no manifesto. O core não deve depender da sorte.
• Um recurso não pode ser aninhado dentro de outro recurso. Colchetes são apenas para agrupamento. Se você colocar uma pasta de script dentro da pasta de outro script, o FiveM não a encontrará. Veja Não foi possível iniciar o recurso.

Um recurso dentro de uma pasta de colchetes ainda é encontrado pelo seu próprio nome, portanto ensure ox_lib funciona mesmo que a pasta seja [core]/ox_lib.

#Dependências no manifesto

Linhas de ordem no server.cfg são uma ferramenta. Uma linha dependency no manifesto de um script é a outra, e é mais confiável:

dependency 'ox_lib'
dependency 'oxmysql'

O FiveM então verifica se esses recursos existem e os inicia primeiro. Se um estiver faltando, você obtém uma mensagem clara em vez de um erro nil: Não foi possível encontrar a dependência X para o recurso Y. Use ambos: uma boa ordem no arquivo e dependências nos manifestos que você controla.

#Duplicatas

Duas coisas dão errado com duplicatas:

• O mesmo ensure duas vezes. Garantir um recurso duas vezes em server.cfg o inicia e o reinicia imediatamente. Desperdiça tempo de boot e pode desencadear gravações duplicadas de banco de dados ou eventos no início. Remova a segunda linha. Verifique que uma pasta de colchetes não inclua um recurso que você também garante pelo nome.
• Duas pastas com o mesmo nome de recurso. Se você tiver resources/[old]/my_script e resources/[mic]/my_script, apenas um é usado, e qual não é algo que você controla. Delete ou renomeie um, e sempre delete a versão antiga de um script antes de instalar uma nova.

Quando uma correção que você fez parece não ter efeito, verifique se você não editou a cópia que não está em execução.

#Encontre o culpado quando a ordem está errada

Inicie o servidor e releia o console do topo. O primeiro recurso que imprime um erro é a causa, e tudo depois disso pode ser consequência. Exemplos típicos:

• oxmysql imprime um erro de banco de dados: nada que use SQL funcionará.
• ox_lib falha: cada script com @ox_lib/init.lua quebra (correção ox_lib).
• O framework falha: cada script que pede um objeto de jogador fica nil.

Corrija a primeira falha e reinicie.

#Lista de verificação