Etapa 01 · obrigatório
Identidade da definição
O loader usa estes campos para localizar o arquivo, escolher o comportamento e validar a definição. Comece pelo esqueleto obrigatório.
Identificação
O id precisa ser exatamente <namespace>:<path> do arquivo.
Somente 2 é aceito.
Minúsculas, números e _ . -.
Minúsculas, números e _ . / -.
data/infinity_nexus_multiblock/multiblock/minha_maquina.json
Tipo de máquina
Define se o controller processa receitas ou apenas expõe inventorário e capabilities.
Metadados opcionais
Valores no padrão são omitidos do JSON final.
Metadado; mínimo 1.
Maior prioridade vence em sobreposição.
Só vale sem item_slots; não reposiciona slots com x/y.
Campos preservados
Estes campos vieram do JSON importado. Eles serão mantidos no download, mas ainda não são editados nem validados nesta fase.
Etapa 02 · obrigatório
Pattern da estrutura
Pinte as camadas de baixo para cima. A orientação canônica olha para south; o jogo rotaciona tudo conforme o FACING do controller.
Editor de camadas
3 × 1 × 3
Clique ou arraste para pintar. Botão direito apaga. Com foco na grade, use as setas, Enter e Backspace.
Etapa 03 · obrigatório
Matchers dos símbolos
Cada símbolo não-âncora precisa apontar para um bloco, uma tag ou um bloco com blockstate específico.
Símbolos usados
A ordem dos matchers não importa para o loader.
/reload.
Etapa 04 · opcional
Slots de itens
Define o inventário por item_slots. Com x/y, o layout padrão respeita a posição; sem posição, usa a grade automática.
item_slots
Sem item_slots; o inventário usa inventory_rows.
x/y válidos mantêm a posição e os demais entram na grade automática de 18 px. Em GUI customizada, slots sem posição ficam apenas para automação.
O filter aceita item ou tag; sem filtro, o slot aceita qualquer item. Slots output não usam filtro.
Etapa 05 · opcional
Energia e fluidos
Define capabilities.energy, capabilities.fluids e os filtros de bloco em capability_ports. Itens usam o inventário da máquina; energia e tanques são opcionais.
capabilities
Sem capabilities; a máquina não expõe energia/fluidos.
capability_ports
Sem filtro; todas as capabilities usam qualquer bloco formado.
Sempre disponível via inventário. Use [] para não expor item.
Símbolos disponíveis no pattern: C, I.
Vazio libera a capability em qualquer bloco formado. Use [] para não expor nenhum bloco. Separe vários seletores por vírgula ou espaço.
energy.id é o identificador usado por uma energy_bar; fluids[].id identifica cada tanque e não é o tipo do fluido.
filter aceita um fluido ou tag, como minecraft:water ou #c:water.
Etapa 06 · opcional
Controller único e receita
Todas as definições usam o mesmo bloco e item controller. Aqui você apenas configura a receita shaped opcional que cria esse item.
controller compartilhado
Todas as definições usam o mesmo controller; não há bloco ou textura por máquina.
O bloco, o item e o block entity são registrados uma única vez pelo mod:
infinity_nexus_multiblock:multiblock_controller
Cada definição é associada ao controller pelo componente infinity_nexus_multiblock:multiblock_definition.
recipe
Sem receita shaped para o controller.
Pattern 3x3 clique na letra e depois no slot
Use o botão direito em um slot para apagar. A key abaixo acompanha automaticamente os símbolos usados.
Key automática informe apenas o item
Aceita item ou tag, como minecraft:iron_ingot ou #c:ingots/copper.
recipe é opcional e gera data/<namespace>/recipe/controller/<path>.json com resultado infinity_nexus_multiblock:multiblock_controller.
Etapa 07 · opcional
GUI e elementos
Personaliza o layout da GUI. Sem uma GUI customizada, o loader usa 176x166 e o inventário do jogador.
gui
Sem GUI customizada; o loader usa o layout fallback 176x166.
Layout visual arraste para posicionar
Arraste energia, fluidos, progresso, entidade e demais elementos para ajustar x/y. Os campos numéricos continuam valendo para largura, altura e demais propriedades.
Novos elementos começam com o layout do spawner: título em 8,4, texto em 8,75, inventário em 8,84, barras em 158/148/138,10 com 8x64 e entidade em 96,18 com 32x32. Slots começam em 8,16 e avançam 18 px, com 9 por linha.
Elementos opcional
player_inventory. item_slots só é obrigatório quando houver elementos slot ou posições x/y; sem slots de item, a GUI pode ter só barras. Barras precisam apontar para a energia ou o tanque existente; progress_bar, arrow e entity só valem em máquinas type=recipe. entity mostra a entidade do output da receita e usa apenas x/y/width/height. Elementos slot usam a referência de item_slots; slots com x/y não podem ser misturados com eles.
Etapa 08 · opcional
Receitas data-driven
Crie os arquivos de receita em data/<namespace>/recipe/. O tipo é fixo e o builder preenche definition automaticamente.
storage; receitas não serão processadas por ela. Use uma máquina type=recipe.
Receitas
Nenhuma receita adicionada.
output; saídas de fluido exigem tanque; entidades usam um seletor de spawn do pattern.
ingredients: um id ou tag por linha; também aceita JSON de ingrediente em uma linha. fluid_ingredients: use fluido quantidade por linha e só aparece quando a máquina tem tanque. output.type aceita item, fluid ou entity; o builder oculta energia, fluidos e saídas que a máquina não suporta. Toda receita usa type: infinity_nexus_multiblock:multiblock e recebe definition com o id desta máquina. O JEI mostra as receitas quando o controller está associado a uma definição type=recipe.
/inm hand para gerar o input de ingredients e o objeto de output. O input não serve como output e vice-versa; nos campos de saída do builder, use id, count e components separadamente. /inm look envia o ID puro, o matcher completo e o state separado. No campo Bloco dos matchers, cole o ID puro ou o matcher completo: o builder separa bloco e propriedades automaticamente. As linhas no chat são clicáveis e copiam o texto. O alias /infinity_nexus_multiblock faz o mesmo.
Etapa 09 · opcional
Herança e templates
Compartilhe pattern, slots, capabilities e GUI com um pai usando extends ou family. O filho declara apenas o que muda.
Herança
Sem herança; a definição é autocontida.
Use apenas um dos dois; eles são equivalentes no loader.
ID completo de outra definição, de preferência um template. O pai é resolvido recursivamente.
Objeto aplicado depois dos campos do filho; vence qualquer campo igual. Arrays substituem o valor inteiro.
extends, family, overrides e template não são herdados. Ciclos, pai inexistente, os dois campos juntos ou overrides inválido são rejeitados pelo servidor.
Etapa 10 · revisão
JSON e checklist
Revise o resultado, copie o JSON e salve no caminho indicado. O jogo continua sendo a autoridade final.
Receitas
Arquivos separados em data/<namespace>/recipe/.
Assets e registro
O builder não cria PNGs, modelos ou classes Java. Confira os caminhos manuais.
JSON gerado
Somente a definição da máquina; receitas são exportadas separadamente.
Checklist do loader
As mesmas checagens que bloqueiam a exportação.
data/.../multiblock/....json exatamente com esse nome e rode /reload. O id é o caminho do arquivo: não renomeie depois de baixar. O controller é único e já registrado pelo mod; qualquer namespace pode apontar para ele.