Orbiter: Newtonian flight with no mission counter

Newtonian flight with no mission counter and no economy

Orbiter puts a Newtonian solar system in front of you and lets you fly a spacecraft through it without ever scoring a point. The sun, the planets and their moons are the playground, and the craft you take over can be historic, hypothetical or drawn straight from science fiction. What you do not get is a mission counter: there are no predefined missions to finish beyond the ones you write for yourself, no aliens to destroy and no goods to trade. The audience that fits is the pilot who wants to work out an ascent into orbit, a rendezvous with a station or a transfer to another planet, not the player waiting for a campaign to hand out objectives.

The hardware table is modest for a 3D simulator. RAM is 500 MB minimum and 2 GB recommended, the CPU row asks for a dual core and leaves the recommended cell empty, the GPU row asks for 50 GFlops minimum and 100 GFlops recommended, and disk is 5 GB minimum against 10 GB recommended. The figure that actually hurts sits in the recommended row of that last line, in a parenthetical: 80 GB if you want hi-res textures.

The recursive clone pulls nested repositories before anything builds

Building starts at the repository, and the flag that matters sits on the clone itself. Over SSH:

git clone --recursive [email protected]:orbitersim/orbiter.git

The HTTPS route produces the same tree without an SSH key configured:

git clone --recursive https://github.com/orbitersim/orbiter.git

You should end up with a top level holding CMakeLists.txt, CMakePresets.json, COMPILE.md, a .vsconfig and compileOrbiter.py, next to the code directories Src/, Orbitersdk/, Script/, Config/, Scenarios/, Flights/, GravityModels/, Tests/, Utils/, Extern/ and cmake/. The README does not say which nested repositories the recursive flag pulls in, and it gives no command for checking that a submodule landed.

After the clone come CMake for the configure and generate steps and Microsoft Visual Studio for the compile itself. VS Community 2019 is the version recorded as building successfully, with a note that other versions should also work. VS2019 carries CMake support in the box, which is why a separate CMake installation is called unnecessary when that generator is used.

A fresh clone cannot draw a planet without a second installation

Here is the gap that a skim misses. This is an open source tree that cannot render a single planet on its own, because the planetary texture files Orbiter needs in order to run are not in the git repository, so a clean clone produces a program with nothing to load. The documented workaround is to install a build from the project download page and then aim the source tree at that installation, with the two kept in separate directories.

Three mechanisms hand over that path. At configure time the CMake entry is `ORBITER_PLANET_TEXTURE_INSTALL_DIR`, and when the installed copy sits in `C:\Orbiter` the value is written with forward slashes, `C:/Orbiter/Textures`. The same key can arrive from an environment variable of that name instead of the CMake option. The third route runs after compiling: set `PlanetTexDir` in `Orbiter.cfg`.

Order matters between those routes. CMake knows the directory at generate time, while `Orbiter.cfg` is read by the binary you already built, so a wrong path never turns into a compile error and you find out at launch instead. High resolution textures are a separate download from the Orbiter website, and they are the reason the recommended disk figure carries 80 GB.

Ninja and VS2019 make the build single threaded on purpose

Two build caveats sit under the compiler choice, and both come from tooling rather than from the simulator. With the Ninja generator, which is what the Visual Studio built in CMake path defaults to, you may also need vspkg to configure the VS toolset. With the VS2019 generator you may have to set Visual Studio to a single thread, because the build tools that generate the Orbiter documentation are not threadsafe and that generator does not understand the CMake `JOB_POOL` directive.

So a parallel build is not a free speedup here, and the documented fix is a Visual Studio setting rather than a CMake one. An architecture constraint also has to line up in two places: Orbiter is a 32-bit application, and both vspkg and CMake must be configured accordingly. Miss that pairing and the failure arrives as a toolchain mismatch rather than a source error.

Documentation is optional and heavy. Turning it on needs a filter that converts ODT and DOC sources to PDF, such as LibreOffice, a LaTeX compiler suite such as MiKTeX, and Doxygen for the source level pages aimed at developers. COMPILE.md is named as the place holding the build details.

The MIT grant stops at the bundled D3D9Client directory

Orbiter is published under the MIT licence, while the D3D9Client graphics engine bundled under OVP/D3D9Client keeps separate LGPL terms recorded in LGPL.txt inside that directory, so the terms inside one repository are not uniform and an MIT grant over the tree does not reach that graphics client. The last push was on 2026-09-27, the only named stable line is Orbiter 2024 from 2024-12-31 next to 2024-rc4 from 2024-12-30, and the rolling artefact is a development build stamped 2026-10-04.

Those two facts set the upgrade budget. Anything newer than the 2024 line is a development build, and the only compiler recorded as working is VS Community 2019, so a machine carrying a newer Visual Studio has no written configuration path.

Beyond the compiler, three entry points sit at the top level for driving builds: CMakeLists.txt, CMakePresets.json and compileOrbiter.py. The README shows none of their contents and names no preset, so a first build starts from plain CMake. The same silence applies to moving an existing tree forward: no upgrade or rollback procedure is written down anywhere in the repository, which leaves you diffing the tree yourself.

Help files live in Doc and exist only if you built them

Help is a build product here, not a download. The help files sit in the Doc subfolder, and they are there only if you built them, with Orbiter User Manual.pdf named as the main user manual. Inside a running simulator the same material opens from the Help button on the Orbiter Launchpad dialog, or from Alt-F1.

That ties the manual to the build route. The PDF appears when the conversion chain ran, and no separate download for it is described, so a source build carries the cost of LibreOffice, MiKTeX and Doxygen before a single help page opens. For anything the documentation leaves out, the stated place is the Orbiter user forum at orbiter-forum.com.

The in-game path has a gap of its own. Nothing describes shipping a modified manual or pointing the built in help system at an external PDF, so extending the documentation means editing the sources that feed the converter rather than dropping a replacement file into the tree.

Choosing the packaged build trades source access for textures

The nearest alternative to compiling is not a different simulator, it is the packaged Orbiter build that the texture instructions already tell you to install. The difference in approach is concrete. A packaged build arrives with the texture set the repository omits, needs no CMake, no Visual Studio and no vspkg alignment, and starts from a 32-bit binary you did not compile. The source tree hands you that binary's inputs instead: the 32-bit target you control, Orbitersdk/ for add-ons, Script/ and Scenarios/ for content, and the freedom to change behaviour, but nothing to render until `ORBITER_PLANET_TEXTURE_INSTALL_DIR` resolves.

Keeping both is the intended arrangement, which is why the two installations are told to sit in separate directories. The price of that arrangement repeats itself: every fresh clone has to be aimed at the texture installation again, and a tree copied to a second machine loses the setting unless the environment variable travels with it. Choosing the source route is a choice to own that step.

No missions and no trade is the deal, not a missing feature

Against commercial games with a space theme, the contrast is the one Orbiter draws for itself: no predefined missions beyond the ones you set, no aliens to destroy, no goods to trade, Newtonian mechanics in exchange. What you get for that difficulty is control. Ascent profiles, rendezvous geometry and transfer windows are yours to compute rather than yours to trigger, and nothing in the project supplies an objective on your behalf.

That makes it the wrong tool in specific situations. If you want a story, a progression curve or a first flight that finishes, the absence of scripted missions leaves you to write the scenario, and the project says as much, noting that some people get hooked while others get bored. It is also the wrong choice when your toolchain cannot produce a 32-bit Windows target, since that requirement is fixed in the documented build, and when your disk cannot hold the 10 GB recommended, let alone the 80 GB that hi-res textures need.

Editorial conclusion

Orbiter suits pilots who want Newtonian flight without a mission counter, and it suits you badly if you want a campaign or a modern graphics pipeline. Build once from a clean clone and confirm ORBITER_PLANET_TEXTURE_INSTALL_DIR resolves, because the repository alone cannot render a planet. If you only want to fly, stay on the packaged build and skip the toolchain. Every fresh clone then has to be re-pointed at the texture installation, and redistributing a build means reading the terms in OVP/D3D9Client first.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. orbitersim/orbiter on GitHub
4. README
5. Releases