Nimby Rails
Version 1.18.27
- Fix: crash when loading saves with potentially invalid demand curves
- Fix: show again reservations on the map but only if the map reservation mode is enabled
Version 1.18.26
- Fix: shared simulation multiplayer did not properly sync train motion state
- Fix: wrong auto scroll listing position in some cases
- Fix: more instances of possible crashes while pausing the game, disabling train mods, and then editing trains which were using these mods
- Fix: rare crash while rebuilding timetables
Version 1.18
Signal texture mods
[p]Mods can now offer new textures (or collections of textures) for signals. In 1.18 the visuals of signals have been completely made independent of their function and logic. The core simulation keeps the existing textures and rules, but by using mods you can now put any texture you wish on any signal. Multiple signals states can also be textured as desired, both the default 2 states for path signals and any amount of custom states if the mod also provides a signal texture script.
[/p]
NimbyScript
[p]NimbyScript is a custom programing language for developing scripts for NIMBY Rails. It is quite limited compared to general purpose languages, but in exchange it has nearly the same speed as compiled C code, because is actually compiled as C code on loading the script. To ensure the future evolution of the language it has not been designed as special purpose. For example concepts like Train or Station are expressed as types, not as a first level entities of the language.
You can read the NimbyScript guide and its API reference in the official wiki:
https://wiki.nimbyrails.com/NimbyScript
The Steam modding guide explains how to make script mods:
[dynamiclink href="https://steamcommunity.com/sharedfiles/filedetails/?id=2268014666"]
For your personal saves, you can make private mods which reside in the "mods" folder of your saved games folder. A copy of the script is also stored in the save, so save sharing and multiplayer remain functional even when using private and unsubscribed Workshop scripts.
Scripts are displayed in the UI as "Extensions". These new extensions appear in some editors, like Signal properties panel or the train editor panel. Players first enable an extension in the list, then the extension can be further configured with its own UI in the same panel.
[/p]
NimbyScript APIs
[p]There's many new features in the train simulation for 1.18, but most of them are exclusive to NimbyScript. This will allow modders to precisely express certain features the way they see fit, within the confines of the API.
[/p]
Changing the result of a path signal check
[p]All path signals can now call into one or more scripts to change the result of a "pass" check into a "stop" check. Scripts can use any logic they want for this extra check, including checking other trains, the simulation time, looking up tags,
[/p]
Path change from any signal
[p]All path signals can now also be path change signals by using scripts. Scripts can return a new goal position for the train checking the signal. The train will automatically pathfind to the new goal position and if it reaches it, it will also automatically pathfind toward its line stop goal. The goal position of the train can be changed an unlimited amount of times by any amount of signals or scripts, and it will always pathfind itself back to the line stop when needed.
[/p]
Lookahead system
[p]Trains periodically scan their future path for up to 15km, and invoke a script for each path signal hit during this scan. These scripts in return can set speed limits for the train, which unlike a red signal, apply immediately and from any distance. This allow to emulate signal aspects which limit the train speed rather than just stopping it. The lookahead system can also be used to passively gather information for signal texture states.
[/p]
Marker reservations
[p]A new "blank" signal, the marker, is now provided. This signal is very useful as a passive sensor for scripts, and it will be used like this most of the time. But it also has an active capability: it can "fake" a reservation at its point of the track. This allows to extend reservations beyond signals with the use of scripts which get called when a reservation probe runs on top of the marker signal.
[/p]
Custom signal texture state
[p]The decision to which texture show for any given signal can be fully customized by scripts. Scripts can reference any amount of states declared in a signal texture mod to change the signal texture, under any logic they desire. This works for all signals, not just path signals.
[/p]
Shift assignation condition modifications and vetoing
[p]When the shift dispatch system is trying to find a shift for a train, and it finds a suitable candidate, it will now call a script with all the gathered information. The script can then veto this decision to force the system to keep looking for a different shift.
The initial setup for the shift dispatch process can also be scripted. The system will first prepare a default setup with all the relevant information, like simulation time and train location, and a script can then force it to ignore some of that information so more shifts are considered, or modify some of the information, so for example shifts in the past are also considered.
[/p]
Interventions and teleporting
[p]Lower frequency scripts with access to the more powerful SimController API can issue unlimited interventions, teleports and drive orders to trains.
[/p]
Schedule-less line running
[p]Scripts can force a train to run a specific line at any time, ignoring the schedule system. This is useful for technical maneuvers and for roleplaying non-pax operations. These trains can even carry pax if there exists any shift with the same line scheduled a similar time, mostly useful to issue extra trains in high TPH services like subways.
[/p]
Hitching and train reconfiguration
[p]Trains can now have up to 8 different post-purchase configurations. These configurations are player-edited, in the train editor. They cannot append new cars or reorder them, only remove them from the purchased configurations. Scripts are then able to switch the train into any of these 8 configurations. For example a train could be reconfigured to to not have a locomotive prior to coupling. [/p][p][/p][p]Train coupling is now possible, and controlled by scripts. This is internally called "hitching" since "coupling" is already being used for car coupling in train compositions. The concept of "train coupling" is extremely complex when every possibility is considered, and it's unworkable to try to fit them into the UI/UX and the schedule system. So instead coupling is only offered to scripts, with an API which allows to couple any train to any other train (including multiple trains), optionally changing its orientation. Combined with reconfiguration this enables many coupling concepts. The coupling and uncoupling process will be controlled by scripts, so the specific mechanics are left to mod developers.[/p][p][/p]Timing changes
[p]In order to enable scripts to set arbitrary speed limitations at any time, the train dynamics formulas had to be changed and simplified. This means some saves will see a subset of their line and shift timing change, and might need manual adjustment.[/p] Devblog for September 2025
Version 1.17.11
Version 1.17
Version 1.17 has been released
[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. This test was successful in the beta branch and it is now being deployed for all players. NimbyScript will be used for custom signal logic and other functionality in future versions.[/p][p]But to make this version a little more exciting it includes a couple extra features.[/p][p][/p]Dynamic braking
[p]Trains are now capable for braking for some dynamic simulation obstacles: (potentially) red signals and other train tails.[/p][p][img src="https://clan.akamai.steamstatic.com/images/37091993/8c1e6d5d072f4205efdbbeee2cdd53739dc8ea9f.png"][/p][p]When a train is approaching a signal, and it is within braking distance, it will start checking it in advance, and will start braking if it would become a stop signal at that moment in time. To remain compatible with existing saves trains are still capable of unrealistically braking to 0 speed immediately. A future version will expand this capability to also making it possible to reserve the signal in advance (not just checking it) with expanded capabilities in the signal system.[/p][p]When a train approaches the tail of another train, it is now capable of slowing down and matching the speed of the train in the front. Again to remain compatible the allowed distance for this feature is much shorter than it should be in reality, to reduce the impact on existing saves.[/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"][TAG-30][/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] Version 1.17 is now in the beta branch
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
Devblog for May 2025
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: 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