Saída do Resource Pack do FreeMinecraftModels

O FreeMinecraftModels atualmente escreve seu pack gerado em output, não em outputs.

Caminhos de Saída Padrão

O plugin reconstrói esta pasta na inicialização e em /fmm reload:

plugins/FreeMinecraftModels/output/FreeMinecraftModels

Ele então compacta essa pasta em:

plugins/FreeMinecraftModels/output/FreeMinecraftModels.zip

Esse caminho de zip é o que o ResourcePackManager espera quando se integra ao FreeMinecraftModels.

O Que É Gerado

A pasta gerada sempre inclui:

• pack.mcmeta
• pack.png
• assets/minecraft/atlases/blocks.json
• assets/freeminecraftmodels/... saída de modelos e texturas

O FreeMinecraftModels gera arquivos de definição de item-model em:

assets/freeminecraftmodels/items

Um caminho legado de override via armadura de cavalo de couro ainda existe no código para servidores anteriores ao 1.21.4, mas o plugin declara api-version: 1.21.4, então nenhum servidor capaz de carregá-lo passa por essa ramificação.

Saída de Display Model (1.21.4+)

Quando um modelo tem um arquivo de display model .json irmão (veja Notas de Autoria de Modelos), o FMM copia esse JSON (com referências de textura reescritas para combinar com as texturas extraídas) para:

assets/freeminecraftmodels/models/display/{modelId}.json

Também gera uma definição de item correspondente em:

assets/freeminecraftmodels/items/display/{modelId}.json

O DisplayModelRegistry rastreia quais modelos têm JSONs de display em runtime para que ItemMeta.setItemModel() possa ser chamado em ItemStacks para dar-lhes a aparência correta na mão e no inventário.

Bundle de Entidade Personalizada Bedrock

Junto com os assets do pack Java, o FreeMinecraftModels exporta um bundle de entidade personalizada Bedrock para cada modelo convertido em:

plugins/FreeMinecraftModels/output/FreeMinecraftModels/assets/freeminecraftmodels/rspm_bedrock_pack

Cada modelo contribui com suas texturas, geometria, render controller, animações, animation controllers e definição de entidade, tudo sob o namespace freeminecraftmodels: (freeminecraftmodels:<model_id>).

Notas que importam na hora de criar modelos:

• Um modelo sem texturas é pulado, com Skipping Bedrock custom entity export for <id>: model has no textures. no console
• A geometria Bedrock exclui os ossos de montaria (m_), os de nome gerados (fmm_nametag_bone_*) e hitbox. As âncoras tag_ criadas pelo autor permanecem, frequentemente sem cubos.
• Um modelo sem animações ainda exporta um único slot de animação idle
• A largura/altura de hitbox em runtime da entidade Bedrock vêm do osso hitbox do modelo; sem ele, o fallback é 1.0 x 2.0

O backend Bedrock exige um plugin ativo chamado floodgate, Geyser-Spigot ou Geyser. A comparação ignora maiúsculas, mas não aceita outros nomes. Num servidor apenas Java, o FMM continua a exportar os ficheiros do pacote sem criar nem executar esse backend.

Saída de Item Condicional para Arcos e Bestas

Quando o FMM detecta um conjunto de modelos de estado de arco ou besta (veja Notas de Autoria de Modelos), ele gera um único JSON de definição de item para o modelo _idle que alterna condicionalmente entre todos os estados no nível do resource pack. Nenhum trabalho de pacote no lado do servidor é necessário -- o cliente lida com as transições de estado nativamente.

Saída de Arco

Para arcos, a definição de item gerada usa minecraft:condition em using_item com um minecraft:range_dispatch em use_duration (escala 0.05):

Condição	Modelo usado
Não usando o item	_idle
Usando, fallback (acabou de começar)	_draw_start
Usando, limiar 0.65	_draw_half
Usando, limiar 0.9	_draw_full

Saída de Besta

Para bestas, a definição de item gerada usa minecraft:select em charge_type. Quando carregada (flecha ou foguete), mostra o modelo _charged. O fallback descarregado usa minecraft:range_dispatch em crossbow/pull:

Condição	Modelo usado
Não usando, não carregada	_idle
Usando, fallback (acabou de começar)	_draw_start
Usando, limiar 0.58	_draw_half
Usando, limiar 1.0	_draw_full
Carregada (flecha ou foguete)	_charged

Localização de Saída

A definição de item condicional gerada é escrita junto com outras definições de item em:

assets/freeminecraftmodels/items/display/{baseModelId}_idle.json

Apenas o modelo _idle recebe um arquivo de definição de item. Os modelos de saque e carregado são referenciados dentro dele como entradas condicionais.

Correções de Compatibilidade com Minecraft 26.1+

O gerador de pack aplica duas correções automáticas de compatibilidade para Minecraft 26.1 e mais recentes:

• Clamp de UV: as UVs de face são clampadas aos limites de pixel da própria textura de origem (0–textureWidth / 0–textureHeight) antes de serem reescaladas para o espaço UV 16x16 do Minecraft. Alguns autores de .bbmodel deixam UVs negativas ou superdimensionadas nas faces — um atlas foi redimensionado, o autouv passou da borda, e assim por diante — o que o validador mais rigoroso do 26.1 rejeita. O clamp permite que o modelo seja compilado; uma face com UV fora dos limites perde no máximo alguns pixels de detalhe de textura.
• Bones vazios e apenas de âncora são pulados: um bone sem cubos não escreve JSON de geometria, então escrever uma definição de item-model para ele deixaria uma referência pendurada. O 1.21.x tolerava isso silenciosamente; o 26.1+ registra cada caso como Missing block model: freeminecraftmodels:.... O gerador agora pula tanto o arquivo de geometria quanto a definição de item para esses bones. Isso também cobre bones hitbox (apenas colisão), âncoras posicionais tag_name, as variantes fmm_nametag_bone_* autogeradas do FMM e bones puramente wrapper/âncora.

Essas correções se aplicam automaticamente; nenhuma configuração é necessária.

nota

Pular esses bones é o motivo pelo qual um bone de nametag tag_ nunca precisa de cubos — ele é uma âncora posicional, e o gerador deliberadamente não escreve nada para ele. Veja Nametags exigem um bone tag_.

Saída Determinística

O pack gerado é byte-estável: regenerá-lo a partir de modelos inalterados produz um zip idêntico e, portanto, um SHA1 idêntico.

Isso importa porque o ResourcePackManager pula o reenvio de um pack cujo SHA1 já coincide com o que o host remoto tem. Se os bytes mudam à toa, essa verificação nunca coincide, o RSPM refaz o upload a cada reinício, e todo jogador rebaixa um pack cujo conteúdo não mudou.

Dois lugares do gerador escrevem JSON direto no disco, então a ordem de iteração dos mapas é a ordem de bytes do arquivo:

• as definições de item-model por osso em assets/freeminecraftmodels/items
• o bloco display do JSON de modelo por osso em assets/freeminecraftmodels/models

Ambos agora usam mapas com ordem de inserção. Antes eles usavam Map.of, que é respaldado por java.util.ImmutableCollections — isso semeia um salt aleatório por JVM e sonda a partir de um índice dependente do salt, então o mesmo punhado de chaves saía em uma ordem diferente a cada inicialização do servidor. Chaves como translation / scale, e type / index / default, trocavam de lugar a cada boot, reescrevendo todas as definições de item e todos os arquivos de modelo sem motivo.

Se você antes via jogadores rebaixando o resource pack após cada reinício mesmo sem ter mudado nada, era por isso.

nota

O determinismo só vale se o seu conjunto de modelos estiver inalterado. Adicionar, remover, renomear ou editar um modelo muda legitimamente os bytes do pack e deve disparar um novo upload.

Comportamento de Reload

Quando o FreeMinecraftModels recarrega, ele:

• derruba modelos ativos, props, disfarces, runtimes de script, estado de listeners e armazenamentos de cooldown de script antes de reconstruí-los
• reexecuta a etapa de importação de conteúdo
• reconstrói a pasta output/FreeMinecraftModels
• regenera output/FreeMinecraftModels.zip
• dispara resourcepackmanager reload se o ResourcePackManager estiver instalado
• emite FmmReloadedEvent na thread principal após a nova inicialização concluir, para que plugins dependentes possam recriar seus anexos de modelo

É por isso que setups modernos de FMM + ResourcePackManager não precisam mais do antigo fluxo manual de cópia de zip.