JGR's Patchpack extends OpenTTD with signalling and rail physics

A separate game build, not something you load into a normal install

The distinction at the top of the README settles how you should think about this project. JGR's Patchpack is a collection of features and other modifications applied to OpenTTD, and it is a separate version of the game which can be installed and played alongside the standard game, not a loadable mod, whether that is a NewGRF or a script.

That has consequences in both directions. You cannot drop it into an existing OpenTTD installation as an add-on; you install a second, patched build and run that. But you also keep the standard game, so you can compare the two, play multiplayer on whichever you prefer, and return to vanilla without uninstalling anything.

The audience is stated as well as implied. The README says this is mainly intended to be used by players who are already familiar with the standard game and how to play it, and that it is not aimed at beginner or novice players. Some features and settings are there for very experienced players and so may have a steep learning curve.

For context, OpenTTD itself is a transport simulation game based on Transport Tycoon Deluxe, written by Chris Sawyer, which tries to mimic the original as closely as possible while extending it with new features. The patchpack inherits that base and works inside it.

The documentation layout is worth noting before you dig in. The README links a changelog in jgrpp-changelog.md, a wiki with guides on how to use the included features, an installation.md with instructions on how to install, and a thread on the TT-Forums. The feature list in the README is a summary; the wiki is where the mechanics are explained, and for a project of this depth the wiki is the documentation.

Signalling is the centre of gravity

Reading the feature list, one subsystem dominates: signalling and train control.

Routing restrictions let you decide which paths a train may take, with a guide on the wiki under Signalling. Programmable pre-signals are signals whose behaviour depends on what comes next rather than on a fixed rule, and the README notes they are not shown in the build signal window by default. No-entry signals work the same way and are also hidden by default. There is a setting for whether to pathfind up to the back of a one-way path signal, and multi-aspect signal graphics, which the README says requires a NewGRF that supports it and realistic train braking.

That last dependency is the interesting one, because it shows the patches are designed to interlock. Signal behaviour, signal graphics and train physics are three separate mechanisms that only work correctly when they agree with each other.

Around that core there is a long tail of quality of life changes: remembering the last used signal type between games, a client setting to show all signals using the default base set sprites, a client setting for the introduction year of train wagons, a setting for rail depot maximum speed, and a setting to allow auto-fill signal dragging to skip over stations and waypoints.

For a player, the effect is that the game stops treating signalling as decoration. Pre-signals and routing restrictions are the difference between a network that looks like a railway and one that behaves like one, and the patchpack's own framing, that nearly all of the listed patches have been modified, fixed or extended in some way and are therefore not the same as the originals they are linked to, suggests this is a mature rather than a fresh set of changes.

Realistic braking turns train length into a constraint

The second major change is train physics, and it is the one that changes how you play rather than how you configure.

In realistic train braking mode, trains have a stopping distance and will reserve ahead accordingly, and they cannot stop instantly. Combined with drive-through train depots, which allow a train to be driven through a depot without being picked up, and freight train through load, an alternative loading mode for freight trains where the train is longer than the platform, the patchpack makes length and speed into network design variables.

The rest of the rail system follows from that. Multiple rail types per tile means a single tile can carry different rail, with a setting to sort track types by category and speed, and a setting to allow converting track type under trains when compatible with the new rail type. There is a polyline rail track building tool, a setting to enable flipping direction of all train types in a depot, and a feature where trains adjust their speed to match the train in front to avoid stop-start behaviour.

The interface changes too. A new train purchase window puts locomotives and wagons in separate lists, the train info window shows information about full and empty loads and achievable speeds, and there is a news setting for trains waiting because of routing restrictions, which is a small touch that tells you the signalling system is feeding back into the news message system.

What the README does not do is quantify any of this. There is no performance figure and no statement about compatibility with particular NewGRF sets, so the honest way to evaluate it is to read the wiki guides for the specific features you care about.

Roads, crossings, bridges and tunnels get the same treatment

The road and infrastructure sections show that the patchpack is not only about railways.

For roads there are one-way road and road vehicle overtaking enhancements with a wiki guide, a setting to allow articulated road vehicles to overtake, a setting to control road vehicle re-routing when the road layout changes, a setting to disable road vehicles from passing through each other when blocked for an extended period, and a setting to turn off road vehicles slowing in curves. Pathfinding is improved when multiple vehicles head for a station with multiple bay entrances, and road vehicle orders to stations and waypoints can carry a required direction. The driving side can even be changed when all road vehicles are in depots.

Level crossings get a set of dedicated changes: close adjacent level crossings, prevent road vehicles from being stopped on level crossings, an improved level crossing safety setting, and trains that break down after colliding with a road vehicle. The overlay sprites for level crossings are limited to the outsides of multi-track crossings when both the adjacent and safer crossing settings are in use.

Bridges and tunnels have their own group. Signals in tunnels and on bridges, custom bridge heads, tunnels under bodies of water, which are off by default, and a series of settings for placing rail stations, NewGRF rail stations, NewGRF objects, road and tram stops and docks under bridges. Vehicles can be made visible in tunnels through the transparency setting.

Airports and ships have smaller entries, with upgradeable airports and ship collision avoidance, plus a setting that lets NewGRF ships carry more than one cargo.

There are also cross-cutting features such as improved breakdowns, a vehicle repair cost setting, vehicle lifetime profit reporting, a cargo type filter in vehicle list windows, a client setting for the vehicle naming scheme, and settings to disable vehicle expiry and introduction after given years.

Building it from source with CMake, vcpkg and a bundle script

The repository is a full OpenTTD source tree, and its build layout is visible in the file listing.

There is a CMakeLists.txt at the root, a cmake directory, a vcpkg.json for dependency management, and a src directory with the game code. The scripts directory holds the packaging helpers, and the notable entries at the root are build.sh, build-dedicated.sh and make_bundle.sh. There is also a Doxyfile.in for documentation generation, CPackProperties.cmake.in for packaging, and version_utils.sh.

The documentation set around the build is unusually complete for a patch project: COMPILING.md covers compilation, CODINGSTYLE.md the code style, CONTRIBUTING.md how to contribute, known-bugs.md a known issues list, and installation.md how to install. A regression directory is also present, which in a project with this much behavioural change suggests a mechanism for catching changes that break something, although the README does not describe how it is run.

The os directory covers platform-specific code, media holds the assets, and the docs directory the documentation sources.

For a player who does not want to compile anything, the README points to the wiki for guides and to the TT-Forums thread for the patchpack. For a player who wants to build from source, build.sh is the entry point and installation.md is the document to read first.

One caveat for anyone evaluating this: the README is a summary and it says so implicitly by linking out to the wiki for every feature that needs more than a sentence. A feature list this long, with this many settings, cannot be evaluated from the README alone.

Versioning, licensing and the limits of a patchpack

The patchpack has its own release line, named after the upstream OpenTTD version it tracks. The recent tags are jgrpp-0.73.2 on 2026-08-26, jgrpp-0.73.3 on 2026-09-16 and jgrpp-0.73.4 on 2026-10-12. The default branch is jgrpp, and the last push was on 2026-10-18, so work is landing between releases.

The versioning scheme is the practical detail to internalise: when you pick a build, you are picking an OpenTTD version too. A patchpack release that tracks 0.73 is not a drop-in for a player on a different OpenTTD release, and the accompanying NewGRFs have to match too. Multi-aspect signal graphics, for instance, need a NewGRF that supports the feature.

On licensing, there are two layers and the README is careful to distinguish them. OpenTTD is licensed under the GNU General Public License version 2.0, but it includes some third party software under different licenses, and the README points to a Licensing section for the details. The repository itself carries a licence that GitHub cannot classify, so the LICENSE file at the root is the text to read for the patch code, and the upstream project's terms govern the game code it is built on.

The practical limits are the ones the README already names. This is not a mod, so it cannot coexist in the same installation as your standard game beyond being a separate executable. It is not aimed at newcomers, and it assumes familiarity with the base game and with signalling concepts. And because the patch list is long and interlocking, a player who enables a handful of the deeper features may find the result behaves differently from the standard game in ways the documentation only partly covers.

What the patchpack is best understood as is a fork with a coherent design: signalling, realistic braking and richer track construction, developed by one maintainer against successive upstream releases and published as numbered builds with a changelog.

Editorial conclusion

OpenTTD players who already know the standard game and want deeper signalling, longer trains and stricter infrastructure rules should install JGR's Patchpack, because it delivers a signalling layer the base game does not have and keeps its own versioned releases. It is the wrong tool for a new player, which the README states outright, and it is the wrong tool if you need a mod you can drop into a standard install, since this is a separate game version. Before downloading, read installation.md rather than the README, check the jgrpp-changelog for what changed in the release you pick, and note that the repository records a licence GitHub cannot classify while the OpenTTD code it builds on is under GPL version 2.0.

Frequently asked questions

Official sources

1. Issues
2. JGRennison/OpenTTD-patches on GitHub
3. README
4. Releases