EDControlRoom

⚠️ This violates the Elite Dangerous Terms of Use

Frontier defines automation as more than one action in game per button press, and does not permit it. (source)

This tool is well past that line. Do not run it on an account you'd mind losing. No warranty, no assurance of account safety.

Multiplatform Elite Dangerous command-and-routine tooling. It handles the repetitive station-side loop of trading and hauling so the commander can stay focused on the parts that still benefit from human attention. It is not a hands-off flight bot.

Live-validated on macOS (Elite through CrossOver) and Windows (community-validated). Linux paths exist in the code but are not yet validated.

Contents

• The Idea
• What You Get
• Quick Start
• Documentation
• Development
• Repo Layout
• Contributing
• License

The Idea

A co-pilot, not an autopilot. You stay focused on flying; EDControlRoom takes over anything that lives behind a game menu.

The flagship is the two-way haul routine. When your ship drops near a station, it handles the boring bits end to end: request docking, work through station services, sell, refuel and repair, buy the return cargo, set the next-leg route, undock, clear mass lock, and prime the FSD. When the drive is primed it uses TTS to call the commander by title or name and announce the ship is ready to jump — that is your cue to take over for alignment and the next jump.

That makes it a direct fit for high-volume A↔B cargo work like community goal loops or long chill hauls, where the station-to-station cycle is the part worth automating and human attention is better spent on flying.

See it in action: live stream demo — co-pilot handling a station cycle

What You Get

A terminal Control Room with TTS callouts, a LAN web frontend for haul dashboard / search / Spansh routing, and journal-driven dock, undock, jump, buy, sell, dest, home.

(Expand / click the following sections to see the screenshots.)

Terminal Control Room (TUI) — ship status, activity log, market, and haul session, with TTS callouts.

• Live panels: SHIP STATUS (commander, system, station, fuel, cargo, FSD target), ACTIVITY log, and MARKET table from Market.json.
• Full command bar for dock, undock, jump, buy, sell, dest, home, travel, market ....
• Start haul work from the command bar: haul [commodity], haul start, haul load, haul search [system], haul search url <inara-url>, haul route <n>, multi_leg_haul <route>.
• pause / resume an active two-way haul; stop and new_session control the persisted session timer / profit.
• Ctrl-R reopens replay / command history; Ctrl-C interrupts (haul-aware safe stop first, cancel on second).
• Speaks TTS callouts locally, e.g. "commander, ship ready to jump" at the end of a leg.

Web dashboard — two-way haul control with live session stats and routine progress.

• Quick stats strip: home system, current system, destination, cargo, routine, completed runs, session profit.
• Active routine board with the five haul stages (Buy, Undock, Depart, Transit, Sell) plus elapsed, current / accumulated credits, and cargo moved.
• Active route panel: jumps remaining, LY remaining, boosts remaining for the dispatched Spansh route.
• Header controls: Pause, Resume, Stop after run, Stop now, Save the current haul as the default, Reconnect, and Instant off for the 5-second safety delay.

Haul search — Inara-backed profitable route finder with one-click dispatch.

• Filter by origin (and optional destination), max route distance with presets, station distance, cargo capacity, profit metric, and min supply / demand.
• Results sort by profit / hour or profit / trip and show cargo, both stations, distance, and route LY.
• Start route hands the selected pair to the two-way haul routine; Set destination just routes there; Travel assist flies to an arbitrary system + station without hauling.
• Same search is reachable from the TUI via haul search [system] and haul search url <inara-url>; haul route <n> picks a numbered result.
• Note: v1 excludes surface / land settlements — station and carrier routes only.

Spansh route — fetch a Spansh route and compare it side-by-side with the in-game route.

• Inputs: from / to system, jump range (LY, unladen), efficiency, supercharge mode, optional final station, all-in-one navroute wait, and compare retries. From, jump range, and supercharge mode auto-fill from live ship state (current system + Loadout event); wait / retries auto-fill from server config.
• Fetch Spansh to pull a route, Set in-game route to plot it in Elite via the galaxy map, Compare to diff Spansh vs the plotted route jump-by-jump, or All in one to run the full flow.
• Switch to Spansh starts the standalone Spansh route runner: it flies the fetched route waypoint by waypoint, and every time you arrive at a waypoint it automatically sets the galaxy map to the next one.
• Route detail table shows system, neutron flag, +LY per jump, and cumulative total for both routes side by side. Dashboard's Active route panel tracks jumps remaining / LY remaining / boosts while the runner is active.

Quick Start

uv sync
uv run python3 control_room.py lan

lan starts a headless server and prints the bound URL on startup (e.g. http://192.168.1.50:8765). Open that URL in a browser to use the web frontend — ideally on a secondary device (tablet, phone, or another laptop) so Elite can stay the foreground application on the game machine. Routines drive Elite by key input, and alt-tabbing away from the game window will break them.

lan does not run a TUI or speak TTS. For TTS callouts, attach a TUI client from another terminal (same machine or another LAN box). Paste the URL lan printed, or use the shorter host:port form:

uv run python3 control_room.py connect http://<ip>:8765/ --token edcr
uv run python3 control_room.py connect <ip>:8765 --token edcr

Both the server and the web page default to token edcr, so no --token override is needed unless you want a different one.

Before your first run: set arrow-key secondaries on UI_Up / UI_Down / UI_Left / UI_Right in Elite. See docs/user/bindings-setup.md.

Full walkthrough: docs/user/getting-started.md.

Documentation

• docs/user/: install, bindings, getting started, haul workflow, commands, troubleshooting.
• docs/operators/: operator references (control room, remote / multi-client, bindings files, input and market timing).
• docs/diagnostics/: CLI and bindings reference for diagnostics.
• docs/status/README.md: maintained project status entrypoint.

Development

Use the repo uv environment for tests:

uv run python3 -m unittest discover -s tests

main is the active rolling-update branch; stable features and releases are marked with semantic version tags like v1.22.0. Commits use Conventional Commits (feat:, fix:, refactor:, docs:, chore:).

Repo Layout

• control_room.py: primary operator surface at the repo root.
• tools/: supported auxiliary CLIs (run_routine.py, diagnostics.py, ship_controls.py, bindings helpers).
• edap/: active runtime code.
• tools/scratch/: exploratory probes and one-off validation helpers.
• archive/legacy-windows/: historical Windows-era reference code.

Contributing

Issues and PRs welcome. Before opening a PR:

• Follow Conventional Commits for commit messages.
• Run the test suite: uv run python3 -m unittest discover -s tests.
• If your change touches user-visible behavior, update the relevant doc under docs/user/ or docs/operators/.

Bug reports and feature ideas are best filed as GitHub issues with journal / config details when relevant. Chat and questions: Discord.

License

MIT. See LICENSE. This project traces back to the original ED autopilot work by SKai2 and is being maintained and reshaped for the macOS-first Control Room direction.