Skip to content

Launcher: add an opt-in switch to start without plugins - #3379

Merged
isaacsa2 merged 18 commits into
openOMSI-org:mainfrom
isaacsa2:feat/launcher-disable-plugins-20261027
Oct 28, 2026
Merged

isaacsa2 merged 18 commits into
openOMSI-org:mainfrom
isaacsa2:feat/launcher-disable-plugins-20261027

Conversation

@isaacsa2

Copy link
Copy Markdown
Contributor

What changes for the player?

Settings > General gains Disable plugins, off by default. Turning it on starts the next game without plugins; turning it off restores them on the next start. The choice is saved between launches and applies to a new duty, a saved situation and a tutorial.

This gives players a way to check whether a plugin is involved in a freeze without moving files or setting an environment variable. It does not establish that plugins caused a particular report. Normal OMSI bus scripts still run; features provided by plugins will be unavailable.

How to test

  1. Leave the option off and start a duty with a known working plugin. Its usual features should be available.
  2. Turn the option on, close the running game and start another duty. The command line should contain --no-plugins, and the log should say plugins are disabled for this session. Global Lua/compiled plugins, legacy OMSI plugins, vehicle Lua plugins and scenery Lua plugins should not load.
  3. Repeat with a saved situation and a tutorial. Change another launcher setting, restart the launcher and confirm the option stays on.
  4. Turn it off and start again: plugins should return. OMSI_NO_PLUGINS=1 remains an independent override, so unset that override when checking restoration.

An existing game is not hot-unloaded. For the reported integration-stage freeze, compare the same map, bus and settings with only this option changed, and attach the new log. Discord and Steam have their own integration paths.

Screenshots

Before and after: the actual launcher UI served with the repository's mock fixtures, at the same 1280×720 viewport and General tab. The old version label comes from the fixture; these are interface checks, not a native game build.

plugin-settings-before plugin-settings-ui

What does this change, and why?

The launcher persists disable_plugins in settings.cfg and passes --no-plugins through a shared argument prefix before the saved-game/tutorial early returns. The game keeps that choice for the session and checks it at global loading, vehicle attachment and lazy object-plugin driving. The existing environment override still works. No process-wide environment mutation is needed, and the normal bus-script runtime is unchanged.

The label and help are in app.yml with Brazilian/European Portuguese, Spanish, French and German translations. The user guide explains the scope and restart requirement.

Validation

  • Launcher core: 111 passed, 2 failed, 2 ignored. Both new regressions pass: preference/default/save round trips and enabled/disabled arguments for all three entry paths.
  • The two failures are the existing process-identity tests: this container cannot read its own start time through /proc/<pid>/stat. An isolated run of main's unchanged process_start helper reproduces the same None precondition. No process-management code changes here.
  • Actual Settings page in headless Chromium: default off and both toggle directions reach saveSettings, using mock transport. Rust tests cover persisted serialization separately.
  • Locale validation: 0 errors and 0 warnings. Size budget, crate layers, JavaScript syntax and whitespace checks pass.
  • All nine published files were compared byte for byte with the locally checked source.
  • A focused omsi-app CLI/disabled-loader test is included. Its local build and the platform/workspace CI are still pending; a full workspace test or release build has not been claimed.

What could break?

Disabling plugins deliberately removes their features, including bus/map features supplied by Lua plugins. It does not disable normal OMSI scripts or diagnose every possible integration freeze. Native Windows legacy-plugin startup, real-map driving, Android, VR and multiplayer still need testing with the build artifacts.

Performance

No driving benchmark was available. This adds a saved launcher preference and session guards, with no renderer, GPU passes or allocation-policy change. There is no FPS improvement claim. The option is off by default; a same-map native performance comparison remains pending.

Checklist

  • cargo test --workspace and cargo build --release pass
  • One player-facing change: optional plugin isolation
  • New interface texts are in app.yml
  • Existing settings without the key keep plugins enabled; saves are not rewritten
  • Native plugin/restoration and same-map performance tests completed
  • No original OMSI 2 assets or new large files; the existing locale catalogue has only the two added entries

@thibautgnt thibautgnt left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @isaacsa2, this is a really useful troubleshooting switch, and passing --no-plugins from one shared argument prefix (so a new duty, a saved situation and a tutorial all get it, with tests for each) is clean. A few things before merging:

  1. Conflict with main, only in crates/omsi-launcher-core/src/lib.rs, in settings_from_text_on (main 2454-2456 / PR 2434-2435). #3309 (unified UI theme) split nav_light and nav_classic_2d out of the long boolean arm onto their own lines. Resolution: take main's side as is (the long arm without them, "nav_light" => ..., "nav_classic_2d" => ...) and only change main's "info_bar" => v[&k] = json!(b(val)), into "info_bar" | "disable_plugins" => v[&k] = json!(b(val)),. Do not keep the PR's version of the long arm, it would reintroduce nav_light / nav_classic_2d there. app.yml, tests.rs and settings-schema.js auto-merge. With that resolution size budget, arch guard and the locale check pass.
  2. The game respawns itself without the flag, so plugins come back in the middle of a troubleshooting session: crates/omsi-app/src/app_impl/saves.rs:78 (load_quicksave, the quickload) and saves.rs:170 (restart_after_device_loss, which is exactly the kind of restart a freeze investigation hits) build a new command line from scratch. OMSI_NO_PLUGINS survived these because it is inherited from the environment, the new CLI switch is not. Fix: after the --situation arg in both places, if self.args.no_plugins { cmd.arg("--no-plugins"); }.
  3. Translations: the two new texts (app.yml:29911 "Disable plugins" and app.yml:29917, its help) have 5 languages (es, fr, pt, pt-pt, de) where the catalogue's texts carry all 29 (zh-tw, ru, ka and sr are missing, among others), so most players see the option in English. Please add the other 24.

Non-blocking:

  • The help text could say that a game already running keeps its plugins until the next start, as the user guide does ("Starts the next game..." mostly says it already, so optional).

@github-actions

github-actions Bot commented Oct 27, 2026 •

Copy link
Copy Markdown
Contributor

Test builds for 77ad24e

Platform Download
Android (arm64) android.zip
Linux x64 (game and dedicated server) linux-x64.zip
macOS (Apple silicon) macos-arm64.zip
Windows x64 (game and dedicated server) windows-x64.zip
  • Unpack the download into a new folder, not over your openOMSI. The launcher shows the version as ...-pr3379, and a test build is never updated. It shares your settings and OMSI 2 folder; mods you installed into your openOMSI folder are only seen when you unpack it into a copy of that folder.
  • Android: the download holds an APK that installs as a separate app, openOMSI PR Launcher: add an opt-in switch to start without plugins #3379, beside the release, and shares its openOMSI folder.
  • What to try is under How to test in the description. Please comment with what you found and the version the launcher shows.
  • The links work for 14 days after the build.

chore: sync latest main into PR openOMSI-org#3379 after locale fixes
@isaacsa2

Copy link
Copy Markdown
Contributor Author

Thanks for the detailed review!

I've checked the latest branch state, and all three requested changes are now included in "77ad24e":

  1. Merge conflict: The settings parser retains main's separate "nav_light" and "nav_classic_2d" match arms, with "disable_plugins" added alongside "info_bar". No regression to the unified UI theme handling.

  2. Plugin isolation across restarts: Both "load_quicksave" and "restart_after_device_loss" now forward "--no-plugins" when enabled, keeping plugins disabled throughout the troubleshooting session.

  3. Translations: Both new UI strings now cover all 29 catalogue languages, including the previously missing languages.

The PR test-build workflow for "77ad24e" also completed successfully.

Native plugin loading/restoration testing is still pending, so I'm not claiming full runtime validation yet.

Thanks again for catching the restart issue, especially the device-loss recovery path. That would have undermined the troubleshooting switch exactly when it was needed.

The requested code changes are in place. Ready for another review!

@isaacsa2
isaacsa2 requested a review from thibautgnt October 27, 2026 14:23

@thibautgnt thibautgnt left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @isaacsa2, all three points are done and the rest of the change is untouched, so this is good to go from my side.

  • Conflict: settings_from_text_on keeps main's separate nav_light and nav_classic_2d arms and only adds disable_plugins next to info_bar (crates/omsi-launcher-core/src/lib.rs:2455). It still merges cleanly with current main.
  • Restarts: load_quicksave and restart_after_device_loss both forward --no-plugins now (crates/omsi-app/src/app_impl/saves.rs:79 and :171), so plugins stay off for the whole session.
  • Translations: both new texts have all 29 languages, and the locale check vs current main passes (+2 keys, no errors, no warnings).

Non-blocking:

  • The branch history still has the two temporary locale commits (a workflow and a script added, then removed by the bot commit). The final tree is clean, so a squash merge keeps them out of main.

@isaacsa2
isaacsa2 merged commit c627fce into openOMSI-org:main Oct 28, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants