escrow_ignore no fxmanifest: mantenha config.lua e locales abertos

Você vende scripts, e compradores precisam alterar uma configuração, um arquivo de idioma ou uma ponte de framework sem tocar no seu código principal. O escrow de ativos do Cfx.re encripta Lua por padrão, então os arquivos que compradores devem editar têm que ser marcados como abertos. É isso que escrow_ignore faz, e este guia cobre usá-lo e testar o resultado.

#O que o escrow encripta

Quando você faz upload de um recurso para o sistema de escrow, seus scripts de cliente e servidor Lua são encriptados. Compradores os executam, mas não podem lê-los. Arquivos que não são código Lua, como páginas NUI, imagens, áudio, modelos e ativos stream/, são entregues como estão.

Qualquer coisa que um comprador precise configurar tem que permanecer legível. Se você encriptar config.lua, ninguém pode alterar seus preços ou chaves. Então você pede ao escrow para pular.

#A sintaxe escrow_ignore

No fxmanifest.lua:

fx_version 'cerulean'
game 'gta5'

shared_script 'config.lua'
client_script 'client/main.lua'
server_script 'server/main.lua'

escrow_ignore {
    'config.lua',
    'locales/*.lua',
    'bridge/*.lua',
}

Os caminhos são relativos à pasta do recurso, e * funciona como um curinga, então locales/*.lua deixa cada arquivo Lua em locales/ aberto. Você também pode listar arquivos individuais.

#O que permanece legível

Seja deliberado sobre o que você abre. Bons candidatos:

• config.lua: preços, empregos, nomes de itens, atalhos de teclado, alternadores de recursos.
• Arquivos de localização: para que compradores possam traduzir. Veja scripts traduzíveis.
• Arquivos ponte de framework: pequenos adaptadores para ESX, QBCore e QBox, para que compradores possam conectar seu próprio framework ou inventário personalizado.
• Hooks do lado do cliente para outros scripts, como um arquivo que dispara uma notificação ou um alerta de polícia.

Mantenha fechado tudo que é o núcleo do produto: lógica, validação, qualquer coisa que decida sobre dinheiro ou itens. Lembre-se de que arquivos abertos também estão abertos para cópia: um comprador pode colar sua configuração ou ponte no recurso de outra pessoa, então não coloque lógica valiosa neles.

Dica: cada arquivo aberto é um ônus de suporte. Um comprador que o edita mal escreverá para você sobre isso, então mantenha arquivos abertos pequenos e bem comentados.

#Upload para o portal Cfx.re

O escrow funciona através de sua conta Cfx.re:

1. Prepare a pasta do recurso com um fxmanifest.lua válido (não um __resource.lua antigo; veja fxmanifest vs resource.lua).
2. No portal Cfx.re, abra a seção de ativos e faça upload do recurso como um ativo de escrow. O portal encripta os arquivos que não estão em escrow_ignore e mantém o resto legível.
3. Vincule o ativo à sua loja, para que uma compra dê ao comprador acesso. Veja vendendo scripts FiveM para o lado da loja.

Os menus do portal mudam de vez em quando, então siga a documentação atual do Cfx.re para as etapas exatas de upload e limites.

#Teste a compilação em escrow

Nunca envie o que você testou apenas em sua pasta de desenvolvimento. Após o upload:

1. Faça download da versão em escrow de volta do portal, do jeito que um comprador a receberia.
2. Coloque-a em um servidor de teste limpo com sua própria chave de licença vinculada à conta que possui o ativo.
3. Inicie-a e percorra o fluxo: os arquivos abertos são carregados, as alterações de configuração se aplicam, eventos de cliente e servidor disparam.
4. Altere um valor em config.lua e reinicie para confirmar que o arquivo aberto é realmente capturado.
5. Teste em um segundo framework se você suportar mais de um.

Se o recurso não iniciar com uma mensagem de direito, o servidor de teste não está usando a chave de uma conta que possui o ativo. Falta de direito no escrow lista as causas.

#Dependências em arquivos abertos

Quando alguns arquivos estão abertos e o resto encriptado, eles ainda compartilham um recurso e devem funcionar juntos:

• Arquivos abertos podem usar os globals e funções que declaram, normalmente. Mantenha um config.lua que apenas define uma tabela Config, e o código encriptado lê Config.
• A ordem de carregamento é a ordem do manifesto. Uma configuração deve vir antes do código que a lê, então liste-a como um shared_script primeiro, como acima.
• Use exports para comunicação entre seu código e o próprio recurso de um comprador, em vez de contar com globals compartilhadas. Exports são estáveis e documentados; veja exports em Lua.
• Declare dependências (dependency 'ox_lib') no manifesto, para que uma biblioteca ausente dê um erro claro em vez de um nil.

Não abra um arquivo que só funciona junto com um arquivo encriptado que você também alterou na mesma versão. Compradores que editaram o aberto terão que mesclar manualmente.

#Problemas comuns

• Um novo arquivo adicionado, mas ainda encriptado: não foi correspondido por escrow_ignore. Verifique o caminho e o curinga.
• Compradores dizem que a configuração é ilegível: o arquivo foi encriptado no upload. Corrija o manifesto e faça upload novamente.
• Funciona para você, não para o comprador: você testou a cópia de desenvolvimento aberta; teste a compilação de escrow baixada.

#Lista de verificação