Hideki

Adicionar um item não é apenas escrever um nome em um arquivo. O inventário precisa conhecer o identificador, nome exibido, peso, empilhamento, imagem, comportamento de uso e forma de persistência. Este guia mostra o fluxo completo e separa o que muda entre vRP, Creative, QBCore, Qbox e ESX. Antes de começarBackup do resource e do banco antes de alterar a produção.Servidor de homologação ou uma janela de manutenção para testar restart, adicionar, remover e usar o item.Identificação do inventário real em uso: vRP/Creative próprio, qb-inventory, ox_inventory, esx_inventory ou outro.Imagem do item no formato e na pasta esperados pelo seu inventário; o nome do arquivo precisa coincidir com a configuração.Passo a passoEscolha um ID minúsculo, sem espaços e estável, por exemplo fdev_water. O ID é usado pelo código; o label pode conter acentos.Defina o contrato do item: peso em gramas ou quilos, stack/unique, quantidade consumida, metadata, imagem e se ele será utilizável.Abra a implementação da sua base e confirme o arquivo correto. Os locais mais comuns são qb-core/shared/items.lua, ox_inventory/data/items.lua, cfg/items.lua e a tabela SQL items.Cadastre o item no formato do framework e crie o callback de uso no servidor. Dê o item somente depois de validar a origem, a quantidade e o limite de peso.Teste o fluxo real: adicionar, abrir inventário, mover, usar, consumir, relogar e reiniciar o FXServer. Confira também o console e o log do banco.Documente a alteração e mantenha uma migração reversível. Nunca sobrescreva arquivos do core durante uma atualização sem guardar o diff.Erros comuns e cuidadosNão copie um cadastro QBCore para Qbox sem verificar se a cidade usa ox_inventory; Qbox frequentemente centraliza os itens no inventário, não no core.Não confie em evento disparado pelo cliente para entregar item, dinheiro ou efeito. O servidor deve confirmar jogador, quantidade e permissão.A tabela items do ESX muda entre versões e inventários customizados. Confira as colunas existentes antes de executar SQL.vRP e Creative possuem forks com assinaturas diferentes. Trate os exemplos dessas bases como padrão de adaptação e confira a API já usada na sua cidade.Após editar um arquivo Lua, reinicie o resource. Se o item continuar invisível, verifique nome da imagem, cache do inventário e erro de sintaxe antes de apagar cache indiscriminadamente.Checklist finalID único e documentado.Peso, stack/unique e quantidade de consumo conferidos.Cadastro feito no inventário correto.Imagem aparece no slot.Uso e remoção funcionam no servidor.Item continua correto depois de relogar e reiniciar.SQL ou configuração versionado e com backup.Próximo passo: comece em um item de teste como fdev_water, valide em uma cidade de homologação e só então replique o padrão para comida, ferramentas, documentos e itens com metadata. Consulte também a documentação do QBCore Shared Items e do ox_inventory Creating Items. Conteúdo revisado pela FiveMDEV. Faça backup antes de alterar uma cidade em produção. Exemplos práticosUse o mesmo contrato em qualquer base: um ID estável, um label amigável e uma regra de uso validada no servidor. O exemplo abaixo é a referência que será adaptada nos blocos seguintes. -- Contrato do item (documentação da equipe) local item = { id = 'fdev_water', label = 'Água FiveMDEV', weight = 500, -- confirme se a base usa gramas ou outra unidade stack = true, consume = 1, image = 'fdev_water.png' }vRP e Creative: confirme a assinatura da sua forkNas bases vRP/Creative, o cadastro costuma ficar em um arquivo de itens ou em uma chamada vRP.defInventoryItem. A assinatura e o formato do peso variam entre vRP, vrpex e Creative. O padrão abaixo mostra a ideia e os pontos que você deve adaptar ao arquivo já existente. -- Exemplo comum em vRP/vrpex; confira a assinatura da sua base. local itemName = 'fdev_water' vRP.defInventoryItem( itemName, 'Água FiveMDEV', 'Beba para recuperar hidratação.', nil, -- use a função de uso da sua base, se existir 0.5 -- algumas forks usam kg; outras usam uma unidade própria ) -- Entrega server-side, depois de validar source, quantidade e capacidade. local user_id = vRP.getUserId(source) if user_id and vRP.tryGetInventoryItem(user_id, itemName, 1, true) then -- Exemplo de consumo; substitua pelo status/efeito da sua cidade. TriggerClientEvent('cidade:client:recuperarSede', source, 250000) end-- Padrão de configuração encontrado em várias forks Creative. -- O nome do arquivo (cfg/items.lua, config/items.lua etc.) é local da base. return { ['fdev_water'] = { name = 'fdev_water', label = 'Água FiveMDEV', weight = 500, stack = true, usable = true } } -- No resource de entrega, use a API que a Creative já expõe: -- vRP.giveInventoryItem(user_id, 'fdev_water', 1, true)Como validar: procure no seu core uma definição existente de água ou pão e copie a mesma assinatura. Se a sua base não possui defInventoryItem, não invente uma nova API: use o helper de cadastro já utilizado por ela. QBCore com qb-inventoryO QBCore tradicional mantém itens estáticos em qb-core/shared/items.lua. A imagem costuma ficar em qb-inventory/html/images (confirme a pasta da sua versão). O nome da chave e o campo name precisam ser iguais. -- qb-core/shared/items.lua ['fdev_water'] = { name = 'fdev_water', label = 'Água FiveMDEV', weight = 500, type = 'item', image = 'fdev_water.png', unique = false, useable = true, shouldClose = true, description = 'Água de teste da FiveMDEV.' },-- server.lua do seu resource local QBCore = exports['qb-core']:GetCoreObject() QBCore.Functions.CreateUseableItem('fdev_water', function(source, item) local player = QBCore.Functions.GetPlayer(source) if not player then return end local owned = player.Functions.GetItemByName('fdev_water') if not owned or owned.amount < 1 then return end if player.Functions.RemoveItem('fdev_water', 1, item.slot) then TriggerClientEvent('cidade:client:recuperarSede', source, 250000) end end) -- Ao entregar por um job, loja ou recompensa, valide a capacidade na sua versão: -- player.Functions.AddItem('fdev_water', 1)Qbox com ox_inventoryEm instalações Qbox atuais, confirme primeiro se o inventário é ox_inventory. Nesse caso, o item fica em ox_inventory/data/items.lua e a entrega usa exports do inventário. Não mantenha dois cadastros concorrentes para o mesmo ID. -- ox_inventory/data/items.lua ['fdev_water'] = { label = 'Água FiveMDEV', weight = 500, stack = true, close = true, consume = 1, description = 'Água de teste da FiveMDEV.', client = { image = 'fdev_water.png', export = 'fdev_items.useFdevWater' } },-- server.lua: entregue apenas após validar a regra do servidor. local success, response = exports.ox_inventory:AddItem(source, 'fdev_water', 1) if not success then print(('Não foi possível adicionar fdev_water: %s'):format(response)) end -- resources/[local]/fdev_items/client.lua exports('useFdevWater', function(data, slot) -- consume = 1 remove uma unidade; aplique aqui somente o efeito visual/status. TriggerEvent('cidade:client:recuperarSede', 250000) end) -- Para remover manualmente: -- exports.ox_inventory:RemoveItem(source, 'fdev_water', 1)O AddItem retorna sucesso e uma resposta como inventory_full ou invalid_item. Trate esse retorno para não anunciar uma recompensa que não entrou no inventário. ESX LegacyNo ESX tradicional, itens podem estar na tabela items. Em versões com ox_inventory, o cadastro pode ser centralizado no próprio ox_inventory; confira o bridge antes de executar SQL. -- Confira SHOW COLUMNS FROM items antes de usar em produção. INSERT INTO items (name, label, weight, rare, can_remove) VALUES ('fdev_water', 'Água FiveMDEV', 500, 0, 1) ON DUPLICATE KEY UPDATE label = VALUES(label), weight = VALUES(weight), can_remove = VALUES(can_remove);-- server.lua do resource ESX local ESX = exports['es_extended']:getSharedObject() ESX.RegisterUsableItem('fdev_water', function(source) local xPlayer = ESX.GetPlayerFromId(source) if not xPlayer then return end local item = xPlayer.getInventoryItem('fdev_water') if not item or item.count < 1 then return end xPlayer.removeInventoryItem('fdev_water', 1) TriggerClientEvent('cidade:client:recuperarSede', source, 250000) end) -- Entrega comum em ESX tradicional: -- xPlayer.addInventoryItem('fdev_water', 1)Teste seguro e diagnóstico-- Checklist de teste em qualquer framework (adapte a função de entrega). local function testarItem(source) -- 1) entregue uma unidade pelo servidor, nunca por evento público do cliente -- 2) confira se o inventário mostra label, peso e imagem -- 3) use o item e confirme a remoção/efeito -- 4) relogue e reinicie o resource para validar persistência print(('Teste de fdev_water solicitado por %s'):format(source)) endSe aparecer “item inexistente”, confirme o ID exato e reinicie o inventário. Se aparecer “imagem ausente”, confira maiúsculas/minúsculas e a pasta de imagens. Se o item duplica, remova eventos client-side que entregam recompensa e deixe uma única rotina server-side.

XAMPP é útil para desenvolvimento local, mas uma VPS FiveM normalmente não precisa manter Apache, PHP e phpMyAdmin carregados apenas para hospedar o banco. Instalar MariaDB pelo gerenciador do sistema deixa o ambiente mais simples de atualizar e permite desligar serviços que a cidade não usa. A economia de RAM vem desses componentes extras: o banco continua precisando de memória para atender consultas. Antes de começarVPS Linux Ubuntu ou Debian com acesso sudo.Janela de manutenção e backup validado do banco atual.A cidade e o banco no mesmo servidor; se forem separados, use rede privada e firewall.Passo a passoFaça um dump do banco atual e confirme que ele pode ser restaurado em ambiente de teste.Instale MariaDB pelo repositório do sistema e habilite o serviço para iniciar com a VPS.Execute o assistente de segurança, defina senha administrativa forte e remova acessos desnecessários.Crie um banco e um usuário exclusivos para a cidade. Não use root na string do oxmysql.Mantenha o banco escutando apenas localmente quando o FXServer estiver na mesma VPS.Configure a conexão no server.cfg e teste criação de personagem, salvamento e reinício completo.Só depois de validar a migração, remova ou desative o XAMPP que não será mais usado.Erros comuns e cuidadosNão exponha a porta 3306 à internet para resolver conexão. Para acesso externo, use VPN, túnel SSH ou rede privada.Não apague XAMPP antes de comparar dados, usuários e funcionamento da cidade.Não copie senha de banco para Discord, print, Git ou tópico público.Checklist finalBackup restaurado em teste.MariaDB inicia automaticamente.Usuário da cidade não é root.A porta do banco não está pública.oxmysql conecta e salva dados após restart.Próximo passo: Se a cidade ainda usa consultas lentas, meça primeiro e depois revise índices e resources que repetem consultas sem necessidade. Conteúdo revisado pela FiveMDEV. Faça backup antes de alterar uma cidade em produção. Exemplos práticosOs comandos abaixo são para Ubuntu/Debian. Execute um por vez e confirme cada resultado antes de continuar. sudo apt update sudo apt install mariadb-server sudo systemctl enable --now mariadb sudo mariadb-secure-installation sudo systemctl status mariadb --no-pagerDentro do console do MariaDB, crie um banco e um usuário exclusivos. Substitua a senha por uma senha longa, guardada fora do código. CREATE DATABASE cidade_rp CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER 'cidade_app'@'localhost' IDENTIFIED BY 'TROQUE_POR_UMA_SENHA_FORTE'; GRANT ALL PRIVILEGES ON cidade_rp.* TO 'cidade_app'@'localhost'; FLUSH PRIVILEGES;Depois, configure o oxmysql no server.cfg. Não publique a senha real. set mysql_connection_string "mysql://cidade_app:[email protected]/cidade_rp?charset=utf8mb4" ensure oxmysql ensure sua-baseBackup manual antes de qualquer alteração: mysqldump -u cidade_app -p cidade_rp > cidade_rp_$(date +%F).sql

Uma abertura sustentável começa com cidade estável, regras claras e canais de suporte. Divulgar antes de testar transforma os primeiros jogadores em equipe de QA involuntária e prejudica a reputação. Antes de começarServidor de teste estável.Equipe com responsáveis por desenvolvimento, suporte e moderação.Regras, política de privacidade e canal de reporte visíveis.Passo a passoDefina o público e a proposta da cidade em uma frase clara: estilo de RP, idioma, horários e diferenciais reais.Faça um beta fechado para testar fila, criação de personagem, economia, empregos, voz, punições e recuperação após restart.Crie uma página ou postagem de apresentação com requisitos, Discord oficial, regras e como pedir suporte.Publique vídeos curtos e honestos mostrando a experiência real, não apenas cenas encenadas.Planeje calendário de atualizações, changelog público e canal para sugestões.Acompanhe retenção, erros recorrentes e comportamento da comunidade; corrija a experiência antes de ampliar anúncios.Erros comuns e cuidadosNão compre membros, visualizações ou avaliações falsas; isso não cria comunidade nem confiança.Não prometa recursos que não estão prontos.Não abra administração ampla para recrutar rapidamente sem processo de confiança.Checklist finalBeta concluído.Fluxos essenciais estáveis.Equipe e escala de suporte definidas.Regras e canais oficiais publicados.Plano de lançamento e contingência pronto.Próximo passo: Use os tutoriais de performance, segurança e Discord como base operacional antes de investir em divulgação. Conteúdo revisado pela FiveMDEV. Faça backup antes de alterar uma cidade em produção. Exemplos práticosAntes da divulgação, use uma configuração clara para que o servidor apareça com nome e descrição consistentes. Não inclua senhas ou chaves nesse exemplo público. # server.cfg sets sv_projectName "Minha Cidade RP" sets sv_projectDesc "Roleplay em PT-BR - beta fechado" sets tags "brasil,roleplay,pt-br" # Mantenha os resources de produção explícitos e versionados. ensure [local]

Veículos podem afetar desempenho, colisão e economia da cidade. Instale um de cada vez em teste e valide o pacote inteiro, não apenas se o spawn funcionou. Antes de começarVeículo obtido com autorização e instruções do autor.Backup do resource de veículos e banco, se houver concessionária.Ambiente de teste com acesso ao console.Passo a passoIdentifique se o veículo é addon ou replace; os métodos são diferentes e misturá-los causa conflito.Organize arquivos de stream e data seguindo a estrutura do resource.Registre o spawn name, categoria, preço e permissões em uma planilha ou documentação interna.Adicione handling e som somente quando o pacote indicar, sem copiar arquivos de outro veículo sem compatibilidade confirmada.Inicie o resource, faça spawn em teste e avalie portas, rodas, colisão, interior, som e distância de visão.Meça impacto com vários veículos e remova assets que geram falhas ou consumo excessivo.Erros comuns e cuidadosNão use veículos sem permissão de distribuição.Evite packs enormes sem curadoria: quantidade não substitui otimização.Não altere handling de produção sem registrar o valor anterior e testar dirigibilidade.Checklist finalSpawn name documentado.Modelo e colisão testados.Som e handling validados.Desempenho medido.Origem e licença registradas.Próximo passo: Veja a categoria de veículos da FiveMDEV e prefira recursos com instruções, autor e compatibilidade claramente informados. Conteúdo revisado pela FiveMDEV. Faça backup antes de alterar uma cidade em produção. Exemplos práticosPara um veículo addon, mantenha o manifest e os data files junto ao pack. Troque os nomes pelos arquivos reais recebidos do autor. -- resources/[vehicles]/meu-veiculo/fxmanifest.lua fx_version 'cerulean' game 'gta5' files { 'data/vehicles.meta', 'data/handling.meta', 'data/carvariations.meta' } data_file 'VEHICLE_METADATA_FILE' 'data/vehicles.meta' data_file 'HANDLING_FILE' 'data/handling.meta' data_file 'VEHICLE_VARIATION_FILE' 'data/carvariations.meta'<!-- Exemplo de identificação; preserve a estrutura original do autor --> <handlingName>MEU_VEICULO</handlingName> <vehicleMakeName>MINHA_MARCA</vehicleMakeName>

Artifacts e game build resolvem problemas diferentes. Artifact é a versão do FXServer; game build seleciona conteúdo de GTA usado pelos clientes. Atualize com teste, registro e possibilidade de retorno. Antes de começarBackup do artifact atual, server.cfg, resources e banco.Servidor de homologação ou janela de manutenção.Lista dos resources mais críticos para validar após a atualização.Passo a passoLeia as notas da versão e confirme se existe motivo concreto para atualizar: correção, compatibilidade ou recurso necessário.Baixe o artifact recomendado e substitua-o primeiro em ambiente de teste.Mantenha cópia funcional do artifact anterior para rollback.Defina sv_enforceGameBuild somente quando um asset ou resource exigir; não altere game build por tentativa.Reinicie totalmente, teste conexão, spawn, inventário, veículos, voz e mapas.Monitore console e feedback dos jogadores antes de levar a mudança à produção.Erros comuns e cuidadosNão atualize artifact, framework e dezenas de scripts na mesma janela; você perde a causa de uma regressão.Não confunda build do jogo com versão do FXServer.Não escolha build antigo sem testar compatibilidade de assets e clientes.Checklist finalArtifact anterior preservado.Game build documentado.Fluxos essenciais validados.Console sem erro novo relevante.Rollback pronto.Próximo passo: A tabela de builds e as variáveis atuais estão na referência de comandos do Cfx. Conteúdo revisado pela FiveMDEV. Faça backup antes de alterar uma cidade em produção. Exemplos práticosRegistre a alteração no próprio arquivo e mantenha uma cópia do artifact anterior. Use um build somente quando um resource ou asset realmente exigir. # server.cfg # Alterado em AAAA-MM-DD: recurso X exige este build. # Testado em homologação antes da produção. sv_enforceGameBuild BUILD_EXIGIDO # Após validar o artifact recomendado: ensure meu-resource-principal

Discord é parte da operação da cidade, mas deve receber apenas o necessário. Integração boa informa a equipe sem vazar dados, tokens ou mensagens em excesso. Antes de começarServidor Discord com canais separados para equipe, auditoria e avisos.Bot ou resource com origem confiável.Responsável pelo token e pelo canal de destino.Passo a passoDefina quais eventos realmente precisam de log: conexão, punição, alteração administrativa e falha crítica costumam ser suficientes.Crie webhooks por finalidade, com permissões mínimas e nomes claros.Guarde URL de webhook e token fora de repositórios públicos; use configuração local protegida.Envie mensagens estruturadas, sem incluir senha, token, IP completo ou conteúdo privado desnecessário.Implemente limites para evitar centenas de mensagens em caso de loop ou queda do servidor.Teste log de sucesso, erro e reinicialização em um canal privado antes de usar em produção.Erros comuns e cuidadosNão entregue permissão de administrador do Discord a bots sem necessidade.Não use um único webhook para tudo; isso dificulta auditoria e revogação.Se um token vazar, revogue-o e gere outro em vez de apenas apagar a mensagem.Checklist finalCanais e responsáveis definidos.Tokens protegidos.Eventos úteis registrados.Limites contra spam testados.Plano de revogação documentado.Próximo passo: Depois, revise o checklist de segurança e trate toda integração externa como parte do inventário da cidade. Conteúdo revisado pela FiveMDEV. Faça backup antes de alterar uma cidade em produção. Exemplos práticosGuarde o webhook em configuração protegida e interrompa o envio quando ele não estiver definido. O exemplo abaixo não registra tokens ou informações privadas. local webhook = GetConvar('cidade_discord_webhook', '') local function logDiscord(message) if webhook == '' then return end PerformHttpRequest(webhook, function() end, 'POST', json.encode({ username = 'Cidade - Logs', content = message }), { ['Content-Type'] = 'application/json' }) end logDiscord('Servidor iniciado com sucesso.')

NUI conecta a interface CEF ao resource. Quando aparece “Failed to fetch”, investigue o nome do callback, o manifesto e a resposta do servidor antes de alterar a interface inteira. Antes de começarResource com ui_page e arquivos NUI declarados no manifest.Console F8 do cliente e console do servidor disponíveis.Uma ação reproduzível que dispara o erro.Passo a passoAbra o console F8 e registre o primeiro erro, a ação que o gerou e o nome do resource.Compare a URL do fetch com o nome usado em RegisterNUICallback; ambos precisam representar o mesmo callback.Envie JSON válido e defina o cabeçalho apropriado na chamada do navegador.Garanta que toda execução do callback chame cb(...), inclusive nos caminhos de erro.Verifique se SetNuiFocus é ativado e removido nos fluxos corretos para não prender teclado ou mouse.Teste o fluxo com dados vazios, permissão negada e reinicialização do resource.Erros comuns e cuidadosNunca confie em valores enviados pela NUI para entregar dinheiro, itens ou permissões: valide novamente no servidor.Não deixe callback sem resposta; a interface aguardará até falhar.Evite mensagens de debug e dados sensíveis no navegador em produção.Checklist finalCallback e URL têm o mesmo nome.Todos os caminhos retornam cb.Foco fecha corretamente.Validação crítica acontece no servidor.Erro reproduzido e resolvido em teste.Próximo passo: A documentação oficial de NUI callbacks traz exemplos em Lua, JavaScript e C#. Conteúdo revisado pela FiveMDEV. Faça backup antes de alterar uma cidade em produção. Exemplos práticosOs dois nomes abaixo devem ser iguais. E o callback Lua sempre responde, inclusive em um caso de erro. fetch(`[Conteúdo oculto]()}/getPlayerInfo`, { method: 'POST', headers: { 'Content-Type': 'application/json; charset=UTF-8' }, body: JSON.stringify({}) }) .then((response) => response.json()) .then((data) => console.log(data));RegisterNUICallback('getPlayerInfo', function(_, cb) local playerId = PlayerId() if not playerId then cb({ ok = false, error = 'Jogador indisponível' }) return end cb({ ok = true, id = GetPlayerServerId(playerId) }) end)

O banco sustenta personagens, inventário, economia e permissões. Trate qualquer alteração como migração: saiba o que muda, faça backup e valide em cópia antes de executar em produção. Antes de começarAcesso limitado ao banco correto.Backup recente e testado.Arquivo SQL e documentação do resource que será instalado.Passo a passoConfirme host, porta, nome do banco e usuário sem expor a senha em prints ou repositórios.Crie uma cópia de teste do banco de produção ou use base limpa para validar o SQL.Leia o SQL: identifique tabelas criadas, colunas alteradas, chaves e possíveis comandos destrutivos.Execute a migração uma vez, valide logs do oxmysql e teste criação de personagem, salvamento e compra.Crie índices apenas quando uma consulta medida justificar; índices em excesso também têm custo.Documente versão do schema e data da alteração para facilitar rollback.Erros comuns e cuidadosNão abra MySQL publicamente para “resolver” conexão remota. Prefira rede privada, firewall e usuários restritos.Não use a conta root da base para resources.Não apague tabelas de produção para reaplicar um SQL sem backup.Checklist finalBackup criado e restauração testada.SQL revisado em teste.Usuário do banco tem privilégios mínimos.Console sem falha de conexão.Migração registrada.Próximo passo: Se o script não inicia, volte ao guia de instalação e confira se banco, resource e dependências são da mesma versão. Conteúdo revisado pela FiveMDEV. Faça backup antes de alterar uma cidade em produção. Exemplos práticosCrie tabelas com chave primária e use parâmetros na consulta. Não concatene valores recebidos do jogador dentro do SQL. CREATE TABLE IF NOT EXISTS player_preferences ( citizen_id VARCHAR(64) NOT NULL, music_enabled TINYINT(1) NOT NULL DEFAULT 1, updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (citizen_id) );local rows = MySQL.query.await( 'SELECT music_enabled FROM player_preferences WHERE citizen_id = ?', { citizenId } ) local enabled = rows[1] and rows[1].music_enabled == 1

Mapas exigem organização. MLO, YMAP e YTYP não são intercambiáveis: cada asset pode pedir stream, manifest ou ordem própria. O método abaixo facilita voltar atrás se algo falhar. Antes de começarBackup do resource de mapas e da configuração atual.Arquivo obtido de fonte autorizada, com instruções e dependências.Servidor de teste para validar colisão, interior e streaming.Passo a passoCrie uma pasta exclusiva para o mapa em resources/[maps] ou na convenção já usada pela cidade.Mantenha arquivos de streaming dentro de stream quando essa for a estrutura indicada pelo autor.Crie ou revise o fxmanifest.lua e inclua apenas as declarações de dados solicitadas pelo resource.Inicie o mapa após suas dependências e faça uma reinicialização completa.Visite a área em jogo, teste colisões, portas, interior, noite e distância de visão.Se houver textura invisível ou crash, remova o último mapa adicionado e leia a primeira mensagem relevante no console antes de trocar arquivos aleatoriamente.Erros comuns e cuidadosNão substitua arquivos de outro mapa sem backup; conflitos de nomes e IPLs são comuns.Não misture versões de GTA/FiveM ou assets de procedência incerta.Evite carregar packs gigantes sem medir impacto de streaming e memória.Checklist finalMapa carrega após restart.Sem erro de data file no console.Colisão e interior testados.Desempenho avaliado em área movimentada.Plano de reversão disponível.Próximo passo: Use o guia de manifest como referência e consulte os downloads de mapas da FiveMDEV para encontrar assets com informações de compatibilidade. Conteúdo revisado pela FiveMDEV. Faça backup antes de alterar uma cidade em produção. Exemplos práticosUm YTYP normalmente precisa ser declarado como data file. Use o nome do arquivo real do mapa; não copie esta estrutura sem conferir a documentação do asset. -- resources/[maps]/meu-mapa/fxmanifest.lua fx_version 'cerulean' game 'gta5' files { 'stream/meu_interior.ytyp' } data_file 'DLC_ITYP_REQUEST' 'stream/meu_interior.ytyp'# server.cfg ensure meu-mapa

Segurança é uma rotina de redução de risco. O objetivo não é prometer invulnerabilidade, e sim impedir que um script, uma permissão excessiva ou uma credencial exposta comprometa toda a cidade. Antes de começarInventário de administradores, scripts e integrações externas.Backup recuperável de arquivos e banco.Uma instância de teste para verificar atualizações e novos resources.Passo a passoDê a cada administrador somente a permissão necessária; contas que moderam jogadores não precisam editar configurações ou executar comandos arbitrários.Proteja txAdmin com senha exclusiva, revise periodicamente os admins e remova acessos antigos.Valide dinheiro, inventário, permissões e recompensas no servidor. Dados recebidos do cliente devem ser tratados como não confiáveis.Mantenha artifacts e dependências atualizados após testar em ambiente separado.Instale scripts apenas de fontes confiáveis, revise arquivos de configuração e examine chamadas externas inesperadas.Faça backup automatizado, teste restauração e guarde uma cópia fora do servidor principal.Registre quem alterou uma configuração crítica e quando.Erros comuns e cuidadosNão publique tokens de Discord, chaves de API, senhas ou dumps de banco.Não execute recursos ofuscados ou sem origem em produção sem revisão.Não conceda permissões globais por conveniência a toda a equipe.Checklist finalPermissões revisadas.Segredos removidos de arquivos públicos.Backup restaurado em teste.Scripts novos aprovados antes da produção.Logs e responsáveis definidos.Próximo passo: No txAdmin, use papéis granulares: a documentação de permissões detalha o que cada acesso permite. Conteúdo revisado pela FiveMDEV. Faça backup antes de alterar uma cidade em produção. Exemplos práticosO cliente nunca deve decidir sozinho saldo, permissão ou recompensa. Valide a ação no servidor e retorne cedo quando a regra falhar. RegisterNetEvent('cidade:resgatarRecompensa', function() local source = source local reward = 500 if not jogadorPodeResgatar(source) then print(('Tentativa bloqueada: %s'):format(source)) return end -- Credite usando a função do seu framework, somente após validar. entregarRecompensa(source, reward) end)

Otimização começa por medir. Remover scripts aleatoriamente pode mascarar o problema e quebrar funções da cidade. Use uma cópia de teste, registre os números e mude uma causa de cada vez. Antes de começarAcesso ao console e ao txAdmin.Período de teste com cenário reproduzível: mesma área, quantidade de jogadores e recursos.Backup antes de atualizar artifact, banco ou framework.Passo a passoAbra o monitor de resources com resmon e anote os maiores consumos em repouso e durante ações pesadas.Separe o diagnóstico entre cliente, servidor, banco e streaming de assets; um FPS baixo no cliente não prova sozinho que o banco está lento.Verifique loops frequentes, consultas repetidas e envio excessivo de dados antes de “otimizar” valores no escuro.Teste OneSync e as opções suportadas pela sua base, observando entidades, população e sincronização após cada alteração.Reduza imagens e texturas desnecessárias, mantenha mapas e veículos sob controle e valide o carregamento em máquinas comuns.Meça novamente após cada mudança e mantenha apenas a alteração que melhora o resultado sem regressão.Erros comuns e cuidadosNão desligue OneSync ou culling apenas para esconder um bug; valide impacto em entidades e jogadores distantes.Não use números milagrosos de ms como regra absoluta: compare o comportamento real da sua cidade.Uma reinicialização programada não corrige vazamento, consulta ruim ou resource quebrado.Checklist finalMedição antes e depois salva.Resources pesados identificados.Erros de console tratados.Cidade testada com jogadores e veículos.Backup preservado.Próximo passo: A lista atual de comandos e variáveis do servidor está na documentação Cfx. Conteúdo revisado pela FiveMDEV. Faça backup antes de alterar uma cidade em produção. Exemplos práticosUse espera variável em loops. O exemplo abaixo consulta a distância com menor frequência quando o jogador está longe, em vez de rodar trabalho pesado a cada frame. CreateThread(function() while true do local wait = 1000 local ped = PlayerPedId() local distance = #(GetEntityCoords(ped) - vector3(215.0, -810.0, 30.0)) if distance < 20.0 then wait = 0 -- desenhe ou habilite apenas o que for necessário perto do local end Wait(wait) end end)# server.cfg - altere somente após testar onesync on set onesync_enableInfinity true

A maioria dos erros de instalação acontece antes de o código do script ser executado: pasta errada, manifest ausente, dependência não iniciada ou SQL não importado. Esta rotina reduz tentativa e erro. Antes de começarBackup da cidade e do banco antes de mexer em produção.Arquivo original do resource e instruções do autor.Acesso ao console do servidor e ao banco de teste, quando houver SQL.Passo a passoLeia o README e identifique framework, versão, dependências, SQL e configuração.Extraia o resource em uma pasta única dentro de resources/[local]; não deixe uma pasta dentro de outra com o mesmo nome.Confirme que existe fxmanifest.lua. Ele declara o que o FiveM deve carregar.Instale e inicie as dependências antes do resource principal no server.cfg.Importe o SQL somente no banco correto e revise nomes de tabelas para não sobrescrever dados.Adicione ensure nome-do-resource, reinicie e leia o primeiro erro do console, sem ignorar mensagens anteriores.Teste com uma conta comum, uma conta staff e reinicialização completa.Erros comuns e cuidadosNunca cole uma chave, webhook ou credencial recebida junto com script sem entender onde ela será usada.Não use start e ensure misturados sem motivo; padronize o projeto.O manifest antigo __resource.lua é legado; prefira fxmanifest.lua quando o autor suportar.Checklist finalPasta e manifest conferidos.Dependências iniciam primeiro.SQL validado em ambiente de teste.Console sem erro do resource.Fluxo principal testado dentro do jogo.Próximo passo: A referência do fxmanifest.lua explica as entradas reconhecidas pelo FiveM. Conteúdo revisado pela FiveMDEV. Faça backup antes de alterar uma cidade em produção. Exemplos práticosExemplo de resource Lua simples. O manifest declara os arquivos; o server.cfg garante a ordem de início. -- resources/[local]/meu-resource/fxmanifest.lua fx_version 'cerulean' game 'gta5' author 'Sua equipe' description 'Resource local de exemplo' version '1.0.0' shared_script 'config.lua' client_script 'client.lua' server_script 'server.lua'# server.cfg ensure oxmysql ensure qb-core ensure meu-resource

Não existe um framework universalmente melhor. A escolha correta depende dos scripts que você precisa, da experiência da equipe e da capacidade de manter atualizações. Decida antes de comprar ou instalar dezenas de resources. Antes de começarUma lista do que a cidade realmente precisa: economia, empregos, inventário, telefone, organizações e administração.Tempo para testar uma base vazia antes da abertura.Critério para aceitar scripts: origem, documentação, atualização e suporte.Passo a passoListe os recursos indispensáveis e a compatibilidade de cada um.Compare a documentação e a atividade da comunidade do framework, não apenas o visual de uma cidade de demonstração.Para vRP e Creative, confirme a versão exata da base: scripts de versões diferentes podem não conversar entre si.Para QBCore, Qbox e ESX, confirme exports, dependências e versões de banco esperadas pelo script.Monte uma instância de teste e instale os três resources mais críticos antes de migrar a cidade inteira.Registre a decisão, a versão e as alterações locais em um changelog.Erros comuns e cuidadosNão misture arquivos de dois frameworks tentando “adaptar depois”; trate cada adaptação como desenvolvimento e teste.Compatível não significa pronto: leia instalação, SQL e dependências.Evite uma base sem procedência ou sem documentação, mesmo que pareça completa.Checklist finalFramework e versão documentados.Recursos essenciais testados.Banco criado em ambiente de teste.Plano de backup e atualização definido.Próximo passo: Com a base escolhida, siga o guia de instalação de resources para manter o server.cfg previsível. Conteúdo revisado pela FiveMDEV. Faça backup antes de alterar uma cidade em produção. Exemplos práticosAntes de instalar um resource, documente a escolha e as dependências. Este exemplo evita que a equipe misture bases por acidente. -- resources/[local]/cidade-config/config.lua Config = {} Config.Framework = 'qbcore' -- defina uma única base por ambiente Config.RequiredResources = { 'oxmysql', 'qb-core', 'meu-resource' }

Este guia cria uma base limpa para testes ou para o início de uma cidade. Comece com a receita oficial do txAdmin; instalar uma base completa antes de validar o servidor dificulta descobrir a origem de um erro. Antes de começarUma conta Cfx.re para vincular o txAdmin e gerar a chave do servidor.Windows ou Linux com acesso de administrador.Uma pasta exclusiva para o FXServer; não misture arquivos antigos e novos.Passo a passoBaixe o artifact recommended no portal oficial e extraia-o em uma pasta dedicada.Execute o FXServer sem argumentos. O txAdmin já acompanha o FXServer e deve abrir no navegador.Informe o PIN exibido no console, vincule a conta Cfx e proteja o painel com uma senha forte.No Recipe Deployer, use inicialmente a receita CFX Default FiveM. Ela confirma que rede, chave e artifact funcionam antes de introduzir um framework.Guarde o server.cfg no versionamento ou em backup e altere uma configuração por vez.Conclua com Save & Run Server e teste a entrada de um jogador antes de instalar scripts.Erros comuns e cuidadosNão publique a chave Cfx, senha do txAdmin ou dados do banco em Discord, prints ou repositórios.Não abra o painel txAdmin para a internet sem restringir acesso e permissões.Se a receita pedir banco de dados, não reutilize uma base de produção para testes.Checklist finalServidor inicia sem erros críticos.Uma conta consegue conectar.A chave Cfx não está exposta.Existe backup inicial de server.cfg e da pasta txData.Próximo passo: Depois da base estável, escolha um framework e instale o primeiro resource em resources/[local]. Consulte também a documentação oficial do txAdmin. Conteúdo revisado pela FiveMDEV. Faça backup antes de alterar uma cidade em produção. Exemplos práticosUse este server.cfg mínimo apenas como ponto de partida. Ajuste a chave e o nome antes de iniciar. # server.cfg endpoint_add_tcp "0.0.0.0:30120" endpoint_add_udp "0.0.0.0:30120" sv_hostname "Minha Cidade - Teste" sv_licenseKey "SUA_CHAVE_CFX_AQUI" ensure mapmanager ensure chat ensure spawnmanager ensure sessionmanager ensure hardcap rcon_password "TROQUE_POR_UMA_SENHA_FORTE"

Visualizar Arquivos PRAÇA EXPANSÃO COMPLETA V3 COM POSTO PRAÇA EXPANSÃO COMPLETA V3 COM POSTO GTA RP FIVEM Autor Hideki Enviado 23/09/2026 Categoria Fivem Gráficos, Mapas, Props Tipo MAP / MLO Encriptado NÃO Créditos Exclusivo FivemDEV