Um resource pack pode aplicar identidade visual, sons, fontes e texturas a um servidor. No multiplayer, o servidor envia uma URL ao cliente, que pode aceitar ou recusar conforme a configuração. Um pacote obrigatório pode bloquear a entrada de quem não consegue baixá-lo; por isso, publique um ZIP acessível, confira o hash e teste atualização antes de exigir aceitação.

O Paper expõe opções em server.properties para configurar URL, SHA-1, prompt e exigência. Versões modernas também permitem conjuntos de pacotes empilhados por meio das APIs Adventure. Escolha o mecanismo adequado ao seu fluxo e consulte a documentação correspondente à versão usada.

Prepare o arquivo certo

Valide a estrutura do ZIP e a compatibilidade com as versões de cliente suportadas. Um arquivo corrompido, grande demais ou montado com pastas aninhadas incorretas pode falhar ao carregar. Teste numa instalação limpa do cliente e compare resultado com clientes já conectados, pois cache antigo pode esconder um arquivo diferente.

Use uma URL que o cliente consiga baixar diretamente por HTTPS sem página de login, redirecionamento interativo ou expiração breve. Teste a resposta sem depender da conta administrativa. A hospedagem do arquivo precisa estar disponível mesmo quando o servidor Minecraft está sob manutenção, para que o teste de aceitação não falhe por indisponibilidade separada.

Calcule e configure o SHA-1

O hash SHA-1 deve corresponder aos bytes exatos do arquivo ZIP publicado. Calcule depois da versão final, copie o valor hexadecimal e confira comprimento e ausência de espaços. Se alterar qualquer arquivo dentro do pacote e gerar ZIP novo, calcule novamente: manter o hash antigo pode impedir verificação ou atualização previsível.

Defina o valor correspondente em resource-pack-sha1 quando usa essa propriedade. O cliente pode comparar a integridade com o hash informado. Guarde uma cópia da combinação validada de URL e hash, junto com a versão visual do pack, para que rollback seja possível.

Decida se o pacote é opcional ou obrigatório

Deixar o pacote opcional permite ao jogador recusar e ainda entrar, quando a configuração permite. Torná-lo obrigatório comunica que a experiência do servidor depende dele, mas eleva o impacto de qualquer problema de hospedagem ou compatibilidade. Pese esse requisito antes de ligar a propriedade correspondente.

Se obrigatório, publique instruções claras e um canal de suporte para clientes que recebem erro. Teste recusa, falha de download e reconexão depois de aceitar. Evite que jogadores fiquem presos sem mensagem compreensível. Para pacote opcional, explique recursos que ficam ausentes para que a diferença visual não pareça bug.

Planeje mudanças sem cache confuso

Para trocar arquivo, publique a versão nova em endereço estável somente quando pronta e atualize o hash ao mesmo tempo. Alguns clientes podem preservar cache ou decisão de recusa; teste com sessão limpa, reconexão e versão de cliente suportada. Se precisa disponibilizar rollout gradual, mantenha uma cópia do pack antigo e o caminho de restauração.

Não sobrescreva ZIP durante download e não use endereço temporário de compartilhamento. O arquivo deve permanecer acessível de forma consistente. Em setups modernos com vários pacotes, UUID identifica recurso e chamadas do servidor podem empilhar ou remover pacotes; documente a ordem porque elementos podem substituir recursos anteriores.

Teste em conexão real

Reinicie o servidor quando a alteração exigir arquivo lido no início e confira logs. Conecte clientes representativos e observe prompt, progresso, resultado e eventual desconexão. Teste pelo endereço e porta que a comunidade usa, não somente dentro da mesma máquina onde o ZIP está publicado.

Confirme texturas, sons e menus nas áreas do jogo que dependem do pack. Uma transferência concluída não prova que todos os recursos estão corretos. Avalie tempo de download em rede lenta e tamanho do pacote para reduzir barreira de entrada.

Diagnostique falhas pelo passo certo

Se o cliente não iniciar o download, confirme se URL chega ao cliente e se servidor enviou configuração. Se baixa mas rejeita, confira ZIP, hash e compatibilidade. Se o jogador conecta sem recursos, revise se o pack era obrigatório e se a resposta do cliente chegou; status pode divergir entre clientes modificados.

Use log do servidor e ferramenta de navegador para confirmar status HTTP, tamanho e hash. Não publique URL privada ou token de acesso em suporte. Se uma CDN estiver envolvida, invalide cache somente depois que o arquivo novo estiver pronto e confira que cada ponto de distribuição entrega os mesmos bytes.

Tenha fallback e mantenha documentação

Antes de exigir novo pack, decida como voltar à versão anterior e quem pode alterar essa opção. Se o ZIP ficar indisponível, remover temporariamente a obrigatoriedade pode restaurar acesso enquanto a causa é corrigida, mas isso muda a experiência; comunique a equipe e teste comportamento sem o pack.

Registre URL, hash, tamanho, UUID, versões testadas, política de aceitação e resultado de download. A referência oficial do Paper descreve resource packs e identificação por UUID/URL/hash. Consulte também as opções de server.properties e confirme estrutura geral em configuration.

Planeje compatibilidade com clientes modificados

Clientes modificados podem enviar respostas de status diferentes ou não enviar retorno esperado. Não baseie ação crítica unicamente numa confirmação do cliente. Faça validação visual e funcional com usuários de teste e trate falhas de download como experiência recuperável quando o pack não é obrigatório.

Para pacote obrigatório, mantenha um plano temporário de acesso durante indisponibilidade, com responsável e comunicação definidos. Reative a exigência depois de o ZIP, hash e download passarem novamente; registre qual arquivo foi verificado para que CDN e servidor não sirvam versões diferentes.

Registre publicação e fallback

Controle a versão do resource pack com um nome, data e hash em registro interno. Antes de publicar versão nova, teste link num cliente limpo e confira o mesmo SHA-1 que será configurado. Se houver erro, restaure ZIP anterior e hash correspondente como par, pois apontar para pacote antigo com digest novo mantém a falha.

Evite colocar credenciais ou dados sensíveis no pacote

Verifique o conteúdo do ZIP antes de publicá-lo: arquivos de desenvolvimento, caminhos locais, chaves de API e documentos internos não pertencem ao resource pack. O cliente recebe os arquivos e pode inspecioná-los. Mantenha fontes licenciadas e créditos fora de pastas que o cliente precisa carregar, e confirme direitos de uso antes da distribuição pública.

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.