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"][/dynamiclink]
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]
