Version 1.17 is now ready for testing the beta branch!
[p][/p][p]Gameplay wise this is a very small version. It is intended as a public test of the future scripting system, NimbyScript, with the top level logic of path signals and balises now being implemented in NimbyScript rather than the native C++ code. If this test is successful, by not introducing instability or performance issues, then future versions of the game will make it possible for players to use NimbyScript for custom signal logic and other functionality. For for now, in 1.17, NimbyScript is read only and the new Control editor is very bare bones.[/p][p]To make this version a little more exciting it includes a couple extra features, and a few more will be implemented during the beta period.[/p][p][/p]
Recolorable UI
[p]It is now possible to change the colors of the UI:[/p][p][img src="https://clan.akamai.steamstatic.com/images/37091993/1bc00991c475f147fb5dc867ab0f8f300bb1a2d1.png"][/p][p]To access the new settings for this feature, go to Options and select Interface.[/p][p][/p]
Alert listing
[p]Alerts can now be viewed in a listing:[/p][p][img src="https://clan.akamai.steamstatic.com/images/37091993/740ed7ece4994ccc20e6fc807d60e1e8d87b7520.png"][/p][p]All queued alerts are immediately available in the listing, and older alerts are also kept there, past the new alerts and any “missed” alert (shown but not interacted with). There’s a limit of 200 alerts, and they are automatically cleared as new ones are pushed at the front, or you can just clear them manually.[/p][p][/p]
Devblog for June 2025
[p]Development in June was focused again on NimbyScript. The language has progressed to the point of being usable, but it's still lacking some basic features. One of these features, memory ownership (think lists, allocating memory, etc) is a very complex subject and it is for now being postponed. 1.17 will feature NimbyScript, but it will be as a non-editable preview, since it's still too immature and any code written in its current state would be invalidated in the future. [/p][p]But not everything will be a technical test. Two often requested features will also be implemented: recolorable UI and an alert log. Read more in the full devblog:[/p][p] https://carloscarrasco.com/nimby-rails-june-2025/[/p]
Devblog for May 2025
The past two months have been almost solely focused on developing NimbyScript, the future scripting language for NIMBY Rails. It has been quite hard to get started, with some very lofty goals to achieve, and a lot of reading and experimentation was needed. Read on for the programming nerd adventures in NimbyScript.
WARNING: this is an extremely technical post of little to no interest to most players. NimbyScript is nowehere near finished. Once NimbyScript is ready for being introduced in the game it will get a proper guide. This post is NOT the guide for NimbyScript.
https://carloscarrasco.com/nimby-rails-may-2025/
Version 1.16.16
- Fix: hang in train simulator when combining stop selection signals, platforms in series with the first platform being occupied, switches in the middle of platforms and trains too long for the stop area and being forced to stop over the switch - Fix: crash while visualizing pax path routes on the map and at the same time deleting tracks or stations involved in said routes - Fix: attempting work around for crash in the train info window accounting tab, which cannot be reproduced reliably - Fix: station editor stop signal pick mode should not display signal buttons if signals are not visible - Fix: some trains stopped at signals had incorrect signal stop time stats
Version 1.16
Version 1.16 has been released! This version is a direct continuation of 1.14, with new, optional features in the schedule system for advanced players. And for everybody, this release also marks the first time NIMBY Rails has a proper collision system, so you must now pay attention to train physical size and footprint when designing your track layouts.
Unassigned trains
The schedule system now has the capability of setting trains to become unassigned at the end of an order. This means the train stays in the tracks, stopped, but has no orders and no schedule.
Unassigned trains a have new capability: they can become assigned to any shift, as long as a set of rules apply:
The shift must be currently unassigned
The train must be enabled to run the shift
The current sim time-of-week must match the stopping time (be between arrival and departure times) of a stop in a run in the shift
The current location of the train must also match the platform set of said stop (be on the main or the secondary platform of the stop)
This means that for the first time it is not required for the player to come up with shifts that fill an entire week worth of time. If you plan the unassigned stays properly, you can now make shifts as short as desired, including for single line runs, and let the assignment rules pick the trains as needed.
This feature is strictly opt-in. No changes are made to existing saves, and you must manually set orders to end in unassigned mode. If you don't want to deal with this new feature you don't have to. That being said, since trains can now be authorized to multiple shifts, the interfaces for assigning trains to shift are a little different, but still allow to set 1 train per 1 shift, so you can keep scheduling like you always did.
To learn more about this feature and the exact set of rules which govern it, see this devblog:
Due to this fundamental change in the scheduling system all trains in existing saves have received an intervention. On loading the game it might take awhile for them to get reassigned to their shifts and to respawn, also you might see some alert spam.
Global, always enabled full 2D train collision
Up until 1.15 the train collision system was based on special cases which only enabled in and around track branches. It was very limited and missed many kinds of collisions, including every collision based on train sizes over parallel tracks, for example. This is not the case anymore in 1.16:
This means you now have to pay attention to these parameters, rather than assuming trains are like ghosts to each other. In general, as long as you kept your parallel tracks with a decent offset and properly signaled your branches, you won't have much trouble. But if you do, path signals are now more capable of checking nearby tracks for potential conflicts, if you need to help them a little with the new "overlap distance" track parameter. This usually needs to be set to the expected maximum train car width for a given track. You will now see the "shaded" area which appears when tracks intersect now also appears when tracks are very close to each other, and that distance corresponds to the "overlap distance". Path signals now check the nearby shaded areas for given train path before signaling the train to pass.
Station-level stop selection signals
Line stop-level secondary stop signals have been replaced with station-level stop selection signals. This means that when you want to designate a signal for the role of being able to select secondary train stops, you must now do so in the station editor. When a train reaches a stop selection signal, and its current path ends on a track platform of a station which includes the signal in its set of stop selection signals, it will be allowed to change its destination stop area. This is the same functionality formerly provided by line stop secondary signals.
Stop selection signals do not define or restrict the set of eligible stop areas in any way; the eligible set of stops areas is always the current line stop set consisting of the main area and secondary areas. This new feature allows to have multiple stop selection signals and to only need to set them up once per station, so you don't need to create multiple line versions just to change the secondary signal anymore.
Deprecating waypoints with secondary "stops"
This redesign has also highlighted some unintended behaviors of secondary stops. In particular secondary stops are not supposed to work for waypoints. This is an oversight in the previous design and it should have never been allowed to exist.
In 1.16 these stops still work and now display a big warning in the line stop editor panel, but in a future version their secondary stops will be ignored. Reproducing their behavior will require using new tools and it won't be an automatic import process.
Queue behavior for advanced stops
A set of new features allows for trains to queue up behind one another while performing a stop, both in regular line operation and when unassigned, without having to set up multiple individual stop points and track segments. The combination of the following features enable this new behavior, although they are also usable for other purposes by themselves.
Advanced stops footprints can now be longer than the reference train. To create an oversized advanced stop, after the first click to set the head point, keep moving the mouse past the end of the line reference footprint. The new stop creation panel now also displays the stop length.
Trains arriving into stops passing by a stop selection signal can now decide to stop behind trains already stopped. This is only possible if the space behind the existing trains is long enough to fully contain the arriving train, plus a margin of roughly 3m. The available space corresponds exactly to the stop footprint, never to the track platform segments, therefore it is only active when the stop is created in advanced mode and when it is oversized.
Path signals can now be restricted to not check past scheduled stops. This is required to enable multiple trains to use the same stop while in regular operation, otherwise the path check would refuse to let the train enter the stop with other trains in its future path. If you use this option make sure your platform exits are properly signaled.
Trains being dispatched are now aware of other trains surrounding them in the stop footprint of the dispatch being considered, and will only accept the dispatch if the footprint between the train and the stop head point is free of other trains. This enables dispatching to only pick trains at the front of a queue, as long as the picker order stop is pointing in the correct direction. In particular, if you are using this feature with dead end depot tracks, the arrival stop must point towards the track dead end, and the departure stop must point towards the linked end.
All stop vs train and stop vs stop matching is now done based on the precise footprint of line stops or trains over the tracks. The old rules based on the train/stop heads, track segments and directions are not used anymore.
Run and line duration can now go down to 10s
Minimum run duration and line duration is now 10s. In exchange shifts cannot have more than 2520 runs (equivalent to filling the week with 4m runs). If this limit is reached the last run of a shift will be marked as not continuing and the rest of the orders will be ignored. Existing schedules using lines with a native duration of under 5m which were depending on the automatic padding and distribution of 5m duration might need adjusting. For example, a common error is to have your depot orders set to max number of repeats. Make sure you disable repeating runs for single stop depot orders.
Runs generated for autorun lines are sill limited to a minimum of 5 minutes, and this time is now padded, not distributed. If a line with a duration of under 5m is wanted to run in auto run mode with distributed time, please use the line timing options to do so.
Version 1.16 is now in the beta branch
Version 1.16 is now ready for testing in the beta branch! This version is a direct continuation of 1.14, with new, optional features in the schedule system for advanced players. And for everybody, this release also marks the first time NIMBY Rails has a proper collision system, so you must now pay attention to train physical size and footprint when designing your track layouts.
Unassigned trains
The schedule system now has the capability of setting trains to become unassigned at the end of an order. This means the train stays in the tracks, stopped, but has no orders and no schedule.
What is the use of this seemingly useless feature? Unassigned trains a have huge, new capability: they can become assigned to any shift, as long as a set of (strict) rules apply. Basically, if an unassigned train is located on the right platform at the right time, it can become assigned to any shift schedule to service said platform at said time, as long as no other train is assigned to the shift, and the train is authorized to run it. This also means that for the first time it is not required for the player to come up with shifts that fill an entire week worth of time. If you plan the unassigned stays properly, you can now make shifts as short as desired, including for single line runs, and let the assignment rules pick the trains as needed.
This feature is strictly opt-in. No changes are made to existing saves, and you must manually set orders to end in unassigned mode. If you don't want to deal with this new feature you don't have to. That being said, since trains can now be authorized to multiple shifts, the interfaces for assigning trains to shift are a little different, but still allow to set 1 train per 1 shift, so you can keep scheduling like you always did.
To learn more about this feature and the exact set of rules which govern it, see this devblog:
Up until 1.15 the train collision system was based on special cases which only enabled in and around track branches. It was very limited and missed many kinds of collisions, including every collision based on train sizes over parallel tracks, for example. This is not the case anymore in 1.16:
This means you now have to pay attention to these parameters, rather than assuming trains are like ghosts to each other. In general, as long as you kept your parallel tracks with a decent offset and properly signaled your branches, you won't have much trouble. But if you do, path signals are now more capable of checking nearby tracks for potential conflicts, if you need to help them a little with the new "overlap distance" track parameter. This usually needs to be set to the expected maximum train car width for a given track. You will now see the "shaded" area which appears when tracks intersect now also appears when tracks are very close to each other, and that distance corresponds to the "overlap distance". Path signals now check the nearby shaded areas for given train path before signaling the train to pass.
Devblog for February 2025
Work in 1.16 has continued in the month of February. Stacked train stops (sequences of stops for the same platform(s)) were not fully compatible with the new train logic in 1.16 and have been reviewed with a new, clearer set of rules which avoids some pitfalls. Train collision has been finally overhauled with a new system that performs real geometric intersection tests. And a new, very major technical capability for the game is introduced at the end of the post, but its release will have to wait for a future version. Read about it in the dev blog post:
The first devblog of the year is up, and it reveals the focus of v1.16: dynamic schedules. Or, in 1.16 terms, dynamic train dispatching. Trains can now be enabled in multiple shifts, and shifts can contain timetable "holes" which allow the trains to hop into a different shift, following a set of rules. These new systems are all optional and build up from the existing schedule system, so you can use them as little or as much as you want, including not using them at all. This is still a work in progress, but the basics of the system are already implemented. To take a look and for a more detailed explanation see the full blog post:
- New keybind (unassigned by default) to promote the current track selection to a new station. Combine with Shift to instead assign the tracks as platforms of the nearest station. Combine with Alt to instead demote platforms into normal track. - Fix: pasting stations in the clipboard with Ctrl-Shift-V sometimes did not properly register as a new station and the station nameplate did not show up (cosmetic issue) - Fix: straight guide disappears on zoom in when track node is offscreen - Fix: changing building type of selected building must reset its decal
Version 1.15
Stations v3: persistent stations with explicit user editing
The original design idea of stations dates back to five years, since the first pre-EA prototypes. Although stations have evolved in important ways, their basic building mechanics have remained the same. There's some aspects to these mechanics which are undesirable and were making game design evolution impossible, so 1.15 introduces a new concept of stations based on explicit user control, rather than the implicit effects of overlapping tracks.
In short: in 1.15 stations are a collection of track segments explicitly selected by the player. In 1.14 the concept of "if the platform footprint touches, it is in the same station" was a core game rule, implemented and enforced in the most lower levels of the game logic. In 1.15 this rule is now an specific feature of the station creation tool in the track editor. Platform tracks can now freely overlap each other without being part of the same station. It is also not necessary for them to touch to be considered part of the same station. In essence the platform-station relationship is now under full control of the player.
Stations can now exist independent of platforms. In fact, stations with 0 platforms are allowed to exist. And deleting tracks will never delete stations. Deleting a station will now require a explicit player action, respecting the player work.
Tracks can be manually assigned to stations to convert them into a platform. This is streamlined with a dropdown to directly pick nearby stations, so there’s no need to go hunting for icons or nodes on the the map. In a similar fashion, you can also remove the association to a station (the old demote) or create a new station from a track (the old promote). There are bulk editing versions of these tools, so you don't need to manually assign tracks one by one.
Platform extension buildings have been removed. There’s no need anymore for any track to touch any other track, you can just directly edit which tracks belong to a station, and this link will persist until is deleted.
Walk link buildings have been removed. The new station editor allows to create walk links by selecting nearby stations in a list.
In 1.15 the only time you’ll see platform footprints is when you use the station platform tool. These footprints now have zero gameplay relevance, and only exist as a guide to select a station for appending a platform to it. Click inside a footprint and it extends the station with a new platform, click outside and it creates a new station. The end result is that using this tool is very similar to the previous design, but the only time the footprints are relevant is during that first step in this specific tool, and nowhere else.
Station editor
As mentioned earlier, in 1.15 stations have become persisting objects. This will enable new design and gameplay features, but for now the most visible one is a new top level editor in the left toolbar. The station editing options formerly located in the track editor are now located in the station editor. This means the track editor is focused on buildable physical elements, like tracks and declaring these tracks as platforms of some station. And the station editor focuses on more abstract concepts, like population radius, tags and walk links. A few of the most basic station editing options, like naming, will also remain accessible in the track editor.
Big rewrite of the track editor internals
In order to support the new multiplayer system in 1.15, most of the track editor internals needed to be scrapped and rewritten. In particular all the code relating to track modification and creation relied on the fact player changes were immediately applied to the game database. This is not the case anymore in 1.15. Now player changes are only applied to the database when they are confirmed by the player by finalizing the editing action, like by releasing the mouse when moving some tracks, or clicking a second time when creating tracks. All the intermediate states before these actions are now implemented by the track editor, using a new predictive editing system which keeps the main game database untouched. This improves reliability and performance, both in single and multi player. Despite these deep changes track editor tools look and behave almost the same.
Signal and track editor improvements
It is now possible to create signals and branches in platforms. But keep in mind basic line stops ignore if a platform has branches or signals. The game won't pick up a stop area based on the fact of a signal or branch existing at some point in the platform. Please use advanced stops or stop point signals for better control of the train stop position when you create signals or branches in platforms.
The new signal mode now automatically picks a signal facing and side based on an heuristic of the mouse position with respect to the track position. This can be reversed for left hand drive with a new button in the left toolbar. Holding shift to reverse the direction remains possible.
The "forced straight" snapping invoked by the Control key while creating tracks has been replaced with a snapping mode based on proximity to the projection of the tangent of the previous track. It also draws a line for better clarity. This is enabled by default in all saves, but it can be reverted to the old setting with a new button in the left toolbar.
Point mode track creation is now possible. Compared to the point mode creation tool tested in the v1.9 beta series, this new version has much improved UX and it closely mimics the behavior of other popular games with vector based track/road laying. If you prefer to create and erase tracks without editing, as is the norm in other games, you might prefer point mode creation.
Full rewrite of multiplayer internals
As explained in the November devblog, the way multiplayer works in the game engine has been completely rewritten to be more correct. Game consistency errors like invalid stations and glitched tracks should not happen, or if they do, do not happen at any rate different compared to single player. This has been achieved by making the game server the single source of truth and removing the eager execution of player editing actions by clients. Now clients only apply editing changes when told by the server, including for the local player. And this gives the main tradeoff of the new system: multiplayer now exposes latency to the player, and tries to mitigate it at the UI/rendering level (this is how virtually every other videogame works). If you multiplayer with moderate to high latency you will notice small pauses when doing certain actions, and the game editors telling you they are busy sometimes. As mentioned earlier the track editor has been partially rewritten to mitigate latency in multiplayer.
For a more detailed overview of the 1.15 changes, check out the October and November devblogs: