Durante muito tempo, abrir o OMSI significou basicamente a mesma coisa: iniciar o executável, ajustar manualmente o que fosse necessário, escolher mapa, veículo e condições e então começar a sessão.
Para jogar, isso funciona.
Para quem desenvolve ferramentas, testa conteúdo ou precisa integrar outros sistemas ao simulador, começa a aparecer outro problema: como garantir que todos estão iniciando o OMSI da mesma forma?
Como repetir exatamente um teste que apresentou determinado comportamento? E distribuir uma configuração específica para um mapa sem sobrescrever permanentemente as opções do usuário? Como um sistema de multiplayer pode preparar vários jogadores seguindo uma mesma lógica de sessão, sem depender de uma lista de instruções manuais? Foi a partir desse tipo de problema que surgiu o OmsiLaunch.
Não é simplesmente outro launcher
Apesar do nome, a proposta do OmsiLaunch não é substituir a tela inicial do OMSI por outra interface.
O projeto funciona como uma camada de controle entre outras aplicações e o simulador, permitindo definir, preparar, iniciar, acompanhar e encerrar sessões de forma programável. Isso significa que uma interface gráfica pode utilizar o OmsiLaunch. Um sistema de multiplayer também. Uma ferramenta de testes, um gerenciador de conteúdo, um projeto de telemetria ou scripts próprios utilizados por desenvolvedores podem trabalhar sobre a mesma base.
Hoje essa estrutura pode ser utilizada pela API pública, pela interface de linha de comando (CLI) ou pelo OmsiLaunchW.exe, que permite iniciar e acompanhar sessões sem manter uma janela de terminal aberta, com informações e controles disponíveis pela bandeja do Windows.
E para quem está pensando em desenvolver um launcher ou gerenciador próprio para OMSI, o OmsiLaunch também foi feito para isso: em vez de cada nova ferramenta precisar criar novamente sua própria lógica para preparar configurações, iniciar o simulador, acompanhar a sessão e restaurar o ambiente depois, essa camada pode ser reutilizada e a aplicação pode se concentrar na experiência que deseja oferecer ao usuário.
Repetir um teste exatamente da mesma forma
Quem desenvolve conteúdo para o OMSI conhece bem uma situação comum: alguma coisa apresenta um problema, fazemos alguns testes, alteramos configurações, reiniciamos o simulador e depois tentamos reproduzir novamente o mesmo cenário. Só que nem sempre lembramos exatamente tudo o que estava configurado.
Com uma sessão definida através do OmsiLaunch, esse processo pode se tornar reproduzível. Um teste pode determinar previamente qual mapa será carregado, qual ponto de entrada será utilizado e quais condições precisam existir antes da execução.
O próprio desenvolvimento do OmsiLaunch já utiliza esse conceito em seus testes internos, executando cenários conhecidos de forma repetível para verificar o comportamento do simulador e das funções implementadas.
Isso pode ser útil para desenvolvimento de veículos, mapas, plugins e scripts, mas também para uma situação bem mais simples: enviar para outra pessoa exatamente o cenário em que determinado problema deve ser testado. Em vez de explicar todas as etapas manualmente, a sessão pode definir parte considerável daquele ambiente.
Configurações específicas sem destruir a configuração do usuário
Outro problema bastante conhecido aparece principalmente em mapas e projetos maiores. Determinados conteúdos podem precisar de uma configuração específica do OMSI. Quantidade de veículos, opções da simulação, parâmetros gráficos ou outros ajustes podem precisar ser diferentes dependendo do projeto utilizado.
Hoje, normalmente existem duas alternativas: pedir que o usuário altere tudo manualmente ou distribuir arquivos de configuração prontos para substituir os existentes. Nenhuma das duas é particularmente interessante.
O OmsiLaunch trabalha com alterações temporárias vinculadas à sessão. Antes de iniciar o OMSI, os arquivos e configurações necessários podem ser preparados e, ao final, as modificações de responsabilidade do OmsiLaunch são restauradas. O sistema também mantém registros suficientes para recuperação quando uma sessão é interrompida de forma inesperada.
Na Beta 3 isso já pode ser organizado através dos Session Profiles. Um autor de mapa ou outro conteúdo pode preparar um perfil com configurações recomendadas para aquele projeto e distribuí-lo para que o jogador inicie a sessão sem precisar reproduzir manualmente uma lista de alterações.
O perfil pode ser utilizado diretamente pelo OmsiLaunch ou por outra ferramenta construída sobre ele. Quando a sessão termina, o OmsiLaunch desfaz as alterações temporárias que aplicou. Alterações normais feitas pelo próprio OMSI durante sua execução — como caches, logs e estados que o simulador grava normalmente — continuam pertencendo ao próprio OMSI.
Um caminho comum para multiplayer
Talvez uma das aplicações mais interessantes seja multiplayer: um sistema multiplayer para OMSI precisa resolver muito mais do que simplesmente transmitir a posição de um ônibus pela internet.
Antes mesmo disso, os participantes precisam entrar em uma sessão compatível. Mapa, horário, condições da simulação e diversos outros estados precisam seguir uma lógica comum. Sem uma camada intermediária, cada projeto acaba precisando desenvolver sua própria forma de preparar e acompanhar o simulador.
Com o OmsiLaunch, essa parte pode seguir um caminho comum. Um módulo de multiplayer pode preparar a sessão necessária, iniciar o OMSI de forma controlada, acompanhar sua execução e então trabalhar com suas próprias funções de sincronização sobre aquela sessão.
O OmsiLaunch não é o multiplayer – ele pode ser uma das peças utilizadas para construí-lo! E essa diferença é importante porque a mesma estrutura pode ser utilizada por projetos completamente diferentes.
Uma base para outras ferramentas
A mesma lógica pode ser aplicada a vários outros tipos de projeto.
Um sistema de telemetria pode acompanhar externamente os dados de uma sessão e comparar diferentes execuções padronizadas. Uma ferramenta voltada a desenvolvedores pode automatizar cenários de teste. Um instalador ou gerenciador de conteúdo pode preparar o ambiente necessário para determinado mapa, veículo ou projeto antes de iniciar o simulador.
Também não existe uma única interface obrigatória. É possível construir um launcher visual sobre o OmsiLaunch, utilizá-lo de forma transparente dentro de outra aplicação, trabalhar diretamente pela linha de comando ou integrar sua API a um sistema próprio.
A proposta é justamente separar a lógica de controle da forma como cada aplicação será apresentada ao usuário. Assim, projetos diferentes podem reutilizar a mesma base para preparar, iniciar e acompanhar o OMSI sem precisar reconstruir toda essa infraestrutura por conta própria.
Isso também permite que diferentes ferramentas compartilhem uma mesma forma de trabalhar com sessões. Um autor de conteúdo pode preparar um Session Profile sem precisar criar um launcher próprio, enquanto launchers, gerenciadores e outras aplicações podem consumir essa definição e apresentar sua própria experiência ao usuário.
Sessões que podem ser preparadas e depois desfeitas
Controlar uma sessão também significa saber exatamente o que foi alterado durante ela.
O OmsiLaunch trata modificações temporárias como parte do ciclo de vida da própria execução. Arquivos e configurações necessários podem ser preparados antes da inicialização do OMSI, utilizados durante aquela sessão e posteriormente restaurados quando ela termina.
Isso permite que uma ferramenta adapte temporariamente a instalação às necessidades de um teste, mapa ou integração sem transformar essas alterações em modificações permanentes na configuração do usuário.
Esse modelo também facilita aplicações que executam o OMSI repetidamente em cenários diferentes: cada sessão pode preparar seu próprio ambiente e, ao final, devolver a instalação ao estado anterior antes que a próxima execução seja iniciada.
Versão atual: 0.1.0-beta.3
A versão pública atual do OmsiLaunch é a 0.1.0-beta.3, destinada ao OMSI 2.3.004.
Depois da primeira beta pública, o foco desta versão foi consolidar a base do projeto antes de ampliar novamente suas funções. O ciclo da Beta 3 incluiu testes extensivos dentro do próprio OMSI, revisão do controle de sessões, transações e recuperação, API pública, CLI, comunicação com o runtime, OmsiLaunchW.exe, bandeja do Windows, Session Profiles e empacotamento.
Parte das correções desta versão surgiu justamente durante esses testes e durante uma revisão completa da própria documentação e dos exemplos de uso.
A documentação técnica também foi ampliada e revisada integralmente, cobrindo instalação, primeira sessão, API pública, CLI, Session Profiles, LaunchSpec, controle de runtime, IPC local, ciclo de vida, recuperação, erros, compatibilidade e outras áreas do projeto. Além da referência original em inglês, ela está disponível em 15 idiomas.
O OmsiLaunch continua em Beta e novas capacidades ainda serão adicionadas, mas a Beta 3 estabelece uma base bem mais consolidada para jogadores, autores de conteúdo e desenvolvedores começarem a utilizá-lo em projetos reais.
Detalhes
Nome: OmsiLaunch
Versão: 0.1.0-beta3
Tipo: Controle e orquestração de sessões do OMSI 2
Compatibilidade: OMSI 2.3.004
Plataforma: Windows
Interface: API pública, CLI e OmsiLaunchW.exe / bandeja (System Tray) do Windows
Distribuição: Gratuita e open-source
Licença: GNU Lesser General Public License v3.0 (LGPL-3.0-only)
Código-fonte: Público
Status: Beta
Projeto e desenvolvimento: Leo Monteiro
Referência técnica: OmsiHook / Omsi-Extensions, por space928
O projeto mantém também os respectivos avisos e referências dos componentes e códigos de terceiros utilizados ou estudados durante o desenvolvimento.
Site oficial, download e documentação
No site oficial estão disponíveis a versão atual, acesso ao código-fonte no GitHub e a documentação completa do projeto. A documentação possui caminhos diferentes para jogadores, autores de conteúdo e desenvolvedores que desejam utilizar a API, CLI ou integrar o OmsiLaunch a outras aplicações.