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:

In short, this means the game can now be compiled natively for all platforms. This makes this month’s release available in 64-bits architecture for Windows, Linux, and macOS. You can expect builds to be faster, and much easier to port to new operating systems. Of course, we are extremely happy with this result, and what this means for future possibilities.

In this blog post, we’ll look back on how the memory space was reworked, as well as some quality-of-life changes that were merged this month, and the progress the OpenGraphics project has seen. Let’s get going.

Big loco_global integration extravaganza

Until this month, we still mirrored the vanilla game’s approached to memory space in most places. As often talked about in previous blogs, this was done with loco_global instances. Last month, we reported on the progress of reworking this, going from 342 loco_globals in the v25.10 release to just 157 in v25.11… Remarkably, this month takes us down to 0 loco_globals — yes, zero! It was a massive team effort, but it’s paid off massively, making 64-bit builds finally possible.

We usually list PR numbers in our dev log sections, however there were 46 PRs just for loco_global removal this month! If you’re curious to see what such PRs look like, you can find them on GitHub. Follow this link for a list of the relevant PRs.

To illustrate the growth and removal of loco_global instances from the project’s inception to now, please take a look at the graph below. As more of the game became reimplemented, more memory had to be shared between vanilla functions and our C++ functions, thus increasing the number of loco_globals. Only once all vanilla systems had been reimplemented could the relevant memory be fully integrated. Clearly, the last few months saw the final stretches of this effort.

Larger windows and new window styles

Compared to other Chris Sawyer games, Locomotion stands out due to its relatively sober window decorations. In fact, the ‘gradient’ look that characterises them is drawn using just one big sprite! For this reason, window sizes were limited to a width of 800 pixels — that’s all the sprite afforded!

Of course, nowadays, we have screens that are quite a bit bigger, so we frequently got requests for windows to be made larger. Well, here we are! Certain windows, e.g. the vehicle list and map window, can now be resized up to 2000x2000 pixels — much wider than was possible in the original game.

While we were working on this, Aaron had fun playing with introducing some new variants of the default window frame style. The gradient can now be disabled, resulting in a solid background colour. Moreover, the frame background can now be made translucent, resulting in a neat effect that we just had to include. Have a look at the gallery below for some examples.

More resizeable windows

Some players have amassed thousands of objects. Even with the filters OpenLoco introduced, from time to time we received requests to expand the object selection window. With larger windows now being possible, we’ve opted to make the object selection window resizeable. The default dimensions haven’t changed, but you can now resize it (#3405) to be a whopping 2000x2000 pixels, for all your extreme object listing needs.

It was brought to our attention that the vehicle list was quite glitchy when made smaller than its default size. We seized the opportunity to rework its resize routines, capitalising on the increased window limits as well. You can now resize it (#3531) to be quite a bit taller indeed!

Finally, the music selection window has been reworked by @LeeSpork. The window now lists the years music applies to, and allows you to order the list by name or year. This is made even more useful by allowing you to resize the window! We hope this increases your playlist customisation prowess quite a bit (#3384).

Doubling down on CMake

Over the past few years, we’ve continued to rely on CMake to tie our toolchain together. While initially we were dabbling with Visual Studio solution files for Windows, and several CMake files for Linux and even macOS, @Duncanspumpkin unified these to work on all platforms, and we’re now reaping even more the fruits of this labour. Since we had to rework our CMake toolchain again to make 64-bit builds possible, we took the opportunity to drop a bunch of now-unnecessary things in the process. Let’s take them one at a time.

Interop removal

First off, no longer needing to interop with the vanilla game has allowed us to remove a fair bit of code (#3491). This moment has been highly anticipated, and @Duncanspumpkin was all to eager to get it done.

CMake presets

While CMake has been the go-to tool to build OpenLoco for a while, it could be a little confusing to get it to build so-called cross-platform builds, in this case building 32-bit software on a 64-bit system. Now that this is no longer necessary, CMake presets could be simplified quite a bit (#3523). The project readme was adjusted accordingly. Whether you’re on Windows, Linux, macOS, or even BSD, it should be super easy to set up the compiler toolchain now.

Linux builds

For our continous integration (CI) build platform, we generally rely on vcpkg to build libraries we depend on, e.g. the SDL2 hardware abstraction layer. While Linux distributions tend to have their own package manager, you can opt-in to using vcpkg if the system packages are not up-to-date enough. All this to say, our ‘vcpkg’ Linux preset has now been updated to use x64 (#3494) as well.

macOS builds

The return of macOS builds is something that part of the team has been eagerly anticipating. Even when the codebase wasn’t entirely ready, Aaron started to hack away at getting native 64-bit builds (#3288) for this platform. Much of the work tied in with the loco_global rework, and was ultimately split off into their own PRs to ease the review process. Duncan created a CI job for macOS (#3499) as well, so we now have regular macOS builds on GitHub again!

Header checks

Finally, @ZehMatt did quite a bit of house cleaning (#3532), modernising parts of the CMakeLists files that were a bit neglected, and reworking the header checks. These checks are quite important, as they ensure we don’t have any implicit dependencies between headers. This allows us to keep headers small while not getting surprised when using them.

OpenGraphics

This month we had 11 vehicle contributions from @glenjimen and a bridge contribution from @shusaura85!

Vehicles

Bridges

Happy Holidays!

Thank you for supporting OpenLoco over the years! We’re very happy with the milestones we’ve reached this year, both on a code and at a community level. With the end of 2025 in sight, we wish you all happy holidays!

Thanks to @Glenjimen for this little diorama!

Prevent accidental cargo removal

New contributor @luciditee got back into the game recently, and fell into the age-old trap where changing vehicles would remove all of their cargo. Never again, they declared. And so, #3323 was filed, which adds a confirmation dialog to the vehicle component tab. This means changing vehicle/wagon order now prompts for confirmation if the vehicle is currently transporting cargo. A similar prompt is displayed when refitting a vehicle to transport different cargo, as can be seen in the screenshot below.

Rework remaining legacy config into modern config

Since we started work on OpenLoco, the game has always had two config files: one for the ‘new’ options OpenLoco introduces, and one for the vanilla game’s settings. Over time, some variables were moved over (e.g. shortcuts), but it was generally a matter of two worlds.

The main reason for this was that we were still dealing with vanilla game functions that we hadn’t yet reimplemented in C++. These functions were still expecting to be able to read from the old config location! As of v25.09, all functions have been reimplemented, though. To be fully implemented, we have to move on config-wise as well.

As of #3323, all config variables are now stored in the openloco.yml file. You can find this in the OpenLoco folder in your user profile (in Windows, this is AppData\Roaming). Go take a peek!

Show AI allocations as regular ghost elements

Despite their flaws, some people like playing the game with AI companies enabled. However, sometimes, there is considerable delay between the AI planning a route and actually building it. In the mean time, the planned route is reserved using invisible elements. This may be frustrating, as players aren’t allowed to build over them.

In #3270, a new option was introduced to make these planned routes visible as ‘ghost’ elements, much like how players’ construction tiles show up. Note that this option is off by default, as we consider it a bit of a cheat. Below are a few screenshots of what it looks like.

Merge sound and music tabs in options window

This month, @LeeSpork continues their quest of making the OpenLoco jukebox experience as smooth as possible. A longstanding request was to make the music options, and therefore the music volume settings, accessible from the title screen. In #3326, the tab was revealed on the title screen. It was quickly followed by #3352, though, which merges the relatively short ‘sound’ tab into the ‘music’ tab, which is now called ‘audio’. There are already plans for separate volume controls, e.g. for music and sound effects, so watch this space!

Disallow interfering with competitor’s roads and road stations

@LeeSpork discovered that it was possible for players to interfere with competitors’ roads. They quickly filed patches to prevent competitor road removal (#3335), as well as competitor road station replacement (#3336). Nice catch!

Add platform and arch to title screen

As we previously mentioned, as of v25.09, all game functions have been reimplemented in C++. We’re not quite at the point where we can make fully working 64-bit builds (#3288), however, we realised this would be a good time to add platform and processor/arch information to the title screen. With #3328 merged, you can now find this info in the lower-left corner, just below the usual version information.

Catch FileStream exceptions when loading from CLI

This may be a bit obscure, but have you ever tried to load OpenLoco with command-line arguments? As long as you’re passing arguments the game understands, with files that exist, the game is happy to process everything. If it doesn’t understand an argument, the game assumes you’re trying to load a file, though. If this ‘file’ doesn’t exist, the game would throw a FileStream exception, but not catch it, crashing the game. This is now mitigated by #3363, letting the game instead just log a warning to the console.

Rename a bunch of things

Over the course of the literal years we’ve worked on OpenLoco, some parts of the codebase have basically not been touched since they were initially implemented. With the benefit of understanding the codebase better, some things could be named better, in retrospect. This month, some community members expressed interest in understanding the path/signal/routing functions, for example. To make them easier to understand, @duncanspumpkin has renamed a bunch of variables (#3350).

Following this example, @AaronVanGeffen set out to rename several sub_ functions, that had not received a new name in the reverse engineering process (#3359). Similarly, one of the first game commands we implemented was the LoadSaveQuitGame game command. We now understand this better, leading us to rename its arguments (#3367).

Big loco_global integration extravaganza

As we previously mentioned, as of v25.09, all game functions have been reimplemented in C++. However, we still mirror the vanilla game’s memory space in several places. As often talked about in previous blogs, this is done with loco_global instances. When the project started off, these were introduced as a high-level wrapper around a particular memory address. We’re now at the point where the remaining wrappers can be reworked. As you might imagine, this is quite a bit of work, still. Fortunately, this month, we’ve seen a lot of team effort to get there. To illustrate, while our v25.10 release still had 342 loco_globals, this month, we’re down to just 157 of them. This is great progress! Unfortunately, many of the remaining ones are less trivial to tackle…but we’ll get there!

We usually list PR numbers in our dev log sections, however there were 20 PRs just for loco_global removal this month! If you’re curious to see what such PRs look like, you can find them on GitHub. Follow this link for a list of the relevant PRs.

OpenGraphics

Over the last 2 months we’ve have 11 new objects added to the OpenGraphics repo, and 2 updates to existing ones!

Roads

• @shusaura85 replaced ROADRGH with OG_ROADRGH:

Bridges

• @shusaura85 replaced BRDGBRCK with OG_BRDGBRCK:

• @shusaura85 replaced BRDGWOOD with OG_BRDGWOOD:

Land/CliffEdge

@hibiii added a new land type called OG_VOID, as well as the corresponding CliffEdge for it, OG_LSVOID:

Vehicles

@glenjimen replaced CATTLE1 with OG_CATTLE1:

@glenjimen replaced GOODS3 with OG_GOODS3:

@phosporus551 replaced CL71 with OG_CL71:

@phosporus551 updated OG_RE441 with new sprites from a new rendering pipeline:

@phosporus551 replaced RE442 with OG_RE442:

@phosporus551 updated OG_656 with new sprites from a new rendering pipeline:

@phosporus551 replaced 460 with OG_460:

@phosporus551 replaced EWIV with OG_EWIV, as well as the corresponding EWIVDT with OG_EWIVDT: