A propriedade resource-pack-sha1 em server.properties identifica o hash SHA-1 do arquivo ZIP que o servidor fornece como resource pack. Paper recomenda definir o valor para ajudar clientes a verificar que baixaram o pacote correto. O hash precisa corresponder ao ZIP exato publicado; se o arquivo mudar, é preciso recalcular.
SHA-1 aqui funciona como checksum de integridade contra cache ou arquivo diferente, não como prova criptográfica de confiança, autoria ou ausência de código malicioso. Baixe e distribua recursos apenas de fontes autorizadas, use HTTPS e proteja a conta do CDN ou do host.
Use o arquivo ZIP publicado
Gere o hash depois de finalizar e enviar o ZIP. Não calcule sobre a pasta de origem nem sobre um arquivo que será recomprimido depois. A compactação pode alterar os bytes mesmo quando o conteúdo extraído é igual, produzindo hash diferente.
Confirme que a URL retorna o arquivo, e não uma página HTML de erro, autenticação ou redirect não suportado. Verifique status, tipo de conteúdo, tamanho e acesso sem cookies. Uma mensagem do host pode ser salva com extensão ZIP e impedir a verificação dos clientes.
Guarde o artefato exato, seu nome de versão e o hash em changelog. Isso permite comparar o que foi publicado se o servidor enviar versão antiga por cache. Evite sobrescrever a mesma URL sem invalidar caches quando jogadores já baixaram um pacote anterior.
Calcule em cada sistema com cuidado
Em Linux, ferramentas como sha1sum arquivo.zip costumam mostrar hash e nome do arquivo. No macOS há comando equivalente no sistema. Em Windows, PowerShell fornece Get-FileHash -Algorithm SHA1. Use o valor hexadecimal da saída, sem o nome do arquivo nem espaços adicionais.
Compare o hash local ao hash do arquivo servido via URL, baixando uma cópia por HTTPS e calculando sobre ela. Isso confirma que CDN ou proxy de cache está entregando os mesmos bytes. Faça a comparação depois de cada troca e antes de editar `server.properties`.
Não inclua hash de exemplo fixo em tutorial ou script que será copiado para outros pacotes. Cada arquivo produz um valor diferente. Automatize geração no pipeline de publicação e revise se o artefato realmente corresponde à versão aprovada.
Atualize URL e hash em conjunto
Ao publicar novo ZIP, atualize URL e hash como uma unidade. Se usa mesmo endereço, um cache intermediário pode devolver conteúdo antigo; use URL versionada, invalide cache e mantenha a anterior durante a transição. O cliente pode armazenar o pacote e depender do UUID ou versão conforme o fluxo de resource pack.
Em versões de Minecraft que permitem múltiplos pacotes empilhados e UUIDs, considere os identificadores e respostas conforme o protocolo atual. A documentação Paper/Adventure descreve a evolução e os elementos do recurso. Não reduza todo o processo ao campo antigo se sua versão e plugin usam API moderna.
Depois da mudança, teste cliente limpo, cliente que baixou pacote anterior e conexão via versões suportadas. Confira nome, modelo, som, fonte e textos. Se o hash não corresponde, o cliente pode rejeitar ou solicitar download novamente, causando fricção de entrada.
Diagnostique download inconsistente
Se um cliente reporta pacote inválido, verifique horário e versão, URL que recebeu, hash configurado e log HTTP do host. Confirme redirecionamentos, TLS, range requests se usados, tamanho e espaço em disco no dispositivo. Repita em uma rede diferente para separar problema do CDN e da conexão local.
Compare o hash do arquivo baixado pelo cliente ou de uma cópia acessada pela mesma URL. Se diferir do local, verifique deploy parcial, cache, CDN e replicação. Se hashes coincidem, investigue estrutura do pack e compatibilidade de assets com versão do Minecraft.
Evite mandar jogadores desabilitarem verificação ou executarem programas externos. Se a URL foi comprometida, retire o arquivo, revise credenciais e publique versão segura. Hash não corrige recurso malicioso; controle quem publica e audite o pipeline.
Faça deploy reversível
Guarde cópia de server.properties, artefato atual e hash antes de alteração. Faça upload para caminho versionado e valide em staging. Atualize URL e hash juntos e reinicie conforme a versão exigir. Mantenha arquivo anterior até confirmar adoção e compatibilidade da comunidade.
Monitore erros, taxa de recusa, downloads e tickets logo após o rollout. Se muitos clientes falham, reverta à URL anterior conhecida e analise caches antes de gerar outro ZIP. Registre a transição para evitar voltar a um hash que corresponda a um arquivo removido.
Uma alteração sem versão torna rollback ambíguo. Nomeie versões com data ou release, guarde artefato imutável e mantenha um registro de hashes. Assim, suporte pode confirmar exatamente qual ZIP o jogador recebeu.
Cuide de licenças e confiança
Resource packs podem incluir texturas, sons, fontes e modelos de outros autores. Verifique licença, atribuição e permissão para hospedar e redistribuir cada item. Um checksum idêntico não demonstra que há autorização de uso.
Prefira HTTPS e controle de acesso ao painel de publicação. Use conta separada e autenticação forte. Revogue acesso de colaboradores que saem e faça rotação de credenciais se houver exposição.
O hash é uma etapa pequena de uma cadeia de publicação confiável: fonte autorizada, build revisado, upload completo, valor recalculado e teste em cliente. Conservar evidência de cada etapa reduz erros e facilita uma recuperação rápida.
Organize versionamento e cache
Prefira nomes de artefato com número de versão e URL imutável em vez de sobrescrever repetidamente pack.zip. Se precisa manter um endereço fixo, use controle de cache adequado no host e teste a resposta após invalidação. Um proxy de cache atrasado pode servir bytes antigos mesmo que o painel mostre upload concluído.
Registre a data de publicação, hash e sistema de origem. Guarde uma cópia aprovada e outra de trabalho separadas. Se um designer envia versão nova, valide a diferença antes de substituir; uma alteração simples em textura pode mudar hash e afetar todos os jogadores na próxima conexão.
Planeje limpeza das versões antigas sem quebrar servidores de teste ou clientes que ainda precisam delas. Após encerrar a transição, retire URLs obsoletas e revogue acessos temporários ao host.
Automatize sem esconder falhas
Um pipeline de publicação pode calcular o SHA-1 e exibir junto ao artefato. Faça o processo falhar se o upload estiver incompleto, a URL responder com código incorreto ou o hash remoto divergir do local. Uma verificação automática só é útil se seu resultado for revisado e não marcar erro como sucesso.
Não guarde credenciais do CDN em repositório ou log de build. Use conta com acesso limitado ao diretório de resource packs, autenticação forte e rotação. A automação de publicação não deve ter privilégios no console do servidor ou nos dados de jogadores.
Após publicar, faça teste manual em cliente suportado e monitore os primeiros relatos. Automação verifica bits e resposta HTTP, mas não comprova que pack carrega corretamente ou que conteúdo é legível e licenciado.
Fontes e referências
Documentação consultada em 2026-10-08. Os exemplos precisam ser conferidos na versão instalada; este guia não afirma que a configuração foi testada no seu ambiente.