OpenLoco v25.05 is out! This month, we’re introducing new colourful ways to pimp your trains, made it easier to upgrade stations, and did a fair bit of work behind the scenes. For a summary of changes, please find the changelog on GitHub.
Recolour invidiviual vehicles
In Locomotion, players can choose up to two company colours to decorate trains in. This means trains can either look very colourful, or rather drab, with not much in between. @Spacek set out to change this, and filed a PR that makes it possible to optionally recolour individual vehicle parts (#2897). This means you can now customise train colours to your heart’s content! Take a look at the video below for a quick demo of how this works.
Upgrading station elements directly
Last month, we introduced a new way to quickly build track and station elements. This was received very well, but immediately sparked new ideas and minor annoyances, as is tradition. The main thing that stood out to us was how it was cumbersome to upgrade station elements. Basically, in vanilla Locomotion, players have to remove each of the existing station elements in order to place new ones. No longer!
This month, we’re introducing one-click upgrades of existing station elements (#3087). This can be done in two ways: either by clicking individual station elements, or using the dragging method we introduced last month.
Often, a picture speaks a thousand words, so have a look at the video below to see it in action!
Note that replacement costs are calculated. In the video, however, the replacement is free. Why is that? Well, vanilla Locomotion station objects have their removal costs set to completely fund the initial construction costs! This means the removal costs and construction costs zero each other out, making the upgrade free. We think this is not the most realistic, but won’t be changing this before we settle on a new object file format.
Scenario editor improvements
Time doesn’t pass in the scenario editor, so you can take your time building leasurely, right? Surely, nothing will interfere with this, no? Well, as it turns out, there was a Locomotion bug that did just that! @LeftofZen identified a line that wasn’t taking the editor into account, which made buildings disappear in scenario editor as well. This has now been addressed (#3096).
Years ago, OpenLoco introduced a Tile Inspector, which is currently mostly used for debugging purposes. This wasn’t available in the scenario editor, though. Until this month, thanks to a patch from @LeeSpork (#3097)!
Ongoing window system modernisation
Over the last few month’s, we’ve been slowly working to modernise the game’s window and widget system. This month, we changed windows to render their contents relative to their origins, rather than in the full game canvas’ screen space (#2936). This actually makes the drawing code much easier to read, hopefully saving us further headaches down the line.
Another changes is the Window structs are now passed as references in more places,
as opposed to raw pointers (#3103).
Implicitly, this means null-pointers are explicitly avoided, meaning less boilerplate again.
While most of this work is invisible to players, for now, sometimes mistakes slip in. Such is the case this month, with a funny bug: the construction window’s panel background widget was acting like a button! This is fixed in #3110.
Steam install autodetection
As won’t come as a surprise to the reader, you need a copy of the original Locomotion game to play OpenLoco. Getting set up can be a little tedious if you don’t know exactly where the original game has been installed, however. Thanks to a patch from #LeeSpork, OpenLoco now automatically detects Locomotion installs in the default Steam folder on Windows (#3098).
Company AI implementation
@duncanspumpkin’s efforts to reimplement the company AI functions continue unabated. This month, he’s started unravelling what is arguably the longest spaghetti yet: the routefinding. Not known for its accuracy or directness, the company AI’s routefinding can definitely do with improvement. Before we can do so, though, it needs to be reimplemented as-is, in order to fully understand what’s involved. Thanks to Duncan’s tenacity, the first part of this herculean effort is now done (#3101).
Fix a compiler ICE
Compilers are the tools of our trade, translating our C++ code into something computers can run. Internal Compiler Errors (ICE) are rare, but we ran into one on the latest version of the Microsoft Visual C++ compiler (MSVC). Surprisingly, the code in question was not doing any arcane wizardry, instead it was ostensibly innocuous. We assume it’s a bug in the compiler, and have worked around it for now (#3109).