A Rhodiumcode voltou a falar do seu A350 em desenvolvimento para Microsoft Flight Simulator 2024, agora inaugurando a série de posts “Inside the Hangar”. O segundo dev update é o mais técnico até aqui e foca em um ponto que normalmente fica escondido do simmer: a arquitetura de aviônicos e a rede de dados que alimenta cada número exibido nas telas do cockpit.
O estúdio usa como gancho algo que todo mundo já viu em Airbus: aqueles misteriosos “XX” âmbar que aparecem quando um parâmetro some das telas. No A350 da Rhodiumcode, esses “XX” não são apenas textura animada; eles são consequência direta de uma rede de sistemas que realmente deixa de entregar dados, tentando espelhar o comportamento do avião real.
Depois de três anos de desenvolvimento em silêncio, um trailer-surpresa e um primeiro dev update focado em cockpit e sistemas básicos, este novo capítulo deixa claro que o time decidiu começar o projeto de dentro para fora, priorizando o cérebro eletrônico do A350 antes de polir cabine de passageiros, exterior e sons.
Integrated Modular Avionics: o “sistema nervoso” do A350
O foco da atualização é o Integrated Modular Avionics (IMA), descrito pela Rhodiumcode como o sistema nervoso do A350. Em vez de cada sistema ter seu próprio computador isolado, o avião real usa módulos de processamento compartilhados que hospedam o software de diversos sistemas, todos interligados por uma rede de dados de alta velocidade. No projeto para o MSFS, o time decidiu que não faria um A350 sem reproduzir essa lógica centralizada.
Na prática, a Rhodiumcode dividiu o IMA em três blocos: os CPIOMs (Core Processing Input/Output Modules), que processam e distribuem dados; os CRDCs (Common Remote Data Concentrators), que coletam sinais espalhados pelo avião; e a rede AFDX, que amarra tudo isso. Segundo o estúdio, todos esses elementos – incluindo as interconexões entre eles – são simulados, de forma que praticamente todo valor exibido nas telas passa por esse caminho antes de aparecer para o piloto.
O que os “XX” âmbar realmente significam
Com essa base, a Rhodiumcode explica melhor a diferença entre um número âmbar e os famosos “XX” nas telas do A350. Quando um valor é medido, mas está fora da faixa normal, o sistema mostra o número em âmbar. Já o “XX” indica que o dado simplesmente não chegou: não foi medido ou não conseguiu atravessar a rede de aviônicos até a tela. A cor é a mesma, mas a lógica por trás é bem diferente – e, no addon, isso depende de onde a falha ocorreu na cadeia de dados.
Um exemplo citado é a página de falha “FWS 1+2 & CPIOM FAULT”. Os dois Flight Warning Systems do A350 rodam em CPIOMs, que podem perder energia. Se ambos caem, o avião perde a capacidade de exibir o ECAM tradicional com alertas e procedimentos completos. Entra em cena uma tela de fallback do Control and Display System, bem mais limitada, que mostra ou esconde linhas conforme quais CPIOMs ainda estão vivos. Alguns “espaços em branco” na tela, portanto, não são bugs gráficos, mas alertas que o sistema deliberadamente deixa de exibir porque a cadeia de dados foi quebrada em algum ponto.
Performance e complexidade: o preço da simulação profunda
Simular essa arquitetura tem custo alto em performance. Em vez de um único valor de tensão de barramento, por exemplo, o A350 da Rhodiumcode acompanha várias etapas: cálculo no modelo elétrico customizado, medição, envio pela rede através de múltiplos nós, recepção pelo display e, só então, exibição. Cada leitura vira um conjunto de variáveis, porque sistemas diferentes “pegam carona” nesse dado em pontos distintos da cadeia, permitindo que uma falha intermediária afete apenas parte do avião.
O estúdio comenta que o A350 tem doze barramentos AC principais (e insinua que há mais detalhes a revelar depois), o que rapidamente explode o número de variáveis rastreadas. Cada indicação nas páginas de sistemas depende desse fluxo, além da própria simulação dos CPIOMs, CRDCs e switches AFDX, com rotas redundantes para evitar que uma única falha derrube tudo. Foram necessários anos de iteração até chegar a um desenho que rodasse de forma estável dentro das limitações do MSFS, mas o ganho é que muitos comportamentos “secundários” surgem naturalmente, sem precisar ser scriptado caso a caso.
Status do projeto e próximos passos
Em termos de mercado, o alvo é ambicioso: desde 2025 o iniBuilds A350 domina o nicho de alta fidelidade para esse modelo no MSFS, e parte da comunidade se pergunta se há espaço para algo ainda mais profundo. A Rhodiumcode responde apostando justamente na simulação de sistemas em nível de rede, enquanto admite que arte externa, cabine e sons ainda estão correndo atrás do restante do projeto.
No fim do dev update, o estúdio traz um pequeno FAQ: o desenvolvimento segue em paralelo em código, arte e áudio, com um sound designer recém-chegado e efeitos sonoros em produção, ainda sem prévia pública. A equipe procura alguém para ajudar com efeitos visuais e, por enquanto, não abriu testes, embora já esteja coletando candidatos para um grupo inicial reduzido. Sobre lançamento, a resposta continua vaga: só haverá previsão mais firme depois que a fase de beta estiver bem encaminhada. Console é um objetivo, mas não uma promessa; o time está se mantendo dentro das APIs do MSFS para manter a porta aberta, porém admite que pode precisar de executáveis externos no PC para atingir a performance desejada, o que limitaria ou inviabilizaria uma versão para Xbox. Preço também não foi definido, apenas a promessa de algo “razoável”.
Resumo e Análise Editorial FlySimBR
A abordagem da Rhodiumcode é claramente voltada ao simmer hardcore que valoriza simulação de sistemas em profundidade, e o nível de detalhe na rede IMA indica potencial para um A350 mais “vivo” e coerente em falhas do que o padrão atual do MSFS; por outro lado, o foco pesado em backend, a ausência de prazos e a incerteza sobre console mostram que ainda estamos diante de um projeto de longo prazo, que precisa provar na prática que todo esse investimento em arquitetura complexa vai se traduzir em desempenho aceitável e experiência consistente para o usuário final.
