Converta um recurso FiveM mapeando suas depend\u00eancias de framework, invent\u00e1rio e banco de dados, e ent\u00e3o testando um fluxo de jogo por vez. Renomear eventos ESX para eventos QBCore n\u00e3o \u00e9 uma convers\u00e3o completa. Uma migra\u00e7\u00e3o de personagem em todo o servidor \u00e9 um projeto separado.<\/p>\n
Trabalhe em um servidor de desenvolvimento isolado com uma c\u00f3pia do recurso e um banco de dados descart\u00e1vel. Registre as vers\u00f5es exatas do framework de origem e destino, invent\u00e1rio, biblioteca de direcionamento, biblioteca de UI e licen\u00e7a do recurso. Arquivos protegidos exigem uma vers\u00e3o suportada do autor; a configura\u00e7\u00e3o edit\u00e1vel sozinha pode n\u00e3o ser suficiente.<\/p>\n
Pesquise os arquivos de recurso por Por exemplo, um fluxo de loja inclui abrir sua UI, verificar o acesso, ler pre\u00e7os, efetuar pagamento, adicionar invent\u00e1rio e salvar o resultado. Converter apenas sua notifica\u00e7\u00e3o deixa o comportamento importante inalterado.<\/p>\n Resolva o jogador do framework de destino no servidor no momento da a\u00e7\u00e3o. Identificadores ESX e IDs de personagem QBCore\/Qbox t\u00eam significados diferentes; n\u00e3o gere IDs de personagem a partir de hashes truncados ou sobrescreva identificadores de conta. Mantenha um mapeamento revisado quando os dados existentes precisarem ser movidos.<\/p>\n Escolha a integra\u00e7\u00e3o de invent\u00e1rio de forma deliberada. Nomes de itens, unidades de peso, tratamento de slots, metadados e verifica\u00e7\u00f5es de capacidade variam. N\u00e3o alterne silenciosamente para outro sistema de invent\u00e1rio em caso de falha. Defina a correspond\u00eancia de dinheiro em esp\u00e9cie, saldos banc\u00e1rios e eventuais moedas il\u00edcitas sem tratar contas distintas como equivalentes.<\/p>\n Mantenha as chamadas de jogador, trabalho, dinheiro e invent\u00e1rio espec\u00edficas do framework em um m\u00f3dulo apenas do servidor. Notifica\u00e7\u00f5es do cliente e callbacks da UI pertencem a um m\u00f3dulo cliente separado. Declare as depend\u00eancias reais em Para Qbox, consulte os exports do servidor<\/a> e suas diretrizes de compatibilidade. Uma ponte de compatibilidade pode ajudar recursos QB existentes, mas n\u00e3o garante compatibilidade com todos os invent\u00e1rios, consultas de banco de dados ou core modificado.<\/p>\n O servidor deve determinar itens permitidos, pre\u00e7os, saldos, permiss\u00f5es de trabalho e conclus\u00e3o de tarefas recompensadas. Trate cada argumento de evento do cliente como n\u00e3o confi\u00e1vel. Um nome de trabalho sozinho n\u00e3o prova que uma entrega ocorreu; um evento repetido n\u00e3o deve pagar repetidamente. Verifique os resultados de d\u00e9bito e entrega de itens, e defina a compensa\u00e7\u00e3o quando a segunda a\u00e7\u00e3o falhar.<\/p>\n Compare os esquemas instalados de origem e destino antes de escrever uma migra\u00e7\u00e3o. Use um script separado e versionado para esses esquemas exatos. Preserve os identificadores originais, placas, metadados e uma tabela persistente de correspond\u00eancias. Informe linhas duplicadas ou sem correspond\u00eancia em vez de ignor\u00e1-las. N\u00e3o altere via SQL saldos gerenciados pelo framework enquanto estiverem carregados na mem\u00f3ria dele.<\/p>\n Um export ausente geralmente aponta para o recurso\/vers\u00e3o ou ordem de in\u00edcio errados. Um callback que nunca retorna precisa de inspe\u00e7\u00e3o tanto do registro quanto da invoca\u00e7\u00e3o, incluindo argumentos e lado da execu\u00e7\u00e3o. Itens ausentes podem refletir metadados de invent\u00e1rio ou regras de capacidade. Diagnostique o limite de falha em vez de adicionar shims de compatibilidade amplos.<\/p>\n Cfx.re \u2014 manifesto de recurso<\/a> \u00b7 Cfx.re \u2014 seguran\u00e7a do servidor<\/a><\/p>\nESX<\/code>, QBCore<\/code>, qbx_core<\/code>, exports<\/code>, RegisterNetEvent<\/code>, MySQL<\/code> e nomes de tabelas SQL. Classifique cada correspond\u00eancia como servidor, cliente ou compartilhada. Liste as entradas esperadas, valores de retorno e comportamento de falha antes de substitu\u00ed-los.<\/p>\n2. Mapeie o comportamento explicitamente<\/h2>\n
3. Implemente um pequeno adaptador<\/h2>\n
fxmanifest.lua<\/code> e inicie-as antes do recurso.<\/p>\n4. Preserve o limite de confian\u00e7a<\/h2>\n
5. Converta o armazenamento de propriedade do recurso<\/h2>\n
6. Verifique e libere<\/h2>\n
\n
Se a convers\u00e3o falhar<\/h2>\n
Documenta\u00e7\u00e3o de refer\u00eancia<\/h2>\n