Subway junction - Commuters make a 45⁰ sharp turn in subway junctions

[navyou14 3]

Recently stumbled upon a very annoying thing when dragging subway tunnels through my dense city. When building my subway tunnels I tend to create junctions/switch as seen in the first picture. I've created a junction so that a single subway line can be split into two different lines/branches.  I want this to work as a regular switch similar to how rail switches work when two separate lines can be created from a switch, allowing trains to continue in separate directions resulting in two different transit lines. This doesn't seem to work when working with subway tunnels in SimCity 4, as subway trains tend to divert in a unrealistic way as seen in the pictures below. A sharp 45⁰ turn is made and the inbound trains head outbound when they're only supposed to continue on the merged single line while heading inbound. On the contrary, junctions can be created perfectly when creating transit routes like El-Rail, GLR, Heavy Rail and Monorail.

Is there any way to fix this? I use latest NAM. I am not a professional programmer but is it possible to change the way this commuting route is normally displayed in the preferred way in the Traffic Simulator?

 

Note: In the second picture, the problem can be seen where the commuters who are supposed to ride the subway inbound from point B to A. However they instead divert in a sharp 45° turn, going from point B to C. what is seen in the first picture works perfectly fine when working with GLR, El-rail, Heavy Rail and Monorail as I mentioned before, is there anyway to modify this so that they're only restricted to commute in the way that's seen in the first picture?

[Propfam 2,303]

That's the subway behavior as far as I know. Subway, unlike other rails, doesn't realistically turn. It behaves like a glorified road. That's why there's no Real Subway (RSB) currently. There's however a new FLUP system which behaves quite differently. One is for some reason, despite being subway override, a FLUP route can't pass on-ground networks. It must be equipped with respective special pieces in the intersection between new FLUP network and others. Two is when you query the route, the route isn't as you drawn before, but it's the shortest route, aka the diagonal. The subway is quite quirky. It doesn't mean they can't be modded. Just if you mod, it will behave in a quirky way. Thanks.

[rsc204 21,866]

I think the basic issue is that subway is wholly bi-directionally pathed. As such, even though a given connection would probably re-rail a train in the real world, the game sees it as a valid path nonetheless. Perhaps it’s possible to mod something like this, but over the years the subway system has barely had the attention of modders. If anything the flexibility of under the surface routes is why the NAM team looked into re-purposing it. That was no easy task either, it was many years before the recent breakthrough. As such, you are sort of in Virgin territory and little, if any documentation exists to help. 

[Haljackey 17,393]

I'll make my rail junctions look pretty on the surface or elevated, but anything I make underground is a mess. I don't really care what it looks like so long as it connects. The only time I look at underground view is when placing subway stations or laying new subway line. Same goes for water pipes.

Although it is cool to see functional roads under the surface now- that is quite neat and gives a boost to a underutilized aspect of the game.

[Kiwiwriter47 473]

As it happens, the New York Subway's well-known Times Square-Grand Central Shuttle is based on not one but two major turns, both close to being 45-degree angles.

This might help in terms of history. This ancient line, part of the original 28 stations, is getting a major rehabilitation, to enhance its efficiency for the first time since 1904.

It will have cars that do not have seats. As the ride is under two minutes, you should be able to stand for that. 

nycsubway.org: IRT Times Square-Grand Central Shuttle

[Tarkus 6,933]

Based on what I know of how Maxis put together the Subway network, there's an astronomically high preponderance of the underpinnings for it that were lifted directly from the Road network, verbatim.  The same is actually true of the One-Way Road network, too, which produces some rather bizarre results (though perhaps not as much so as with Subway) on its pathing--especially since they chose a brute force method to create the unidirectional traffic, the "Tidal Flow" system that has a certain infamy to us NAMites, and completely reused the Road network's paths. 

This almost complete re-use of Road resources on the Subway network seems to be in spite of the fact that the Rail network existed pre-Rush Hour/Deluxe, and was later used as a basis for the pathing on the Elevated Rail and Monorail networks.  That's what makes this all that much more bizarre.

The path file for that base orthogonal x diagonal intersection (0x06003900) and its Road equivalent (0x00003900) have identical coordinates and directional options, when comparing the Subway paths (Type 4) in the former against the Car paths (Type 1) in the latter.  The only real differences between the two are that the Road one was "updated" to a higher version of SC4PATHS (1.1 vs. 1.0) in order to allow for stop points (which aren't included in the Subway pathing), and the inclusion of Pedestrian paths (Type 2, labeled as "Sim" in most path files) on the Road version as well.

To my knowledge, prior to the addition of the Subway-based draggable FLUPs system that debuted in NAM 39, there's been virtually nothing done with the Subway network in the NAM since its first release almost 17 years ago (April 2004).  The only such fix was reversing the existing paths for Left-Hand Drive (LHD) users in NAM 16 (June 2005).

The degree to which we can make the Subway work more like Rail, El-Rail, and Monorail is an unknown.  The latter all utilize special RUL flags for junctions that may not work on Subway, as they're not in use on Road and Road-like networks. 

Restricting the turns on the pathing would be doable to at least some extent, however.  If you unzip the file I've attached and place the .dat file inside it somewhere in your Plugins (literally anywhere should work, since it's overriding Maxis content, not NAM content) should cause the junction in question to operate more like you expected it would.  This area is something that will require some further research and likely further fixes.

-Tarkus

NAM_Tarkus_SubwayPathFiles_02122021.zip

[Kiwiwriter47 473]

12 hours ago, Tarkus said:

Based on what I know of how Maxis put together the Subway network, there's an astronomically high preponderance of the underpinnings for it that were lifted directly from the Road network, verbatim.  The same is actually true of the One-Way Road network, too, which produces some rather bizarre results (though perhaps not as much so as with Subway) on its pathing--especially since they chose a brute force method to create the unidirectional traffic, the "Tidal Flow" system that has a certain infamy to us NAMites, and completely reused the Road network's paths). 

This almost complete re-use of Road resources on the Subway network seems to be in spite of the fact that the Rail network existed pre-Rush Hour/Deluxe, and was later used as a basis for the pathing on the Elevated Rail and Monorail networks.  That's what makes this all that much more bizarre.

The path file for that base orthogonal x diagonal intersection (0x06003900) and its Road equivalent (0x00003900) have identical coordinates and directional options, when comparing the Subway paths (Type 4) in the former against the Car paths (Type 1) in the latter.  The only real differences between the two are that the Road one was "updated" to a higher version of SC4PATHS (1.1 vs. 1.0) in order to allow for stop points (which aren't included in the Subway pathing), and the inclusion of Pedestrian paths (Type 2, labeled as "Sim" in most path files) on the Road version as well.

To my knowledge, prior to the addition of the Subway-based draggable FLUPs system that debuted in NAM 39, there's been virtually nothing done with the Subway network in the NAM since its first release almost 17 years ago (April 2004).  The only such fix was reversing the existing paths for Left-Hand Drive (LHD) users in NAM 16 (June 2005).

The degree to which we can make the Subway work more like Rail, El-Rail, and Monorail is an unknown.  The latter all utilize special RUL flags for junctions that may not work on Subway, as they're not in use on Road and Road-like networks. 

Restricting the turns on the pathing would be doable to at least some extent, however.  If you unzip the file I've attached and place the .dat file inside it somewhere in your Plugins (literally anywhere should work, since it's overriding Maxis content, not NAM content) should cause the junction in question to operate more like you expected it would.  This area is something that will require some further research and likely further fixes.

-Tarkus

NAM_Tarkus_SubwayPathFiles_02122021.zip

Agreed...subways should have different design and engineering dynamics that should approximate those of rail, elevated, and monorail systems.

[navyou14 3]

On 2/13/2021 at 9:08 AM, Tarkus said:

Based on what I know of how Maxis put together the Subway network, there's an astronomically high preponderance of the underpinnings for it that were lifted directly from the Road network, verbatim.  The same is actually true of the One-Way Road network, too, which produces some rather bizarre results (though perhaps not as much so as with Subway) on its pathing--especially since they chose a brute force method to create the unidirectional traffic, the "Tidal Flow" system that has a certain infamy to us NAMites, and completely reused the Road network's paths. 

This almost complete re-use of Road resources on the Subway network seems to be in spite of the fact that the Rail network existed pre-Rush Hour/Deluxe, and was later used as a basis for the pathing on the Elevated Rail and Monorail networks.  That's what makes this all that much more bizarre.

The path file for that base orthogonal x diagonal intersection (0x06003900) and its Road equivalent (0x00003900) have identical coordinates and directional options, when comparing the Subway paths (Type 4) in the former against the Car paths (Type 1) in the latter.  The only real differences between the two are that the Road one was "updated" to a higher version of SC4PATHS (1.1 vs. 1.0) in order to allow for stop points (which aren't included in the Subway pathing), and the inclusion of Pedestrian paths (Type 2, labeled as "Sim" in most path files) on the Road version as well.

To my knowledge, prior to the addition of the Subway-based draggable FLUPs system that debuted in NAM 39, there's been virtually nothing done with the Subway network in the NAM since its first release almost 17 years ago (April 2004).  The only such fix was reversing the existing paths for Left-Hand Drive (LHD) users in NAM 16 (June 2005).

The degree to which we can make the Subway work more like Rail, El-Rail, and Monorail is an unknown.  The latter all utilize special RUL flags for junctions that may not work on Subway, as they're not in use on Road and Road-like networks. 

Restricting the turns on the pathing would be doable to at least some extent, however.  If you unzip the file I've attached and place the .dat file inside it somewhere in your Plugins (literally anywhere should work, since it's overriding Maxis content, not NAM content) should cause the junction in question to operate more like you expected it would.  This area is something that will require some further research and likely further fixes.

-Tarkus

NAM_Tarkus_SubwayPathFiles_02122021.zip

WOW, I had no idea about all these things and also HUGE thanks for suggesting this Zip file!! I am looking forward to dig in further into the perks of this and follow any potential developments regarding this!