Scripts essenciais de FiveM para um novo servidor: um checklist

Monte um novo servidor de FiveM seguindo a ordem das dependências. Instale primeiro o banco de dados e o framework, depois o inventário e os personagens e, por fim, os sistemas que dependem deles, como veículos, empregos, polícia e celulares. Teste o framework, as dependências e a edição de cada sistema no staging antes de adicionar o próximo.

Divulgação: a RPScripts vende recursos de FiveM, e os links de categoria abaixo levam ao catálogo dela. Eles mostram onde navegar por um tipo de recurso, não uma recomendação de produto. O checklist se baseia na documentação dos frameworks e da Cfx.re linkada em cada etapa, revisada em 13 de outubro de 2026. Esta é uma revisão de documentação, não um teste prático: a RPScripts não instalou nem executou os recursos citados aqui para este artigo. O framework que você usa define a maioria das respostas, então resolva isso primeiro com comparativo de frameworks de FiveM.

Decida três coisas antes de instalar qualquer coisa

1. Framework. ESX Legacy, QBCore ou Qbox. Todo recurso que você comprar precisa dar suporte ao que você escolher. Veja comparativo de frameworks de FiveM.
2. Edição do jogo. A página Legacy vs Enhanced da Cfx.re lista a voz Mumble como obsoleta (deprecated) no Enhanced e o Asset Escrow como ainda não implementado lá. Um recurso que funciona no Legacy não está comprovado no Enhanced.
3. Propriedade dos dados. Para cada sistema abaixo, saiba qual recurso armazena os dados (itens de inventário, chaves, dinheiro, casas) e garanta que apenas um recurso seja o dono deles. Dois recursos gravando os mesmos dados podem causar itens duplicados ou perdidos.

A ordem de instalação

A ordem abaixo é uma sugestão editorial, não uma regra da Cfx.re; mapas e celulares em particular podem precisar vir antes se um recurso de emprego ou de moradia depender deles.

1. Chave de licença da Cfx.re e uma recipe do txAdmin para o seu framework: ESX, QBCore ou Qbox.
2. Banco de dados e oxmysql, iniciados antes de tudo o que usa o banco de dados.
3. Core do framework e suas bibliotecas compartilhadas, como ox_lib.
4. Inventário, depois personagens e spawn.
5. HUD, veículos, moradia, empregos e economia.
6. Polícia, despacho e médico, que dependem de empregos, inventário e veículos.
7. Ferramentas de administração, voz, celular, tela de carregamento e mapas.

A referência do manifesto de recurso da Cfx.re documenta dependency como exigindo que o recurso indicado seja carregado antes do atual. Use o manifesto e a documentação de cada recurso para confirmar a ordem dele. Por exemplo, a página de ESX da Overextended lista oxmysql, ox_lib, es_extended e qtarget antes do ox_inventory, enquanto a página de Qbox diz para iniciar o ox_inventory imediatamente após o qbx_core.

O checklist, sistema por sistema

1. Core do framework e recipe

Precisa fazer: fornecer dados de jogadores e personagens, empregos, dinheiro e a API que outros recursos chamam. Decidir: usar a recipe oficial em vez de copiar uma única pasta do core. Verificar: a versão da recipe e o que ela já instala, para você não adicionar algo em duplicidade.

2. Banco de dados e oxmysql

Precisa fazer: armazenar tudo o que é persistente. Decidir: o servidor de banco de dados e a versão. A documentação do Qbox exige MariaDB 10.9.0 ou mais recente e diz que o MySQL não é suportado; a documentação do oxmysql recomenda fortemente o MariaDB porque muitos recursos escritos para o MySQL 5.7 podem quebrar no MySQL 8. Verificar: se o oxmysql inicia primeiro e se a string de conexão é definida com set mysql_connection_string antes de os recursos iniciarem (documentação do oxmysql). Recursos mais antigos ainda podem chamar o mysql-async; veja migrar recursos mysql-async. Isso é infraestrutura, então não há categoria na loja para ele.

3. Inventário

Precisa fazer: gerenciar itens, armas, stashes e metadados. Decidir: o inventário que todos os outros recursos vão chamar. O ox_inventory exige oxmysql e ox_lib; a configuração de framework dele lista ox, esx, qbx e nd. No ESX, ele substitui por completo os sistemas de itens, inventário e armas, e a página de ESX lista lojas e stashes padrão (esx_shops, esx_weaponshop, esx_policejob) como incompatíveis. O QBCore documenta o qb-inventory. Verificar: se todo script de loja, de crafting e de emprego dá suporte ao seu inventário. Catálogo: scripts de inventário. Mais: compatibilidade de inventário.

4. Multipersonagem e spawn

Precisa fazer: seleção e criação de personagem e o primeiro spawn. O ESX traz o esx_multicharacter como sistema padrão, com quatro slots por padrão e um comando /relog (documentação). O QBCore documenta o qb-multicharacter, incluindo uma opção de apartamento inicial e um spawn padrão (documentação). Decidir: os slots e se os jogadores podem excluir personagens. Verificar: como o substituto armazena os identificadores dos personagens e se ele espera os seus recursos de moradia e de spawn. Catálogo: scripts de multipersonagem.

5. HUD

Precisa fazer: exibir os dados de status que o framework fornece. O PlayerData do QBCore inclui hunger, thirst e stress em metadata, e os HUDs leem esses valores. Decidir: manter uma única fonte de status; dois sistemas de necessidades brigam pelos valores. Verificar: framework, recurso de status ou necessidades e integrações de combustível e voz na descrição. Passo a passo: instalar e testar um HUD.

6. Veículos, garagem, chaves e combustível

Precisa fazer: vender, guardar, trancar, abastecer e recuperar veículos. O qb-vehiclekeys documenta trancar, lockpicking e carjacking, mas a página dele não lista nenhum export; por isso, um substituto exige conferir o contrato no código-fonte. Decidir: exatamente um recurso para chaves, um para garagens e um para combustível. Verificar: qual recurso é dono dos dados de propriedade dos veículos e quais exports os recursos de chaves e de combustível chamam. Catálogo: garagens e scripts de veículos.

7. Moradia e propriedades

Precisa fazer: propriedade, acesso e armazenamento. O ESX documenta um addon Property e o QBCore documenta o qb-houses e o qb-apartments. Decidir: quem é dono dos stashes das casas. O ox_inventory inclui uma etapa opcional convertinventory esxproperty. Verificar: o tipo de interior ou shell, a integração com o inventário e o que acontece com a propriedade quando um jogador é removido. Catálogo: moradia. Mais: compatibilidade de moradia.

8. Empregos e economia

Precisa fazer: pagamento, cargos, serviço (duty), contas de sociedade e lojas. O ESX documenta Society, Addon Account, Billing e Banking; o QBCore documenta o qb-management e o qb-banking. Decidir: um único sistema de banco e de sociedade. Verificar: o formato dos cargos (grades). O Qbox usa grades de emprego numéricos, enquanto o QBCore usa strings, segundo o guia de conversão.

9. Polícia, despacho e MDT

Precisa fazer: serviço, prisões, evidências, registros e alertas. O qb-policejob documenta algemas, evidências, cadeia e um alerta /911p básico, mas a página dele não descreve nenhum MDT. Decidir: qual recurso é dono dos alertas de despacho e qual é dono dos registros. Verificar: nomes de empregos, verificações de cargo e os itens de inventário de que eles precisam. Catálogo: scripts de polícia. Mais: polícia, MDT e despacho.

10. Médico e EMS

Precisa fazer: estado de morte, reviver, tratamento e fluxo do hospital. O ESX tem um addon Ambulance Job e o QBCore documenta o qb-ambulancejob. Decidir: uma única fonte para o estado de morte, porque HUD, polícia e inventário o leem. O PlayerData do QBCore tem um campo de metadata isdead. Verificar: mapas de hospital, nomes de itens e comportamento de respawn.

11. Ferramentas de admin, permissões e logs

Precisa fazer: deixar a equipe agir, e ninguém mais. As orientações de segurança do servidor da Cfx.re dizem para validar no servidor e não confiar em entradas do cliente. A página de exports do servidor do Qbox marca os exports de permissão como obsoletos desde a v1.8.0, em favor do ACE. Decidir: os cargos da equipe e o que é registrado nos logs. Verificar: teste se uma conta comum é recusada em todos os comandos de admin. Qualquer anti-cheat é um recurso à parte; como julgamento editorial, leia o que ele detecta e como bane antes de instalar. Veja também administração do servidor.

12. Voz

Precisa fazer: voz de proximidade e rádio. A documentação de voz da Cfx.re descreve a voz baseada em Mumble e, no Enhanced, uma nova implementação de voz que a substitui. Decidir: a sua edição, antes de escolher um recurso de voz. Verificar: suporte à edição e configurações. Guia: configuração de voz.

13. Celular

Precisa fazer: contatos, mensagens, apps e links com o banco. O QBCore armazena o número de telefone em charinfo, então confira como o celular deriva os números. Decidir: item de inventário ou sem item. Verificar: dependências de framework, inventário e banco e se os dados podem ser migrados. Catálogo: celulares. Mais: compatibilidade de celulares.

14. Tela de carregamento

Precisa fazer: aparecer durante a conexão. A documentação de loadscreen diz que ela permanece até que SHUTDOWN_LOADING_SCREEN seja chamado, a menos que você ative o encerramento manual. Verificar: se ela fecha no spawn e se a música respeita o volume. Guia: criar uma tela de carregamento.

15. Mapas e MLOs

Precisa fazer: interiores e locais para os empregos. Decidir: um mapa por local para evitar sobreposições. Verificar: a edição do jogo, colisões com outros mapas e quais scripts de emprego ou de moradia referenciam as coordenadas dele. Guias: adicionar um MLO e compatibilidade de MLO.

O que verificar antes de comprar qualquer um deles

• Pacote e edição exatos. Nome, criador, versão e se ele cobre o seu framework e o seu inventário.
• Escrow. A página de Asset Escrow da Cfx.re diz que os assets comprados podem ser usados em qualquer servidor que o comprador possua, que um servidor não autorizado falha com uma mensagem de direito (entitlement) ausente e que os desenvolvedores podem excluir arquivos da proteção com escrow_ignore. Pergunte ao vendedor quais arquivos você pode editar.
• Dependências. Bibliotecas necessárias, target, inventário e tabelas do banco de dados.
• Suporte e atualizações. Onde tirar dúvidas e como as atualizações são entregues.
• Documentação. Passos de instalação, referência de configuração e um changelog.

A lista completa está no checklist pré-compra, e o guia de compatibilidade explica os selos das páginas de produto.

Teste cada adição no staging

1. Faça backup do banco de dados e da pasta de recursos; confirme que você consegue restaurar.
2. Adicione um recurso, com o SQL, a configuração e a linha ensure dele, na ordem das dependências.
3. Leia o console. Corrija os erros antes de testar as funções (ler os logs do txAdmin).
4. Teste como jogador comum e como equipe: o que é permitido e o que deve ser recusado.
5. Reconecte (relog) e depois reinicie o servidor. Confira se itens, veículos, dinheiro e propriedade persistem sem duplicar.
6. Fique atento a eventos que dão itens ou dinheiro a partir de entradas do cliente, conforme a página de segurança da Cfx.re.
7. Registre a versão e as configurações e, então, leve a mudança para a produção.

FAQ

Quais scripts um novo servidor de FiveM precisa primeiro?

A recipe do framework, o banco de dados e o oxmysql, depois um inventário e a seleção de personagem. A maioria dos outros sistemas se apoia nesses, então instale e teste eles antes de empregos, veículos, moradia, polícia ou celulares.

Preciso comprar scripts para um novo servidor?

Não necessariamente. Veja o que a recipe oficial do seu framework já instala e só compre um recurso para uma função que você consiga nomear, depois de conferir o framework, a edição, as dependências e o status de escrow dele.

Posso instalar todos os scripts de uma vez?

Pode, mas corrigir as falhas fica mais difícil. Adicione um sistema por vez no staging, com backup, para que cada erro tenha uma causa provável.

Esses scripts funcionam no FiveM para GTA V Enhanced?

Não automaticamente. Confira a página Legacy vs Enhanced e a declaração de cada vendedor, principalmente quanto a voz e Asset Escrow.