Long Commuting time due to RHW neighbor connection

[Fat Boy Tommy 2]

Hi guys!

Just noticed a weird thing in SC4 NUM36 and can't find any info about it.

I have two test cities, one is residential (R-City) and the second with heavy industry (I-City). The cities had grown up and I replaced classic Maxis avenue connections between the cities with RHW-4. I have done it in a proper way as described in the NAM manual (drag RHW to border, plop connector piece on top and do the same in another city). After a while traffic stabilized and the cars from R-city appeared in I-city, not only freight tracks. However, back to R-city, the commuting time rose drastically on the graph. Moreover, commuting time for close-to-border R$ houses changed from "short" to "long". After a while some of these houses were abandoned. Then I removed RHW and replaced it back with avenue. The commuting time was back to "short" and the graph displayed the commuting time decrease. Actually this happens every time I use any of RHW networks with those special neighbor connector pieces. 

Any ideas how I can solve this problem except avoid using RHW on the cities' borders?

And yes, there's no any other city nearby and connection to it, so it can't be infinite commuters bug.

[CorinaMarie 29,857]

Hiya!

I'm not a NAM expert, but I'll move your topic over to their forum so it gets seen by all the right peeps. ( And welcome to Simtropolis. )

[Tarkus 6,933]

In the NAM Traffic Simulator (all capacity levels), the RHW is set to have a base speed of 150, while Avenue has a base speed of 50.  The Neighbor Connectors are also RHW-based--depending on how each half of your RHW is set up, it may be that the actual distance goes up by a couple of tiles, but with that speed advantage, there is no logical way it would cause the commute time to increase to the extent you've described (it should actually decrease quite noticeably), without there being some other underlying issue with your setup, either on the in-game design you're using, or based on what else is in your Plugins folder.

There are a few possibilities at play here:

(a) You also happen to have some sort of other plugin that modifies the Traffic Simulator Exemplar installed, which is specifying a lower RHW speed and thereby breaking the setup (if you by chance picked up the "Variable Route Buses" plugin that was mentioned in another recent thread, it actually has the RHW network set to a capacity of 0 and a speed of 0 (!), thereby breaking it).  Checking the Traffic Congestion DataView would be a useful way of determining what is happening here.  A capacity and speed to 0 will result in a network always showing up bright red in the Congestion DataView.

(b) There may be some sort of issue with how you have the Neighbor Connector Pieces placed.  If there is any separation between the two sides of the RHW (i.e. the two halves are not directly adjacent to one another, and have one or more blank tiles in the median), the Loop Connector pieces (which show a blue arrow with an "N" in the preview) must be placed in the blank tiles between the two halves at the tile's edge.  Additionally, the Neighbor Connector Pieces (and any required Loop Connectors) must be placed on both sides of the neighbor connection in order to ensure proper functionality.

(c) There's some other issue relating to how you have the rest of your transit network grid and zoning hooked into the RHW, that wasn't applicable with your Avenue setup.  Except for some allowable at-grade connections with the smaller networks, the RHW is not intended to act as a surface network, and the RHW networks that require Neighbor Connector pieces usually work best with grade-separated interchanges connecting the surface network grid to the RHW.  If you happen to have any residential zones that had frontage on that original Avenue, they will absolutely abandon if that frontage is switched out to RHW, as the RHW networks do not support residential zone frontage in any capacity. 

If this general advice isn't enough to help you solve the issue, an image of your setup with both the Avenue and RHW versions of it would be very helpful in diagnosing exactly what is happening.

-Tarkus

 

[powerfullshammy 81]

10 hours ago, Fat Boy Tommy said:

Hi guys!

Just noticed a weird thing in SC4 NUM36 and can't find any info about it.

I have two test cities, one is residential (R-City) and the second with heavy industry (I-City). The cities had grown up and I replaced classic Maxis avenue connections between the cities with RHW-4. I have done it in a proper way as described in the NAM manual (drag RHW to border, plop connector piece on top and do the same in another city). After a while traffic stabilized and the cars from R-city appeared in I-city, not only freight tracks. However, back to R-city, the commuting time rose drastically on the graph. Moreover, commuting time for close-to-border R$ houses changed from "short" to "long". After a while some of these houses were abandoned. Then I removed RHW and replaced it back with avenue. The commuting time was back to "short" and the graph displayed the commuting time decrease. Actually this happens every time I use any of RHW networks with those special neighbor connector pieces. 

Any ideas how I can solve this problem except avoid using RHW on the cities' borders?

And yes, there's no any other city nearby and connection to it, so it can't be infinite commuters bug.

Subway, train, monorail. connect those to other cities should bring it back to short the commute if your station placing is just right but I recommend subway eats less land and easier to connect to other cities. Sometimes I'm bad at placing stations of subway if im out of it so commute goes long

[Fat Boy Tommy 2]

19 hours ago, CorinaMarie said:

Hiya!

I'm not a NAM expert, but I'll move your topic over to their forum so it gets seen by all the right peeps. ( And welcome to Simtropolis. )

Thank you!

14 hours ago, Tarkus said:

In the NAM Traffic Simulator (all capacity levels), the RHW is set to have a base speed of 150, while Avenue has a base speed of 50.  The Neighbor Connectors are also RHW-based--depending on how each half of your RHW is set up, it may be that the actual distance goes up by a couple of tiles, but with that speed advantage, there is no logical way it would cause the commute time to increase to the extent you've described (it should actually decrease quite noticeably), without there being some other underlying issue with your setup, either on the in-game design you're using, or based on what else is in your Plugins folder.

There are a few possibilities at play here:

(a) You also happen to have some sort of other plugin that modifies the Traffic Simulator Exemplar installed, which is specifying a lower RHW speed and thereby breaking the setup (if you by chance picked up the "Variable Route Buses" plugin that was mentioned in another recent thread, it actually has the RHW network set to a capacity of 0 and a speed of 0 (!), thereby breaking it).  Checking the Traffic Congestion DataView would be a useful way of determining what is happening here.  A capacity and speed to 0 will result in a network always showing up bright red in the Congestion DataView.

(b) There may be some sort of issue with how you have the Neighbor Connector Pieces placed.  If there is any separation between the two sides of the RHW (i.e. the two halves are not directly adjacent to one another, and have one or more blank tiles in the median), the Loop Connector pieces (which show a blue arrow with an "N" in the preview) must be placed in the blank tiles between the two halves at the tile's edge.  Additionally, the Neighbor Connector Pieces (and any required Loop Connectors) must be placed on both sides of the neighbor connection in order to ensure proper functionality.

(c) There's some other issue relating to how you have the rest of your transit network grid and zoning hooked into the RHW, that wasn't applicable with your Avenue setup.  Except for some allowable at-grade connections with the smaller networks, the RHW is not intended to act as a surface network, and the RHW networks that require Neighbor Connector pieces usually work best with grade-separated interchanges connecting the surface network grid to the RHW.  If you happen to have any residential zones that had frontage on that original Avenue, they will absolutely abandon if that frontage is switched out to RHW, as the RHW networks do not support residential zone frontage in any capacity. 

If this general advice isn't enough to help you solve the issue, an image of your setup with both the Avenue and RHW versions of it would be very helpful in diagnosing exactly what is happening.

-Tarkus

 

Thank you for your reply. 

(a) Not the case. I don't have such plugins as far as I remember and I have already checked long pieces of various networks for how well they deal with traffic. Everyrhing looks fine.

(b) It's two RHW-4 pieces next to each other.

(c) Yes, RHW doesn't provide access to RCI zones.

Please, take a look at the pictures. They are eight: 4 for avenue setup (2 for R-City and two for I-City) and another 4 for RHW-4 setup (2 for R-City and two for I-City). The traffic paths for RHW-4 setup look a bit odd, I don't know if it's supposed to be like that. The RHW-4 piece in R-city with avenue setup before connection to I-city is just to make sure there's no contribution from the pedestrians.

9 hours ago, powerfullshammy said:

Subway, train, monorail. connect those to other cities should bring it back to short the commute if your station placing is just right but I recommend subway eats less land and easier to connect to other cities. Sometimes I'm bad at placing stations of subway if im out of it so commute goes long

Yes, additional transportation system would help, however I don't understand why the game behaves in this way and would like to fix it as it doesn't look normal. 

[rsc204 21,857]

On 30/09/2019 at 2:54 AM, Fat Boy Tommy said:

Moreover, commuting time for close-to-border R$ houses changed from "short" to "long".

Bear in mind here that with the NAM's Traffic Simulator installed, all commutes that include a neighbour connection will show as long. It's only a problem if sims can't get to a job within the time allowed by the simulator, otherwise it shouldn't have much impact.

On 30/09/2019 at 10:44 PM, Fat Boy Tommy said:

(b) It's two RHW-4 pieces next to each other.

Yes, but just to be sure it's clear what Tarkus meant by "Neighbour Connectors", in the case of RHW (and NWM), you need to add a special Neighbour Connector (NC) puzzle piece on top of the RHW at the border. Simply dragging RHW-4 and making the connection is not sufficient, every tile on both sides needs one such piece in place. Have you placed these too?

[CorinaMarie 29,857]

10 hours ago, rsc204 said:

Bear in mind here that with the NAM's Traffic Simulator installed, all commutes that include a neighbour connection will show as long.

Based on empirical data, this isn't always true. Granted that older test was conducted in vanilla, but a new test shows the exact same thing using NAM 36:

 

When the game saves the data to propagate to the adjacent, connected city tiles it knows the average distance to the jobs in the other tile. That's what it uses to estimate the commute distance. Granted in nearly any real game the only jobs will not be right on the border of the other city tile, but it is inaccurate to say the commute will always be long.

[Fat Boy Tommy 2]

On 10/2/2019 at 8:14 PM, rsc204 said:

Bear in mind here that with the NAM's Traffic Simulator installed, all commutes that include a neighbour connection will show as long. It's only a problem if sims can't get to a job within the time allowed by the simulator, otherwise it shouldn't have much impact.

Yes, but just to be sure it's clear what Tarkus meant by "Neighbour Connectors", in the case of RHW (and NWM), you need to add a special Neighbour Connector (NC) puzzle piece on top of the RHW at the border. Simply dragging RHW-4 and making the connection is not sufficient, every tile on both sides needs one such piece in place. Have you placed these too?

Then question is still the same: why is it "short" when connected by avenue and "long" when connected by RHW? So, according to your logic, it also should be "long" for avenue with NUM installed.

As I mentioned before "I have done it in a proper way as described in the NAM manual (drag RHW to border, plop connector piece on top and do the same in another city)". Otherwise I doubt there would be any traffic allowed through the connection.

On 10/3/2019 at 6:22 AM, CorinaMarie said:

Based on empirical data, this isn't always true. Granted that older test was conducted in vanilla, but a new test shows the exact same thing using NAM 36:

 

When the game saves the data to propagate to the adjacent, connected city tiles it knows the average distance to the jobs in the other tile. That's what it uses to estimate the commute distance. Granted in nearly any real game the only jobs will not be right on the border of the other city tile, but it is inaccurate to say the commute will always be long.

You are absolutely right, CorinaMarie! Moreover, in my setup it also was short time with avenue connection.

Maybe it makes sense to reinstall SimCity and NUM36, then perform this test again, just to exclude any possible plugin impact. Will try that. 

BTW, is there any capacity parameter for an RHW connector?

UPD. Just checked one more time: the commuting time for both low or high traffic level is also "long". It is short only for maxis networks such as avenue or road. And 200 times longer for any kind of RHW. Looks like RHW neighbor connector pieces do not work properly.

[Tarkus 6,933]

There is no capacity parameter for an RHW connector--it's the same as the RHW network itself.  Transit network tiles all have their capacity determined by the Catalog Capacity property in the Traffic Simulator Exemplar.  While there are some workarounds (the "Distilled Intersection Paths" effect that some NAM override networks use to boost capacity), that's the only setting there is.

It's also worth noting that the RHW Neighbor Connectors are effectively a workaround for the fact that, with the exception of the default two-tile networks (Avenue and Maxis Highways), the game requires that traffic be going in both directions on any neighbor connecting tile, such that both morning and evening commutes are leaving and returning on the same tile.  The RHW-2, RHW-3, and DDRHW-4 all work fine with Neighbor Connections, but with networks like the RHW-4, the Neighbor Connector Pieces turn the tile at the city edge into bidirectional traffic. 

The "wrong way" traffic is hidden 50 meters underground (sometimes resulting in "spider cars" on the edge of the city tile), and there are also underground paths to move traffic back onto the correct side of the road once it enters the next city.  That's why the commute arrows look as they do--the traffic is switching sides of the road and going underground as needed to get into the next city.  The method that was used before the Neighbor Connector Pieces were added was something called a "Loop Connector", in which one actually dragged a physical surface connection between the two sides of a dual-carriage RHW.

Additionally, I'll note--the DataView you showed is actually the Traffic Volume DataView, which merely shows how many vehicles are traveling down that stretch.  There should be a button to switch it over from Volume to Congestion, which will show you how congested the game sees those tiles.

-Tarkus

Edit: Another question: how exactly did you build your RHW?  It looks rather strange, namely in the fact that the RHW-4 isn't transitioning to Avenue.

 

[Tarkus 6,933]

Double posting . . . I just did a quick test myself of this whole situation.  I've found three things in the whole process:

(a) As Cori found out, it is indeed possible to have a commute involving a Neighbor Connection list come through as "Short" with the NAM Simulator.

(b) Any time a new neighbor connection is first built/rebuilt (regardless of network), the commute time will be listed as "Long" , until the second city (the commute city) has had a chance to run, and then the first city (where the residence is located) has had a chance to run again for a short period of time.  Initially, once the first city is loaded back up, the commutes will still read "Long", but after a bit of additional simulator time (no more than a few seconds at Cheetah speed), it will revise down to "Short", if applicable--and yes, this includes situations involving RHW-4 Neighbor Connectors, as well as the base RHW network (the RHW-2) itself.  I was also able to achieve "Long" with a Road connection, so Maxis networks are no silver bullet.  (It should be noted, the base RHW technically is a Maxis network--just one they didn't finish and disabled in the base game, until the NAM Team re-enabled it 14-15 years ago.)

(c) The initial process of re-building the neighbor connector, and getting it to run in both cities, will cause the Commute Time graph to spike very dramatically.  However, once it's been "broken in" upon the second load of the first city, after a bit of simulation time, it drops back down to what would be expected.

I suspect the OP's sudden reversal of fortune with switching back to Avenue was that the game was in a state where the simulation hadn't run long enough, and it still expected the Avenue connection. 

Long story short--switching networks at a neighbor connection will initially make it look like there's been a dramatic spike in commute time, but it's no real need for panic.  The simulation just needs a few seconds in each city tile in order to return to equilibrium.

-Tarkus

[Fat Boy Tommy 2]

Tarkus, thank you for your thorough reply. I think I have solved the problem by reinstalling SC4 and NUM 36. Now it works exactly as you describes. I also installed 80% of plugins I used (the rest I don't need and there's nothing to do with traffic, but may be the reason lies in those plugins not installed yet). Previously switching between cities and running simulation for some time didn't help unfortunately. Now it works well. Thank you. Probably, I should have started from reinstalling the programs.