Perguntas frequentes sobre o ResourcePackManager

Se não encontrar a resposta aqui, consulte primeiro as restantes páginas do ResourcePackManager na barra lateral.

Que comandos estão disponíveis?

No backend Paper/Spigot:

• /rspm setup: abre o menu de instalação no jogo, com estado das atualizações, plugins recomendados, opção de atualizações automáticas e ligações para a wiki, Discord e conta Nightbreak.
• /rspm recommendedplugins: apresenta o menu partilhado de plugins recomendados, ou uma lista na consola.
• /rspm downloadpluginupdate: transfere uma atualização disponível para o próximo reinício.
• /rspm downloadall: transfere todas as atualizações disponibilizadas por este plugin, atualmente a do ResourcePackManager.
• /rspm applypluginupdate: faz parte do conjunto partilhado de comandos Nightbreak; o RSPM recusa-o sempre porque as suas atualizações exigem um reinício do servidor (a sua extensão do Geyser só carrega quando o Geyser arranca).
• /rspm reload: reconstrói e volta a alojar o pacote combinado.
• /rspm status: apresenta o diagnóstico completo do pacote, alojamento, impressão digital da chave de rede e integrações.
• /rspm verbose [on|off]: ativa ou desativa o registo detalhado. Sem argumento, alterna. Guarda a escolha em verboseLogging de config.yml, mantendo-a após reinícios. Também aceita /rspm verboselogging.
• /rspm itemsadder configure: configura o ItemsAdder para alojamento através do RSPM.
• /rspm itemsadder dismiss: oculta permanentemente o aviso do ItemsAdder para o UUID do jogador.
• /rspm data_compliance_request: transfere todos os dados do servidor guardados remotamente.

O comando principal é /resourcepackmanager, com /rspm como nome alternativo. Os comandos de atualização e plugins recomendados pertencem ao MagmaCore/Nightbreak e são registados pelo RSPM.

O MagmaCore também regista estes comandos independentes, que não são subcomandos de /rspm:

• /nightbreaklogin <token> e /nightbreaklogout guardam ou removem o token partilhado da conta Nightbreak do servidor. Ambos exigem nightbreak.login (predefinição op). Consulte Ligação de conta Nightbreak.
• /nightbreak plugins permite consultar o catálogo de plugins Nightbreak e exige nightbreak.plugins (predefinição op).
• /logify envia o registo atual do servidor para o mclo.gs e exige logify.* (predefinição op).
• /resourcepackmanagerchangelog [dismiss|disable] mostra aos administradores as notas de versão do ResourcePackManager que ainda não leram. Consulte Notificações de changelog.

O primeiro plugin Nightbreak a carregar regista /nightbreaklogin, /nightbreaklogout, /nightbreak e /logify para todo o servidor.

Permissões do backend:

• /rspm setup e /rspm recommendedplugins exigem resourcepackmanager.setup. /rspm setup só pode ser executado por jogadores, pois abre um inventário gráfico.
• /rspm downloadpluginupdate, /rspm downloadall, /rspm applypluginupdate, /rspm reload, /rspm status, /rspm verbose, /rspm itemsadder <configure|dismiss> e /rspm data_compliance_request exigem resourcepackmanager.*.

No proxy Velocity/BungeeCord, só existem comandos de diagnóstico:

• /rspm status: apresenta os backends, resultados de obtenção, estado do pacote combinado e deteção de Geyser/Floodgate.
• /rspm debug bedrock [on|off]: controla os registos detalhados [RSPM-BedrockDebug] de GeyserBinder, úteis quando um jogador Bedrock entra mas não vê o pacote. Volta a ficar desativado ao reiniciar o proxy. Sem argumento, mostra o estado atual.

Velocity aceita resourcepackmanager.command.status ou resourcepackmanager.*. BungeeCord regista o nó exato resourcepackmanager.command.status, que um plugin de permissões pode satisfazer por expansão de caracteres universais. A consola também pode executar. A saída pode ser partilhada sem revelar a chave ou tokens: apresenta apenas uma impressão digital curta da chave, calculada por hash de sentido único.

Que plugins são suportados?

O ResourcePackManager inclui definições de integração para:

• BackpackPlus
• BetterHUD
• BetterStructures
• CannonRTP
• EliteMobs
• EternalTD
• FreeMinecraftModels
• InfiniteVehicles
• ItemsAdder
• MegaBlockSurvivors
• MMOInventory
• ModelEngine
• Nexo
• Nova
• Oraxen
• RealisticSurvival
• ResurrectionChest
• ValhallaMMO
• vane-core

Cada integração só é aplicada se o plugin estiver instalado e o caminho local ou URL remoto configurado for utilizável.

Cada uma tem um YAML em plugins/ResourcePackManager/compatible_plugins/, onde pode configurar isEnabled, pluginName, localPath, url, zips, cluster, additionalLocalPath e reloadCommand. cluster indica que o caminho local contém várias subpastas de pacotes que devem ser combinadas.

Como excluir uma integração automática?

Defina isEnabled: false no ficheiro da integração em plugins/ResourcePackManager/compatible_plugins/ e execute /rspm reload ou reinicie. O RSPM remove as entradas que gerou ou registou para essa integração, incluindo as cópias geradas no combinador. Retirar o plugin de priorityOrder não o exclui: apenas reduz a sua prioridade ao mínimo. Para excluir um ZIP manual, remova-o ou mova-o para fora de mixer.

É compatível com ItemsAdder?

Sim. Inclui um assistente de configuração e avisos para ItemsAdder.

Se o ItemsAdder precisar de ajustes para usar o alojamento RSPM, os operadores recebem um aviso clicável alguns segundos depois de entrar. Quem o ocultou permanentemente deixa de o receber. Pode:

• Executar /rspm itemsadder configure para definir resource-pack.hosting.no-host.enabled: true, desativar as três opções protect-file-from-unzip, definir compress-json-files: false, executar /iareload e /iazip e aguardar que o RSPM combine a exportação regenerada (indica se a combinação teve sucesso ou falhou; não recarrega o RSPM).
• Executar /rspm itemsadder dismiss para ocultar o aviso permanentemente para o seu UUID.

Se o ItemsAdder já alojar o próprio pacote, o assistente não substitui essa escolha automaticamente. Pede que desative primeiro o alojamento do ItemsAdder.

Posso acrescentar o meu próprio pacote?

Sim. Um .zip completo deve ser colocado em:

plugins/ResourcePackManager/mixer

Para controlar os conflitos de ficheiros, acrescente o nome exato, incluindo .zip, a priorityOrder em plugins/ResourcePackManager/config.yml.

Uma pasta descomprimida, com assets/ e pack.mcmeta, deve ser colocada em:

plugins/ResourcePackManager/resource_pack

O RSPM comprime-a e combina-a sob a entrada ResourcePackManager de priorityOrder. Esta fica no topo por predefinição, pelo que os seus ficheiros prevalecem sobre os pacotes dos plugins. Mova-a para baixo se pretender menor prioridade.

A pasta plugins/ResourcePackManager/blueprint contém pack.png e pack.mcmeta, acrescentados a cada combinação. Edite-os para mudar o ícone ou a descrição no menu. A pasta é novamente comprimida em blueprint.zip em cada arranque.

Exemplo:

priorityOrder:
  - ResourcePackManager
  - EliteMobs
  - MyCustomPack.zip

Como funciona a prioridade?

priorityOrder coloca a prioridade mais alta no topo e a mais baixa no fim.

Nos ficheiros que não podem ser combinados, prevalece o pacote de maior prioridade. Nos JSON combináveis, o ResourcePackManager combina o conteúdo. Atualmente, são combináveis:

• sounds.json.
• Ficheiros de idioma em lang ou languages.
• JSON de modelos normais em minecraft/models/item: só o array overrides é combinado, sem recursão; os restantes campos usam a maior prioridade.
• Ficheiros de atlas.
• Ficheiros de fontes.
• Definições de objetos 1.21.4 ou posteriores em items/, com combinação adaptada ao formato, preservando as árvores de predicados sem misturar indiscriminadamente tipos de nós diferentes.

pack.mcmeta tem regras próprias: prevalece o maior pack_format e os intervalos de formato declarados são combinados. As entradas de sobreposição de pastas diferentes são reunidas; quando a pasta coincide, prevalece a entrada de maior prioridade. Cada sobreposição mantém os valores formats, min_format, max_format e os metadados adicionais definidos pelo autor. A única adição: o Minecraft 1.21.9+ rejeita uma lista de sobreposições em que uma sobreposição chega ao formato de pacote 64 ou inferior e outra não declara formats; por isso, quando uma lista combinada contém uma sobreposição dessas, o RSPM atribui a cada entrada que só declara min_format/max_format um intervalo formats equivalente. Fora disso, o RSPM não reescreve os intervalos das sobreposições. Os campos adicionais de pack, overlays e do objeto principal são preservados quando não entram em conflito com um valor de maior prioridade.

Depois de combinar os pacotes, o RSPM acrescenta as origens do atlas base aos atlas das sobreposições. Isto impede que uma sobreposição esconda entradas base quando é ativada, como pode acontecer com ia_overlay_modern_atlas ou ia_overlay_legacy_atlas do ItemsAdder.

Os restantes JSON são substituídos. Os pacotes ausentes de priorityOrder continuam incluídos, com prioridade mínima.

Os ZIPs completos byte a byte idênticos são deduplicados antes da combinação, preservando a primeira cópia, de maior prioridade. Depois, o RSPM também corrige dois problemas comuns dos modelos Java: acrescenta uma textura particle ausente a partir da primeira textura concreta, quando possível, e limita coordenadas UV inválidas ao intervalo Minecraft 0..16.

Os pacotes são reconstruídos automaticamente quando mudam?

Sim. O RSPM monitoriza as origens suportadas. Após 3 segundos sem alterações, um pacote é considerado estável. Quando todos estabilizam, a combinação começa imediatamente e os operadores ligados recebem uma mensagem a informar que os pacotes estão estáveis e vão ser combinados e enviados.

Se as entradas forem byte a byte idênticas às da combinação anterior, não reconstrói. Guarda a impressão digital da lista ordenada de pacotes — nome, tamanho e hash do conteúdo — em .rspm_mix_fingerprint, junto dos resultados. Se coincidir e todos os resultados esperados existirem, republica o ZIP existente. Um resultado ausente, impressão ilegível ou ZIP combinado cujo SHA-1 já não corresponda desencadeia uma combinação completa. Por isso, /rspm reload sem alterações pode terminar quase imediatamente e reutilizar o alojamento existente.

Quando as entradas Java não mudaram, mas a parte Bedrock tem de ser refeita (conversão Bedrock ativa sem pacote Bedrock em disco, alteração de bedrockConversionEnabled ou do destino Bedrock, ou uma atualização do conversor que altere o resultado Bedrock), o RSPM mantém o ZIP Java verificado e refaz apenas o passo Bedrock, pelo que os bytes e o SHA-1 do pacote Java não mudam.

No arranque, o RSPM verifica a impressão digital guardada e o SHA-1 do ZIP combinado antes de os plugins monitorizados terminarem a inicialização. Se coincidirem, o alojamento Java começa de imediato a partir do pacote guardado. O monitor continua a recombinar se um pacote de origem mudar depois.

A monitorização respeita a inicialização dos plugins?

Sim. O monitor conhece os estados de inicialização Magmacore:

• Espera que os plugins monitorizados terminem a inicialização antes de verificar estabilidade.
• Se um plugin entrar em INITIALIZING, pausa e repõe a monitorização de estabilidade até terminar. Integrações opcionais falhadas ou não inicializadas não bloqueiam indefinidamente todo o combinador.
• Isto evita detetar falsamente instabilidade durante arranques ou recarregamentos normais.

Como recebem os jogadores o pacote final?

Com autoHost ativo, por predefinição, ou com a sobreposição explícita de selfHostForce, o RSPM escolhe um URL e envia-o a cada jogador Java que entra:

1. Com selfHostForce: true, tenta alojamento próprio sem verificações de acessibilidade, sobretudo para testes. A validação do URL e o arranque HTTP têm de continuar a funcionar.
2. Caso contrário, com preferSelfHost: true, predefinido, e selfHostEnabled: true, verifica o endereço, compara amostras do pacote transferidas através de localhost e do URL exato do jogador, e exige acessibilidade externa através de magmaguy.com. Só escolhe alojamento próprio se todas as verificações passarem.
3. Se o alojamento próprio falhar ou estiver desativado, reutiliza ou envia o pacote para magmaguy.com/rsp/ e anuncia esse URL. Uma falha remota pode recorrer ao alojamento próprio se estiver ativo, mas tem de passar as mesmas verificações. Uma verificação externa indisponível rejeita alojamento próprio automático; se ambas as vias falharem, não é anunciado um novo URL de entrega.

O RSPM usa a API de múltiplos pacotes para coexistir com outros pacotes enviados pelo servidor. O descritor Bukkit exige Minecraft 1.21.4 ou posterior.

O envio inicial tem um atraso de cerca de um segundo. Respostas FAILED_DOWNLOAD e DISCARDED provocam novas tentativas automáticas, até três por sessão. Uma recusa, um URL inválido ou FAILED_RELOAD (falhou o recarregamento de recursos do próprio cliente; consulte o latest.log desse cliente) não são repetidos. Os jogadores Floodgate são ignorados nesta via, pois recebem o pacote Bedrock através do Geyser.

Com autoHost: false e selfHostForce: false, o RSPM não envia URL. Terá de recolher o ZIP em plugins/ResourcePackManager/output/ e entregá-lo pelo seu próprio sistema.

Consulte a decisão completa em Alojamento próprio.

Posso alojar o pacote por minha conta?

Sim. Desde o RSPM v2, o servidor HTTP integrado é a via recomendada. selfHostEnabled: true e preferSelfHost: true estão ativos por predefinição.

Se preferir usar um servidor web já existente fora das vias integradas:

• Defina autoHost: false.
• Opcionalmente, defina resourcePackRerouting com uma pasta existente, relativa a plugins.
• Aloje o pacote plugins/ResourcePackManager/output/ResourcePackManager_RSP.zip através do seu sistema.

resourcePackRerouting faz escrever uma cópia adicional do ZIP na pasta indicada. O caminho é relativo a plugins e a pasta tem de existir previamente.

Existe um comando para obter os dados guardados no alojamento?

Sim:

/rspm data_compliance_request

Se existir uma sessão ativa no alojamento remoto de magmaguy.com, a resposta é transferida para:

plugins/ResourcePackManager/data_compliance/data.zip

O RSPM também escreve ReadMe.md na pasta data_compliance.

Sem sessão remota ativa, como num servidor com alojamento próprio, o comando informa que não há dados remotos para pedir.

Que opções de configuração existem?

plugins/ResourcePackManager/config.yml disponibiliza:

Geral

• priorityOrder: ordem dos pacotes em conflitos, com maior prioridade primeiro.
• autoHost: aloja e envia automaticamente o pacote combinado; booleano, predefinido true.
• forceResourcePack: exige aceitação do pacote; booleano, predefinido false.
• resourcePackPrompt: pergunta apresentada ao oferecer o pacote; predefinida "Use recommended resource pack?".
• resourcePackRerouting: pasta opcional relativa a plugins para uma cópia adicional do ZIP.
• verboseLogging: regista todas as etapas de preparação e comunicação do alojamento; booleano, predefinido false, para mostrar normalmente apenas o resultado. Ative-o para diagnosticar combinação ou alojamento. /rspm verbose on|off altera e guarda a mesma chave. É independente de bedrockConverterDebug.
• nightbreak.autoDownloadPluginUpdates: transfere automaticamente atualizações do próprio plugin no arranque; booleano, predefinido false. As atualizações exigem reinício para serem aplicadas. A chave está dentro de nightbreak:, não no nível superior. Ao procurar autoDownloadPluginUpdates, encontrará a linha indentada nessa secção. É a mesma opção do menu /rspm setup. As transferências automáticas do plugin exigem um token válido da conta Nightbreak e uma subscrição ativa de apoiante no Patreon. O RSPM não escreve a chave partilhada nightbreak.applyPluginUpdatesWithoutRestart e nunca aplica uma atualização transferida sem reiniciar, porque a sua extensão do Geyser só carrega quando o Geyser arranca.

Alojamento próprio

• selfHostEnabled: permite usar o servidor HTTP integrado; booleano, predefinido true.
• selfHostPort: porta HTTP. -1, predefinido, calcula mcPort + networkHttpOffset-v2. As portas explícitas e calculadas têm de ficar entre 1 e 65535.
• networkHttpOffset-v2: desvio somado à porta Minecraft com selfHostPort = -1; predefinido 1, por exemplo Minecraft 25565 dá HTTP 25566. Na rede, o backend anuncia a porta real. O proxy só usa o seu network-http-offset-v2 como estimativa de recurso antes de receber o anúncio.
• selfHostExternalHost: nome ou IP público apresentado aos clientes. Vazio, por predefinição, ativa a deteção automática.
• selfHostExternalUrl: URL público HTTP/HTTPS completo, incluindo caminho, para um proxy inverso. Vazio por predefinição. Substitui o URL anunciado, sem alterar a escuta local. Credenciais incorporadas e fragmentos são rejeitados.
• selfHostForce: ignora todas as verificações e o envio remoto e força alojamento próprio; booleano, predefinido false, destinado a testes.
• preferSelfHost: tenta alojamento próprio com verificações antes de recorrer ao envio remoto; booleano, predefinido true.

Bedrock

• bedrockConversionEnabled: converte o pacote Java combinado para Bedrock/GeyserMC; predefinido true.
• bedrockAutoDeployToGeyser: copia os mapeamentos personalizados para a pasta Geyser detetada; predefinido true.
• bedrockGeyserFolder: caminho manual da pasta Geyser; vazio ativa a deteção automática.
• bedrockConverterDebug: registos detalhados por objeto e osso da conversão Bedrock; predefinido false.
• geyserExtensionAutoInstall: instala e atualiza o JAR universal como extensão Geyser para apresentar entidades Bedrock personalizadas; predefinido true. false impede instalações e preparação de atualizações futuras, mas não apaga a extensão já existente. Remova-a manualmente com o Geyser parado. O proxy usa a opção equivalente geyser-extension-auto-install.

As versões anteriores tinham também plugins/ResourcePackManager/bedrock_display_offsets.yml, com definições de desvio dos objetos na mão. Esse ficheiro já não é lido: as poses dos objetos na mão em Bedrock vêm agora das transformações display do modelo Java. Consulte Poses dos objetos na mão.

Não existe uma opção de configuração network-key no backend ou proxy. A introdução manual da chave era uma fonte importante de erros, permitindo quebrar a ligação com uma gralha sem erro visível.

O proxy gere e distribui a chave:

• O proxy lê primeiro um network-key guardado e válido, tenta depois derivar a chave de plugins/floodgate/key.pem e, se nenhum estiver disponível, gera uma chave aleatória. Guarda o resultado na sua pasta de dados. Os arranques seguintes reutilizam a chave enquanto for válida; perdê-la repete este processo e pode recriar a mesma chave derivada do Floodgate. Consulte a recuperação da chave de rede.
• Cada backend recebe-a por rspm:network na primeira ligação de um jogador e guarda-a em data.yml. Um backend com chave ignora atribuições posteriores. Mudar de rede exige intervenção do administrador.
• O Floodgate não é necessário para a ligação RSPM. A autenticação Bedrock depende do modo escolhido no Geyser; consulte Floodgate e autenticação online.
• Um servidor independente gera e mantém a própria chave, pois constitui uma rede de um só servidor.

/rspm status mostra uma impressão digital curta de sentido único, nunca a chave. Impressões iguais indicam a mesma identidade de rede; verifique separadamente os resultados de obtenção para confirmar a conectividade e a entrega dos pacotes.

Porque aparecem tão poucas mensagens na consola?

Preparar um pacote inclui recolher os pacotes dos plugins, combinar grupos, esperar pela estabilidade, combinar o resultado, converter para Bedrock e alojar. Registar todas as etapas produzia cerca de sessenta linhas por arranque, tornando difícil encontrar o resultado e as ações necessárias.

Por isso, um arranque normal apresenta uma linha:

[ResourcePackManager] Resource pack is live via self-hosting — http://play.example.com:25566/rspm.zip

Esta linha confirma a publicação de um URL de entrega. Entre com um cliente e observe conteúdo personalizado conhecido para confirmar a transferência e a apresentação.

O RSPM também não avisa sobre condições das quais recupera sozinho. Uma verificação local falhada seguida de alojamento remoto bem-sucedido é tratada como sucesso, sem criar um aviso de um problema já resolvido.

Para ver os detalhes, execute /rspm verbose on ou defina verboseLogging: true e depois /rspm reload. Para a conversão Bedrock, use bedrockConverterDebug: true.

Outros plugins podem registar pacotes através de código?

Sim. A API Java permite registar pacotes programaticamente. Consulte a página da API.

A conversão Bedrock só funciona com FreeMinecraftModels?

Não. O conversor percorre as definições 1.21.4 ou posteriores em assets/<namespace>/items/**/*.json de qualquer plugin. Inclui modelos de ossos FreeMinecraftModels, equipamento EliteMobs, objetos Oraxen/Nexo, armaduras personalizadas e pacotes próprios nesse formato. Os objetos 2D produzem ícones planos; os 3D produzem geometria, elementos equipáveis e um ícone de inventário renderizado por software.

Preciso de reiniciar sempre que o pacote Bedrock muda?

As alterações de texturas e modelos de objetos existentes chegam ao próximo jogador Bedrock que entrar, através da entrega por sessão da API Geyser. Reinicie o processo que executa o Geyser quando mudarem os mapeamentos de objetos ou for necessário registar novos identificadores de entidades ou tipos de propriedades. Esses registos ocorrem no arranque. Exportar novamente identificadores já registados, sem mudar os tipos de propriedades, não exige por si só outro reinício.

Funciona em BungeeCord e Velocity?

Sim. Instale o mesmo ResourcePackManager.jar no proxy e em cada backend que forneça pacotes de recursos. O JAR contém os pontos de entrada Bukkit, Velocity e BungeeCord. Um backend atrás de um proxy prepara uma cópia em plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar quando ainda não recebeu uma chave de rede. Os restantes servidores registados podem funcionar sem RSPM; a deteção de backends impede que atrasem a sincronização dos pacotes.

No proxy, combina os pacotes Bedrock convertidos de todos os backends e entrega-os através do Geyser. A entrega Java continua diretamente em cada backend, com pacotes separados por servidor.

Consulte a instalação, diagnóstico e verificação em Redes com proxy.