OpenLoco v24.08 and Object Editor v2.0.0 v2.3.0 is out!
We’ve implemented even more of the game and fixed a number of bugs.
On the object editor front it now has a nice new cross-platform Ui.
For a complete summary of changes, please find the OpenLoco changelog and Object Editor changelog on GitHub.
Object Editor
This month saw the release of Object Editor v2.0.0 (and then quickly followed by v2.1.0, v2.2.0 and v2.3.0)! This update provides cross-platform support (Windows, macOS, Linux), greatly improved performance, adds dark mode, amongst many other features. The editor is still being actively worked on and improved, and near-future releases are targeting better nested object editing, object validation, object optimisation, the ability to view and edit other Locomotion files (save games, tutorials, etc), and porting a few missing features that the old Windows-only editor has.
Rumour has it there will also be an online mode that connects to a central object server and lets you view and download any object we know about. This will also benefit OpenLoco, as it will allow the game to automatically download missing objects. Stay tuned in the next few weeks and months as there are exciting things happening in this space!
Please submit feature requests and bug reports for the editor, but remember to submit them in the ObjectEditor repository, not the main OpenLoco repository.
Implement Create Port Game Command (#2541)
It seems that the Building, Industry, Port, Airport commands are all very similar, which is great news since we can mostly copy, paste, modify to implement the other commands. It also means that anyone working on custom objects (with the object editor hopefully!) will be able to use the same techniques for all four types when creating the images.
When we were implementing the commands, it appeared that the port command was done last, and has been copy, paste, modified from the airport command. In one place, it accidentally reads an airport variable instead of a port one, leading to a very minor mistake for the company face emotion. All fixed in OpenLoco though.
Implement Sprite Interaction (#2550)
To detect what the cursor is currently hovering over, the game creates a 1x1 pixel image at the cursor hot point. It then works out all the images it needs to draw using the ‘paint’ functions (see other blog posts) and draws the images back to front (painters algorithm). Instead of drawing though, it just works out if an image overlaps another image. Once it knows what image is drawn at the top, it is able to look at the paint meta data for the image to tell what is under the cursor.
This function is mostly identical to the same function in RCT2, and therefore also mostly the same idea as the function in our sister project OpenRCT2. Recently the OpenRCT2 version was refactored, and made into quite a readable form. This gave me inspiration to finally do the OpenLoco version of it. With this now implemented, I think we have now implemented enough that we should be able to introduce custom g1.dat image assets.
Remove unused code (#2542, #2586)
@AaronVanGeffen was in a cleanup mood this month and deleted a bunch of unused code that was originally used for RCT2 features, like picking up guests and drawing weather effects. We do plan to maybe add some sort of weather effects back into the game, but the way these ones worked was not ideal. Also removed was some memory allocation and freeing functions that haven’t been used for a long time. All this leads to a simpler codebase where its easier to see what we have left to do.
Implement Misc Functions (#2553, #2546, #2551, #2564, #2537)
When working out what to work on, I often search the codebase for functions calls to
Interop::call(xxx). Each of these calls represent code that has not been implemented. For the
longest time we have had 100+ Interop::calls. I went on a bit of a spree this month tackling some of
the more simple functions just so I could finally see that number below 100. It now sits at ~90!
This doesn’t mean we have only 90 functions left to implement, but it does mean we are getting closer to
the end goal of a complete reimplementation.
There wasn’t much of note in the functions implemented, but one useful one was the track/road mod (overhead wires) right click interaction. After implementing this @AaronVanGeffen quickly followed it up with a new feature: the currently selected track mod section is now used when right click interacting. All this means you can now remove track mods (e.g. overhead wires) by signal section or whole track network rather than only individual tiles.