openloco / openloco

An open source re-implementation of Chris Sawyer's Locomotion

OpenLoco

An open source re-implementation of Chris Sawyer's Locomotion. A construction and management simulation video game that simulates running a transport company.

---

Contents

• 1 - Introduction
• 2 - Downloading the game (pre-built)
• 3 - Contributing
• 4 - Compiling the game
  • 4.1 - Building prerequisites
  • 4.2 - Compiling and running
• 5 - Licence
• 6 - More information

---

Build Status

	Windows / Linux	Download
master

Chat

Feel free to join our Discord server to talk about developing the game, or for help getting it to run.

1 Introduction

OpenLoco is an open-source re-implementation of Chris Sawyer's Locomotion (CSL), the spiritual successor to Transport Tycoon. OpenLoco aims to improve the game similar to how OpenTTD improved Transport Tycoon, and OpenRCT2 improved RollerCoaster Tycoon.

CSL was originally written in x86 assembly, building on top of the RollerCoaster Tycoon 2 engine. However, the engine has changed substantially enough that OpenLoco currently does not share its codebase with OpenRCT2.

The reimplementation efforts of OpenLoco are gradual, aiming to ultimately rewrite the entire game in C++. In the earlier years of the project, the in-game UI has been completely reimplemented, and most of the underlying data and object structures have been uncovered. Recent efforts have focussed on reimplementing the game (command) logic. Once this has been completed, it is our goal to get a solid multiplayer experience working in OpenLoco. It is also our goal to increase the map and vehicle limits. However, until all logic has been reimplemented, we are bound to the limits imposed by the CSL save format (SV5/SC5).

---

2 Downloading the game (pre-built)

The latest releases can be downloaded from GitHub. Releases are currently provided only for Windows. For Linux and BSD distributions, we currently do not provide any builds. Please refer to the next section to compile the game manually. For macOS, we recommend using Wine.

Please note that OpenLoco requires the asset files of the original Chris Sawyer's Locomotion to play the game. It can be bought at e.g. Steam or GOG.com.

---

3 Contributing

We warmly welcome any contributions to the project, e.g. for C++ code (game implementation, bug fixes, features) or localisation (new translations). Please have a look at our issues for newcomers.

For code contributions, please stick to our code style. You can use clang-format to apply these guidelines automatically.

---

4 Compiling the game

If you would like to contribute code to OpenLoco, please follow the instructions below to get started compiling the game. Alternatively, we have platform-specific guides for Ubuntu and macOS.

If you just want to play the game, you can just download the latest release from GitHub. Releases are currently only provided for Windows (32-bit only).

4.1 Building prerequisites

The following libraries/dependencies are required:

• libpng
• libzip
• OpenAL
• SDL2
• yaml-cpp (fetched during CMake generation)
• fmt (fetched during CMake generation)
• breakpad (only required on Windows)

Windows

• 7 / 8 / 10 / 11
• Visual Studio 2022
  • Desktop development with C++ (ensure MFC component is selected)
  • Dependencies are managed with vcpkg

Linux

• cmake 3.22+
• make or ninja
• 32-bit versions of the libraries mentioned above

---

4.2 Compiling and running

Note: The game can currently only be built for 32-bit architectures.

Windows:

1. Check out the repository. This can be done using GitHub Desktop or other tools.
2. With VS 2022 use the "Open a local folder" option to start the project file generation. This may take some time as it downloads dependencies.
3. After successful generation of the project files open "build/windows-msvc/openloco.sln".
4. Select a config Debug or Release and run Build -> Build Solution.
5. Run the game from "build/windows-msvc//OpenLoco.exe" or within VS.

Alternatively using CMake use the following commands.

1. Run cmake --preset windows-msvc
2. Run cmake --build --preset windows-msvc-release

Linux:

The standard CMake build procedure is to install the required libraries, then:

cmake --preset linux
cmake --build --preset linux-release

Installing some packages can be problematic on desktop AMD64 distributions. To work around this, you can use our Docker images for compilation.

Note: Due to issues with distro yaml-cpp packages, its source release is downloaded during CMake generation.

Running the game will need the data directory from the root of the source code next to the binary. Assuming you're in $SRC/build,

ln -s ../data
OR
cp -r ../data ./data 

MacOS

For technical reasons OpenLoco can only be built as 32-bit x86 application, for which Apple dropped support in Mac OS 10.15. We can't provide MacOS builds at this time.

---

5 Licence

OpenLoco is licensed under the MIT License.

---

6 More information

• GitHub
• TT-Forums
• Locomotion subreddit

openloco's Issues

Feature request: on-screen FPS indicator

As seen in OpenRCT2.

Name window events

	event	name?	called by
	event_0]		window_close
42	event_on_mouse_up]
39	event_2]	resize
	event_3]		window_process_mouse_input
5	event_4]		window_process_mouse_input, ui__construction__event_1_on_mouse_up
	event_5]		window_process_mouse_input
4	event_6]	update
	event_7]		sub_4CD3D0
2	event_8]		handle_input, sub_4C98CF
2	event_9]		handle_input, sub_4C98CF
	event_10]		sub_4CD422
	event_11]		window_process_mouse_input
	event_12]		window_process_mouse_input
	event_13]		window_process_mouse_input
	event_14]	tool_abort	tool_cancel
	event_15]		process_mouse_over
7	event_onscrollgetheight]	get_scroll_size
	event_17]		window_process_mouse_input
	event_18]		window_process_mouse_input
	event_19]		window_process_mouse_input
	event_text_input]
	event_21]		sub_45F18B
	event_22]		window_process_mouse_input
2	event_tooltip]
	event_24]		process_mouse_over
	event_25]		window_process_mouse_input
111	event_26]
	event_draw]
	event_scroll_paint]

Did some inventarisation. Listed are all the possible window events, and how many times they're called (if > 1).

Feature request: additional vehicle route commands: "wait for ANY load of X", "wait for at least N units/tons of X"

In the vanilla game, you can add a "wait for full load of " or "unload all " entry to a vehicle's route.

If you're in a situation where you want a train to go back and forth between station A and station B, and you want the train to wait at station A until there is at least some cargo of a particular type available there, but you don't want the train to mindlessly just leave station A and do a full round trip to station B and back if it there didn't happen to be any cargo available to load at station A, and you also don't want to have to force the train to wait for a completely full load at station A, the vanilla game has no way to let you do what you want.

---

This problem could be solved by implementing another type of command that can be added to the vehicle's route: "wait for any load of ". Then, when the train arrives at station A, if there are 0 units of cargo, it will wait there, loading, until the station does have >0 units of cargo for the vehicle to load up. (Same wait-in-loading-state behavior as with "wait for full load", except that it won't wait all the way until the vehicle is entirely full.)

A very real scenario where this would be useful is with cargoes whose value upon delivery declines steeply with time: particularly grapes (vineyard --> winery). You typically don't want your train to wait for a full load of grapes at the vineyard station, because the time spent loading at the station counts toward the delivery time, decreasing the value of the delivery. But you also don't want your train to arrive at the station, load 0 tons of grapes because there were none there, and then do a useless, time-wasting round trip to the winery station and back delivering nothing.

There are a variety of reasons why there might be no cargo available at the station right when the train arrives:

• It's a station on a multi-train route, and another train just filled up with all of the available cargo
• The vineyard isn't producing any grapes temporarily, due to it being wintertime and the crop plots being at high altitude and therefore being snowed upon and producing no grapes
• The station where the train loads up is a "handoff" station [trains on route 1 pick up cargo from a producer industry and then force-unload it at the station; and then trains on route 2 pick up the unloaded cargo from the station and take it to its final destination], which generally tend to have 0 units of cargo and then suddenly have dozens/hundreds of units dumped into them all at once by the vehicles from the first segment of the route (and so therefore you want vehicles on the second segment of the route to wait at the handoff station until there's some cargo there, but probably not wait for a completely full load, since that might mean waiting for another round trip from the vehicles on the first segment)

Also, if we add "wait for any load of X", we may as well also add "wait for at least N units/tons of X", so that you can have behavior similar to "wait for full load" but with an exact threshold instead of 100%. (Could also do it as "wait for at least N% capacity of X", "wait for at least a half load of X" (quick automatic 50% version of the former, etc.)

I mean, good grief, for Sawyer's sake! RollerCoaster Tycoon 1 had far more advanced loading options available in its ride station window. Wait for any load, full load, half load... wait for at least N seconds, wait for no more than N seconds... leave if another train arrives at station... So it's kind of insulting when Locomotion gives such limited functionality by comparison.

(Incidentally, a "only wait for up to a maximum of N in-game days" sub-option on "wait for load of X" commands would be good to have.)

---

This is obviously something that'll need to wait a bit before it's possible to implement. And it'll need an extended save format, since the route entries/commands are obviously persistent with the vehicle and there'd need to be additional new vehicle states as well. But I figured I'd post it now so we remember to come back to this later on. (Also I've been playing Locomotion a bunch lately and was actively being bothered by the lack of this exact feature mere moments ago.)

Add some screenshots in the README

I think people will be more interested in testing this re-implementation and maybe collaborate with some code if you show the current state of this port.

Case insensitive file loading needed for POSIX

Feature Request: Train Depots

This should be an obvious yes, it makes sense porting some features either from OpenTTD or TTD itself. I thought that the train Depot is quite versatile for the fact that a train could go in while others could go past without worrying about crashing into another. Makes doing repairs more safer.

Original game bug: railroad stations refund for slightly more money than they cost to build 💰

This could be considered a minor exploit that allows you to earn money for free; it would take a very long time to actually take advantage of this to earn a useful amount of money, however. In general, it seems to just be an oversight; a percentage that was set to an unintended value.

Most station-types-of-things (e.g. cargo loading bay, passenger terminus, and passenger stop, on roads) will refund about 70-75% of the money they cost to build if you remove them immediately after building. The same goes for things like signals and electric lines on railroads, and for docks and airports: most refund for ~70-75%. There are some exceptions there, such electric wires on railroads, which refund for only 50%, and docks, which refund for 90%, which seem sort of arbitrary (particularly the docks one; airports, which are generally considered to be an analogous type of "port" to ship ports, refund for a straight 75%, by contrast). In any case, all of the things I've just mentioned refund for less than the cost spent to build them.

For some reason, railroad station segments refund for the same amount of the money spent to build them. And in fact, for reasons that I can't entirely explain, in most cases that I've seen they actually refund for exactly $2 more than was spent to build them, regardless of what year it is. (It's always $2 more, never any other amount.) If I had to guess, this is probably due to the game doing some sort of small rounding-up operation after it multiplies a 100% percentage on the construction cost. I am essentially 100% certain that this phenomenon is not related in any way to the in-game inflation simulation.

---

Here's a pair of screenshots demonstrating the railroad station build/destroy money phenomenon in the year 2000.

Building for $17,468 per segment:

Destroying for $17,470 per segment:

Cloning vehicles

Currently, if you want an extra vehicle to follow a certain route, you'd have to buy a new vehicle, add cars if it's a train, then make orders, then make it run, but if there were a cloning option, you'd just clone it and make it run.

That feature would be especially useful if your vehicle has a lot of orders or cars because it'd require a lot of clicking if you do it the normal way.

AppVeyor

Create an appveyor project that automatically builds each push

Fix rail viaduct's glitch when it's over road

It is weird to have a bridge with no pillars.

Closing all windows by pressing Delete button

The title speaks for itself.

Feature request: add keyboard shortcut bindings for the slow/medium/fast simulation speed buttons

In vanilla Locomotion, there are no keyboard shortcuts for the > >> >>> simulation speed buttons; the Keyboard Shortcuts options window only offers a binding for toggling the || button ("Pause/Unpause Game"; defaults to the Pause key). The omission is frankly a bit baffling.

(This is another feature request that'll have to wait a while, but I wanted to open it now.)

Original bug: trains with many engines can be perpetually broken-down and un-modifiable

Three relevant facts:

• Engines are able to break down as long as their parent vehicle is not stopped.
• If a vehicle with even a single broken-down engine is told to stop, it will wait until all engines are fixed before it actually enters the stopped state.
• Vehicles cannot be sold or modified unless they are stopped.

The logical conclusion is hard to encounter by accident in the base game, but happens easily in the official Shinkansen add-on scenario because every car on a Shinkansen train is an engine that can break down. Basically, once reliability falls to a certain point (which is a higher number the more engines are present), the train enters a vicious cycle where, while one broken-down engine is being fixed, another one breaks down, and then when that one is being fixed, another one breaks down, ad infinitum. Such a vehicle will never enter the stopped state even if it isn't actually moving, and thus it can never be sold or edited to solve the problem, and will also cease to generate any money as trains also can't load or unload while broken-down.

It may or may not be possible to get rid of such a vehicle, depending on whether or not it is still moving. If it is, you can delete the tracks under it and it will crash. If it isn't, you're out of luck, as it will just float uselessly in place if the tracks are removed.

Make mountain tool available when adjusting land in-game

It would be good if she went to edit the country as in the map editor. Then railways would be better in the game. So I've got to make the slides in advance in the editor and figure out where to run the rail.

macOS build crashes as soon as you want to start a scenario

Stack alignment issue, but I don't understand where it comes from. AFAIK I hooked all library calls, yet those don't get mentioned during the crash.

* thread #1: tid = 0x2213952, 0xa16bb200 libdyld.dylib`misaligned_stack_error_, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0xa16bb200 libdyld.dylib`misaligned_stack_error_

Original game bug: AI builds simple ship line where one dock is in an obviously-landlocked lake

Just ran into this particular AI bug today while playing the game.

This AI company started up, and as its first action, built two docks (one by San Diego and another by Los Angeles) and placed a hovercraft at the San Diego dock.

Problem is... while the Los Angeles dock was toward the Pacific Ocean side, the San Diego dock was built in a small lake (geographically it appears it's meant to be the Salton Sea) that's completely disconnected from the Pacific Ocean or any other body of water. So the boat can't actually get from one dock to the other.

How hard could it be for the AI company logic to check that there's a passable, connected water route between the two docks in this maximally simplistic ship route? The game goes as far as to disallow land tool alterations in the water if the modification would impede active boat routes, so clearly it must have some statically-determined notion of the path the boat will take between its stops. But I guess there are some circumstances under which it just does a really poor job of pathfinding. Like, so poor that it believes the ship will take an overland route somehow.

Screenshots and save files below.

Screenshots

Screenshot 1 of 4

Overview of the braindead ship route set up by the AI company.

Screenshot 2 of 4

The AI company doesn't have a low Intelligence score or anything like that. (See game manual page 84 for description of Intelligence attribute.)

Screenshot 3 of 4

Demonstration of water tiles near the San Diego dock where raising the land is disallowed. I raised land on all of the tiles where it was allowed; the one-tile-wide path where there's still water is the area that the game protects because it believes it to be part of the boat's current route.

Screenshot 4 of 4

I also tried messing with the land in front of the Los Angeles dock; it actually allowed me to completely surround the dock with non-water tiles. This would never happen normally. Also, in the earlier screenshots you may have noticed that there's a narrow river a short distance inland that vaguely goes parallel to an imaginary line drawn between San Diego and Los Angeles; I was able to blockade that river with land tiles freely as well wherever I tried, with no complaint from the game.

Save Files

I was making incremental saves with this particular game, so I have one from shortly before the AI company started up, as well as one from after it started up and built its docks in idiotic locations.

Save File 1 of 2: May 11, 1980

North America (West) 1980 13.zip

This is the latest save file I have from before the AI company starts up. I moved the camera over to the San Diego / Los Angeles area and re-saved for testing convenience, but otherwise left it exactly the same.

If you load up this save file, Rottenfish Transport will pop into existence on May ~23; he'll start "Surveying landscape near San Diego" on May ~30; and then he'll start building his ship route on June 1.

Annoyingly, with this save file, while he does build essentially the same ship route, he consistently builds the San Diego dock on the Pacific Ocean side, in exactly the same spot every time (i.e. he doesn't reproduce the buggy behavior where he builds it in the Salton Sea). I suspect this must be due to the scenario random seed being a bit different than it was when I was actually playing (originally, I was building railroad tracks over to the East at the time, which presumably influenced the random seed I guess).

Save File 2 of 2: May 29, 1980

North America (West) 1980 14.zip

This is the save file that I made immediately after the AI company started up and had built its docks, but before it placed the ship down at the San Diego dock. You'll notice the slightly different dock placement compared to the earlier save file, as well as the slightly earlier build date, due to different influences from the game's random system.

With this save file, you can enjoy watching the hovercraft go around and around in circles in the Salton Sea after it departs the San Diego dock; and you can try out some of the land modification stuff that I described earlier for yourself.

Feature Request: Custom Catenary

The default overhead wire for locomotion is a bit boring, and depending on what country you're from, it can look out of place. However a function to be able to 1. change the catenary type, and 2. change how far apart the poles can be. that would be a major improvement for scenery
for instance, maybe some PRR catenary for NEC routes

Original bug: orphaned yellow build direction arrows & white ghost sprites

I think this also happened in RCT2 from time to time, can't remember for sure though.

Sometimes when you leave construction mode, the yellow arrow sprite will remain where it was semi-permanently, and you can move around and so forth and it'll continue to be drawn at that location on the world. As soon as you re-enter construction mode and the yellow arrow is needed again, the orphaned arrow sprite will go away and return to its proper position for the new construction being done.

I've also seen white ghost placement sprites become orphaned in a similar manner when cancelling out of construction mode. I can only confirm for sure that I've seen this happen for the company headquarters building, but it may be possible for other types of buildable things.

Original game bug: AI companies build roads with lots of unnecessary turns

I wrote up a big wall of text about this on the Gitter, so I guess I'll save some time and replicate that here:

The plane left/right/left/right thing is very similar to how the idiot AI's build their ground vehicle routes. Particularly roads. Suppose they are building a truck route and need to do an overall diagonal path to get from point A to point B. Well, roads in this game, unlike rails, can only face 90 degree directions: there's no 45-degree half-turn piece. The only turn options you have for roads are a single-tile tight turn and a 2x2-tile wide turn. Given that these constraints are in place, the optimal thing to do would be to build the road so that it primarily consists of one long stretch at one 90 degree angle, and then another long stretch at the other 90 degree angle (so that the hypotenuse of the triangle goes directly from point A to point B).

But the AI wants to make a diagonal road really, really, really badly, and so it will build its road as an approximation of a diagonal road, by alternating left and right turn pieces back and forth. But of course, as you cannot build a true diagonal road in the game, there's no advantage to making a crude approximation of a diagonal road out of a bunch of 90-degree turns; it's still effectively equivalent to building an L-shaped road with two long straight 90-degree segments. (I guess technically the 2x2-tile wide turns would get a very slight distance reduction compared to the L-shape, thanks to Pythagoras.)

Now, the consequences of the AI's decision to make a futile attempt at building a diagonal road using back-and-forth turns are that (a) it looks ugly and stupid, and (b) the trucks travelling on the route have to slow down on turns, especially the tight turns; there are max speed limits for each different turn radius. So particularly in more modern years when the available trucks have a higher max speed and could take advantage of it on long straightaways, the AI's zigzag roads ensure that their trucks will constantly be travelling well below their maximum speed. Meaning that making the road "diagonalish" ends up being completely counterproductive for them.

It remains to be seen whether the AI's road construction logic consists of trying to stay as close to a straight line from point A to point B as possible; or if perhaps it does some sort of optimization for shortest path distance, and the 2x2 turns have a distance value assigned to them which leads the AI to believe that a path with more turns will be shorter overall (due to 2x2 circle circumference versus 2x2 square perimeter: 2*pi is around 75% of 8); or if there's some other idiocy going on.

The ultimate fix here is to make the AI realize that building a road with an excessive number of turns, especially 1-tile tight turns, involves a substantial speed penalty for their trucks/buses, making the turn-heavy route actually inferior to a straightaway-heavy route in the end; and have them factor that into their decision of the route they decide to build. (At least for the cases where the vehicles that the AI intends to put on the road have top speeds sufficiently high that the turn-radius-enforced speed limits would force the vehicles to slow down considerably. For some of the earlier-year vehicles, it doesn't matter as much, since they have relatively low top speeds anyway.)

Perhaps the AI logic could do a time-to-traverse-the-route simulation when it's deciding which hypothetical road to build (factoring in the vehicles it plans to use and the speed limits at each piece of road it will follow due to turns and bridges and so forth), so that it can actually compare between a straightaway-favoring route and a turn-favoring route and have the matter of "oh wait, these turns mean that it will actually take longer to get there, despite the route ostensibly being closer to an optimal diagonal path" come into play.

Or, a simpler approximate way to implement this might be to just arbitrarily assign turn pieces a "negative point value", if you will, that makes the AI try to avoid using them unless they are truly necessary to make building the route possible or to avoid making an expensive alternative route that involves bridges or whatever. 2x2 wide turns get a mild negative selection bias, and 1x1 tight turns get a much harsher negative selection bias. Something like that.

Original game bug: Airplanes are really twitchy as they taxi on the runway and in air

It's bizarre to me that the original makers of this game decided to included a scene of an airplane taxiing at an airport in the title sequence, because it's hard not to notice the weird twitchy "fake-out" turns the plane does as it moves along. You'd think they'd have noticed it and done something about it.

All airplanes seem to do this. Here's a video of a 747 being twitchy at a Large Airport:
https://youtu.be/heF0R7actig

Seems like a screwup of some kind with the animation frames for all aircraft.

Also, airplanes frequently do really twitchy things while in the air. If you watch closely, you can catch a brief glimpse of this in the video posted above at around the 0:37 mark, right as the airplane accelerates through 350 mph or so. For one frame, it suddenly appears to have turned to the left (90 degrees off from the direction it's travelling); and then the next frame, it's back to normal.

Ability to make trees and buildings fully transparent

Income floating text renders as red, not green

I was playing the scenario "Weatherworld" and created a simple passenger train, which rain between two towns. Upon arriving at a station, the floating money text would appear, but would be red instead of green:

Feature request: make shift key during construction work more like RCT2 (config option, probably)

In RCT2, the shift key lets you move the ghost piece you're about to build up and down freely, so you can begin building at any height you want above ground, or below ground. It's great.

In Locomotion, the shift key only moves the ghost piece down to one fixed spot (the minimal amount of lowering required to make it be underground). There's no way to start building at other depths underground, and more egregiously, there's no way to start building at any height above ground.

I have no idea why Chris Sawyer did it this way; maybe he started implementing the (more limited) shift key functionality when first working on Locomotion post-RCT1, and then when he got sidetracked into doing RCT2, he thought it'd be handy to have the feature in that game too, and even extended its functionality to be more useful; but then when he got back to work on Locomotion, he never thought that the additional "choose heights other than one depth just barely underground" functionality would be a good thing to backport over?

RCT2 lets you build a freaking Burger Bar deep underground, or way high up in the air on a silly support structure. Yet Locomotion doesn't allow you to do the frequently-convenient (and sometimes necessary) task of starting construction at any height other than ground level or just slightly underground. Instead, you have to do stupid nonsense like building ramps to get up to the height you want, and then destroy the ramps; but that's costly since the ramp pieces have bridges under them and are therefore expensive to build but only refund a fraction of the funds when destroyed (and it's even worse if you have to do the ramp thing underground, since tunnels are even more expensive to build than bridges but still share the barely-refund-anything-when-destroyed property). And there are also cases, in tight situations, where it's just not really feasible to do the ramp gimmick anyway.

I'm thinking it would probably be reasonable to make this a default-on config option, so that people who still want the shift key to do just that one limited thing that the game manual says it'll do can have it continue to work that way if they really want that for some reason.

Feature Request: Expand upon the Multiplayer Side of Loco

I propose the p2p system for the original game multiplayer be swapped with a more up-to-date system of Server Lists similar to that of OpenTTD's style. Granting ease of access to more profound multiplayer experiences in a flash!

Feature request: path based signalling (PBS) for railways, like it's is available in OpenTTD

After playing OpenTTD with PBS it felt really annoying, to have only the block signalling in Locomotion, which allows only one train per block. I would like to see this enhancement in OpenLoco.

Release macOS artefacts on tag

Currently AppVeyor builds and pushes it's artefacts to a GitHub release on tag. The same should happen for macOS.

Feature Request: Ability to place fences in game

I've noticed that you can only place fences in scenario editor and not in-game. It's a good scenic object and can be useful if you feel up to making your game look neat (side note: this would also be a good idea for misc buildings)

Station var_2A

var_2A is read by the UI, and used to form a string. station->var2A % 15 + 230. The strings line up with different station types:

STR_0230    :                                                        0
STR_0231    :{SYMBOL_RAILWAY}                                        1    < Rail
STR_0232    :{SYMBOL_ROAD}                                          10    < Road
STR_0233    :{SYMBOL_RAILWAY}{SYMBOL_ROAD}                          11
STR_0234    :{SYMBOL_FLAG}                                         100    < Airport
STR_0235    :{SYMBOL_RAILWAY}{SYMBOL_FLAG}                         101
STR_0236    :{SYMBOL_ROAD}{SYMBOL_FLAG}                            110
STR_0237    :{SYMBOL_RAILWAY}{SYMBOL_ROAD}{SYMBOL_FLAG}            111
STR_0238    :{APPROX}                                             1000    < Sea
STR_0239    :{SYMBOL_RAILWAY}{APPROX}                             1001
STR_0240    :{SYMBOL_ROAD}{APPROX}                                1010
STR_0241    :{SYMBOL_RAILWAY}{SYMBOL_ROAD}{APPROX}                1011
STR_0242    :{SYMBOL_FLAG}{APPROX}                                1100
STR_0243    :{SYMBOL_RAILWAY}{SYMBOL_FLAG}{APPROX}                1101
STR_0244    :{SYMBOL_ROAD}{SYMBOL_FLAG}{APPROX}                   1110
STR_0245    :{SYMBOL_RAILWAY}{SYMBOL_ROAD}{SYMBOL_FLAG}{APPROX}   1111

Game graphic broken

OS : Windows 7
Commit : c71a455

Graphics are broken so I cannot test it all.
I use notebook(with 610M nvidia optimus) both graphic modes are not working(intel or nvidia)

Increase stations length limits (Long Station Patch)

Another patch, just wrong, can not use the aircraft.

https://www.tt-forums.net/viewtopic.php?f=38&t=50627

Feature request: add "Quit OpenLoco" menu item to the main menu

Just like vanilla RCT2, vanilla Locomotion only gives you a single "Quit Game" main menu item when you're in a scenario; and this menu item merely kicks you back to the game's title screen. So to actually completely quit the game, you have to do two actions: "Quit Game" in the main menu, and then "Exit Game" from the title screen. (I always thought that "quit" and "exit" were synonyms in computer UI design... I guess Chris doesn't share that point of view.)

OpenLoco should implement an additional main menu item to quit the game entirely, as was done in OpenRCT2.

Release Linux artefacts on tag

Currently AppVeyor builds and pushes it's artefacts to a GitHub release on tag. The same should happen for Linux.

Raise window/viewport limit

Particularly when running at higher resolutions, it's extremely common and annoying to have existing windows close when new windows are temporarily opened.

The original limits are: 12 windows, 10 viewports.

Fortunately it's very easy to increase these limits, even in a hacky manner, because of how the new_window_pointer/new_viewport_pointer stuff works. (It's actually kind of clever and nice, in its own way.) Only pointer references have to be messed with; there are no magic constants scattered around everywhere to be hunted down and adjusted.

---

I managed to make a working raise-window-and-viewport-limit mod in a statically-hack-the-EXE-file manner, by doing the following:

1. Finding window_list, new_window_pointer, viewport_list, and new_viewport_pointer in Loco.exe based on the corresponding reverse engineering already done on RCT2.exe:

window_list          @ 0x011370AC
new_window_pointer   @ 0x0113D754
viewport_list        @ 0x0113D758
new_viewport_pointer @ 0x0113D820

2. Statically hacking Loco.exe to add an additional data section at the end of the EXE with a bunch of free space (I created .data2 going from 0x01320000 to 0x01400000) and fixing up the EXE's headers and physical size accordingly.
3. Creating new locations for the four labels mentioned earlier in the new data section, laid out so that there's enough room for 100x loco_window structs between window_list and new_window_pointer, and 100x loco_viewport structs between viewport_list and new_viewport_pointer:

ext_window_list          @ 0x01320000
ext_new_window_pointer   @ 0x01355778
ext_viewport_list        @ 0x0135577C
ext_new_viewport_pointer @ 0x01355F4C

4. Using a hex editor to update all of the instruction arguments referring to the 4 relevant locations so that they now point to the new locations instead.

• AC 70 13 01 --> 00 00 32 01 (44 replacements)
• 54 D7 13 01 --> 78 57 35 01 (57 replacements)
• 58 D7 13 01 --> 7C 57 35 01 (4 replacements)
• 20 D8 13 01 --> 4C 5F 35 01 (15 replacements)

And it works.

---

I'll probably make a branch and PR soon, implementing these limit overrides in this project, in a "doesn't involve statically hacking the EXE file with a hex editor" manner.

Maybe I'll even (gasp) use malloc/operator new for the memory, like a sane person, instead of permanently reserving it as a big chunk of the data section. (I mean, I have a certain respect/awe/incredulity for Sawyer's insistence on doing everything directly in assembly language, but some of this stuff is just done in such a stone-age manner...)

Building when the game is paused option

I just know that some people including me would want that feature.

This feature can be off by default though.

Feature request: Add option to disable vehicle breakdowns

To allow for more leisurely play-styles and use of massive fleets of vehicles or trams, there exists a "No Breakdowns" mod for vanilla which disables breakdowns entirely.

It would be nice to have this in OpenLoco, and should be easier to implement than a proper solution like bulk-upgrading tools for your fleet.

Feature request: make it possible to actually see and control which way the company HQ faces when building it

This is a minor aesthetic thing but it's bothered me.

For whatever reason, despite the company headquarters building being a thing you can construct at will, and having 2x2 size, and being a directional building (i.e. it has an obvious front, and doesn't have 4-way symmetry), the "ghost piece" shown when you go to build it lacks a yellow direction arrow indicating which way it will face. Plus the company HQ ghost piece is, as far as I can tell, 4-way symmetrical and gives no visual indication itself of which way the building will ultimately face.

Using the Z key (the default keyboard shortcut for "rotate construction object") doesn't affect the rotation of the company HQ when constructed. And there's no rotation button on the construction UI.

(The helipad airport makes a good contrast for the company HQ. It basically demonstrates everything the latter should have: a yellow direction arrow on the ghost piece; a ghost piece that actually resembles the thing that will be built in a way where you could maybe tell which direction it's facing just by looking at it; a construction UI with a rotation button; and responsiveness to the Z key.)

From what I've seen doing some testing, the HQ is always built such that it faces the lower-right corner of the screen at the time you place it. That seems to be the only determining factor. And that's rather odd.

Feature request: non-braindead road/rail pathfinding (i.e. things actually go where you ask them to without needing tons of waypoints)

This'll be a big one, in terms of removing major grievances people have with the game.

It'll be interesting to see whether this is simply a matter of the pathfinding algorithm having a disappointingly low cap on how many track pieces it's allowed to look ahead; or if there are other factors at play.

I've been told that there's some WIP A* pathfinding code over in OpenRCT2 that might be useful for this, once we get down to business on it.

Feature request: window snapping

Same as OpenRCT2.

Obviously this will need to wait until window code is done, but I'm opening this now, since it's something that shouldn't be terribly hard to implement once we get there, and it's a feature that I would especially like to have.

trees in operation are dying

When there is a lot of track and a lot of train the trees will all die. And extreme is not nice, then a man has to plant trees. If it could be turned off to keep the trees out.

'Load save' dialog lists files it shouldn't

Ubuntu 17.10, AMD64
Commit 0fa0aa5

It lists 1.DAT (which is not a save) and Britain 1.SV5.BAK (which is a back-up save).

Locomotion:

OpenLoco:

The original problem of overweight games will accept goods and passengers

On one side of the world, they get to the train station, even though it has nothing to do with

Houses under bridges should not coexist

It's very perplexing (for me) to see buildings below the bridges, especially, if this leads to removing of one or more bridge pillars. Maybe there could be a height restriction, depending from the "real" distance between ground and bridge deck. Therefore also the houses would need a height declaration.

edit: spelling error

Support gender for nouns and plurals in translations

Unlike OpenRCT2, transport game like OpenTTD or OpenLoco has cargos, which is a noun, and their grammatical uses may differ to languages, such as German, Dutch, etc.
I think it should be support a gender for nouns to make a sentense more frequently in their languages.
And plurals, too.

See http://wiki.openttd.org/Format_of_langfiles#Plural_form and http://wiki.openttd.org/Format_of_langfiles#Genders how OpenTTD implements.

(My language, korean, actually doesn't have any noun genders system, but I uses them to implement Josa system in korean, which may differ to last sound of a word.)

Changing cargo between vehicles bugged

If you unload cargo to a station and have another vehicle pick it up to finish the delivery, the days needed for the whole trip will add up every time. Say you want to have a ship deliver oil to the shore and then have a train take it over to deliver it to the refinery. Because of this bug, the game will always think that it took 255 days and you would get minimum profit. This bug is from the original game.
An example: The right train is forced to unload coal to the central station, the left than takes it to the Steel Mill. There is no way this took 255 days.

`register_hook_stub` only remembers the last address passed

Original game bug: hitting "Stop" on a ship while it's "unloading" --> unloads cargo, claims to have earned income, but no money is earned

I kinda thought I noticed this the other day, but I confirmed it for sure today.

With trains and other vehicles, if you tell them to Stop right after they have arrived at a station and just begun the process of Unloading+Loading, they will finish the Unloading and Loading steps first before they actually enter the Stopped state; and when the Unloading process finishes you will earn money from the delivered cargo as per normal.

With ships, however, if you hit the red flag while they are in the process of Unloading, they will instantly switch to the Stopped state (not waiting for the Unloading and Loading steps to complete as is the case with e.g. trains). The cargo onboard will go away as if it was delivered, yet no money will be earned for the delivery.

The Finances panel of the vehicle window for the ship will show that the last income was on the expected date (when it arrived at the dock); and that the full amount of cargo it had onboard was delivered; and that it allegedly earned you the correct amount of income for the amount of cargo delivered over the given distance in the given amount of time.

But there's no "cha-ching" money sound effect; no floating +$ text; no actual increase in your cash balance; and no increase in the Ship Income cell of the Finances window for the current year.

So this is a true bug where the game fails to pay the player for cargo delivered, despite claiming to have done so. (Probably due to some mistake in the vehicle state transition logic for ships, because ships weren't tested to a sufficient extent.)

🚢 💸 💸 💸 💸

Cloning vehichles?

Crashes when changing resolution

Clicking in the dropdown causes the game to crash (seems to fail getting the correct dimensions as it shows the max int value)

Haven't built it from source yet, so don't have any meaningful information besides the access violation:

Exception

Unhandled exception at 0x004C003A in openloco.exe: 0xC0000005: Access violation reading location 0x0114B004.

Version	OS
18.02	W10 Pro 16299

Unit Testing

I think it's a good idea to add unit tests early on, to get and maintain high code coverage. For OpenRCT2 we use Google C++ Testing Framework. Do we want to use the same framwork for OpenLoco? I remember @IntelOrca saying he wanted to switch to somehting else.

Of course writing tests will take a lot of the time, and may not always be possible, but it would help catch errors made while disassembling a function if it was referenced in another already-decompiled function that is being tested.

Auto save

We should implement auto saving asap so that players don't lose their data due to crashes when play testing OpenLoco.