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 telemetria, um instalador de mapas ou até scripts próprios utilizados por desenvolvedores podem trabalhar sobre a mesma base.
A interface de linha de comando presente na primeira versão é apenas uma das formas de utilizar essa estrutura. A ideia é justamente permitir que outras aplicações construam seus próprios fluxos sobre uma base comum, em vez de cada projeto precisar desenvolver novamente sua própria forma de preparar e controlar o OMSI.
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 a ideia de alterações temporárias vinculadas à sessão. Antes de iniciar o OMSI, os arquivos necessários podem ser preparados. Durante aquela sessão, as configurações definidas permanecem ativas. Quando ela termina, os arquivos anteriores são restaurados.
Essa restauração também faz parte do controle da sessão quando alguma coisa não termina exatamente como deveria. O projeto mantém registro das alterações realizadas e possui mecanismos de recuperação para restaurar o estado anterior quando uma sessão é interrompida de forma inesperada.
Isso abre uma possibilidade interessante para autores de mapas e outros conteúdos: em vez de escrever no manual que o usuário deve alterar uma série de opções antes de jogar, um projeto pode futuramente distribuir uma sessão preparada para aquele conteúdo. O usuário inicia o mapa com as configurações adequadas e, quando termina, continua com sua instalação exatamente como estava antes.
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.
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.
Primeira beta pública
A primeira beta pública do OmsiLaunch é a 0.1.0-beta2. O projeto é destinado à versão 2.3.004 do OMSI 2.
Ainda é uma versão inicial e várias partes do controle do simulador continuam em desenvolvimento, mas a estrutura principal já está disponível, documentada e pode ser utilizada. O projeto é open-source e sua documentação apresenta de forma mais detalhada os conceitos por trás da arquitetura, as capacidades atualmente disponíveis, exemplos de utilização e as limitações desta primeira beta.
Os casos citados aqui são apenas alguns exemplos. Testes padronizados, configurações temporárias, multiplayer, ferramentas de desenvolvimento, telemetria, gerenciamento de viagens e outras aplicações podem partir da mesma base e construir fluxos completamente diferentes.
Detalhes
Nome: OmsiLaunch
Versão: 0.1.0-beta2
Tipo: Controle e orquestração de sessões do OMSI 2
Compatibilidade: OMSI 2.3.004
Plataforma: Windows
Interface: API pública e interface de linha de comando (CLI)
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 o download da versão atual, acesso ao código-fonte, documentação técnica, conceitos do projeto e informações para desenvolvedores.