O que é o projeto fnf indie cross e por que ele existe
A ideia central por trás do fnf indie cross é permitir que mods de Friday Night Funkin' criados para versões mais antigas do jogo rodem junto com conteúdo feito para Engine versions modernas, algo que originalmente não funcionava sem intervenção manual. A maioria dos criadores de mod precisa lidar com incompatibilidades de asset path, differences de script entre as builds mais recentes e antigas, e conflitos de audio manager quando tenta mesclar conteúdo de diferentes branches da comunidade. O projeto nasceu exatamente pra resolver isso de forma menos dolorosa do que tentar patchear tudo à mão. Na prática, eu tive um caso bem específico envolvendo um mod chamado "Psych Engine Extended" que usava a biblioteca HScript de uma versão, enquanto outro mod que eu queria juntar com ele dependia da versão Lua-based do sistema de animação. O jogo simplesmente travava no load screen e não dava log algum útil. A solução foi identificar que os dois mods estavam registrando o mesmo path de asset com nomes diferentes, então eu renomeei o diretório assets/char no segundo mod, atualizei os references no script de loading, e configurei o manifest.xml do primeiro mod pra usar include_paths em vez de overwriting. Isso resolveu o conflito de asset registry. Levei cerca de 40 minutos pra descobrir onde estava o problema real.
Como configurar o fnf indie cross no seu projeto
Você precisa primeiro ter o Psych Engine ou a build mais recente do FunG installada no seu PC. O processo de setup varia dependendo da engine base que você está usando, mas o fluxo geral é o mesmo. Baixe o pacote de compatibilidade, extraia ele na pasta raiz do seu mod, e edite o file manifest.xml pra listar os assets cruzados que você quer incluir. O campo include_assets define quais pastas do mod original devem ser mergeadas com as do destino. É importante não adicionar assets duplicados — se dois mods tiverem spritesheets com o mesmo nome mas frames diferentes, um vai sobrescrever o outro silenciosamente. Configuração básica do manifest.xml
O arquivo precisa seguir um esquema específico. A tag root deve apontar pro path base do mod, e as subtags child_path identificam os diretórios que serão combinados. Se você estiver juntando mods de diferentes builds do FNF, precisa também configurar a flag compatibility_mode pros assets que usam old-style animation timing. Sem essa flag, frames de animação que eram 0.1s num mod antigo vão rodar a 0.05s no destino, quebrando totalmente a sincronia musical.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Pitfalls comuns e coisas que dão errado
O problema mais frequente é o que eu chamaria de dependency chain rot. Quando você mistura três ou mais mods diferentes, cada um deles pode depender de bibliotecas diferentes com versões conflitantes. O mod A precisa da library v2.3, o mod B precisa da v2.7, e o sistema de cross acaba carregando a versão mais recente, que quebra funcionalidades que o mod A esperava ter disponível de forma diferente. Eu resolvi isso mantendo uma pasta libs/ separada dentro do mod principal e copiando manualmente as bibliotecas necessárias pra lá, com nomes versionados pra evitar colisão. Funciona, mas exige paciência. Outro problema real é performance. Mods que usam o cross system tendem a carregar mais assets na memória do que o normal porque o merge é feito em runtime. Dependendo da quantidade de spritesheets e arquivos de áudio envolvidos, você pode ver frame drops durante fases com muitos personagens na tela. Se o seu mod tiver mais de 50MB em assets, recomendo fazer profiling antes de lançar. Ferramentas como o built-in memory monitor do Psych Engine ajudam a identificar quais assets estão consumindo mais RAM do que deveriam.
Download e fontes oficiais
O pacote de compatibilidade do fnf indie cross é mantido principalmente no repositório oficial do Psych Engine no GitHub. A versão mais recente costuma estar na branch main, mas às vezes há patches de compatibilidade que só aparecem em branches temporárias antes de serem mergeadas. Sempre verifique a data do último commit antes de baixar — pacotes com mais de três meses sem atualização podem não ser compatíveis com as builds mais recentes da engine. Não recomendo usar forks não oficiais porque eles frequentemente não recebem patches de segurança e de compatibilidade que chegam pro repositório principal.
Alternativas quando o cross não funciona
Se o sistema de cross simplesmente não conseguir unir os mods que você quer, existem abordagens manuais. Você pode extrair os assets individualmente e reposicioná-los nos diretórios corretos do mod destino, ajustando paths e references um por um. Esse método leva mais tempo — eu estimaria entre 2 e 4 horas pros mods médios — mas dá controle total sobre o que está sendo carregado e evita conflitos de library. Para projetos grandes com muitos assets, considere dividir o trabalho em fases: primeiro misture os assets gráficos, depois os de audio, e por fim os scripts. Assim você isola problemas específicos sem ter que debuggar tudo de uma vez. O sistema em si é útil mas tem limitações claras. Ele funciona bem quando você está combinando dois mods com estruturas similares. Quando a diferença entre as builds é grande demais, ou quando há dependências circulares entre bibliotecas, o melhor caminho é o método manual mesmo. Nenhum sistema de cross automação consegue compensar diferenças fundamentais de arquitetura entre as versões da engine.
