NAM Traffic Simulator and Data View Support Thread

[Kel9509 1,403]

Sorry if this question has been answered before, but do busses count for congestion under the NAM?  The documentation is contradictory.

In the Data Views feature guide, it says: "Furthermore, some of the volume views include non-congestion producing travel types, which are pedestrians, buses, and ferries."

But in the NAM Traffic Simulator feature guide, it says: "In combination with the pathfinder upgrading, this allows buses to be counted toward traffic and congestion, just like all other vehicles."

So do busses count towards congestion or not?

[Tarkus 6,932]

Buses do indeed count towards congestion with the NAM Simulator.  The Traffic Simulator Exemplar's "Travel type generates traffic" value for Buses is set to "True".  Ferries are not handled by the Traffic Simulator Exemplar, so the only travel type that has it set to "False" is Pedestrians.

IIRC, the documentation for the Data Views was written sometime in 2008-2009, prior to Simulator Z becoming the NAM's standard, and versions of the Data View Plugins existed for its predecessors (i.e., Simulators A, B, C, D, and E), for which Buses did not count toward congestion.

-Tarkus

[Darkslide 0]

Hi. I just got into this game and mod (thanks for all your amazing work!) and got very confused by the way the traffic simulator models the effect of intersections, especially the interplay with NWM and FTL networks. I think I understand how it works now, but... I'd just kinda like to understand *why* you guys chose to do it that way? It seems to create very arbitrary effects and doesn't really make sense to me.

As I understand (and seems to match my in-game observations), the natural slowdown of traffic at intersections is modeled by setting the second and third ITCE value to 0.2 and 0.4, which means tiles one or two steps away from the actual intersection see the congestion by having their capacity artificially reduced. The actual intersection instead has its capacity increased to 1.25 because that's used to boost capacity on certain networks (the DIP thing).

This would make sense to me if it worked consistently on all networks, but the problem is that it doesn't work for DIP networks at all (like most NWM roads or turning lanes) because the DIP tile itself already counts as an "intersection", and the game can only apply one ITCE modifier at a time. So the DIP tiles always have 1.25 capacity even if they're one tile over from the "real" intersection.

What this means in practice is that if I use a normal road to connect to my intersection, I see a very heavy congestion effect (0.2 is a pretty harsh factor). But if I upgrade the road from normal RD-2 to NRD-4 or ARD-3 or almost any other NWM road variation, the intersection effect suddenly disappears completely (so while an ARD-3 is "supposed" to be 25% better than a RD-2, it actually feels 1.25 / 0.2 = over six times as good in practice). When I instead try to add a stretch of turning lane in front of my "problematic" intersection (which would sound like a realistic way to improve intersection congestion in real life), it doesn't really do anything useful because while the FTL tiles themselves are now free of congestion (thanks to their 1.25 DIP bonus), the normal road tile right before the turn lane starts now suddenly gets 0.2 capacity (even though it is far away from the "real" intersection and realistically an opening turn lane should not cause traffic to slow down so much there). So FTLs unintuitively don't reduce congestion at all, they just "push it down the road" (literally). Unless you build an entire stretch between two intersections out of turning lane tiles, then the whole intersection penalty magically disappears again.

So it kinda feels like this system just arbitrarily punishes you for using default networks and makes NWM/FTL networks incredibly overpowered by bypassing a major balance mechanic entirely (which is sad for me because I like to use Tram-in-Avenue and 3x3 roundabouts a lot, and those don't support intersections with NWM networks or turning lanes). I understand that there's no "better" way to model intersection effects without reducing all DIP networks to a cosmetic-only change, but if the solution is so broken then why try to model them at all? I feel like at that point it would be better to just give up on trying to make intersections affect traffic completely, and then at least you get consistent results for other (non-intersection-effect) congestion (e.g. upgrading a RD-2 to an ARD-3 actually makes it 25% better, and not 500%).

Would it make sense for me to change my files so that ITCE is 1.25,1.0,1.0? Or does that break the simulator completely because then traffic flows way too well?

[Tarkus 6,932]

First off, welcome to Simtropolis!

You've definitely hit on one of the more vexing series of tradeoffs we've had to try to work around over the years, with regards to network capacity and DIPs, and one that partly harkens back to the "Traffic Simulator Wars" of the late-00s/early-10s.

The original ITCE values from Maxis were 0.7, 0.8, 0.9, so the intersection tile itself actually reduced capacity.  The discussions about changing the profile of the ITCE values started in 2007, when the NWM was in early planning stages, and mott and jplumbley were in their research phase, which led to NAM Simulators A and B being developed with future NWM compatibility in mind.  At the time, the most pressing concern was related to network capacity--namely, equalizing the per-tile capacities and speeds of Road, OWR, and Avenue.  (z1 later buffed the OWR to have higher per-tile capacity and speed with one of the early updates to Simulator Z, based on the green wave phenomenon.)  However, the renewed interest in simulator settings and optimization led to experiments and development with the ITCE, the Congestion vs. Speed curve, and other areas.

jplumbley thought that the notion that the intersection tile itself was the highest point of congestion in the ITCE didn't make sense, as the actual congestion at intersections is on their approaches.  For Simulator A, he changed it to 1.5, 0.9, 0.95.  At the time, we didn't know that the TLAs' crossover paths would cause those networks to invoke the ITCE (let alone about DIPs).  Once the TLA ITCE effect and DIPs were discovered, z1's Simulator Z platform was the basis of all the NAM's simulator plugins.  He thought jplumbley's first value of 1.5 was too extreme, so settled on 1.25 (pre-DIPs, I believe it was 1.0), but even before upping the first value, he had tended to believe the second and third values were not creating enough of a congestion penalty to accurately simulate traffic light/stop sign queuing.  From what I recall from back then, he had a steep dropoff between the first and second values even before the first value was raised to the current 1.25, and he was concerned that not having that steep dropoff would negatively impact the simulation.

The general explanation that's been used to rationalize certain NWM networks/FTLs being buffed at intersections, as well as the ITCE-induced congestion spiking near transitions from base networks to NWM/FTL transitions, has been that:

a) the additional lanes minimize the delays caused by turning traffic, and in particular, left turn traffic (right turn traffic in LHD) having to yield to oncoming traffic, and blocking the passage of traffic going other directions through the intersection

b) as the traffic volume generally drops off to some extent as one gets farther from a major intersection that has turn lanes (mostly if there's development near that intersection), the overall effect to congestion for having an FTL will still be neutral at worst (i.e., it's still there but has been pushed backward, as you've noted), but potentially slightly positive at best (the increased capacity is at the highest-volume point, and the dropoff at the transition is at a lower-volume point where the effect will not be as extreme)

Is this ideal?  No, but all the options currently available to us have significant tradeoffs, and we've generally felt this set of tradeoffs is the best compromise under the circumstances.

Can you raise the second and third ITCE values yourself?  Yes, certainly, with an "at your own risk" caveat, since you're running a modified simulator that differs slightly from what the NAM has provided and supports.  The extreme dropoff to 0.2 and 0.4 for the second and third values has been a source of controversy among some users, and back when the Traffic Simulator Configuration Tool (TSCT) still existed and was supported, there was an option to dial that back.  When Simulator Z 3.0 debuted with NAM 45 (September 2022), we discontinued the TSCT, as not only would it have required a fair bit of reprogramming (made somewhat more difficult by the state of the original source code from over a decade prior), z1 found the simulator properties and their effects on both pathfinding quality and system performance to be more sensitive than previously thought.  In fact, he found that setting the capacities above a certain level actually hampered both quality and performance, which meant the Medium, High, and Ultra versions actually performed measurably worse than the Low and Classic versions.

Given the recent advancements resulting from DLL modding, it's possible we may eventually arrive at a better solution, though there's still considerable challenges to overcome before we can really consider that prospect, as the areas that would need to be modified remain uncharted territory.  Barring any eventual ability to add true new networks (which appears would be extraordinary difficult to do--see here), the other thought would be to allow overrides of network capacity/speed on an IID-level basis (i.e., explicitly stating that a TLA-3 tile has a certain capacity, rather than defaulting to base network capacity x  ITCE), by some mechanism such as exemplars or by supporting new properties in path files.  This would probably be beneficial even in the case that we are able to add true new networks down the road (pun fully intended).

-Tarkus

[Lab Rat 13]

Automated Notice Message

All posts after 1 March, 2026 @ 01:37 GMT were lost in the site crash.

We've added this message thread divider in every topic across all forums for what were then active threads. (We decided active is if the most recent extant post (from the backup) was on or after 1 January, 2026.)

This divider serves as notice that the conversation was interrupted. Answers and further discussion which used to be here have been lost. Keep this in mind when replying. Our hope is to rebuild what is missing.