Please find the download on our website, or read the changelog on GitHub.

Open Graphics

The main aim of the Open Graphics sub-project is to provide a complete set of replacement objects for the original game. There are areas of the game, though, that are seen as lacking content. Where appropriate, we will add new objects to fill the gaps. This month sees the introduction of the first of these with the North American Expansion.

@Shusaura85 added Train Station 3.

@Spacek531 added Acela powercar and Acela coach.

@Phosphorus551 went above and beyond with 32 new objects for the North American Expansion:

• CL-8 ‘Marathon’
• CL-60 ‘Oxen’
• Ridley electric multiple unit
• ‘Pennliner’ diesel railcar
• EPL-7 ‘Longship’
• HSL-8 ‘Achilles’
• 1920’s mail car
• 1920’s passenger car
• 1980’s passenger car
• 1960’s passenger car
• Mikado 2-8-2
• MS-2 ‘Polaris’
• Rowan electric railcar
• MRA-7 electric multiple unit
• ST-7 ‘Steven’
• Level crossing sound 7
• Early train horn 9
• Early train horn 8
• LFT powercar
• LFT passenger car
• APM ‘Turbo’ powercar
• APM ‘Turdo’ passenger car
• Express boxcar
• CL-44 ‘Revolution’
• CL-40 ‘Provenance’
• DFL-40 ‘Banshee’
• EE-5 ‘Boxer’
• TFL-1 ‘Tandem’
• EE-1 ‘Sabre’
• Northern 4-8-4
• ECI ‘Renaissance’ intercity bus
• Beckmann Model-1922 omnibus

But that wasn’t enough for them; they also added the 12 vanilla replacements:

• Model 36R bus
• CM ‘Baroque’ intercity bus
• TDH5301 bus
• Overhead catenary wire for trains
• American train horn sound
• American region object
• Overhead catenary wire for trams
• SMC ‘Accordion’ articulated bus
• XTA ‘Road Train’ articulated bus
• Icarus ISD omnibus
• Wickham Model-C omnibus
• ECI ‘Cobra’ articulated bus

But wait, there’s even more! They also updated the following vehicles:

• OG_CE68 sprite count warning fix
• OG_PCARUS2 sprite and model rework
• OG_ALOCENT sprite and model rework, uses new sounds
• OG_DASH7 sprite and model rework, uses new sounds
• OG_SD70MAC sprite and model rework, uses new sounds
• OG_E8 sprite and model rework

Drag dimension tooltips

I was watching a @MasterHellish video recently, and he mentioned how annoying it is to work out lengths of stations and tracks when building. So to address that, we now show the dimensions of a dragged tool in a tooltip. It’s a small change, but hopefully it makes it much easier now to plan out your perfect station. It isn’t completely perfect though, and you will notice that the dimensions show up for some tools where it doesn’t make much sense (e.g. the town placement tool). Expect some improvements to this in the future.

Are there any other limitations in modification tools that you feel need addressed? Let us know on Discord.

Improved Linux support

I’m not much of a Linux user, and frankly think how programs are installed on Linux is odd. But as we do have some Linux users, we have to follow those conventions.

This month we reworked how the data directory is located on Linux: it now looks for it in /usr/share/openloco as well as ../share/openloco (relative to the binary).

New contributor @ben-leone added code to try find the vanilla game directory on Linux based on common GOG/Steam install locations.

There is also an AppImage build available for Linux users. This uses a new build setup that utilises Zig to build OpenLoco with a much older version of glibc. Hopefully, this will mean that we have okay support for most Linux distros. Thanks @ben-leone and @ZehMatt for work on this.

Toolbar rework

@AaronVanGeffen has been working on reworking the top and bottom toolbars. The main aim is to simplify the code and prepare for changing the layout of the toolbars. In the future this will allow users with widescreens to have buttons in more logical positions.

Fixes and refactoring

@duncanspumpkin fixed a bug from our last release that prevented signal placement and removal on curved track in some cases. Oops!

@LeeSpork fixed issues with scenario challenge time limits and a journey time exploit.

@LeftOfZen named a bunch of unknown variables.

@Spacek531 named and refactored some vehicle related code.

New contributor @MinerSheep tidied up the software drawing engine which also fixed a crash-on-close bug.

@shusaura85 fixed a bug that prevented vehicles from using roads that are enabled via the object selection window.

I’m sure I’ve missed a few other refactors, but hopefully I’ve covered the main ones.

For a complete list of fixes refer to the changelog on GitHub.

Please find the download on our website, or read the changelog on GitHub.

Signal auto placement

I’m never quite sure what to call this feature, but in the signal placement tool you can now change the mode to repeated placement. When in repeated placement mode, the track will be walked along, placing signals around a customisable track piece interval. This will greatly speed up how long it takes to place all your signals at nice even spaces. The auto placement will stop as soon as it hits a junction, another signal, or a station. If, for some reason, you decide you wanted to adjust the spacing of already placed signals, we also have you covered. Whilst in repeated placement mode, a right click removal of a particular signal will remove all signals in the block (the track between a junction or station). For a demonstration, see the video below.

I hope you enjoy this quality-of-life feature. I’ll now go through a little history of the feature.

This feature was first requested back in 2018, but at that time we didn’t have enough of the code implemented to add it. In 2021, @LeftOfZen started trying to add this feature, but our knowledge of track iteration code was still so lacking, that the feature was never completed.

During 2024, I implemented a lot of the Company AI code. One function in there was placeAiAllocatedSignalsEvenlySpaced; a function that would place signals evenly along a track. If I had been thinking about this feature at the time, we could have very easily copied this code. Instead, I forgot about it until @MasterHellish made a YouTube video in 2026, lamenting about the lack of this feature. You would think that would have reminded me that I had basically already implemented it in the Company AI code but it didn’t. Instead I implemented it all from scratch again.

The reason I didn’t immediately put two and two together is that the Company AI track iteration has to iterate over track that is ‘pre-allocated’ to the company. It’s a subtle difference, which meant it used a slightly different function name and wouldn’t turn up when I was searching. After finishing the feature, I went back and found the Company AI code and it is almost identical, doh.

Are there any other features that you would like to see in OpenLoco? Perhaps they have also fallen through the cracks? Especially, if it’s a feature like this, where it doesn’t require saving anything new, but is more an improvement to the interface, then perhaps we could implement it. Feel free to bring up ideas on Discord (preferably referencing an issue from GitHub).

Trying to fix Tutorials

The tutorials in Locomotion are not great. They all depend on replaying a mouse pointer recording, moving and clicking on UI elements, expecting them to be in a particular place. Whenever we change a UI element, there is a high likelihood that the tutorial will break. The tutorials must also be run at a certain window size, as they were originally recorded for particular fullscreen resolutions.

We do plan on completely reworking the tutorials in the future, but for now we just want to make them mostly work. @AaronVanGeffen and @LeeSpork both worked on the tutorials this month, getting them finally working again. It’s been a bit of a constant battle, as we have had a few UI and under-the-hood changes that broke many tutorial assumptions. However, they are now at least playing back properly again…

Or are they? Just when they thought the job was complete, I merged my signal auto placement, which changed the UI such that tutorial number 3 broke again. :)

Catalan translation

@J0anJosep contributed a Catalan translation for OpenLoco. It’s great to see even more languages being supported!

Open Graphics

@Shusaura85 added OG_TRSTAT2.

@Phosphorus551 updated/balanced some existing vehicles:

• OG_BALDWIN1 - increased weight to 120t
• OG_SPECIAL - increased power to 500hp
• OG_USPACIF - increased top speed to 60mph
• OG_APT1 - fixed the alternating-directions flag

Misc Refactoring

@AaronVanGeffen worked on a few under-the-hood changes related to the company information panel, company window, news window, landscape generation window, and scrollview widget. In particular, this means scrollbar behaviour should be much more consistent throughout the game now.

@LeftOfZen fixed some off-by-one errors in the group box UI widget and named a few unknown variables.

@ZehMatt has been making some more major changes with how widgets and windows are referenced and are drawn. Eventually this should allow us to make a tutorial system that is robust.

@Gymnasiast, who works on our sister project OpenRCT2, corrected a small namespace mistake in our code.

New contributor @ravsmedstrom standardised some internal naming.

Misc Bug Fixes

There were quite a few bug fixes this month. Please refer to the changelog for a complete list.

Many thanks to @AaronVanGeffen, @gerritdrost (new contributor!), @LeftofZen, @Spacek531, @LeeSpork, @ZehMatt, @Shusaura85, @calosqwqqwq (new contributor!), and @Duncanspumpkin.

Please find the download on our website, or read the changelog on GitHub.

Fixed initial game setup

You may have read in yesterday’s announcement that we reworked the game initialisation functions. This was all fine and good, unless you had no game config yet, e.g. when you had never played the game before on your machine. In that case, we normally show a popup asking you where Locomotion has been installed, leading you into a file browser where you can select the right folder. It was that last part that broke. Oops! It’s fixed now, thanks to @ZehMatt! (#3844)

Raise the limit of audio sources, fix the lag when the limit is reached

@LeftOfZen noticed extreme lag on large maps with many vehicles. It turned out that in this edge case the game quickly reaches the limit for the engine, OpenAL. By default, it can handle 256 sources at once, after which you’re not supposed to add more. Well, we continued adding more anyway, triggering (invisible) errors and therefore lag.

Fixing the matter, @ZehMatt increased the limit to 1024 sources, and made sure we now actually stop adding more audio sources once the limit has been reached. (#3841)

Jittery ‘object grid’ scrollviews, part 2

Yesterday, we declared victory on the jitter issue with scrollviews for object selection (industries, town buildings, trees, walls). Unfortunately, we spoke too soon. One line was accidentally dropped from the patch, leading to the issue not being resolved, after all.

Well, in the pursuit of what that line had been, we ended up fixing another edge case where the scrollbar ‘thumb’ was not being resized when it needed to be. In the end, these scrollviews are now even better than they were. A silver lining, right? (#3840)

Can click beyond end of list in company list/station list/music selection windows

An off-by-one in the company list, station list, and music selection windows meant that you could select an empty ‘item’ beyond the end of the actual list, leading to an invalid action being performed (e.g. opening a window to a non-existing company or station). Not good! Thankfully, this one was an easy fix. (#3847)

Extra zoom levels

Sneaking in at the very last minute, @ZehMatt dropped us all an epic feature - extra zoom levels! Now there are 2 additional zoom levels allowing you to zoom in 2x and 4x further respectively. This is a huge improvement that we are sure everyone will love!

Cargo statistics

@spacek531 added some useful cargo statistics display to the towns and industries windows, giving the player more info about what is happening in the game.

Jukebox and music

@LeeSpork made some improvements to the UI for music options, adding extra options to the Audio settings and allowing it to open the jukebox without having to start/load a game. They also fixed a bug with the jukebox window not invalidating after unchecking “Play music” from the main toolbar.

Home button in file browser

@LeeSpork added a welcome UI improvement; a button in the file browser dialogue to allow the user to return to the ‘home’ folder for your locomotion files, ensuring you can always get back to the default save folder, no matter where you’ve ended up.

String formatting fixes and spelling updates

Grammar and spelling aficionados, rejoice! @LeftofZen and @AaronVanGeffen added some improvements and fixes to string formatting and English translations. Amongst other things, no longer to en-GB users have to see ‘z’ in half their words, and no longer do en-US users need to see annexe.

One of the longest-standing spelling mistakes, and indeed a vanilla spelling mistake, is the in-game track A Traveller's Serenade, which was spelt incorrectly as seranade. No longer!

Bug Fixes & Stability

A large number of visual and gameplay bugs have been resolved. @AaronVanGeffen solved the long-standing issue of jittering in scrollviews in the terraform, town list and industry list windows. He also fixed an issue with the population chart overflowing and thus rendering as a visual glitch, and to top it off he also fixed a bug preventing windows from showing their resize handles.

Additionally, @duncanspumpkin fixed an issue with the data path when starting the game from command line.

Keybinding/Shortcut improvements

@ZehMatt added multiple improvements to shortcuts/keybinds, including a very neat keybinding previewer:

Performance and Engine Optimisation

Under the hood we have some noticeable performance gains, particularly in loop-heavy operations. @ZehMatt optimised the code for yearly update cycles, improved tile element iterators, refactored how the tile elements are stored, refactored the startup process of the game to separate out CLI logic from the rest of the game logic, and improved the widget system allowing easier future improvements, expansion and safety.

@LeeSpork refactored some window events and @AaronVanGeffen improved how custom mouse cursors are stored, as well as a bug being fixed by @LeftofZen around those custom cursors not being rendered properly.

Codebase Cleanup & Refactoring

The codebase itself received a lot of attention and refactoring to improve development ease and compile times. @spacek531 and @LeftofZen continued the long project of providing human-readable names for previously-unknown variables in the code base, stemming from the reverse-engineering efforts. @AaronVanGeffen and @duncanspumpkin improved null pointer checking, which should hopefully result in less crashes. Transitive header dependencies in the codebase were improved by @AaronVanGeffen and @LeftofZen, and @ZehMatt improved the Visual Studio CI/CD setup to handle VS 2026. @duncanspumpkin improved the code surrounding how tree removal is handled, and last but not least, new contributor @killerdevildog added some useful helper functions around iterating over in-game objects, something which is done frequently.

OpenGraphics

Over the last 2 months we have had an enormous number of contributions from @shusaura85 and @phosphorus551. We also fixed some issues with some very old PRs, so we were able to merge some vehicles from @glenjimen as well. We are now up to a total of 150 OG objects, bringing us over 25% mark of vanilla’s 545 objects! Additionally, a number of vehicles were updated with new stats in anticipation of a rebalanced US vehicle set.

Vehicles

Trains

@phosphorus551 added no less than 19 trains since the last OG update, and @glenjimen contributed 3 himself:

Trams

@phosphorus551 added all of the tram replacements; pictured in order: OG_TRAM1, OG_TRAM2, OG_TRAM3, OG_TRAM4, and OG_TRAMCOMB:

Town Names

@shusaura85 implemented all of the town names replacements.

Here is a selection of names that you could see in-game if you use “silly” town names from OG_STOWNNAM:

Roads, Tracks, Bridges

@shusaura85 added OG_BRDGSUSP, aka the suspension bridge, as well as both US roads (OG_ROADUS1, and OG_ROADUS1). Finally, @phosphorus551 recreated the standard-gauge track object, OG_TRACKST.

Making cargo more intuitive

To indicate what cargo is produced by industries and what cargo passes through stations, Locomotion uses small icons in various places. This makes sense when you consider the game originally had to run on displays with resolutions of 640×480 or 800×600. While experienced players have likely memorised the meaning of all these icons, they do make it quite hard for new players to pick things up. Well, nowadays we can afford to use up a bit more space, right?

This month, we’ve reworked the station construction tab to list cargo produced and accepted by a new station in full, with a label next to the icons (#3734).

Before:

After:

We’ve also added tooltips to the cargo icons in the station window, so you can still quickly look up what an icon means without having to check the construction window again (#3735).

Increase dimensions of Build Vehicle window

Last month, we introduced new sorting options for the Build Vehicle window. Thinking the sort options weren’t that easy to discover, and the window felt a little cramped anyway, @AaronVanGeffen set out to improve the window further. The sort options have been moved into a dropdown of their own, and the window has been made a little larger by default (#3710).

Before:

After:

Fix item removal in various list windows

We also changed the way list windows work last month. While our tests looked very promising, there was one thing we did not properly test: item removal. Suppose you deleted a vehicle while the vehicle list was open? Yeah, the game would crash. Oops. The same thing happened with the other list windows: stations, towns, industries, and companies. We’ve reworked the way items are removed (#3727), so this shouldn’t bug us again.

Our rework presented another edge case when regenerating the landscape in the scenario editor. If you happened to have the town or industry list windows open, their lists would not fully refresh. Suppose you regenerated with more or fewer towns or indeed industries, the list would refresh, but not repopulate. This meant entries would potentially be missing — or lead to invalid entries. We’ve added a hard refresh to both windows for this particular situation (#3733).

Fix save state not being deterministic without auto save

Something that puzzled us in the past, but ultimately forgot about, was that save games would not give the exact same result on disk unless autosaves had been enabled. Our replay checks always used autosaves, though, so surely there couldn’t be a big problem?

Aiming for a perfectly deterministic simulation, @ZehMatt investigated the matter once more. He found the whole reason it was not deterministic to be that there was lingering game state for stations. When autosaves were enabled, it would zero some fields out every time an autosave was performed. In particular, this also impacted how cargo stats were calculated, since it used the old data, which also influenced the pseudo-random number generator (prng).

We have changed the station manager to now explicitly zero-initialise the remaining fields when allocating a new station (#3737). With that, the game now always outputs binary identical files, and the determinism bug is gone.

Separate OpenLoco into a library and app

When we revamped our CMake config a few years ago, we set out to modularise our codebase to make it easier to create smaller, testable targets. This was successful to a degree, but mostly for particular data structures and utility functions. The majority of the actual game code was still not explicitly covered by tests, save for replay tests covering parts of the simulation. Splitting it up further would be a monumental task, surely…

Cue @ZehMatt. Eager to expand test coverage to include tile element management at least, he split up the source tree to distinguish an OpenLoco library from the actual game. This, then, would allow targeting particular functions without actually running the full game.

As of #3742, this became a reality! Many files were moved around to realise this! We now build the source tree as a library, with the main game executable using (linking) this library.

Allow setting preferred company name

OpenLoco has allowed players to set up preferred company ‘owner’ names and faces for a while, but for in-game companies, we’ve been stuck with ‘Name Transport’ still… until now! In #3720, new contributor @Llammissar added an exta option to let players set custom company names as well! Neat.

Start copy/paste implementation for blueprints

One of the long-term plans we set out with when starting OpenLoco, is the idea of blueprints. These would allow you to save and rebuild parts of your map in another. For example, that massive station with an interchange you made? Yeah, you would be able to save that, and rebuild it in the same or other map.

Obviously, this is not a trivial feature to add. As such, we never really got around to implementing it… until @duncanspumpkin suddenly had a nice proof-of-concept for basic copy/paste functionality (#3649). You simply select part of the map to copy it, then paste it elsewhere on the map. This then provides basic proof-of-concept functionality behind these blueprints. Over the past month, some of the rough edges were smoothed out, and we decided to merge it as part of the construction window — for now.

At present it will only work for railroad track, signal and station map elements. We will look to improve the support for other map elements such as roads, buildings, and terrain.

In the near future, we aim to extend this feature into the full-blown blueprints feature we talked about. We’re not quite sure where they’ll go yet. Maybe in a tab in the construction window, or maybe in a seperate window entirely? Exciting times, for sure.

For a simple example, check out the following clip:

Fix auto layout for cars that are centered

A few community members have reported the fact that when a vehicle object has the centrePosition flag, it does not correctly centre on the train. This bug was introduced when @duncanspumpkin reimplemented the train auto layout code. The vanilla game’s auto layout code was very long and complex, and had to be implemented all in one go. This often leads to mistakes. For this particular issue, at the time, Duncan had it working almost correctly, except when there was an even amount of cars. Whilst fixing, that though, this bug slipped in Just typical that, whilst fixing an edge case, you completely break the general case!

@Hammster created a fix for the issue (#3572) and Duncan tidied up the fix to make it align with the codebase.

Fix loan potentially going negative (#3688)

A few releases ago, @duncanspumpkin decided to try align all of our UI code that handled increasing/decreasing amounts. This was meant to reduce the chance of subtle bugs in the various places where we do this. Unfortunately, for the loan payback, he forgot that money types can go negative, so the wrong lower limit was set.

It was easy to fix, Duncan wanted to go through all the other changes he made for increasing/decreasing to ensure he hadn’t made similar mistakes. Fortunately, we concluded he hadn’t.

New cheat: keep cargo on vehicle pickup/modify

Tired of losing cargo when picking up or modifying a vehicle? We’re guessing that’s how @ethan-xd felt when he implemented a cheat to prevent just that (#3591). It’s just a checkbox away.

Jukebox improvements

This month, we’ve merged a few of @LeeSpork’s patches on what seems to be their favourite part of the code base: the jukebox. Notably, they fixed music automatically resuming after saving when the game paused (#3185), even when the game itself would still be paused.

The original Locomotion title theme can now be added to the ‘custom’ jukebox playlist as well (#3639). It is still not included by default.

After last month’s addition of separate volume sliders for the various game audio channels, the jukebox suddenly felt out of place. Instead of just moving it back to its own tab in the options window, we’ve opted to move the jukebox into its own window instead (#3707). It can be quickly opened via the audio (ear) menu, or via a custom keyboard shortcut.

Refactor list windows to use faster sorting algorithm

Keen-eyed players may have noticed that the game’s list windows have always updated three rows at a time. This was most notable when the window was just opened: every game tick, three more rows would be added. Similarly, values for existing rows would be updated in an almost ‘scrolling’ fashion. While there was something satisfying about this, it also meant that it would take a few seconds before e.g. the higher-digit vehicles would appear in the lists.

This month, @AaronVanGeffen has reworked these lists to now use a two-step approach instead. When opening the window, all relevant ids are stored in

This applies to the company list (#3705), station list (#3704), industry list (#3703), town list (#3702), and vehicle lists (#3701) windows.

This fixes a problem with vehicle lists (#3701) where having both the general vehicle list as well as station-specific ones open at the same time could lead to flickering vehicle rows.

Finally, we unified the use of two window struct properties that were both used for keeping track of the amount of rows displayed. As of this release, the previously unnamed variable var_83C is no longer used for this purpose, replacing it with rowCount (#3709).

Add more sorting options when building vehicles

As of OpenLoco v23.10, the Build Vehicle window has had options to search/filter the listed components, e.g. by powered/unpowered. Similarly, the list could be sorted by name or year of invention. @ethan-xd saw an opportunity to add more sorting options, and introduced the ability to sort descending as well (#3594).

Address sanitisation passes

Investigating a mysterious crash, @ZehMatt set out on an AddressSanitizer quest. Two bugs surfaced in the process.

First, he discovered copying news messages into the news window was going one byte beyond its buffer limit (#3719). Fortunately, this was a buffer on the top of the active stack frame, so unlikely to lead to anything truly bad.

Second, he discovered an issue with the routing iterator. The way it was set up would return a pointer to routing data, rather than the actual value (#3718). This meant that, in case the routing table changed, the iterator might suddenly return a different value than expected. As a preventative measure, this was changed to return a immediate value instead.

We’re not sure if either of these actually solved bugs that people actually encountered, but they’re a good examples of the kind of issue we have to look out for.

Name a few more previously unnamed things

@duncanspumpkin named the awaitingCargoTransfer flag, placed on vehicle components (#3621). As the name suggets, this indicates a vehicle component is waiting for a cargo transfer. When placed on vehicle head structs it indicates that the vehicle cannot wait at the station for further loading. In the future, we would like to split this off to a different flag to make cargo loading more flexible.

When it comes to buildings, we recently discovered buildings are categorised into what we now call amenity categories. Towns use these to decide what buildings to keep or replace, and indeed to build. So far, we’ve named religious buildings (e.g. churches), hotels, parks, courthouses, parks, and landmarks. There is room for three more categories, but no vanilla objects seem to use them. In fact, most vanilla buildings do not have an amenity category, as they are general residential. Either way, it’s interesting to still discover more of these subtle, underlying mechanisms.

Objects that claim to belong to any of these newly discovered amenity categories now have their category validated. If an invalid value is found, the object now can no longer be loaded to prevent crashes (#3623). Such invalid values were especially dangerous as they could end up writing data to many different parts of the save file, corrupting saves in unexpected ways. Luckily, most of the time doing so would immediately cause a crash, though, instead of subtly corrupting your save!

On the topic of unexpected values, a similar check is now applied to the building generator function id associated with miscellaneous building objects.

There are still quite a few unnamed flags and variables left. If you feel like joining in on the naming effort, please reach out to us on Discord!

Localisation improvements

@erdikayaTR has improved the Turkish localisation, adding translations for newer strings and clarifying older ones (#3712).

Like Locomotion, OpenLoco support custom keyboard shortcuts. @LeeSpork noticed one of the lesser used modifier keys, the Menu key, was not being localised. This has now been fixed (#3467).

Fix crash when starting bus behind bus

This was quite a curious bug, in that you only hit the issue when starting a bus immediately behind another bus when it is stationary. Technically, the vanilla game suffered from this mistake as well, but instead of crashing it would just read invalid memory and miscalculate the road occupancy. Instead of reading a non-existing object, the null value involved is now correctly ignored (#3698).

Fix new signals not correctly updating network

Due to a mistake made during implementing the ‘Place Signal’ code, depending on where you clicked on the track when placing a signal, the game might not actually update the signal network! This would cause unexpected crashes/stoppages of trains.

@duncanspumpkin investigated and fixed the issue (#3697). He realised that the issue was missed during testing, as back then we were using straight track pieces, which in retrospect wouldn’t be affected by the issue. There might yet be further issues with this code, so please let us know if you still encounter odd issues when adding a signal to track.

Please find the download on our website, or read the changelog on GitHub.

What follows is a quick summary of the new features and bug fixes for this month.

Migrate codebase to SDL3

When implementing a game, programmers can choose to either target a particular operating system directly, or use an intermediary layer that makes it possible to target multiple platforms in one go. To this end, OpenLoco has made use of SDL since the beginning. Recently, a major new version of the SDL API was released, meaning old APIs were replaced and new ones added. To make it possible to leverage the new functionality, we had to rewrite part of our codebase.

The majority set of rewrites was merged early in the month (#2882), followed by a series of improvements on display handling by new contributor @kevinz26 (#3671). Nice!

Audio volume can now be set separately by channel

There are many different kinds of audio in Locomotion. It even includes a jukebox! Like Locomotion, OpenLoco only had a single volume slider, grouped with the music options. Until this month, that is, as now you can set a specific volume for each specific kind of audio (#3678)!

Vehicle sounds now use reverb when entering or leaving a tunnel

Armed with a newly-refactored audio subsystem (#3678), @ZehMatt set out to add a new effect to the game: reverb! This is now used for vehicle running sounds when they are in a tunnel #3678. We think it’s a nice touch!

Here’s what it sounded like in v26.02:

And here’s what it sounds like in v26.03:

Improved entity invalidation

Normally, tiles are ‘invalidated’ whenever elements or entities on them have changed, requiring them to be redrawn. However, under some circumstances, e.g. when dragging a vehicle ‘ghost’ around, it was possible for a (ghostly) remnant of the vehicle to stay behind. It seems we missed a spot, somewhere!

This was reworked by making the invalidation implicit in the entity’s moveTo call, rather than explicit. @ZehMatt realised there was an optimisation here: sometimes, a tile was invalidated even if the vehicle hadn’t actually moved (#3312)! This probably won’t lead to much of a rendering speedup, but it’s a nice bonus!

News settings default to newspaper style again

Last November, we reworked the remaining Locomotion config settings, folding them into our own, modern OpenLoco config file. We missed an edge case, however. For new config files, news settings were not initialised correctly. Indeed, all news settings defaulted to off, rather than the newspaper style players have come to expect. Oops.

New config files will now get the right ‘newspaper’ defaults (#3657). Unfortunately, we can’t reset the settings without affecting players with custom news settings, however. So if you’re not seeing news unexpectedly, please check the news options in the messages window.

New widget identification

When a player interacts with an element in an in-game window, a so-called widget, you often want something to happen. To do this, the input subsystem relays to the relevant window that a particular widget has been interacted with in a certain way, so that the window can do what is expected.

Like Locomotion before it, OpenLoco handles this by using a numeric index. Using enums, the first widget in a window is assigned index 0, the next index 1, etc. This is great if your widgets are sequential, but we would like to move to a more declarative way of denoting the window layout. Suddenly, widgets are not so sequential any more, meaning we need a new way to identify them. Enter WidgetId #3560.

Instead of simple enum sequences, WidgetIds are instantiated using a string, which is hashed to a number at compile time. This means we still get something that’s easy for machines to compare with, while also making it possible for interface design to be moved externally to the C++ internals. Something nice to look forward to.

Improved assertions

Traditionally, in C and C++, programmers can use assert to denote what would otherwise be implicit expectations in source code. For example, you might want to make sure that a particular thing never happens, e.g. the sky shouldn’t be painted in a green colour, somehow. Such extra checks take time, though, so typically asserts are skipped entirely in non-debug builds.

There are times when we do want things to fail, though, and when they do, preferably with a bit of extra information. Enter our own assertion diagnostics #3656, courtesy of @ZehMatt. These have the added advantage of saving the source location, so error traces don’t show the error handler as the source of the error, but the actual location where the assertion was triggered. Hopefully, these will help narrow down any pesky mistakes in the future!

Drawing circles

Locomotion sported a necessary feature for new players: in-game tutorials. While not really going into the nitty-gritty of the game, they helpfully covered the basics. Unfortunately, though, they are simply a sequence of mouse pointer locations, recorded separately for common screen resolutions at the time the game was released: 640×480, 800×600, and 1024×768. If these resolutions seem alien to you, well, this is what most of us had to contend with back in the day!

In recent discussion, we talked about how best to replace the old ‘mouse’ tutorials. One idea is to use the new widget identifiers to mark the elements that instead should be clicked by the player to advance the tutorial.

One way to mark them would be to use circles, someone suggested. A problem presented itself: oddly enough, we had no primitive yet to draw circles! @ZehMatt stepped up and implemented one in #3559.

Tutorials haven’t changed yet, and probably won’t for a while. But at least we can now draw circles!

OpenGraphics

This month saw 3 contributions from @shusaura85:

An updated dry grass object:

Two new roads:

What follows is a quick summary of the bugs and their fixes.

Crash when hovering over stations with the order tab open (#2205)

We kept getting weird crash reports that we couldn’t quite place, somehow involving the vehicle order manager. It had us puzzled for a while, until @Sashna on Discord came up with a reliable way to reproduce the issue. As it turns out, there was a situation where a pointer to the end of the order table could be reused, leading to it being incremented past the end of the table! Once this was diagnosed, Duncan was able to come up with a fix relatively quickly.

The vsync setting is not saved correctly (#3626)

In the previous release, we introduced an optional vsync cap for the game’s frame rate. Ironically, the setting was not saving correctly, leading to an uncapped frame rate after restarting the game. This was a minor issue to resolve, so at least now it actually persists!

Constant alternating colors on vehicles and other things (#3627)

We also introduced parallel, multi-threaded rendering in the previous release. However, the remap colours in the game were still sharing a palette buffer. This led to a race condition for e.g. recoloured vehicles, meaning they would alternate between colours in certain situations. Ironically, this was flagged as a potential issue ahead of time, but the relevant ‘thread local’ keyword had not been applied. After we identified that this was indeed the cause, it was another one-line fix.

macOS builds are missing OpenGraphics objects (#3629)

As of December 2025, we have native builds for macOS again. However, as it turns out, the application bundles were missing our OpenGraphics objects entirely! CMake wizard Duncan dug into this and found the cause to be a bug to do with CMake presets! A workaround was promptly applied, and our macOS builds now ship with OpenGraphics objects!

Can click beyond last item in town and industry list windows, opening invalid windows (#3652)

@LeeSpork identified an issue where the town and industry list windows would let the player select ‘items’ where there were none, just after the end of the list. This led to opening invalid windows, often triggering a crash. Turns out the relevant checks were using > instead of >= to check bounds. Foiled again, off-by-one errors!

Over the next few months, the refactoring will be aimed towards getting ready for a new save format (NSF). For the NSF, we will be aiming to increase the map size limits, and generally most other limits. It is not a simple task of just changing some constants though, so don’t expect this to be completed for a while. Related to the NSF, we will also be looking at introducing a new object format (NOF). The NOF will allow removing limitations of the DAT format and will hopefully be more human readable. Much like the NSF, this will take quite some time to fully decide how it will work.

Even when we move to a NSF and NOF, we will still maintain support for the old formats in various ways, so don’t worry about losing your favourite custom objects.

Other areas for improvement are path finding. I suspect that we won’t be able to improve the land path finding just yet, without an NSF, but the water path finding should be achievable. If you have knowledge on pathfinding algorithms, it would be great to hear from you.

OpenLoco

Parallel drawing

@ZehMatt added parallel drawing support to OpenLoco (#2825). For the first time, having a multi-core CPU will actually improve performance in OpenLoco! The way drawing works in OpenLoco is that the window is split up into columns of 32 pixels wide (the width of a tile). Each column is drawn independently of the others. This is trivially parallelisable and @ZehMatt really showed this as the number of lines of code required to add parallel drawing was just 28!

However, keep in mind that drawing is not always the bottleneck of OpenLoco. Just running the simulation can be very CPU intensive, and that is not something we can easily parallelise at this time.

Related to this change, @lapingvino on Discord mentioned this change caused dependency issues on his system. I might have been a little dismissive of the issue at first as we were only using the C++ standard library parallelism features, but after looking into it properly it did turn out that GCC’s libstdc++ depends on Intel TBB for parallelism. So if you are using libstdc++ you now need to remember to have TBB if you want parallel drawing to work (#3608). Unfortunately, GCC will silently remove the parallelism if TBB is not found so we didn’t catch this on any of our CI systems as they only have the minimum of required dependencies installed.

Name unknown flags and variables

@Cgettys, myself, @shusaura85 all worked on identifying various flags, variables and other unknowns in the codebase (#3512, #3615, #3571, #3600, #3550). Ideally, we would like to have all save file and object file related data identified before embarking on the NSF and NOF work. It’s not terribly exciting work, but I personally quite enjoy finally assigning a name to something and understanding how it affects the simulation.

Various refactoring and bugs

@AaronVanGeffen, myself, @ethan-xd, @ZehMatt, @LeeSpork, @LeftOfZen, all worked on various minor refactoring and minor bugs. Checkout the changelog for details on the bugs.

OpenGraphics

We made a mistake last month and accidentally didn’t include all of the OpenGraphics objects that had been created. We have corrected the issue and you should now see all of the objects released last month.

Onto the fun stuff; this months was the most productive month yet! Contributions have been organised by creator below.

@phosporus551

@phosporus551 had an insane 37 contributions this month:

28 OpenGraphics recreations:

7 branch new narrow-gauge trains (that don’t replace a vanilla object). These fill a gameplay gap in the mid tier for narrow-gauge trains. Whilst wider game balance for vehicles still has to be discussed in more detail, these certainly go a long way to bridging the underpowered nature of the vanilla narrow-gague vehicle selection.

2 revisions on existing OpenGraphics objects:

@shusaura85

@shusaura85 fixed a vanilla compatiblity issue with level crossings not being able to be placed on the existing OG_ROADRGH, as well as added OG_BRDGGIRD:

@glenjimen

@glenjimen contributed OG_COAL1: