Version 1.13 is now ready for testing in the beta branch. This new version is a continuation of features introduced in 1.12, which were spun off to its own version, since 1.12 was complex enough.
Pax path walk legs
Pax are now able to plan paths including the act of walking between two stations, instead of taking a train. This includes cases where there is no possible train between stations, and when the train exists but it will faster to just walk (at least at the time of arrival). These walk legs are modeled as walking in a direct line (unrealistically fast) at 1 m/s (unrealistically slow), so it evens out.
The feature is meant to model the generic act of walking between stations. In particular it's not meant to model explicitly signaled OSIs, or fare zones for example. These real world cases are still a particular case of just walking between stations, so this feature aims at the more general case. This feature is also not able to consider things like rivers, mountains, country borders, particular streets or paths, islands, bays, etc. All these cases would require a combination of street routing and terrain routing and are an immense amount of work, and out of scope for the game.
If one or more of these cases bother you, or you just don't want to have walking legs for some stations, it is possible to disable them by changing the max walking radius of the station to 0. For a walking leg to be allowed between stations, both of their center points (the small circle displayed when you disable all station names and icons) must be within each other walking radius. A walking radius of 0 cannot contain any point so no walk legs will be possible.
Station capacity and station halls
A recurrent player complain about the station system, always supporting an active thread in the forums, is the 10k transfer pax limits in stations. In 1.13 this limit has been lifted to 100k, and train boarding speed has been increased by 10x to compensate. Additionally there's no more limits to newly spawned pax, or limits related to the number of platforms. This is now possible since the original limits were put in place when the pax pathfinder was much slower. In the years since that decision was made its performance has improved immensely, and the game became deeply multithreaded, so now it's a good time to test this increase. I say "test" because during the beta period it will be evaluated what is the performance impact if this change and it will be toned down if it's too bad for some players.
Additionally, in order to support walking legs, station halls have been introduced. Stations can now store pax in 2 places: the platforms and the hall. Pax in platforms behave like always: they are eligible to board trains. Pax in the hall are not allowed to board trains. Instead they have a countdown timer, and when it reaches 0, they are moved to the platforms. If the platforms are full, they remain in the hall, waiting for a spot. Hall capacity is unlimited.
Assets map overlay
Station and train asset listings can now be displayed on the map as a "blob" overlay:
These blobs are circles whose area is proportional to the listing max value. You can change the colors, including the transparency. Adjusting the degree of transparency also enables a heatmap-like view. The map updates in realtime just like the asset listing, and it can also clamp the range to the visible objects by using the existing "on map" button in the assets panel.
Devblog for May 2024
The beta development for 1.12 wrapped up in May, and it is now the default version. Some of the initial design decisions of 1.12 had to be changed in the light of existing player saves, but it in the end it held well overall, and it's a very major improvement in the simulation quality of the game.
Private 1.13 development has already started. Two major new features have already been implemented: walk legs and station halls. These correspond or solve some very often suggested features by players. To read more on how they look like read the devblog for this month:
https://carloscarrasco.com/nimby-rails-may-2024/
Version 1.12
Version 1.12 has been released as the default game version! This version completely changes the way pax are spawned and the way they pick their destinations, and gives players and modders new tools for influencing these choices.
Population density, geographical point based pax origin and destinations
In 1.12 pax are spawned on specific geographical points, rather than by picking a station. And their destinations are also points in the map. Only after these points have been established are stations also picked, based on which stations can be reached from these points. Geographical points are picked based on population density. For now there is no visualization of these points so pax still just appear inside their origin stations, but the consequences of this previous step are very directly noticeable, specially when enabling the new "best path" mode.
Additionally, the way demand is generated has also changed. In 1.11 and earlier the achievable pax spawn rate of a given station was fixed, based on the station coverage. In 1.12 the pax rate depends both the population density around a station, and the reachable population from the station, subject to the distance demand curve. This means that opening more destinations in your network will not cut down on the desirability of the existing destinations as much as it did in 1.11.
All existing saves will see changes in their pax demand and generation flows, some of them very severe. A combination of changing the global demand % and the demand curves will help restore similar levels of demands compared to 1.11. For example, if more local demand is desired, you can change the destination curve to have much smaller % demand for 50km or more distances (less than 1%), then hike up the global demand %.
Overlapping station areas
Since pax now spawn on map coordinates, and they have a (player configurable, limited) capability of picking their origin and destination stations, it does not make sense to divide station coverage like in 1.11. In 1.12 station coverages can overlap:
Additionally, maximum station area radius has been increased from 1.5km in 1.11 to 2.3km in 1.12.
Points of interest
Players can now create special sign-like buildings which add some amount of population to a point in the map:
These signs count as population points, just like the built-in population texture. They can be used to for example liven up areas which see high demand in real life but have low population, like airports.
Mod POI layers
In addition to player created POIs, mod authors can also provide map mod POI layers. Players can subscribe to these mods to immediately layers of POIs to their game map. These layers can be hidden, or have their proposed demand curve altered by players if desired.
Multiple, player customizable demand curves
To make the new POI feature even more powerful, it is possible pick a different demand curve for each player created POI, or globally for each mod POI layer. This allows to define POIs which have a different time based demand curve, for example a stadium only being active for a few hours a week, but having an outsized effect on its nearby stations by combining it with a large population value. Or making the distance demand curve of an airport much less dependent on the distance, compared to the default curve.
Version 1.12 is now ready for testing in the Steam beta branch. This version completely changes the way pax are spawned and the way they pick their destinations.
Population density, geographical point based pax origin and destinations
In 1.12 pax are spawned on specific geographical points, rather than by picking a station. And their destinations are also points in the map. Only after these points have been established are stations also picked, based on which stations can be reached from these points. Geographical points are picked based on population density. For now there is no visualization of these points so pax still just appear inside their origin stations, but the consequences of this previous step are very directly noticeable, specially when enabling the new "best path" mode.
Additionally, the way demand is generated has also changed. In 1.11 and earlier the achievable pax spawn rate of a given station was fixed, based on the station coverage. In 1.12 the pax rate depends both the population density around a station, and the reachable population from the station, subject to the distance demand curve. This means that opening more destinations in your network does not cut down on the desirability of other destinations, it will just make existing stations generate more pax (always in proportion to the demand curves).
Overlapping station areas
Since pax now spawn on map coordinates, and they have a (player configurable, limited) capability of picking their origin and destination stations, it does not make sense to divide station coverage like in 1.11. In 1.12 station coverages can overlap:
Points of interest
Players can now create special sign-like buildings which add some amount of population to a point in the map:
These signs count as population points, just like the built-in population texture. They can be used to for example liven up areas which see high demand in real life but have low population, like airports.
Multiple, player customizable demand curves
To make the new POI feature even more powerful, it is possible pick a different demand curve for each POI. This allows to define POIs which have a different time based demand curve, for example a stadium only being active for a few hours a week, but having an outsized effect on its nearby stations by combining it with a large population value. Or making the distance demand curve of an airport much less dependent on the distance, compared to the default curve.
Work continued with the new pax demand generation system in 1.12, with the introduction of multiple custom demand curves and player defined POIs. In 1.12 it will be possible for players to define custom time based and distance based pax demand curves, to control pax spawn and pax picking of destinations. These curves can alter the built-in population layer, and they can also alter a new kind of game object: points of interest. These POIs will be a special kind of building players can place anywhere on the map, and then assign a population value and a demand curve to them. They then become part of the pax generation for all the stations covering them, and also an attractor for pax demand from other stations. Check the blog post for more details and other new features:
February saw the final releases of the 1.11 beta series, and the start of internal experimentation and development for 1.12. I originally intended for 1.11 to also feature pax generation changes, but the scope of the changes became too big to just be a "plus one more thing" feature during a beta period, so it has now been reassigned as the major feature of 1.12.
Work on the new pax generation system has begun, with many experiments done in February, to put some ideas to the test and see which ones are practical and which ones are not. The guiding principle is to try to model natural demand for pax trips, and then adapt the designs to the reality of a real time game. Solutions have been found for some the challenges of adapting this idea to the game, but a lot of work still remains to be done.
Version 1.11 is now the default Steam version! This version contains only few user-visible changes, with the bulk of the work focused on optimizing the game sim to extract as much performance as possible from 4+ core CPUs. There's also pax pathfind improvements and new features, like board and disembark -only line stops.
Major multithreading optimzations
In 1.11 the game simulation and the game UI can now run fully independent from each other. This boosts the game simulation speed by potentially a large margin, depending on how large your save is (and for users with less powerful GPUs, on how complex your on-screen buildup is). Since the game simulation was already massively parallel, this increases the CPU usage of the game. Faster sim = more CPU usage. If you prefer the game making less use of your CPU, in 1.11 it is also possible to limit this capability down to just 2 sim threads, with the corresponding sim performance hit.
New pax pathfind capabilities
Board only and disembark only line stops are now possible. Although not super realistic, it is useful to keep local pax from boarding long distance lines making multiple stops in a large city, for example. Or to make sure large capacity lines only empty their trains in some selected, less busy stations. Factorio or a human transit simulation? You decide!
Pax pathfinding can now consider a pax staying inside a train for more than 2 train runs. This limit has been in the game since 1.5 and it is now finally removed. The pax pathfinder can now plan a path leg which keeps the pax inside the train until the train starts a technical line or an already visited station appears (not just the boarding station), whichever comes first, over any amount of train runs, including an entire week worth of them.
"Figure 8" or "pretzel" shape lines are now better supported. These lines, in conjunction with single line stations, have had limited support in the pax pathfinder. In 1.11 the game is able to detect more cases of a transfer station, including cases of a line crossing over itself on the same station, or a common looking line having a single direction loop in one end (in this case, the station(s) just before the loop are marked as transfer). This means there are now some cases where pax can disembark in a station and pick a train of the same line, to avoid the loop part of a "figure 8" line for example.
Finally, it is now possible to restrict pax from boarding a train if they plan to ride it for a too short time. For example, if you have a long distance line making a couple of stops in a big city, and want to forbid local pax from using it like a subway between the two stations, you can set a minimum stay time in these stops. Pax will stop considering them as valid legs in their trips if the ride time is under your setting.
Multiplayer fixes
I've written this a bunch of times over the years already, but the new version contains major multiplayer fixes and optimizations. This time I'm confident enough that I've enabled up to 100x shared sim speed and made it the default setting, and feedback from the beta period has been positive. Give it a try if you are a multiplayer fan.
Better time zones
A new option in the company panel now allows to change into a new time zone mode: Approximate. This mode uses a real world time zone map, instead of the previous simplified rule of having one time zone every 15 degrees of longitude. It's still called "approximate" because in order to keep performance from diving, it is a rasterized map with a resolution of around 5km, so locations within a 5km border of a time zone might display the wrong one. Still it's a huge improvement over the previous system.
Custom accounting start of day time
It is now possible to change what time of day the game accounting considers as the start of day, relative to UTC 0. So for example, if your save is mostly built up in the USA east coast, you might want to consider changing accounting start time to -5h, so it tracks the USA Eastern time zone.
--- For a more detailed and technical look into what's in 1.11, check the devblogs:
Version 1.11 is now available in the Steam beta branch! This version contains only few user-visible changes, with the bulk of the work focused on optimizing the game sim to extract as much performance as possible from 4+ core CPUs. There's also pax pathfind improvements and new features, like board and disembark -only line stops.
Major multithreading optimzations
In 1.11 the game simulation and the game UI can now run fully independent from each other. This boosts the game simulation speed by potentially a large margin, depending on how large your save is (and for users with less powerful GPUs, on how complex your on-screen buildup is). Since the game simulation was already massively parallel, this increases the CPU usage of the game. Faster sim = more CPU usage. If you prefer the game making less use of your CPU, in 1.11 it is also possible to limit this capability down to just 2 sim threads, with the corresponding sim performance hit.
New pax pathfind capabilities
Board only and disembark only line stops are now possible. Although not super realistic, it is useful to keep local pax from boarding long distance lines making multiple stops in a large city, for example. Or to make sure large capacity lines only empty their trains in some selected, less busy stations. Factorio or a human transit simulation? You decide!
Pax pathfinding can now consider a pax staying inside a train for more than 2 train runs. This limit has been in the game since 1.5 and it is now finally removed. The pax pathfinder can now plan a path leg which keeps the pax inside the train until the train starts a technical line or an already visited station appears (not just the boarding station), whichever comes first, over any amount of train runs, including an entire week worth of them.
"Figure 8" or "pretzel" shape lines are now better supported. These lines, in conjunction with single line stations, have had limited support in the pax pathfinder. In 1.11 the game is able to detect more cases of a transfer station, including cases of a line crossing over itself on the same station, or a common looking line having a single direction loop in one end (in this case, the station(s) just before the loop are marked as transfer). This means there are now some cases where pax can disembark in a station and pick a train of the same line, to avoid the loop part of a "figure 8" line for example.
Multiplayer fixes
I've written this a bunch of times over the years already, but the new version contains major multiplayer fixes and optimzations. This time I'm confident enough that I've enabled up to 100x shared sim speed and made it the default setting (famous last words?). If you are a multiplayer fan give the beta a test.
--- For a more detailed and technical look into what's in 1.11, check the devblogs:
Work continued in December to implement major optimizations, but some diminishing returns were starting to hit, so I started a partial multiplayer rewrite to try to fix the many issues it currently has. I discarded large swats of code, old attempts at fixing shared mode and editor synchronization. It's now looking much better, at least on my end, so we will see how it goes when the beta goes public. I then took some holidays to think about where to go next with 1.11. The main idea I had for the release was not working out, so I implemented some small features and will consider making a release sooner than later.
Time flies when you are deep into optimization programming, and that's how November went by. The remaining roadmap items are very CPU intensive, so the game needs to extract more performance from the CPU cores. A very deep rearchitecture is ongoing, with a variety of strategies like database-like transactions and triple buffering game state. As a result the UI and the game sim are now fully asynchronous, removing a large pause from the game sim, letting it run for a longer in time on the CPU cores.
November was definitely a technical maneuvers kind of line, maybe December will return to more regular service.
