OpenTTD Blueprint

What it is

A pair of installers — one Bash, one PowerShell — that take an OpenTTD installation you already have and bring it to a specific, reproducible configuration: a curated set of add-ons in a known load order, with matching parameters and game settings.

Run the script, get the same setup, on either platform.

The problem

Getting OpenTTD into a particular state is fiddly and easy to get subtly wrong. A dozen add-ons, each needing the right version, in the right load order, with parameters set to match each other, plus game settings that assume all of it is present. Do it by hand and it works; do it again six months later on another machine and it doesn’t, in ways that only show up hours into a game.

The obvious fix is to bundle everything into an archive and unpack it. That fix is also the problem — you have just become a redistributor of a dozen other people’s work, under a dozen licences you did not read.

Reproduce, don’t redistribute

The repository contains no third-party content at all. No add-ons, no game binaries, no assets. What it contains is a manifest: content identifiers, last-tested versions, load order, parameters, and the settings that go with them.

Worth being precise about what that reproduces. The content set, its load order, its parameters and the game settings are reproduced exactly. The version is not guaranteed: acquisition resolves each item against OpenTTD’s catalogue as it currently stands, and its console interface offers no documented way to request an exact historical version non-interactively. The manifest’s version is the last one tested, to diff against — not a promise about what will land.

Everything else is fetched at install time, from its original source, under its original author’s licence.

It isn’t a downloader

This is the part worth explaining, because the obvious implementation would be to fetch content from the community content service directly.

Blueprint doesn’t do that either. It drives OpenTTD’s own console commands and lets the game’s built-in Online Content system do the fetching. There is no scraping, no unofficial mirror, and no download code of its own to get wrong or to go stale when the service changes.

Blueprint never handles or stores the content itself. It describes what is wanted and asks the game to fetch it.

That decision produced the project’s most interesting bug. Content identifiers turned out to be reported in one byte order by the service’s own package URLs and the opposite order by the game console’s listing — but only for some content types. Rather than hardcode a guess about which types swap, the implementation checks both valid forms and takes whichever matches. Filenames and script identifiers are likewise read back from the game’s own output instead of being predicted. Observed behaviour first, then an implementation that tolerates it.

One blueprint, two platforms

The Bash and PowerShell implementations are deliberate ports of each other rather than two tools that happen to do similar things. Shared logic lives in the manifest, not duplicated in each installer. Windows uses its built-in tar where Linux uses tar, so neither side needs an extra dependency.

Both support a dry run that writes nothing, back up existing configuration before changing it, are safe to re-run, and have an uninstaller that restores what was there before.

Linux needs Bash 5+ with jq, tar, find and awk. Windows needs PowerShell 7+ — the version built into Windows is not enough. Neither needs administrator or root. macOS is not supported.

What it validates

Two CI workflows, both green: ShellCheck plus a fixture test suite on Linux, PSScriptAnalyzer plus a fixture test suite on Windows. Linting and tests are separate things and both run.

32 tests on the Linux side, and a comparable set on Windows. They deliberately never touch a real OpenTTD installation and never use the network — they run against fixtures and a throwaway directory, which is what makes them deterministic in CI.

That leaves real end-to-end installation as manual validation, and it earns its keep: a live stability check found three genuine bugs that fixture tests could not have caught, including one where a content pack’s own settings conflicted with another’s.

What it doesn’t own

Blueprint’s own code, manifests and documentation are AGPL-3.0-or-later. That covers this project’s work and nothing else.

It does not extend to OpenTTD, or to any add-on the tool causes to be downloaded. Those keep their own licences — mostly GPL — regardless of how they were acquired. The repository documents every item it references with its licence and original source, and bundles none of them.

It is also an independent project. Not an official OpenTTD project, and not affiliated with or endorsed by it.

Where it stands

Active, at v0.2.0. Public and open source; releases up to v0.1.0 were MIT and those grants stand.

No external adoption is verified — no stars, no forks, no contributors, and no users I know of. A public repository can be cloned quietly, so that is a statement about what I can see, not about what has happened. It is a working tool that happens to be public, not a project with a community.

Source

Official upstream: github.com/Sako404/openttd-blueprint.