1. NIMBY Rails
  2. News

NIMBY Rails News

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:

https://carloscarrasco.com/nimby-rails-january-2025/


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.

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:

https://carloscarrasco.com/nimby-rails-february-2025/

Devblog for January 2025

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:

https://carloscarrasco.com/nimby-rails-january-2025/

Version 1.15.17

- 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

[h2]Stations v3: persistent stations with explicit user editing[/h2]

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.


[h2]Station editor[/h2]

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.




[h2]Big rewrite of the track editor internals[/h2]

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.


[h2]Signal and track editor improvements[/h2]

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.


[h2]Full rewrite of multiplayer internals[/h2]

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:

https://carloscarrasco.com/nimby-rails-october-2024/

https://carloscarrasco.com/nimby-rails-november-2024/