z1

The NAM Unified Traffic Simulator The NAM Unified Traffic Simulator (or the NAM Simulator, for short) is a traffic simulator that is derived from the original Maxis traffic simulator, but is also built upon the knowledge gained from all previous NAM traffic simulators, including work by the7trumpets, Tropod, jplumbley, Mott, and z. It uses the Simulator Z core; what makes it a unified simulator is that it makes available to the player all the main features found in all previous traffic simulators. What makes this possible is the Traffic Simulator Configuration Tool (TSCT), which can be used to customize the NAM Simulator in any of these ways, and it also allows the ordinary player to safely customize the traffic simulator in ways that were not possible previously. The TSCT is available as an option in the NAM installer when the option "I want to build a custom simulator" is chosen; it is also available as part of the NAM Traffic Subsystem. Since the NAM Simulator evolved from Simulator Z, many of the features listed here for the NAM Simulator were also present in various versions of Simulator Z. However, many of these versions were never released together with the NAM, and so most people will be seeing the features they contained for the first time here. One of the main areas of the work on the NAM Simulator involved increasing the efficiency of the pathfinder to close to its theoretical maximum (it uses the "perfect pathfinding" settings), while also increasing the Sims' maximum commute time to be closer to real-world conditions. This allows a smoother distribution of traffic throughout the city, with typically less congestion. At the same time, the congestion that does exist is less likely to lead to abandonment due to commute time; Sims know that they occasionally have to sit through traffic jams, and are a bit more patient. Better pathfinding also means that Sims act much smarter about finding jobs and routes to them; this also results in less abandonment due to commute time. As in the real world, zones can be farther apart without causing problems; this is especially helpful when building existing cities to scale. Finally, running the pathfinder with near-optimum settings allows the simulator to run up to several times as fast as previous simulators. The second major area of work on the NAM Simulator involved a more flexible distribution of traffic among the various travel types. In combination with the pathfinder upgrading, this allows buses to be counted toward traffic and congestion, just like all other vehicles. This is a significant change from all previous simulators, and it's an important point to remember when planning your transportation infrastructure. More flexible distribution of traffic also means that the NAM Simulator is much more dynamic about allowing Sims to choose their transportation. In cities with excellent highways and road capacity, car usage has been measured at over six times that of previous simulators. Yet for cities with less extensive road networks and reasonable mass transit, car usage is actually less than in previous simulators. Other changes in the NAM Simulator include the following: More realistic subway costs. Subways in SC4 are tremendously underpriced compared to the real world. The improvements to the pathfinder have made huge networks of subways less necessary, so the monthly cost for subway tiles has been multiplied by six to add more realism. More realistic air pollution due to traffic. Until now, the amount of air pollution emitted by traffic has been unchanged from the original game, where it was based on cities that had far less traffic capacity than that used by any of the current simulators. To keep the amount of air pollution emitted by traffic to a more realistic amount, the proportion of traffic air pollution to actual traffic has been lowered in the NAM Simulator. This lower proportion is linked to the Clean Air Act, so it is in effect only when the Clean Air Act is enabled. More accurate numbers for the Commute Time Graph. Due to a bug in the game, it is impossible to get accurate Commute Time Graph numbers for all situations. However, the NAM Simulator has adjusted the scaling of this graph to provide reasonably accurate numbers for most situations. Improved intersection effects. Despite the appearance of stoplights at intersections, Sims don't actually stop; they don't even slow down unless congestion is present around the intersection. the NAM Simulator provides much more congestion around heavily-travelled intersections, thereby doing a better job of simulating stop lights and stop signs. Greater monorail and high speed rail usage. Due to a bug in the game, monorail and HSR usage is generally less than it should be, sometimes by quite a bit. the NAM Simulator compensates for this bug by raising monorail usage to appropriate levels Monorails and HSR have been fixed to contribute to and be affected by traffic congestion, just like all other vehicles. The following features are new as of the May 2010 NAM: Greater highway usage. The traffic simulator has been tuned so that Sims use highways much more than ever before. This usage still tends to fall short of real world usage, though, due to the structure of the game. The amount of rapid transit available in a city will also have a big effect on highway usage. All mass transit speeds have been recalibrated to provide a more realistic simulation. Improved customer levels for businesses. Capacities and speeds of one-way roads have been raised to duplicate the real-world advantage of these roads. Street capacities have been raised so that they reflect the capacities implied by their speed limits. There are Park and Ride versions of the NAM Simulator; these can be enabled with the Traffic Simulator Customization Tool, mentioned above. Park and Ride changes the game slightly so that cars cannot reach their destination directly. Instead, those Sims who prefer to drive must park near some sort of mass transit station, and then take mass transit to the stop closest to their workplace. From here, they must walk the rest of the way. For this to work well, you need to have an extensive mass transit system. You also need to build parking lots and/or parking garages near key mass transit stops; generally the best places are at the edges of your residential areas that are closest to your jobs. Or you could just build parking facilities near the Sims' jobs (the ones that come with buildings generally don't count), but this really defeats the main purpose of Park and Ride. If you choose the Park and Ride version of a simulator, but don't build extra parking facilities, your game will not work very well at all. I have found RalphaelNinja's Ninja Boulevard Station and Ninja Boulevard Kiosk to be very useful in general, and particularly useful for Park and Ride, as they both contain large underground garages. I have enclosed modified lot files for both of these stations at the end of this post; the modifications bring the monthly cost down to be more in line with similar stations, and they also double the capacity, bringing them more in line with RTMT (and making them especially useful for Park and Ride). Since the exquisite design of these stations must have cost a lot of money, I left the plop cost alone. Also, since I have enclosed only the lot files, if you don't have these stations already, you'll need to download them from the above links. What are the different versions of the NAM Simulator, and how are they used? The NAM Simulator comes in five versions - Classic, Low, Medium, High, and Ultra. The name of the version refers to the network capacities in the simulator. The following is a list of the network capacities for each version of the simulator; all capacities are per tile: Which simulator version is appropriate for a particular city depends primarily on two things: the population of the city, and the amount of rapid transit (rails) available. Less capacity is needed for lower population cities, but less capacity is also required for cities with a lot of rapid transit. For example, a city of two million Sims has been run quite successfully using the Low capacity version of the NAM Simulator, but it had an extremely extensive subway system. So pick a simulator version based on these two factors; if it doesn't seem the right capacity, you can always switch it out for a different capacity version. Experience has shown that in large cities, the effects of such a switch may take up to five years to fully manifest. You can tell when things have stabilized by looking at the Traffic Volume Graph in the following way: First, let the game run until there is a sudden shift in traffic patterns. Sometimes, this may take over a year. Then run the game until you go at least a full year without any sudden change in traffic patterns. At that point, the transition to the new capacity simulator is complete. Installing the NAM Simulator The NAM Simulator is installed during the NAM installation. If you've already installed the NAM, you can reinstall the simulator by installing and running the NAM Traffic Subsystem. Traffic Volume View and Other New Data Views The Traffic Volume View included with the NAM as of the June, 2009 version offers a number of improvements to the one included with the game. Rather than the seven shades of blue in the original, this version uses the full spectrum of color, including approximately 48 distinct color shades. The maximum volume shown for each travel type has been increased from a flat 1200 for all types in the original Traffic Volume View to a value which is 300% of the capacity of the underlying network for the selected travel type. (Since only one commute period is shown at a time, this is one half of the standard network capacity, which is calculated for a full day.) The legend has been increased from five to nine entries, and each color in the legend is followed by the percentage of the underlying network capacity that that color represents, as well as the actual number of Sims represented by that percentage. When a travel type may have more than one underlying network (e.g., cars may travel on streets, roads, or highways), a subtext below the legend indicates which network is being referenced in the display. The colors in the display have been arranged so that they are more concentrated at lower levels, in order to give finer granularity at lower volumes. Between volumes of 0% and 10%, colors change about every 1.5%. Between 10% and 130%, colors change about ever 5%. And between 130% and 300%, colors change about every 10%. Please note that while every attempt has been made to attain the greatest accuracy possible, all numbers are somewhat approximate. The numbers following each color in the legend refer to the approximate beginning of the range of that particular color. You may notice that starting at 100%, the colors closely follow those in the Traffic Congestion View. However, it is important to keep in mind the difference between the Traffic Congestion View and the Traffic Volume View. The Congestion View is compiled from an entire day's travel statistics, while the Volume View refers to only a single commute period. Therefore, yellow in a single volume view does not necessarily indicate congestion, and blue or green in a single volume view does not necessarily indicate lack of congestion. An experienced player may be able to look at both commute periods of certain volume views and get a good idea of congestion, but it is necessary to be careful here. Finally, most transit station types light up in all volume views. This does not indicate anything about usage; it is simply so you can identify them easily. Certain types of transit stations do not light up because of the way they were designed. The Traffic Volume View also includes a new Subway View. The new Subway View acts in most ways like the normal underground Subway View, which is entered by selecting the Subway Tool when you want to build or demolish subways. However, it has included in it the volume display feature of the Traffic Volume View, which allows you to see the usage of your subways as you are building (or demolishing) them. Like the rest of the Traffic Volume View, this view shows the volume of traffic in each subway line visible in the main map, as well as in all subway lines in the minimap. The last feature included in the Traffic Volume View is a new Subway Building View, which is entered whenever you select a subway station to build. It differs from the standard Subway Building View in that no buildings other than subway stations are displayed; zones are displayed wherever possible; and like the Subway View, the volume of traffic in each subway line visible in the main map, as well as in all subway lines in the minimap. In addition, zones and transit station locations are shown in the minimap. Finally, most transit station types light up in all volume views. This does not indicate anything about usage; it is simply so you can identify them easily. Certain types of transit stations do not light up because of the way they were designed. A new Zones view is also included with the NAM. The new Zones view is identical to the Subway Building View, except that subway volume levels are not displayed. The new Zones view is currently optional (unlike the other data views described above, so you must select it during the NAM installation if you want to have it installed. It is strongly recommended that you use the DatPacker if you have a substantial number of plugins. This will not only speed up the loading of your game, but it will also great speed up switching back to the normal view from both the Subway Building View and the Zones View. Patch for RTMT Users If you are using RTMT, it is highly recommended that you install the latest patch, which is especially important for the NAM Simulator users. You can find the patch here. Stations originally created by @RalphaelNinja with modified reduced costs and doubled capacities: Modified Ninja Boulevard Stations.zip

You're not doing anything wrong. With Simulator Z, traffic always slows down at heavily used intersections, simulating stop lights (at least to some extent) or stop signs. This is implemented by using the intersection effect, which has always existed in SC4, but not at levels that made any difference. Unfortunately, when it is used at meaningful levels, congestion results at the affected intersections. You can see this in the way congestion shows up around the intersections. Using the Ultra version of Simulator Z will definitely reduce this effect drastically, if not completely, due to the simulator's higher capacity. Although the TSCT has been discontinued, you can still select the usual simulator capacities in the installer. As for the traffic advisor, he doesn't know about the intersection effect, so you'll just have to ignore him.

I was a little surprised you recommended the 12600K instead of the 13600K, until I looked around a bit in the Canadian stores and couldn't find the 13600K. It's still a fairly new CPU, so that's probably why it's a bit hard to find. I thought that that was why you recommended the 12600K. I agree that the 13600K is the CPU to get if you can find it at a reasonable price. Windows 11 is necessary in order to take full advantage of the features of these CPUs. @Haljackey, the "K" at the end of its name means that the CPU is unlocked, which means you can overclock it. I've been overclocking my CPUs for decades; it's not hard, and it's completely safe if you follow the directions. Overclocking essentially gives you a speed boost for free, something that comes in handy while you're waiting for the NAM traffic simulator to run. If this interests you and you get the 12600K CPU, you'll need to get a motherboard with the Z690 chipset (such as the one I recommended), as that's the only series that supports overclocking. If you get the 13600K CPU, you can either get a Z690-based motherboard (which would require a simple BIOS update) or a Z790-based motherboard; either would work fine for you. As for a basic summary of the difference in Intel chipsets (i.e., Z-series vs. B-series vs. H-series), I'd recommend the Intel document How to Choose a Gaming Motherboard. This document also contains useful information about a variety of motherboard basics. I should have figured that if anyone had a bigger monitor setup than me, it would be you... An ultrawide monitor might be the perfect upgrade from your setup, especially since these go all the way up to 49". Many of these come in 1440p resolutions, but some of them also offer 5120 widths. This is twice the width of my monitor, so it's perfect for someone used to having two monitors. The common term for these monitors is "double QHD". Here are the command line arguments I use for my copy of SC4: -CustomResolution:enabled -r2560x1440x32 -f -Intro:off -CPUCount:1 -d:DirectX All of these options (except the -Intro:off) are necessary to get the display to work properly at 2560x1440. If your display doesn't work properly with these arguments, you probably need a better graphics card. This has always been true. The DatPacker program, available on the LEX, can eliminate the majority of these delays.

I think the most meaningful upgrade you can make that will enhance your whole SC4 experience is to get a 32" QHD (2560x1440) monitor. I've had my current one for five years, and there's no comparison to my old 24" monitor. SC4 will run at that resolution out of the box (it's the highest resolution that will work without a wrapper), and you just get to see a lot more real estate at a reasonable size, with no display lag. I'm partial to HP monitors, as I find they tend to offer the best price/performance, and you can get essentially the same monitor I have: HP 32-inch 165Hz QHD HDR at Amazon. At CA$441 it's not exactly a bargain, though; this same monitor has been on sale in the US recently for as low as $165. I'd recommend waiting for the upcoming sales. You can recoup a lot the cost of this monitor by cutting back on the video card in Shadow Assassin's recommendation, which is way overkill if you're just playing SC4. I got a Radeon RX 570 for a little over $100 a few years ago, and it drives my monitor flawlessly. Prices are higher today, but you can still get a ASUS Dual AMD Radeon RX 6500 XT OC Edition 4GB GDDR6 Gaming Graphics Card for $241; this is also a newer generation. The CPU that SA selects seems to be the best balance between affordability and power available right now, at least in Canada. The B660 chipset motherboards aren't really the best for gaming. Instead, I'd recommend the ASUS TUF Gaming Z690-Plus Wi-Fi D4 ATX LGA 1700 Motherboard at the same price. As for memory, you can get the excellent Corsair Vengeance RGB DDR5 32GB (2x16GB) 5200MHz C40 Intel Optimized Desktop Memory, which should be at least as good as G.Skills, and save over $100 in the process. The other items look reasonable to me, although with the exception of the SSD, I haven't looked into them in detail. If you add up all the changes I suggested, your total price should be about the same, plus you get the nifty 32" monitor in the deal.

Your version of SC4 is the latest and should be completely compatible with the NAM. Why you're having these problems is a mystery, but rest assured that the NAM Team is looking into this.

Some traffic congestion with the Low traffic simulator at these population levels is normal, and should not cause a problem. If you think there is too much congestion for your taste, try a higher capacity simulator. You have to reinstall the NAM to do this. When you install the NAM, you are given the choice of different capacity simulators. In order of increasing capacity, these are Classic, Low, Medium, High, and Ultra. The Low capacity simulator is recommended for most people. Generally, cities don't need additional parking, as there is implied parking at all commercial and industrial buildings. Adding parking to a city will generally have no effect in the way that the city runs. RTMT is by far the most comprehensive solution here. You will need the base pack ROAD TOP MASS TRANSIT as well as the add-on pack RTMT Add-On Pack V3.60 . RTMT v4.0 should be coming out in the next few months; this contains a lot more stations, and it is considerably easier to install.

I notice that you're running the Classic capacity simulator. I would strongly recommend upgrading to Low. As an alternative, you could build up your subway network. Your usage and congestion are not at all unusual for your population level using the Classic simulator. I was able to create a city with 4.129 million Sims with this simulator. It worked fine, but everything was congested, even with a huge subway network.

Transit Switch Entry Costs and Station Capacities Transit switch entry costs and transit station capacities are two very important properties of virtually every transit building exemplar, yet for many years their optimal settings have been poorly understood. This post attempts to clarify their usage, so that builders or modders of transit stations can use the correct values for these properties. These values have been optimized for the current NAM Traffic Simulator ("Simulator Z"), which has been in use since 2009. The values listed in this post have been adopted by the BSC in the PIM-X tool; the Transit Switch Entry Costs are currently implemented in the tool for stations serving a single travel type. If you just want the numbers to use for these properties, it's not necessary to read this entire post; the numbers for the Transit Switch Entry Costs are grouped together in this section, and the formulas for calculating station capacities are near the very end of this post. The intervening material explains why the numbers and formulas are set to what they are. If you're not sure which number(s) should be used for a particular station, the explanatory material should make it clear. I'll first discuss the Transit Switch Entry Costs, since this issue is a bit simpler. Setting the Transit Switch Entry Cost to the proper value is very important. If it is set too low, then pedestrians and possibly other travel types may cut across the lot, leading to what is commonly known as "shortcutting"; the travel time of the station's main travel type(s) is also distorted if the network travels through the station. (This last point does not apply to subways, which work differently from everything else.) If the Transit Switch Entry Cost is set too high, the result can be even worse, as after a certain point Sims may not use the station at all, and in some cases the entire transit line may become abandoned. The cause of these problems may be very difficult to detect, and for the average user, it may appear that the traffic simulator or some other aspect of the game is malfunctioning. What exactly is the Transit Switch Entry Cost? It's the inverse of the speed in kilometers per hour for the referenced travel type. The game is designed so that it works best when the Transit Switch Entry Cost (TSEC) for a particular travel type allows that travel type to move through a transit-enabled (TE) lot at the same speed that the travel type would travel at on the embedded network. Based on this, and using the speeds for travel types found in the NAM Traffic Simulator, the proper TSECs for various transit stations are as follows: Pedestrians and bus stops: .067 Street stations (RTMT): .04 Road and avenue stations (RTMT): .022 One-way Road Stations (RTMT): .015 Bus stations (road passing through): Use value for appropriate RTMT station above Underground garages: .022 Above-ground parking lots and garages: .067 Highway stations: .0067 Subway stations: .0095 Freight rail stations: .0095 El rail and GLR stations: .0087 Passenger rail stations: .0071 Monorail, HSR, and Bullet Train stations: .0044 Stations adjacent to networks that do not run close together: TSEC of slowest network* Stations adjacent to multiple networks that intersect or run close together: TSEC of fastest network** *Note: "Close together" means no more than two squares between networks. If one of these networks allows only pedestrian access (i.e., there is no bus stop or car parking on the station), then the TSEC should be 0.067. **Note: In the case of adjacent stations, if the station is able to handle more than one network type running next to it, the TSEC should never be higher than the TSEC for passenger rail. Bus stops have the same TSEC as pedestrians because buses don't actually drive through bus stops (although this is different for RTMT). However, pedestrians walk through bus stops, so the TSEC is set for their speed. Diagonal stations use the same TSEC values as their orthogonal counterparts, since in SC4 there is no real diagonal travel; it is all orthogonal. The above values are incorporated into the current version of the PIM-X tool (SC4 PIM), specifically in the current version of the SC4PIM New Properties XML Update. However, transit stations that service multiple travel types in addition to pedestrians must have their TSEC set manually. For such stations, the following rule should be used; this rule covers all situations: The formula for the transit switch entry cost for any station is 1/speed, where "speed" is the speed of the fastest travel type that is designed to pass completely through the station at normal speed (excluding subways). If the travel type passes next to the station instead of going through it or if there is no through travel type (such as for stations that are adjacent to their networks or for parking lots), the pedestrian speed should be used in that formula. Note that network enabled lots are handled differently from transit enabled lots. The TSEC of a network enabled lot is 1/speed, where "speed" is the speed of the fastest network passing through the lot. Some lots contain a mixture of both through networks and networks that contain transit stops. These lots should be treated as transit enabled lots, and the proper TSEC will be the lowest of the TSEC for the networks that pass through the lot and the TSEC for the transit enabled networks. The lot capacity will be the total of the standard TE lot capacity plus the network lot capacity as described below. Note that the formulas for calculating TSECs and capacities are the same whether you are using pass-through lots or terminal lots. Now on to capacities. First I'll give the rationale, and then the various capacities and formulae. If you just want to see the latter, you can just skip to the end of the post. The way the game is presented to us, transit stations appear to act much like networks. They have fixed capacities, and when these capacities are exceeded, transit stations appear to suffer their own form of congestion - their "service quality" declines. Transit stations are even shown in the Traffic Congestion Data View. When their usage is no more than 100%, they're is shown as green, just like networks, but as their usage passes 100% and their service quality declines, their color goes from green to yellow to orange to red - again, just like networks. We are led to believe that a transit stations at 300% capacity, which shows up as bright red in the congestion data view, is performing quite poorly compared to one operating at, say, 30% of capacity. This is all completely false, and Maxis knew it. A station running at 300% of capacity has the same "service quality" as a station running at 30% of capacity; they operate identically. Maxis actually could have implemented such a service quality approach fairly easily, by multiplying the Transit Switch Entry Cost by the inverse of the Congestion vs Speed curve. But as we know, they didn't, and in fact the TSEC is used by Maxis only for toll booths. If this were the whole story, nothing would need to be done here; the current capacities could be used for transit stations, and though their "service quality" would be displayed inaccurately, no harm would be done. But it's been know for a number of years by some players that there's a maximum number of Sims that a transit station will process in a day. However, the numbers reported for this limited varied, although they were always a certain multiple of the station's capacity. Two years ago, I set out to verify that such a number existed, and if it did, to find out what it was; RippleJet later joined me in these experiments, and Tarkus participated in the thread where the results were presented in depth. Although I verified that the limit existed, I did so mostly in trivial cases. RippleJet's experiments were the first to use realistic station capacities. His results can be found in this post. Some of my experiments showed slightly different aspects of the problem; one of the more interesting ones can be found in this post. Between these experiments and others that preceded and followed them, the following facts were determined: All stations have a fixed capacity that is some multiple of their nominal capacity. Until this fixed capacity is reached, they suffer no performance degradation; they are completely unaffected by high usage, even when it's well over 100%. Once the fixed capacity is reached, however, the stations simply stop working for the day. No more Sims are permitted through the stations via any network. The stations are effectively broken for the rest of the day. What is this fixed capacity? Different experiments have yielded different numbers, as have different in-game situations. The maximum capacity found by RippleJet's experiments was 400% of the nominal capacity, and although this number has been seen in various other situations since then, no lower maximum has been reported. Somewhat higher maximums have been reported for specific stations, but no pattern has been observed. Occasionally people report much higher maximums, but for standard stations, this seems to be due to the fact that the traffic simulator will let as many Sims who want to use the station use it the first time, and only in subsequent runs will it scale back the station usage. This is in keeping with other known behaviors of the traffic simulator. If a station breaks at 400% of its nominal capacity, we clearly don't want that to happen; that doesn't correspond to any RL event, and is essentially just a bug. Therefore, we need to set station capacities high enough so that their usage never exceeds 400% of their nominal capacity. How high is that? In other words, what's the maximum amount of traffic that can be expected through a station? Below is an example of a station in an ordinary city; this city was not designed to test station capacities, but merely provides a good example: The station is mostly hidden by the query; it is a combination bus and tram station for tram-in-road, and you can see a bit of the tram shelter sticking out just past the number 980. You'll also notice that for RTMT and NAM stations, "Service quality" has been renamed "Reserve Capacity," since a reduction in this graphic does not imply a reduction of service quality at the station, even in circumstances such as these. One of the things that's interesting here is that this is no megalopolis; the population here is only around 150,000. When you figure that about half of that is the city's workforce, and the query includes both commute periods, you see that almost the entire workforce of this city is going through this station. Looking closely at the picture, it's easy to see why; this station gives access to the rail station, which is the main (and fastest) connection between residences and jobs. If we were to do a straight extrapolation here, we would come to the conclusion that in order to support cities containing millions of Sims, seven-figure station capacities would be necessary. But situations such as this don't arise in such cities (fortunately), as their increased density tends to greatly increase the number of ways for Sims to get from their homes to their jobs. In reality, the station above is the most heavily used station I have ever seen. I think that we would be safe in saying that no station would need a capacity of more than 200,000; if one did, there would be larger variants available, or multiple stations could be used. Now we're ready to look at which capacities we should actually use. There are three basic approaches here. For the first one, if 200,000 is really a safe capacity for virtually all stations, and the true capacity is at least 400% of the nominal capacity, then we could simply use the following rule for nominal capacities: All Stations: 50,000 From the point of view of game play, this would work out a lot better than the current capacity system. The Maxis bus station has a capacity of 1000 and the Maxis subway station has a capacity of 2000, yet it is not at all unusual to see five-figure usage numbers for these types of stations. This means that stations with capacities set this low, or even in this range, are going to break frequently. Players may not notice the details of this type of breakage, but they do notice the red in their congestion maps, and undoubtedly the single biggest complaint players have about transit stations is that their capacities are too low. When a subway line has a capacity of 30,000 (as in the High version of the NAM traffic simulator), and players have erected blocks of buildings where each building houses thousands of Sims, then a subway station every few blocks (which is much more frequent than in real cities) with a capacity of a few thousand just isn't going to cut it; a single tall residence could saturate such a station. The Maxis transit stations simply were not built with today's custom content in mind, and they and other stations with similar capacities simply do not function well at all in that environment. On the other hand, a single capacity for every type of transit station simply doesn't look good. Eye candy is not a bad thing; a BATter's job is to create beautiful eye candy. So in this case, it looks a lot better if we create numerical eye candy - capacities that are sufficient for each type of station, but which don't get exceeded, so that the station doesn't break. This also allows us to use capacities lower than 50,000 for many types of stations, because many types of stations will never approach that usage level. The question at this point then becomes: What capacities should we use? In terms of game play, the capacity required for a particular type of station bears very little relationship to the size of the station. So for this purpose, we just need to know what the minimum capacity should be for a given type of station. When I first started looking at the issue of station capacities more than two years ago, one guideline I kept in mind was that in RL, stations rarely get congested before the networks they serve. The reason for this is that it is much easier and cheaper to overbuild a station than to overbuild an entire network. But what formula should be used for determining these station capacities? There have been many formulas proposed, but I found that none of them gave satisfactory results. I think that the reason for this is that all the formulas I saw had station capacities increase linearly with the capacities of the networks that they served, while what I was seeing was that the proper growth curve was more of a logarithmic one. I found that the formula used in RTMT by Cogeo produced capacities that seemed to come closest to actual usage needs, although being basically a linear formula, it produced numbers that were about right on the high end for complex stations, but were too low on the low end for simple stations. I found that by doubling the low end numbers, leaving the high end numbers the same, and adjusting the numbers in the middle accordingly, I got capacities that worked extremely well. As Simulator Z had not been built yet, this was all done using the CAM traffic simulator, which had capacities approximately the same as the High version of the current NAM traffic simulator. Yet these station capacities still work fine today; the only change I've made is to reduce the bus capacity somewhat, since the potential volume of buses has been limited because buses now contribute to traffic congestion, whereas they didn't in the original Maxis traffic simulator. The question may be raised at this point as to whether the capacities used for RTMT stations, and inline stations in general, are valid for all stations, since station usage for these two classes of stations includes all through traffic. I have found the answer to be a clear "Yes." The reason for this answer is that SC4 traffic does not behave the same as real world traffic; much of the differences can ultimately be pinpointed to the fact that most travel distances in SC4 are much shorter than in the real world. As a result, for example, instead of taking a train for at least several kilometers, Sims tend to travel much shorter distances. This means that virtually the entire traffic of a train line may enter or exit at a single stop, and this may happen at multiple stations along the train line. For such stations, there really is no difference between through traffic and traffic that enters or exits the line at that station. For buses, the situation is slightly different, but the ratio of cars to buses varies so greatly on any given road that I have found that here too, an RTMT-type bus stop requires the same capacity as a roadside bus stop. Based on all of this, and on extensive experience with RTMT and traffic simulator experiments, the following base capacities for transit stations are recommended. Where these transit stations are supported by RTMT, these are the RTMT capacities. Bus: 17,000 Subway: 24,000 Freight train: 15,000 Passenger train: 45,000 El rail: 45,000 Monorail: 45,000 Parking facility: 30,000 The astute reader will notice that all of these capacities are lower than the 50,000 mentioned earlier; the reason for this is that each of these stations handles just a single travel type, whereas the 50,000 is designed for a broader range of stations. The type of differentiation in the above table certainly seems better than the one-size-fits-all figure of 50,000, but it still makes no differentiation between different sizes of stations, nor does it account for stations that handle multiple travel types. Originally, while accounting for this in the stations that I use and have modified, I had been doing this on a somewhat ad hoc basis, ending up with something that seemed about right. In order to be more systematic, I have come up with formulas that produce numbers very close to those that I have been using; these are the formulas that PIM-X will be using to produce reasonable station capacities for any type of station. Unlike the TSEC, there is no "exact" correct capacity, so some rounding can be done by the developer. For example, I had been using a capacity of 50,000 for the Maxis Grand Railroad Station; the formula that follows yields 51,000, but this is one of those cases where rounding off (in this case to 50,000) just looks nicer. The formulas I have devised for station capacities follow. For stations with buildings, only the first floor of the building is used in calculating the station's capacity, as additional floors are generally not used for passenger waiting space. Another point to consider in these formulas is that the bigger the station is, the less distance the Sims have to walk to get to any part of it. Since the whole station is fairly monolithic as far as the traffic simulator is concerned, bigger stations therefore do serve more Sims, though not by all that much. Here are the formulas. Note that in the case of overhanging buildings, all tiles beneath the overhanging building are considered part of the lot for these calculations. Bus stops and stations: 17,000 for the first tile, plus 1000 for every additional tile on the lot. Large bus stops may not have buildings as such, which is why the tile count of the lot is used. Subway and Other Underground Rail Stations: 24,000 for the first tile, plus 2000 for each additional tile in the lot. This time, we're talking about the lot instead of the building due to the underground nature of these networks. Passenger train (may include freight): 15,000 per tile for the first three tiles of track served by the station, plus 3000 for each additional tile. For stations serving multiple tracks, additional tracks are counted at the rate of 5000 for the first tile plus 2000 for each additional tile. If the tracks are sidings and not through tracks, such as in the Maxis Grand Railroad Station, each tile of siding is counted at 1000 per tile. Buildings attached to train stations also add 1000 per tile per floor. Freight train only: 10,000 per tile for the first three tiles of track, plus 2000 per tile after that. Sidings add another 1000 per tile. Nothing is added for the size of the lot; freight lots tend to contain all sorts of things, most of which just sit there forever. Also, the size of the lot is somewhat proportional to the number of tiles of track served, so it's implicitly counted to some extent. El rail: Same formula as for passenger rail. El rail over road: Same formula as for passenger rail, but with an extra 12,000 added to cover road through traffic. El rail over avenue: Same formula as for passenger rail, but with an extra 24,000 added to cover avenue through traffic. Monorail, HSR, and Bullet Train: Same formula as for passenger rail.. Parking facilities: 1000 per tile. For multi-level garages, only the tiles containing the garage count, and their number is multiplied by the number of levels of the garage. Underground garages have a flat capacity of 50,000, since they don't have any real dimensions. Network enabled lots: These are lots that allow network traffic to pass through them, but do not permit any transitions with the lot. Therefore, these lots are not actually transit stations, although they are constructed according to the rules used for transit stations. The capacity of a network enabled lot is the sum of all the individual networks (including networks of the same type) entering the lot. Multiple networks: There are also rules for combining these basic types. For example, adding a parking facility adds the standard 1000 per tile for the parking lot; if it's a garage, the standard garage rule applies. The one exception here is a parking lot added to a subway station, as it implies a bigger station. In this case, it's 2000 per tile of parking lot; for a garage, it's 2000 per tile for the first level, but the standard 1000 per tile for additional levels. Adding an underground garage to a station adds 15,000 to its capacity. If the station serves multiple networks, the basic rules are used for the highest capacity network. After that, for additional rail types, 10,000 is added for the first tile of the first rail line, and 2000 is added for each additional tile. (For subways, the total length of all the above-ground rail lines in the station is counted.) For buses, 4000 is added for the first tile of the rail line, and 500 is added for each additional rail tile. Sidings and buildings are not counted here; they've been counted once, and that's enough. Finally, always round off the capacities to the nearest thousand, and if they're over 50,000, round them off to the nearest 5000. The capacity formulas aren't exact, nor do they need to be. That should cover it. Although the station capacities produced by these rules are large, they are just large enough to assure that stations won't break under any but the most extreme usage. They also produce station capacities that rise nicely with station size and layout. Finally, they happen to produce capacities very close to the ones that have been used all along in many test cities going back several years, and which work very well in a wide variety of situations.

The first post of this thread has been updated with more accurate values for the TSECs. The new values are within 4% of the old values, so it's not essential that current stations be updated, as the effect of the new values are minimal. However, if you are building new stations, please use the new values.

This is true only for stations that support large numbers of networks (typically more than three) passing through them. For other types of stations, the HSRP transit switches will either be excessive, will reduce the functionality of the station, or simply will not work properly. To find the correct TE switches for a given station, find the NAM station that most resembles it and copy the TE switches from the NAM station, adjusting them if necessary. Paying attention to the number of networks supported by the station is key, as is whether the station has networks passing through them or just adjacent to them. In the latter case, the BriPizza stations work as an excellent template. (Note: When I say "networks passing through them" (the TE lots), this is technically not correct, as networks don't pass through lots. But it appears as if they do, and this terminology is fairly intuitive.)

Before NAM 43, there had been no modifications to the traffic simulator for many years. The modifications to the traffic simulator in NAM 43 (which I gather was not where your problem occurred) were merely minor bug fixes. @gviper, the behavior you describe sounds like that of the old Maxis traffic simulator. The only way you would get such a simulator in your game would be if you accidentally deleted the NAM traffic simulator. In your Network Addon Mod folder, there should be a subfolder named "9 Traffic Simulator", and this subfolder should contain the traffic simulator and the traffic data volume view. If it doesn't, please try reinstalling the NAM, and then checking that folder again.

@The Angry Convert The log file is very useful; it is telling you that the TSCT can't find your traffic simulator files. You are indeed running an older version of the NAM, and it appears that that is what is causing your problem. If you look in the main Traffic Simulator Configuration Tool folder, you will find a subfolder named "data". Inside this subfolder is a file named "TSCT.conf". You need to edit this file. Depending on which version of the TSCT you have, there will be a couple of lines that reads something like: # pathTS is the path to the TrafficSimulator pathTS=C:\Users\Name\Documents\SimCity 4\Plugins\Network Addon Mod\9 Traffic Simulator You need to replace the part of the line following the "pathTS=" portion with the actual path to the folder containing your traffic simulator. In your case, this path would end in the string "Dokument\SimCity 4\Plugins\Network Addon Mod". Once you do this, save the file, and everything should work.

Yes. You need to have the NAM installed, and then you need to use one of the Subway to Underground Rail Connector (SURC) pieces that exist at the bottom of the Misc Transit menu.

I found out why I couldn't fix my prop pox. This particular city also suffered from two versions of the phantom slider bug - one in which the sliders of all the police stations would gradually drop to zero (along with their coverage), and one in which the health facilities didn't have their individual sliders drop, but the global slider dropped over time. This led to complaints that my health facilities were underfunded, even though the individual facilities had sufficient funding and coverage. As the way I got to this situation was a bit different from the standard way of generating phantom slider problems, I had to generate my own solution, which was actually a bit simpler than most solutions for dealing with these problems. Once the phantom slider problems were fixed, the standard fix for the prop pox worked, and the city has been running completely healthy for many decades now. From my experience, both here and in one other case, it appears that the phantom sliders can affect the prop pox. In cities where both problems are present, fixing the phantom sliders first and then the prop pox should end up fixing both problems permanently.

I guess that's me... 1. z 2. Male 3. Pisces I'm adding a BMP-formatted square icon just in case that works better than what you've got. z.bmp

Actually, transit stations suffer no inefficiency when they go over 100%. It's only when they reach at least 400% that they suffer, and at that point they simply stop working. I investigated this when I noticed, as Naomi did similarly, that I had transit stations running at well over 100% capacity without any problems. So I decided to do some testing. The 400% level is only a minimum, and varies by station; some stations function fine until they reach 600% of nominal capacity, and sometimes even more. The cutoff level is definitely affected by station capacity. For example, a station with a capacity of 1 will accept up to about 100 Sims (10,000% of nominal capacity), then suddenly stop functioning. Although it is commonly believed that these stations simply shut down for the rest of the day, it's more complicated than that. The stations remain shut down until the traffic simulator routes less than the maximum amount of traffic through them. This tends to happen on the next traffic simulator run, as nonfunctioning stations make the route that contains them very unattractive to the traffic simulator. But the traffic simulator will run no more often than monthly, so stations that are over functional capacity tend to remain that way for at least a while. Once the stations reopen, the traffic simulator notices this, and starts sending lots of Sims through them. This tends to quickly overload the station once again, and this cycle may repeat many times.

On another note, I thought I'd describe what I have found most useful in eliminating the Eternal Commuter Loop from my cities. You have undoubtedly noticed that when these loops occur, they do so near the corners of cities, so as to minimize the commute distance in any given city. Basically, simply severing all connections in that corner of two of the connecting cities seems to do the trick nicely. It takes some trial and error to see how far connections need to be severed, but I have found with my cities that about one half of a large tile always does it. (The exact amount depends on suitable job availability and location in the city.) Of course, this means if you have an Eternal Commuter Loop involving only medium or small city tiles, you may have to sever all connections between a pair of them. Trying to dissuade the Sims from proceeding to the outbound neighbor connection once they have entered the city from an inbound connection is useless. As has been noted here, toll booths or similar obstacles don't work; that was the first thing I tried. I also tried gradually eliminating the paths connecting the inbound and outbound neighbor connections; this didn't work either. The Sims would simply take longer and longer detours until they finally reached the outbound connection. I once saw a huge stream of them travel a quarter of a large tile in the exact opposite direction from the outbound connection, turn around at the first opportunity, and then backtrack a full half tile until they reached the outbound neighbor connection. They traveled right by lots of attractive jobs on their detour without even blinking. The Sims can be extraordinarily clever here, too. For example, I once saw huge numbers of Sims coming in by bus. I broke all the road connections to the neighbor destination, but that didn't stop them. They found an entrance to the el train system and took an incredibly convoluted route that I didn't even realize was possible until they had crossed my firewall. For the last leg of their trip, they switched back to buses, and then they were gone. Their behavior can be understood when you realize that the simulator's destination finder runs before the pathfinder. The destination finder looks for the closest suitable destination taking only the direct distance into account. (It's actually a bit more complicated than that, but that's a good approximation.) Once the destination finder has identified the outgoing neighbor connection as the closest suitable destination, that's where the Sims are going, as long as they can reach it at all. The only way to stop this loop once the Sims have entered the city is to have lots of appropriate jobs waiting for them in a location that is closer than the outbound neighbor connection.

A note about commute times and the commute time graph... In the original game, the maximum commute time was six minutes. Six minutes! Yet the Prima Guide says that it's 2.5 hours. What happened? Well, six minutes sounded ridiculously slow, so Maxis simply multiplied it by 25. That's where the 2.5 hours came from. For the NAM traffic simulator, I decided to add some realism, at least in terms of showing what the game was really doing. So I had all commute times scaled way down. Now if you look in the traffic simulator, you'll see a property named "Trip Length to Minutes Display Multiplier" whose value is 25 in the original Maxis traffic simulator. So you might think, "Aha! This is where the commute time is multiplied by 25! All I have to do is set it to one." But setting this property to one does not change the commute time displayed. As far as I can tell, it does nothing at all. My guess is that Maxis originally intended to use this property for the implied purpose, but later decided to move its function to the Commute Time Graph, where it currently resides. In the Commute Time Graph, there is a property named "Graph Data Value Adjuster". You might expect it to be set to .04 in the NAM traffic simulator, in order to just offset the multiplier of 25 that Maxis uses. Unfortunately, things are not all that straightforward. If a city has no neighbor connections, then indeed, a value of .04 would result in the actual commute time being displayed in the graph. However, neighbor connections raise commute time. The game has no idea how much time a Sim will need to spend commuting in a neighboring city, so instead it uses a simple formula (the exact parameters of which have not been determined as of this writing) whereby the higher the proportion of the city's workers who commute to neighboring cities is, the higher the citywide commute time. For cities with lots of commuters, this can easily raise the average commute time to unrealistically high values of many, many hours. (Keep in mind that the commute time is the one-way commute time.) To avoid that, and to take into account that the vast majority of cities have at least some neighbor connections, I set the Graph Data Value Adjuster property to .015 instead of .04. This generally works out rather well. However, in cities with very little or no neighbor traffic, the value shown in the Commute Time Graph will be too low; in cities with large amounts of neighbor traffic, the value shown in the Commute Time Graph will be too high. What this effectively means is that the value shown in the Commute Time Graph will never be exactly correct. It may be off by a little, or off by a lot. It is most accurate when applied to an "average" city. So in the city shown in the last post on the previous page (#30), the average commute time is not a little over an hour. In fact, we have no idea what it really is. Neither does the game; it can't, since a lot of commuting happens outside the current tile. Similarly, for the graph shown in post #33 above, the average commute time is not 20 minutes. All we can say is that the proportion of Sims commuting to neighboring cities is smaller than it is in the case where the graph displayed 60 minutes. For these reasons, the value displayed by the Commute Time Graph is useful only when compared to other values. And an increasing commute time is not necessarily bad; it may simply mean that more Sims are commuting to other cities, which is usually a positive thing. In general, commute times that occur entirely within a single city are almost always in the single digits and are often in the low single digits, even on a large tile. Any number in the double digits or higher usually implies at least some neighbor traffic. The one time that the Commute Time Graph can be used to get an accurate commute time is if you are playing a city that has no neighbor connections. In such a case, if you take the value in the commute time graph and multiply it by 2.67, you will get the actual average commute time in minutes for your city.

Recently, the problem with phantom sliders has been mentioned in a number of posts. This problem occurs when you have lots containing sliders (typically civic lots), and you plop a lot that has the identical ID as an existing one, except that it has a different capacity or funding level. Depending on which direction things have been changed, over a period of months the sliders on all buildings of that category (for example, all education buildings) will slowly creep up or down, until they are stuck at either the maximum or at zero. Resetting the sliders helps only temporarily. This can be fatal to a city, either bankrupting it when all the sliders hit their maximum, or denying it a crucial service when all the sliders hit zero. Fortunately, and contrary to what many people believe, this problem can always be fixed. If you have plopped just a single building that triggers the phantom slider bug, the fix is simple: Simply remove that building. If you're not sure which building it is, you can try removing various buildings until the phantom slider bug goes away. Once it goes away, it doesn't come back unless you plop another conflicting building. If you want to use the settings of the new building that caused the phantom sliders, then bulldoze all occurrences of that building (new and old) in your city. Then run the game for a couple of months, verifying that the phantom slider bug is gone. At that point, you can plop either the new or old version of the building (but not both!), and the phantom slider bug will not return. For the case of a single building that's causing the phantom sliders, this fix will work even years after you plopped the building. This is the most common case. What is happening here is that the game keeps a record, updated frequently, of each type of building and what the costs and capacities of that building are. It uses the sum of the resulting cost figures to compute the total budget for the category. However, the game cannot keep track of a building type that has two different costs or capacities, so it uses only one of them. As a result, the total budget for a category is different from the actual total costs of all the buildings in that category. The game notices this, and tries to fix it by raising or lowering the funding for all the buildings in the category. But like a dog chasing its tail, this just moves the problem to another level, and the next time around, the game ends up having to make the same type of fix in the same direction. This continues until the slider reaches one end or the other of its range. Occasionally, this problem cannot be resolved by removing the offending building. The circumstances under which this happens are not completely clear, but it appears likely that this happens when two or more buildings that trigger phantom sliders are present in the same city. The game appears to calculate total costs incrementally, which makes sense from a computational point of view. However, that leaves it vulnerable to becoming completely confused if multiple buildings that cause the phantom slider are placed. In such a case, removing all the offending buildings doesn't help, as the game's basis for computing the costs of that whole category have been corrupted. Not only does removing all instances of the offending buildings not help, but removing all custom buildings of that category doesn't help. It's at this point that many people give up and nuke their city. However, this is not necessary; the city can be saved, although it requires a bit of effort. First, be sure you have the loaded. Then delete all the buildings of the affected category. For example, if your schools were showing phantom sliders, you would have to delete all schools, universities, museums, libraries, and any other building that is classified as educational. Fortunately, you can see where each one of these buildings is located in the Education Data View. Before deleting each building, use the TerrainQuery cheat to find its location. Write this down, along with the type of building you're deleting. When you've deleted all the buildings in the relevant category, the corresponding Data View will be completely empty of all green dots and circles. And your Phantom Slider problem will be gone. Why? Once you've deleted everything, the game notices that there are no buildings in this category, and therefore no capacities and no expenses. This conflicts with its internal data, but since its internal data is calculated, it merely resets it. So this reset effectively undoes the cause of the phantom sliders. You should run the game a couple of months or so to give it time to notice that the entire category of buildings is gone, but then you can start replacing your buildings. As long as all buildings you plop of the same type have the same capacities and costs, the phantom slider bug should not return. Update (9/28/21): It turns out that there are many cases where the fixes above are not sufficient to remove a Phantom Slider bug. These appear to all involve multiple buildings of the same class (such as all education buildings, for example). @CorinaMarie has written an excellent post detailing how to fix the bug in these cases. If you have a Phantom Slider bug that involves more than one building, or that does not go away easily, I recommend that you go straight to the method described in her post.

Which lot would this happen to be?

That sounds good to me. What's the best way to proceed?

Like everyone else, I am thrilled by the fixes offered by this patch. However, once I installed it, I found that it did not in fact fix my poxed city. I followed the directions on the download page multiple times, very carefully each time. Each time, the problem would be temporarily fixed, but the next time I opened the city, it was back. This city was one of the first to be identified as poxed, and I had many people from the BSC Team working with me to try to fix it. It's clear that it's a classically poxed city. Any suggestions?

I've attached a file containing a large number of hard-to-find codes for things such as the Occupant Types and many, many other codes that are used throughout the game. This should save people a lot of time figuring out what they are. Just jump to "Occupant Types" in this file to see them all listed. Building and Prop Exemplar Codes.txt