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:

Revert drawing widgets in relative positions (#3305)

In previous releases, we’ve been reworking how the in-game windows and their widgets are organised. Notably, this May, we changed how these are drawn. Unfortunately, this has turned out buggier than we had originally expected. While we made several attempts to fix the issues, they have proven non-trivial to address.

As it stands now, it seems we were a bit too eager for these changes to be made, while the drawing engine isn’t as separated as much as we would like. We therefore made the decision to revert the changes from earlier this year, and work on refactors to make them actually meet underlying assumptions in the —hopefully— near future.

Fix keyboard shortcut assignment (#3309)

Over the course of recent months, we reworked part of the input manager. This component is responsible for processing keyboard and mouse input events from the OS, and delegates them to the relevant game components. One of these delegates is the shortcut manager. For the previous release, we received reports that it was no longer possible to bind keyboard shortcuts that used modifier keys (e.g. ctrl, shift). As it turns out, the two parameters involved with shortcuts (charCode and keyCode) had been accidentally swapped! Because both parameters use a uint32_t type, the compiler was fine with it. For now, the bug has been fixed, but you can bet we’ll switch to stronger types for these in the future…

Bump sfl library (#3310)

In C++, we have the luxury of a standard library that provides various dynamic container data types, e.g. std::string or std::vector. These provide automatic RAII-based memory management, which means we don’t have to manually allocate or free the memory involved. For developers, this is generally advantageous over more lower-level languages like C. However, in certain situations, there is a fair bit of runtime overhead involved with (heap) memory allocation. Sometimes, you’d just like to use a container in static memory, or even stack memory. Enter sfl. This library provides ample well-tested containers that don’t require runtime memory allocation, or only require it under certain conditions. We’ve started to use it in various places with notable performance improvements! If you’re doing (game) development yourself, it’s definitely worth a look.

Continued loco_global integration efforts

As of last month, we have finished reimplementing all C++ functions, but our reimplementation still refers to vanilla 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. Such wrappers allowed us to start using strongly typed C++ from the get go, instead of having to rely on raw addresses for longer.

Many of the remaining loco_globals can be ‘integrated’ into static memory space as-is. However, extra care needs to be taken when more than one compilation unit refers to the same bit of memory space. For example, certain windows remember where the last ‘ghost’ element was placed. However, some game commands update those very same memory addresses. In such instances, this needs to be reworked, so there is only one real memory owner.

At the time of writing this blog post, 351 loco_global instances remain, across 95 files. Hopefully, by the time the next release turns around, we will have made ample progress in rewriting them.

This is a major milestone of a release. We have finally implemented every single function from the original game. This means that, apart from graphics and sound assets, OpenLoco is now a complete reimplementation of the game! Talking of graphics assets, this release also contains a whole bunch of new OpenGraphics objects as well.

For a summary of changes, please find the changelog on GitHub.

Changes and Features

Rotate Company Headquarters

@LeftOfZen was testing some refactoring to company headquarter ghosts, and noticed that you couldn’t rotate them from the UI. It’s a simple change, but adds to the consistency of the UI.

Improve Zoom to Cursor

Zoom to cursor was implemented many years ago, originally by @AaronVanGeffen on the OpenRCT2 project. Recently, on the OpenRCT2 project, @mixiate vastly simplified and improved the accuracy of the function. Aaron has now backported the improvements to the OpenLoco engine. It’s nice when we can share some code between the projects as the two engines are very very similar.

Disable Currency Selection in Title Screen

@LeeSpork found it odd that you could change the currency on the title screen. It didn’t do anything, but it was odd. Now it’s been disabled. It’s not too surprising this occurred; the title screen is basically displaying a save game like everywhere else. We should really get round to making our own title screen, like we have done for OpenRCT2.

Reimplementation

Implement Create/Remove Road Mod Game Command

These game commands are mostly useless as they’re only used to remove/add the catenary wires on tram tracks. I’m not sure why you would want to remove these wires, as trams require them to run. Either way, the commands existed in the base game so we have also implemented them. There is a huge amount of code for these commands, as they require iterating all connected tram tracks to remove/add the wires. One of the reasons to implement these commands is that their iteration code might be useful for other future features.

Implement Remaining Vehicle Update Functions

There weren’t many vehicle update functions left, but some of them were complex. The most complex were the road vehicle update. In particular was the function that calculated whether the vehicle should try overtake another vehicle. It does this by looking ahead for a slower/stopped vehicle and then lays out a chain of routings to change lane, overtake, then merge back. It did help finally resolve a bunch of unknowns I had with how the routings system worked. Other vehicle functions were the place down vehicle function, which is surprisingly similar to the overtake function, involving looking ahead for a clear section of road/rail to place, then laying out a chain of routings.

At some point I should really write a big blog post on how the routing system works, as it is complex at first sight, but easy enough to understand once you get stuck in.

Implement Update Traffic Handedness

I had left this function to the very, end as it did a bunch of moving about of memory that I didn’t want to implement. Instead, we can just duplicate the memory and reference the correct one based on traffic handedness. But I could only do that when all vehicle update functions were implemented. At the same time, I fixed an original bug where when road vehicles calculate lane occupancy if they are overtaking it would access invalid memory (company AI memory, to be exact). This could cause the check to return unexpected results. I’ve fixed this by ignoring overtaking, but I’m not 100% sure that that is correct. It is at least deterministic now. When overtaking, we should perhaps just say all lanes are occupied. Either way, perhaps something people should test and let us know if its a bit wonky.

Remove All Hooks

With all the functions implemented it was time to finally remove all the hooks into the original game. We are now free to modify interfaces to our hearts content, giving us lots of flexibility for new features. We aren’t fully standalone from the original game yet, as we still share some memory addresses, but it wont take long to change those.

With all the hooks gone we can also start getting x64 builds working, and perhaps even ARM builds.

OpenGraphics

We’ve forgotten to continue posting about OpenGraphics updates but they have been happening over the last few months; there are 24 new objects since we last posted in March about this, and they’re all by just 2 contributors, @shusaura85 and @glenjimen! Here’s a short summary:

Vehicles

@glenjimen figured out how to set up a modern Blender workflow and started generated some gorgeous vehicles, which all have twice the rotation frames as the vanilla objects so the look extra smooth in-game. The new vehicles/sprites are highlighted in red in the below image. Starting at the bottom, we have OG_GRAINHP2.dat replacing GRAINHP2.dat, then OG_GRAINHP1.dat replacing GRAINHP2.dat and finally in the top right, we have OG_GOODS1.dat replacing GOODS1.dat:

Road Stations

@shusaura85 replaced all of the vanilla road stations as well as the bus stop with OG versions:

Tunnels

@shusaura85 replaced TUNNEL1.dat and TUNNEL2.dat with OG_TUNNEL1.dat and OG_TUNNEL2.dat, respectively. Vanilla shown on the left, OG on the right:

Hill Shapes

The hill shapes object, HS1.dat, which controls how the vanilla terrain generation works, was replaced with OG_HS1.dat by @shusaura85. The new file has many more terrain shapes and much more natural shapes at that, generating some very nice terrain with vanilla generator. Vanilla is shown on top here, and the OG replacement on the bottom:

Streetlights

@shusaura85 replaced SLIGHT1.dat was replaced with OG_SLIGHT1.dat:

Land

@shusaura85 replaced all of the land types with OG versions. Top tiles are the vanilla land sprites, bottom are the OG replacements. The darker cliffs are the replacements:

Cliffs

Land objects have associated cliff objects, so these were also replaced by @shusaura85:

Snow

@shusaura85 replaced SNOW.dat with OG_SNOW.dat:

Water

@shusaura85 replaced WATER1.dat with OG_WATER1.dat:

For a summary of changes, please find the changelog on GitHub.

Bug Fixes

Company AI implementation

The last sections of Company AI have now been merged. The final part was all to do with the path finding for laying down track and road. I know a lot of people think that the AI path finding is rubbish, but it does at least mostly work. With it now implemented, we can start to think about how we could improve it. One idea I’ve had is to borrow the path finding code for use with a normal player. We could have a point to point pathing mode where it lays down the track for you. This wouldn’t be too hard to do, and perhaps it will help root out the bugs the AI has when creating a path.

Another idea I have, for Company AI in particular, is to try make it into a plugin. The idea being that the community could write their own AI that specialises in particular tasks. It is perhaps a little early to do just yet, but no harm having a think about what would be needed or require changing for it to happen.

Road Removal Game Command

@AaronVanGeffen implemented the road removal game command a few months ago. Unfortunately, it had a few little issues, and no-one at the time went through and fixed. After finishing the AI, I was free to fix the remaining issues. There wasn’t anything too revolutionary in the code, but we did make a very very minor tweak to the road removal cost calculation: it now rounds towards 0 instead of rounding towards -1. I’m sure no one will notice this tiny change, but it simplifies our code.

With Road Removal implemented, we now have all the core game commands implemented. In theory, you could play the game without hitting any of the unimplemented ones. However, there are two that you may hit: the road add/remove mods commands, which are used by tram track to add/remove catenary wires. It’s pretty useless to have a tram track without catenary wires, though.

Game commands are the core mechanism that makes multiplayer work, so with them mostly all done now we could start looking at multiplayer properly!

Miscellaneous Implementation

This month we had three contributions outside of the core team that were focused on implementing functions. Thanks everyone who contributed!

@spacek531 implemented the connect jacobs bogies code a few months ago. Much like road removal, it had been sitting in the review queue for a while, sorry about that. It is now finally merged.

@fionasoft implemented destroyTrain, which is the code that handles train crashing. It was a fun one to test!

@petergaal implemented a number of scenario setup functions. These functions handle working out the best road for towns to place and initialise some lookup functions that speedup calculations.

I implemented updateTree, a surprisingly complex update function. Trees, it turns out, can grow, multiply, die, and be covered in snow. There are a huge amount of things that can trigger the tree death! And tree death is a whole animation in itself; it’s not just a simple case of removing the tree.

Vehicle Route Finding

With the AI now finished, it was time to move focus to the remaining vehicle functions. The majority of the remaining vehicle code all had interactions with routing. I had purposely left these functions until the end to ensure we understood how things worked. I’m still not 100% sure, but I think I get the gist of it.

All vehicles are comprised of a number of cars and a number of hidden components. All of these components have their own positions and are updated separately. They all share what I have called a routing. A routing is a list of track ids that the vehicle will follow. The maximum length of the routing is 64 track ids. (This is why you can’t place a train that takes up more than 64 track pieces.) It’s not quite as simple as ‘head of train is the first routing entry’, though. There is an invisible component that runs in front of the head of the train (I think) and there is an invisible component trailing at the back of the train (I think).

Whenever a vehicle comes up to a junction, it has to decide on a routing. This is the route finding code. It works mostly how you would expect, i.e. find the shortest path to the destination. It can only look ahead a certain distance, and only a max of 5 functions. It also has to take into account signals, which will hopefully indicate if there is a train blocking a route. Track and road route finding look to be mostly the same, but with the additional complexity of signals for track and multiple lanes for road. There are three variations of the route finding code. One for normal path finding, one for aimless wandering (when you don’t set orders) and one for longest path. This last one is a bit curious, and it appears to be used with placing down vehicles. I haven’t quite got to the bottom of what it is there for yet.

Windows and UI

@LeftOfZen has finally fixed the issue with scrollbars when you have a huge number of items. The scrollbar should no longer break.

@ZehMatt has been fixing more of the fallout of adjusting how coordinates work, so hopefully now there aren’t any graphical issues when you have the news window open. He also identified an issue with the landscape generation window resetting its state every tick, which presented itself in problems scrolling the terrain options.

Last but not least, @LeeSpork has been adjusting the map window ensuring its minimum size is sensible.

Preparation for standalone

As we are nearing the end of the reimplementation effort, we need to start getting ready for being standalone. This month, @ZehMatt has been replacing stored pointers in object code with memory offsets instead. This is a neat trick that will simplify the code when we move to 64-bit.

I started looking at how we can track all our reading/writing of original game memory. We will need to make sure that we don’t read/write in original game memory space if we want to be standalone. It’s a bit of a dull task but it will help with understanding the code as well.

Italian translation

New contributor @Martinocom has added an Italian translation to the game. It’s great to have new contributors and new languages!

Infrastructure

New contributor @tyrone-sudeium has added a Linux statically linked build type which uses vcpkg for dependencies. This works much the same as the Windows build, which is also statically linked. I know that traditional Linux developers may see this as sacrilege, but it does make things much simpler. We will of course not be removing the existing dynamically linked setup.

@janisozaur has been fixing a few small warnings on newer compilers, ensuring when we update it all runs smoothly.

Bug Fixes

At the end of last month, I merged a cleanup change that was meant to fix an edge case with viewports. Unfortunately, it also broke right-click viewport dragging. This has now been fixed.

There was also a bug with the AI, which would cause a crash when the AI was creating an intracity network. I’m not completely sure what triggers this, but it was a mistake made whilst implementing the AI.

Company AI implementation

The Company AI is fully implemented as of today, but it is still under review. In this release, we have merged the remaining game commands that the AI uses to build. For some reason, the AI has a combined command for building track/road and stations. They ultimately just call the place track/road command, followed by the place station command. Ultimately, not too exciting, but interesting that they exist. Perhaps in the future we could make these commands available to users. Although, if we did, that would have to correct the cheats the AI has in the commands that let them place without spending money!