Erro de interação cíclica no LOOT: solução para dependências circulares e conflitos de ordem de carregamento

A natureza do erro de interação cíclica

No ecossistema de modificação de jogos baseados na engine da Bethesda — como os títulos das séries The Elder Scrolls e Fallout, gerenciados pelo Mod Organizer 2, Vortex ou ferramentas equivalentes —, o LOOT (Load Order Optimisation Tool) atua como o principal utilitário para calcular uma hierarquia correta de plugins. Contudo, à medida que a lista de mods cresce para centenas de arquivos .esm, .esp e .esl, os jogadores frequentemente se deparam com um alerta vermelho que bloqueia totalmente o processo:

Cyclic interaction detected between plugins: "PluginA.esp" -> "PluginB.esp" -> "PluginC.esp" -> "PluginA.esp"

Quando essa falha ocorre, o LOOT interrompe a ordenação imediatamente. A ordem de carregamento em uso permanece congelada em um estado indefinido, impedindo que novos patches de compatibilidade sejam alocados em seus devidos lugares. Se o usuário tentar iniciar o jogo nessa condição, arquivos mestres ausentes ou patches invertidos quase invariavelmente causarão um travamento imediato para a área de trabalho (CTD) no menu principal ou a quebra definitiva de scripts de missões durante a jogatina.

Compreender os fundamentos de teoria dos grafos e o modelo de regras do LOOT permite isolar e eliminar a causa da colisão de maneira cirúrgica, sem precisar resetar configurações ou reinstalar grandes pacotes de mods.

Teoria dos grafos e ordenação topológica no LOOT

O LOOT não determina a posição dos plugins com base em suposições arbitrárias; ele processa a lista aplicando princípios rigorosos de teoria dos grafos.

O mecanismo do utilitário estrutura todos os plugins ativos sob a forma de um Grafo Acíclico Dirigido (DAG, do inglês Directed Acyclic Graph):

• Vértices (Nós): Cada plugin ativado na pasta Data do jogo é tratado como um nó exclusivo na estrutura do grafo.
• Arestas direcionadas (Setas): Uma regra declarando que «o Plugin A deve carregar antes do Plugin B» é representada como uma aresta direcionada saindo de A em direção a B ($A \rightarrow B$).

Para converter essa teia complexa de interdependências em uma lista sequencial linear (uma ordem indexada de 00 a FE), o LOOT precisa executar uma ordenação topológica (Topological Sort). Esse algoritmo organiza os nós de modo que, para cada aresta direcionada $u \rightarrow v$, o nó $u$ sempre anteceda o nó $v$ na sequência final.

Um teorema clássico da matemática estabelece que uma ordenação topológica só é possível se o grafo não contiver ciclos direcionados (ou seja, for um DAG).

Se uma combinação de regras impuser que «A deve vir antes de B ($A \rightarrow B$)», «B deve vir antes de C ($B \rightarrow C$)» e «C deve vir antes de A ($C \rightarrow A$)», estabelece-se um circuito fechado contínuo. Diante desse ciclo, não existe matematicamente nenhuma sequência linear capaz de satisfazer todas as condições ao mesmo tempo. Ao detectar essa impossibilidade lógica, o LOOT emite o aviso «Cyclic interaction detected» e suspende a operação.

Hierarquia de regras: regras rígidas vs. regras flexíveis

Para diagnosticar a origem do travamento, é necessário distinguir os dois níveis de regras que o LOOT processa na formação do grafo:

1. Regras rígidas (Hard Rules, restrições obrigatórias)

São imposições estruturais de primeira ordem que o LOOT não pode contornar sob hipótese alguma. Se regras rígidas formarem um ciclo entre si, a ordenação falha obrigatoriamente:

• Flag mestre (Master Flag): Plugins marcados com o flag .esm precisam carregar antes de arquivos comuns .esp.
• Dependências mestras no cabeçalho (Header Masters): Se o Plugin B lista o Plugin A no campo MAST (Master Files) do seu cabeçalho interno (File Header), o jogo exige que Plugin A esteja carregado antes. Uma inversão causará CTD na inicialização do jogo.
• Arquivos oficiais fixos: Componentes centrais oficiais (como Skyrim.esm ou Fallout4.esm) têm alocação prioritária inviolável.
• Regras personalizadas «carregar após» (User "Load After"): Regras criadas manualmente pelo jogador no editor de metadados do LOOT têm status de regra rígida prioritária.
• Metadados de requisitos: Instruções de dependência mandatórias definidas na lista mestra oficial.

2. Regras flexíveis (Soft Rules, diretrizes opcionais)

Diretrizes criadas para otimizar resoluções de conflitos cosméticos ou sobreposições menores, mas que podem ser abandonadas se ameaçarem a estabilidade do grafo:

• Regras de grupos (Group Rules): O LOOT classifica plugins em categorias estruturadas (Core, Bug Fixes, UI, Late Loaders). Se um vínculo de grupo ameaçar fechar um ciclo com uma regra rígida, o LOOT descarta automaticamente a regra de grupo para manter o grafo ordenável.
• Regras de sobreposição (Overlap Rules): Detectadas quando dois plugins sobrescrevem os mesmos registros ou arquivos de dados. São imediatamente ignoradas caso colidam com regras rígidas.

Como o próprio LOOT descarta regras flexíveis conflitantes por padrão, quase todos os erros persistentes de interação cíclica resultam de conflitos diretos entre regras rígidas: contradições entre cabeçalhos de arquivos mestres e regras personalizadas criadas pelo usuário.

Os três principais cenários de dependência circular

Na prática do modding, os ciclos decorrem quase exclusivamente de um destes três quadros:

Cenário 1: Vínculos mestres cruzados entre patches de compatibilidade

Ocorre com frequência quando o jogador instala múltiplos patches de fontes distintas para compatibilizar os mesmos mods de base:

• O Mod A depende da base X.
• O Mod B depende da base Y.
• O patch Patch1.esp foi gerado para compatibilizar A e B, mas incluiu inadvertidamente Patch2.esp como mestre; por sua vez, Patch2.esp traz Patch1.esp (ou um intermediário) listado em seu próprio cabeçalho. Ambos os arquivos demandam fisicamente a precedência do outro, gerando um bloqueio inquebrável nos cabeçalhos.

Cenário 2: Regras manuais do usuário em oposição aos cabeçalhos mestres

Acontece quando o usuário adiciona regras manuais no editor do LOOT ou no grafo do Vortex com base em tutoriais antigos:

• O usuário determina que Armor_Patch.esp deve carregar após Weather_Mod.esp.
• No entanto, Weather_Mod.esp (ou sua estrutura básica) possui Armor_Patch.esp vinculado internamente como um de seus mestres obrigatórios. A instrução do usuário colide com a exigência estrutural do arquivo, fechando um loop de dependência.

Cenário 3: Plugins com flag ESM dependendo de ESP comum

A engine exige que qualquer arquivo com flag ESM venha antes de arquivos ESP sem essa marcação. Se um criador de mods aplica o flag ESM em seu plugin, mas mantém como dependência mestre um .esp comum:

1. Pela dependência mestre: o ESP comum deve carregar antes do ESM.
2. Pela regra de flags: o ESM deve carregar antes do ESP comum. Esse choque de requisitos fundamentais é apontado pelo LOOT como uma interação cíclica fatal.

Procedimento de diagnóstico e resolução em cinco etapas

Na avaliação do 365Finds, a grande maioria dos erros de interação cíclica não se origina de inconsistências na lista mestra oficial do LOOT, mas sim do acúmulo de regras manuais de 'carregar após' definidas pelo jogador ou de patches de compatibilidade de terceiros que declaram inadvertidamente dependências mestras recíprocas; limpar os metadados personalizados e auditar os vínculos reais de registros no xEdit resolve mais de 90% dos travamentos de ordenação sem exigir a reinstalação dos mods.

Adote o seguinte plano de ação estruturado para sanar a falha:

Etapa 1: Anotar o circuito do ciclo no log do LOOT

Ao visualizar o alerta de erro no LOOT, copie a cadeia exata apresentada na janela ou no cartão principal de status. Exemplo: Back cycle: ModAlpha.esp, ModBeta.esp, PatchGamma.esp, ModAlpha.esp Anote todos os arquivos participantes desse anel. O conflito está estritamente restrito às relações entre esses plugins listados.

Etapa 2: Examinar e resetar regras de metadados do usuário

Antes de alterar plugins, teste se o erro não foi induzido por regras manuais:

1. No menu principal do LOOT, localize os plugins identificados no ciclo.
2. Clique no ícone de três pontos verticais (⋮) ao lado do plugin e selecione Editar metadados (Edit Metadata).
3. Acesse as abas Carregar após (Load After) e Grupo (Group).
4. Caso encontre regras personalizadas inseridas manualmente, clique no ícone da lixeira para removê-las.
5. Salve as alterações clicando no ícone de confirmação.
6. Clique no botão de ordenar no topo do LOOT. Se a rotina concluir com êxito, a causa era uma regra manual incompatível.

Etapa 3: Auditar cabeçalhos físicos via xEdit

Caso o erro persista sem regras manuais, a dependência circular está gravada diretamente nos cabeçalhos dos arquivos:

1. Abra o xEdit (SSEEdit, FO4Edit, etc.) pelo seu gerenciador de mods.
2. Na lista de seleção de plugins, clique com o botão direito, escolha «Select None» e marque apenas os plugins apontados no ciclo (junto aos ESMs básicos do jogo).
3. Após o carregamento, expanda cada plugin no painel esquerdo e clique no seu primeiro nó: File Header.
4. No painel direito, inspecione a seção Master Files (MAST).
5. Cruze as listas de mestres para verificar qual arquivo está exigindo o outro como requisito direto no circuito.

Etapa 4: Limpar dependências fantasmas com «Clean Masters»

Muitas vezes, um criador de patch abriu mods adicionais no Creation Kit sem querer, fixando-os como mestres mesmo sem alterar nenhum registro desses arquivos:

1. No xEdit, clique com o botão direito sobre o plugin suspeito de conter mestres excedentes.
2. Escolha Clean Masters no menu de contexto.
3. O xEdit varrerá a árvore do mod e, caso não identifique nenhum FormID dependente daquele mestre, removerá a entrada do cabeçalho MAST com total segurança.
4. Salve as modificações com Ctrl + S e feche o utilitário.

Etapa 5: Tratar conflitos de patches mutuamente exclusivos

Se a opção «Clean Masters» não remover o mestre porque o arquivo realmente altera registros de ambos os lados:

1. Isso indica que foram instaladas variações incompatíveis do mesmo patch (por exemplo, selecionar as opções «Standalone» e «Merged» ao mesmo tempo em um instalador FOMOD).
2. Desinstale ou reinstale o mod em questão pelo gerenciador para manter exclusivamente o arquivo adequado ao seu cenário.
3. Abra o LOOT e ordene novamente. O grafo acíclico será gerado corretamente, permitindo que a ordenação topológica seja calculada e aplicada com total estabilidade.

Referências

• LOOT: The Load Order Optimisation Tool
• How LOOT Sorts Plugins — LOOT latest documentation
• Editing Plugin Metadata — LOOT latest documentation
• Tome of xEdit | xEdit Documentation