• Welcome to SC4 Devotion Forum Archives.

TE Lots, Transit Switches, and You :)

Started by mott, October 25, 2007, 02:47:59 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


Interesting thread here.

Should I take this thread as an advice to start sifting through all the custom TE enabled lots and mass transit stations I have and adjust the transit switch cost? I took a quick look they are most with 0 value.

What would be the recommended or minimum value? I see numbers from 0.02 to 0.1 to 3 these are huge differences.  ()what()

Is this also the cause of stations getting over loaded even when placed close to one another?

How about roadtops are they safe to use?


Quote from: soulstealer on March 13, 2008, 02:07:36 AM
Interesting thread here.

Should I take this thread as an advice to start sifting through all the custom TE enabled lots and mass transit stations I have and adjust the transit switch cost? I took a quick look they are most with 0 value.

What would be the recommended or minimum value? I see numbers from 0.02 to 0.1 to 3 these are huge differences.  ()what()

Is this also the cause of stations getting over loaded even when placed close to one another?

How about roadtops are they safe to use?

You may if you want go through your selection of custom TE Lots.  You are right at most of them being set to 0 which is bad, noone ever really understood the Traffic Switch Cost before but now we know alot more about it.  If you feel comfortable chaning the values I would suggest that you use a simple calculation, which is:

(Lets use a 3x4 lot as an example)
1.)  Square the Length and Square the Width of the lot and add them together.  (for example this would be 3^2 + 4^2 or 9+16=25)
2.)  Take the Square Root of the total.  (for the example sqrt 25 = 5)
3.)  Multiply that value by 0.029 this is the time for a bus to cross a tile on a Street which is the slowest Traffic Type other than Pedestrians and this will prevent any shortcuts by any traffic types other than Pedestrians.  (for the example 5*0.029 = 0.145)

The reason you do the Length + Width calculation first is so that you can get the diagonal distance through the lot.  This is the longest physical distance through the lot and the one you must calculate the Traffic Switch Cost for.

For Road Tops:

I am not a fan of Road Top TE Lots, they force all the traffic on the network through the Road Top TE Lot because there is no other place to go.  My suggestion would be IF you would like to use them that you use them sparingly and not on major routes of path through your city.  It would be suggested that you use them on the side roads that lead to the major routes so that you are not resetting the Commute Time Clock every block and adding thousands of new route calculations.  Beyond that I would also suggest that when using Road Top TE Lots that you leave a route for every Sim completely clear so that the Sim isnt forced to go through a TE Lot.
"You learn something new everyday."

Bringing the new horizons closer to reality.

Berethor ♦ beskhu3epnm ♦ blade2k5 ♦ dmscopio jplumbley ♦ moganite ♦ M4346 ♦ Dedgren ♦ Ennedi Shadow Assassin ♦  Tarkus ♦ wouanagaine
Street Addon Mod - SAM


I have also found that nothing can develop facing a road top TE lot. I had thought of making a set of lots that were 1x1 bus-stops, that looked like parks, with over hanging props, that looked like road top bus stops.

Look for me at ... Becca At Bat


Thanks I will go ahead and do it.

Maybe a small guide is in place for people who wants to make transit stations and for people like me with many questions.

For all lots that are just TE for the visual effect of it. I will remove the 3 transit properties.

For the rest of stations I will follow your guide lines.

Will ditch roadtops.

What about stations that are one type of traffic only, like freight station when only freight rail traffic is allowed through and no pedestrians are allowed in? I assume their cost should be left at 0 to avoid delays in commute time?

What about TE lots like the NY world trade center? It is huge so many sims will try to shortcut through it, it has an avenue running through that allows all kind of traffic on it as well as a high capacity sub station.

And last does NAM or CAM traffic plugins fix the in-game maxis mass transit stations?

Sorry for the hundred questions but I'm concerned this is one of the main causes for traffic problems, routes and station being overloaded, abandonment, eternal commuters and poor game performance.


Quote from: soulstealer on March 13, 2008, 10:22:50 AM
Maybe a small guide is in place for people who wants to make transit stations and for people like me with many questions.

Jplumbley has started to write / is writing / will finish to write such a guide... ::)

Quote from: soulstealer on March 13, 2008, 10:22:50 AM
What about stations that are one type of traffic only, like freight station when only freight rail traffic is allowed through and no pedestrians are allowed in? I assume their cost should be left at 0 to avoid delays in commute time?

In that case the freight train speed should be used when determining the entry cost.
In other words, the delay in commute time should be the same as (or incrementally higher than) going past it on rail.

Quote from: soulstealer on March 13, 2008, 10:22:50 AM
What about TE lots like the NY world trade center? It is huge so many sims will try to shortcut through it, it has an avenue running through that allows all kind of traffic on it as well as a high capacity sub station.

Honestly, yes, the World Trade Center should be checked and corrected...

Quote from: soulstealer on March 13, 2008, 10:22:50 AM
And last does NAM or CAM traffic plugins fix the in-game maxis mass transit stations?

Not yet. It has been suggested for the next NAM update though... ::)

Quote from: soulstealer on March 13, 2008, 10:22:50 AM
Sorry for the hundred questions but I'm concerned this is one of the main causes for traffic problems, routes and station being overloaded, abandonment, eternal commuters and poor game performance.

You will get at least a hundred replies to them! :thumbsup:


Quote from: soulstealer on March 13, 2008, 10:22:50 AM
What about TE lots like the NY world trade center? It is huge so many sims will try to shortcut through it, it has an avenue running through that allows all kind of traffic on it as well as a high capacity sub station.

Now you see what the problem is going to be with extra large lots.  If the Transit Switch Cost is too high, the Sims will not be able to use it because it is too high for the Maximum Commute Time.  But, if it is not calculated properly, Sims will use the lot as a short cut and reset their clocks again.  We dont want them reseting their clocks when they arent intended to.

For lot that are large such as the large Rail Stations made by Ill Tonkso, I would suggest limiting where the entry points are.  For example only allowing Pedestrian Traffic to leaving the south side of the lot and not other side, also only allow the Rail to enter on the north side of the lot.  The reason this will be a good thing is because you are now limiting the amount of distance the Sim can "jshort-cut" through the lot.  In this situation it will allow you to calculate the Transit Swicth Cost based on the length of the South side of the lot.

For example if the Rail Station is 8x12.

If you mod the Transit Switch Points properly, you will be able to calculate the Transit Switch Cost based on the 8 tile South side of the lot.  Now there are two calculations to make sure you have this right.  One for the Rail and one for the Pedestrians.

0.0067 = Speed of Traim over 1 tile
0.29 = Speed of Pedestrian over 1 tile
0.029 = Speed of Bus over 1 tile

Cost of Train = 12*0.0067 = 0.08
Cost of Pedestrian = 8*0.29 = 2.32

Therefore using this method of modding the Transit Switch Cost should be 2.32.  Or is you want to base the slowest speed by the Bus Traffic tyep which will prevent anything but Pedestrians from using the lot as a short cut it will be 0.232.

Now, what if you didnt do this special modding for the oversized lots?  Well you would have to go back to the calculation I showed before which is:

= sqrt( 8^2 + 12^2 ) * Cost
= sqrt( 64 + 144 ) * Cost
= sqrt( 308 ) * Cost
= 17.55 * Cost

Train = 0.118
Ped = 5.08
Bus = 0.508

If we based this off of the Pedestrian Traffic (best practice) this would make the Traffic Switch Cost too high because the Maximum Commute Time for the Standard MAXIS Simulator is 2 one way for Mass Transit.  If we were to use the Bus it would be 1/4 of the Trip and since you have an on/off station it will be 1/2 the Trip, leaving approximately 1 Commute Time for the Sim to get between the stations, which for Rail is approximately a 150 tile trip in length between two identical stations of this size.  With the first suggestion it allows for a Maximum trip between stations of 230 tiles instead of 150 if the Traffic Switch Cost is based on the Bus Traffic Speed.

Simulator B is essentially equal to the Standard MAXIS Simulator with general fixes and a couple options for Capacity.  Simulator A has a modified Maximum Commute Time that will allow a much larger range between stations.
"You learn something new everyday."

Bringing the new horizons closer to reality.

Berethor ♦ beskhu3epnm ♦ blade2k5 ♦ dmscopio jplumbley ♦ moganite ♦ M4346 ♦ Dedgren ♦ Ennedi Shadow Assassin ♦  Tarkus ♦ wouanagaine
Street Addon Mod - SAM


I rather liked the no-trucks lots; they were very handy to route traffic around neighborhoods that it might otherwise shortcut through.

What I don't understand is why RTMT doesn't result in more people using the buses, even if only placed on end streets (where there isn't much space to begin with).

It'd be really nice if we had more bus-transit buildings that actually looked like bus-malls and transit depots... But that's more an art thing, I suppose, but since we have access to the RTMT transit props, it shouldn't be as hard as it normally would be.



Hey JP, will we be able to do missions with these transits? and NOT timeout on us halfway through the mission?
Your Friend;
Mayor Of Steven's Point & Maxiston
(Proud To Be Cities Of Sim Nation!)


UDI missions have nothing with the entry costs and other properties do. $%Grinno$%

Their functioning through TE lots is depending on whether you have dragged the network through the lot after plopping it or not. Note however, that if you're making changes to the surrounding area (building networks, building subways, digging holes, building bridges, terraforming, etc.), you will most probably have to redrag the network through several TE lots over and over again. Whenever a UDI mission fades out in a TE station, just redrag the network and retry the mission.


Very informative article!  So, say I have a train station, 5x3, with the rail running through the middle.  With these rules of TE, does this mean that every passenger on a train that goes through the station gets "reset?"  So, does this mean that if you have ANY transit station where the transit passes through the lot, the sim gets "reset"?

Also, take the example of many of PEG's lots.  Transit does not go "through" most of them, but can go "in and then back out."  Could a car go into one of those lots and get its clock reset?

Thirdly, I have never understood the difference between TE lots and puzzle pieces.  Why do puzzle pieces not cause this problem?  Could TE lots be converted into puzzle pieces?  Are puzzle pieces even lots?

Lastly, does this mean that any MAXIS transit station with the transit running through (i.e. monorail and elevated rail stations) carry this same "clock reset" problem for the trains running through the station?

Thanks for the article; I never knew so much about how transit-enabled lots can actually harm your transit network  :o


Puzzle pieces are extensions of the existing networks. They act the same as the drawn networks, which is why the Sims' commute clocks are not reset when they go across puzzle pieces.

TE lots cannot be converted to puzzle pieces, but the individual tiles of the puzzle pieces and the existing networks can have props placed on them via T21 exemplars.

You can call me Jan, if you want to.
Pagan and Proud!


Ok - first - very good basic info for beginners (beginning/layperson modder), no-cheats-ers, etc. &apls

However, without claiming any expertise on the path finding engine, some of my short term experiments seem to contradict some of what was said.  I have, when real life permits me the time, been investigating ways and means of incorporating transit tile properties into lot definitions.

The main point I would like to express is that a proper transit switch definition(s) will allow non-switched traffic to pass through your (a.k.a. "road-top") te-lot.  Example - for freight to pass through - one needs to define an out-in of freight,freight and a in-out of freight,freight; as long as no other freight,* or *,freight definitions exist (and freight isn't trying to turn a corner - which seems to be a special case) the freight vehicles appear (maybe a little slower or a little faster) to pass through just fine.  (And for those developing more rural areas - there might be a desire to combine a freight station with a passenger station or vise-a-versa.)

(Edit: Please remember - you need both the in-out and out-in definitions - defined for two opposing sides.)

One problem that I have found is that most stations tend to force both a carrier to pedistrian and a pedistrian to carrier switch, without allowing (providing) for the carrier to carrier pass through definitions (as described above).  Even with the "free hop" lure - I have seen some (not always all) passengers pass through a station, without getting off and back on, when the proper "pass through definitions" were in place.  The flip side of this coin is that pedistrians, without another reason for avoiding a te-lot, may get on and right back off, as this is their only way to cross this improperly-te'd-lot (i.e. using the out-in of pedistrian,carrier and in-out of carrier,pedistrian definitions).

(now - back to real life - for me)

But not always the last word, for the more advanced modders, yes-cheats-ers, etc. :-\

Major (to me) concerns:

1) I do admit to not having fully investigated the hover problem with TE-Lots -
how-some-ever I have TE'd-Lots that don't have that problem -
Suggesting to me that there is a way to tie lots and RULs/SC4paths together,
or otherwise overcome the hover-problem.  (Maybe beyond the scope of this thread -)
TE-ing a lot contains two parts - the Transit Overlay (for want of a better description)
and the Transit Switch properties.

For those that consider transit-top-stations a MUST:
2) On dual (passenger and freight) purpose rail lines, I have a problem with passenger-only on-rail stations (that block freight trains - on main rail lines) and freight-only on-rail stations (that block passenger trains - on main rail lines).  Both types of (passenger and freight) trains should be able to travel your main rail lines; so for "-only stations", you need to include a requirement for a rail siding --- or --- consider allowing the other type of train through - but don't allow it to "switch" cargo (passengers or freight) in your station.  And this should translate into any other multi-purpose transit types too.


To the programmer - the transit networks/stations - may be thought of in terms of macro and micro coding, allowing the programmer to have a better grasp of just what is being done/accomplished.

(again - back to real life - for me)




I started using cogeo's Road Top Mass Transit last fall, and I immediately thought it was the best thing since NAM and CAM.  At that time I had no idea of the commuting drawbacks to RTMT lots; I really had no idea how they worked.  I just knew that they made it a lot easier to plan out my city blocks, and they made my cities look a lot more realistic as well.  (When's the last time you saw a building being torn down to put up a small bus stop in a real city?)

At the time, I was working in a large tile with a population of 3 million.  Since I liked the RTMT lots so much, I began replacing most of my standard MT stations with them.  At no point did I notice any difference in simulator run time, traffic patterns, etc.

I then went to the other cities in my region, which tended to be medium tiles with populations approaching a million.  On all straight streets and roads, I replaced every single standard MT station with an RTMT station.  In addition, I added many RTMT stations, since they took up no additional space.  Once again, I saw no noticeable performance hit when I did this.  And of course it's pretty obvious when the traffic simulator is recomputing routes in a large city, so I think any significant difference would have been quite noticeable.  I should also mention that the computer I'm using is several years old, so it's no speed demon.

I have since built many large tiles using RTMT exclusively on straight streets and roads, with stations every six squares or so.  These cities range up to two million in population.  Traffic simulator performance is fine.  The different simulators have the various issues that everyone has noticed and commented on, but these seem no different for me than for anyone else.

So after reading this thread, I now know the sordid details of what happens whenever a Sim passes through an RTMT station.  But the bottom line is that this does not seem to affect performance perceptably, and I've effectively done fairly controlled experiments using the same cities with and without these stations.  Does anyone have experience vastly different from this?  Because based on my experience, I would recommend these stations for everyone.


Quote from: jplumbley on July 16, 2008, 12:25:43 AM
One thing you probably were not looking at was how far the Sims were travelling.
Actually, I was.  And this is one of the things that I found interesting.

When I used to play vanilla SC4 RH, one of my biggest problems, especially in big cities, was commuting.  I was forever struggling to avoid having buildings being abandoned because commute time was too long.  When I installed NAM, with its better pathfinding and higher network capacities, most of these problems went away immediately.  They would still occasionally happen, but usually only when I had my zones too far apart (by Maxis standards), or when I didn't have enough jobs in the city.

When I switched over to using RTMT wherever possible, this behavior didn't change.  Commuting problems didn't get any worse, but they didn't get any better, either.  My Sims typically can't travel more than about half a dozen tiles in any direction without passing through an RTMT station.  If commute time is reset every time they pass through such a station, then they should never hit their max commute time, and they should always find a job, presuming enough jobs are available, which is something I have verified is true.  Yet this is not what happens.  If zones are close enough together, Sims find jobs.  If not, there can be mostly empty office and industrial buildings kept around by high demand, but the Sims never reach them, and I get residential buildings abandoned because commute time is too long.

After reading your excellent tutorial "Understanding the Traffic Simulator," I increased Commute Trip Maximum Time and Maximum Mass Transit Strategy Trip Length in my simulator.  The results were what I expected; Sims could now reach jobs that were much farther away.  Increasing these values also made the Eternal Commuter problem worse, as the Sims were now willing to put up with longer Eternal Commuter loops, but this is exactly what you'd expect from increasing these values.  However, none of this jibes with the idea that trip length is reset every time a Sim passes through an RTMT station.

Although I found this to be very interesting, it is still circumstantial evidence.  I later realized that there's more direct evidence that the game distinguishes between those trips through TE lots that result in network changes and those that don't.  If the game treated all trips through TE lots exactly the same, then the usage figures for transit stations would always be exactly equal to the sum of the network traffic at the station's location for all networks attached to the station.  But this is obviously not the case, and in fact, such a figure would be useless to the player.  Maxis clearly realized this, and the usage figures shown in a station query reflect only transitions from one network type to another.  So I may have a heavily used rail line, but an in-line station on that rail line may show little or no usage.  In fact, if that station serves only that rail line and pedestrians, the usage figures for that station, in my experience, will be exactly the difference between the traffic on that rail line immediately before the station and the traffic on that rail line immediately after that station.  This is as it should be.  But it implies that Maxis is deliberately filtering out from the station usage statistics all rail-to-rail transitions and all pedestrian-to-pedestrian transitions.  So if they are filtering out these transitions for the purposes of station usage, it doesn't seem unreasonable that they would filter them out when deciding which commute times to reset.  And that's what all my experience that I have described above implies that they are doing.

Does this sound reasonable to you?


I realized that there was more evidence that commute time is not being reset for same-network transitions.

I agree with you completely on the consequences of resetting the commute time.  But I don't see these consequences in my cities.  Since my Sims hit an RTMT station every six tiles or so, commute time should be a small number (although I am aware of the limitations of the scale on the commute time graph).  But even more important than the actual number, commute time should be invariant, whether my city is small or large, since the distance between my RTMT stations is constant from day one.

But this is not at all what I see.

I just took a look at a commute time graph for a typical large tile city, built over several hundred years.  I tend to build my cities in chunks, often about six chunks for a large tile.  So the city starts small and gradually grows in area, with growth coming in spurts.  The interesting thing is the way you can see this reflected in the commute time graph.  Commute time starts at about 20, gradually rises for a while, then plateaus.  After a while it rises again, then plateaus again.  Finally, it tops out around 90.  This is exactly what I'd expect - as the city grows, Sims are able to get jobs farther from their homes, and when they occasionally change jobs, they're also free to get jobs that are farther away.  Eventually, the city fills up and an equilibrium is reached.  But I can't see this as being consistent with commute time being reset with every trip through an RTMT station, nor does it match your description of the commute time graph under these circumstances.


Quote from: z on July 16, 2008, 02:36:42 PM
In fact, if that station serves only that rail line and pedestrians, the usage figures for that station, in my experience, will be exactly the difference between the traffic on that rail line immediately before the station and the traffic on that rail line immediately after that station.
I realized after I wrote this that it's not really correct.  I've seen this situation as I've described it many times, but it only occurs where all the traffic at a station consists of all the Sims getting on the train, or all of them getting off.  For many stations at rush hour, this is not uncommon.  But there are also many stations with many Sims both boarding and leaving the train.  In such a case, the station usage may be very high, while the rail traffic (in Sims) on either side of the station is very similar.

This doesn't change my conclusions at all, but I thought it best not to introduce extraneous errors into this discussion.


Mott did a fantastic job at the beginning of this thread illuminating points that many of us did not know, and doing so in a very clear and logical manner.  In effect, he peeled back a few layers of the game to let us see what was going on underneath.  However, he also understood the limits of his knowledge; at one point, he said, "I'm a math major, not a programmer," and he ended his series of posts with the following:

QuoteThat's all I have.  If anyone can correct/contradict any of the above, maybe a programmer knows more specifics about A* CPU/RAM use than I do, then fantastic.  I should be pretty close though.

So I would like to use this post to essentially continue from where mott left off.  Specifically, I'd like to take a closer look at the game from a programmer's point of view and peel back a few more layers.  Mott certainly was pretty close, as he said, but if you apply certain technical aspects of programming knowledge to the observed behavior of the game, it's possible to understand the game a bit more accurately than he described it.  I want to stress that this is in no way a criticism of mott, or anything he did; it is simply building on his understanding to go deeper.  This post is intended for everyone from knowledgable players to advanced developers.  As a result, what I say in the earlier parts of this post may be familiar to many people.  But by the time you get past the first few paragraphs that start in boldface, I think I will be entering new territory for the vast majority of readers.

I really liked the way mott started his posts by listing a number of important but nonobvious points, so I will do the same here.  As in mott's posts, the connection of these points to TE lots may not be immediately obvious, but an understanding of them is necessary in order to build up to the part of this post that directly deals with TE lots.  So here are some more points that are important to understand:

Sims don't commute to and from work every day.  Not even every weekday.  This is easy to demonstrate.  Run your city at whatever speed you like.  While it's running, use the Route Query Tool (shortcut key Alt-/) on a network tile such as a road tile.  Note the various totals for the different travel types; these are the morning commute totals.  Note that they don't change with the time of day (nor the commute period), nor do they change as the calendar advances.  If you switch to Evening Commute on the Route Query legend, you'll get the totals for the evening commute, but these don't change over time either.  Switch to the Traffic Congestion View or the Traffic Volume View, and you'll see that these are static as well.   As far as traffic is concerned, nothing at all happens in Sim City until the next time the traffic simulator runs, which is every four months or so.  And even then, all that happens is that Sims' routes are recalculated.  When this happens, all the signs of traffic mentioned above change essentially instantaneously.  Which brings us to the next point:

There is no traffic.  If the Sims don't ever commute, and the traffic simulator merely recalculates routes, then where is the traffic?  There are the cute little automata, but most people know that they have only a very slight connection with what's happening in the game.  But what about the numbers on the roads, in the MT stations, in the residences, at the jobs?  And what about the two different traffic views, Congestion and Volume?  These are all results from the last traffic simulator run, and they remain static until the next traffic simulator run, months away.  They show a summary of the routes the Sims would follow on the day immediately after the last run of the traffic simulator.  But the Sims don't actual travel these routes; for the game's purposes, they don't need to.  The game just needs to know where these routes are so it can make it look to the players like the Sims are commuting.  It's as if the traffic simulator constructs a detailed photograph of all aspects of traffic in the city whenever it runs, and whenever you enquire about anything having to do with traffic, it shows you the relevant part of the static photograph, which may have been taken months before.  But since the Sims aren't really commuting, and there isn't really any traffic, then...

There are no accidents.  No, this is not some grand philosophical statement; I'm talking about vehicular accidents here.  Now those who are familiar with the traffic simulator exemplar might say, "Wait a minute!  There are four different properties referring to accidents.  What are those all about?"  Internally, accidents are simply another form of congestion, added to the main congestion figures.  The amount that is added is based on the settings of the Congestion to Accident Probability and Capacity to Accident Probability properties in the exemplar.  But accidents don't actually occur in the traffic simulator, because the traffic simulator does not manage dynamic traffic flow.  There is no dynamic traffic to flow.  (This all gets a little Zen-like after a while.)  However, there are the cute little automata, and the Accident Duration and Accident Check Period properties  govern how accidents appear to the player.  Since the automata accidents are tied to the accident probability, which in turn is tied to congestion, accidents are still a good indication of how congested a road is getting.  This is true even through accidents don't actually "happen" in the traffic simulator.  So when you see an accident happening with the automata, nothing is actually happening at that moment on any deeper level in the game.

The building query numbers are often misinterpreted.  I have to plead guilty to this one myself.  However, at this point, it's possible to say definitively what they are.  The second figure in the Current Occupancy (for residences) or Current Jobs (for commercial or industrial buildings) is the maximum potential occupancy of the building.  I think this has been pretty obvious to everybody.  For residences, the first figure in this field refers to the actual potential occupancy; this means the maximum number of Sims who are currently able to live in the building.  Normally, in a thriving city where the population is constantly growing, every residential building is fully occupied, and this first number corresponds to the population of the building.  However, in cities where the population is static or declining, the actual population of the building may be less than this first figure.  It is the actual population number that is used when determining a city's total population.  Unfortunately, there is no way to exactly determine what it is for a particular residential building.  Meanwhile, for commercial and industrial buildings, the first figure refers to the actual number of jobs available in the building; it does not indicate how many Sims are actually working there.  The first figure in all cases tends to be fairly close to the second number, unless the building is abandoned, in which case it is zero.  The Prima manual is incorrect in describing what these numbers mean.

To determine the actual number of workers in a residence, you need to use the Route Query Tool, which lists commuters by travel type.  However, you can't simply add up all the numbers here to get the total number of commuters, as those Sims who take multiple travel types to work will be listed multiple times.  For example, a Sim who takes a bus to a subway stop and then takes the subway the rest of the way to work will be listed under both Bus and Subway categories.  So finding the actual number of commuters may take a little work, including looking at the actual routes that the Sims take.  Jobs for commercial and industrial buildings work in a similar way.  It is this hidden number of commuters or jobs that determines whether a building becomes abandoned; only the actual workers count in this decision.

This all ties in to the previous points.  When a new building grows, it initially shows zero for actual occupancy; when the building is completed, the zero briefly changes to the maximum occupancy, and then settles down to a slightly lower number.  How does this fit in with my static description of traffic?  If you use the Route Query Tool on a building that has just grown on an empty lot, you will find it has no commuters or no jobs, as the case may be.  Only when the traffic simulator next runs are the Sims actually assigned jobs, and travel routes are created for them.  Until then, they all sit at home watching SimTV, and newly built office buildings sit vacant, despite the occupancy number.  There is one exception here:  If a new building grows replacing an older building, and the wealth levels of the old and new buildings are compatibile, some Sims from the old building may decide to stick around.  In such a case, while the building is under construction, even though the current occupancy shows as zero, the Route Query Tool will still show commuters for the building (while it's being constructed!) and routes for them.  The same goes for commercial and industrial buildings under construction.  This doesn't violate anything I've said above, as no new routes are calculated for the Sims who stay over.  (At least not until the next run of the traffic simulator.)

So now you see a bit of what's really going on here.  The traffic simulator itself is implemented as a finite state machine.  This means that it starts out with the entire complex state of all traffic, which is static, processes it, and spits out a new state, which remains static until the next traffic simulator run.  It's important to realize that the new state is based entirely on the old state, and does not take finished portions of the new state into account when calculating the rest of this state.  This is essential if proper optimization is going to be done.  So when mott refers to "making the very first Sim to use a road start slowing it down immediately," that's not quite what happens, since congestion is undefined for the current simulator run until the end of the run.  (Again, this is necessary for optimization reasons.)  Until then, the game uses the congestion figures from the previous simulator run.  However, mott's conclusions still hold, although for different reasons than he states.  Adding the extra congestion levels means that paths are going to be more differentiated in the previous state, which leads to more tiebreaking when calculating the current state, which leads to better simulator efficiency.

This type of model is called "finite state" because there are a finite number of states a city's traffic can be in when the simulator starts running, and there are a finite number of states that the traffic can be in when the simulator finishes with it, although both numbers are astronomically large.  The alternative to a finite state implementation would be a traffic simulator that ran continuously, updating traffic in real Sim time.  This would be a little harder to program, but the main problem with it is that it would take forever to run on anything less powerful than a supercomputer.  So using a finite state machine implementation for the traffic simulator was not merely a wise choice; it was the only choice.

As has been noted elsewhere, the traffic simulator uses a Manhattan A* algorithm to do pathfinding calculations.  But what hasn't been noted before are the optimizations that are being performed.  The algorithm that mott describes is fairly complex; it has things like exponentials in it, and you don't want to use it any more than you have to.  If you have a large tile with millions of Sims, if you had to apply this algorithm to find the path for each one of them, it would take far too long.  Fortunately, there are well known optimizations that can be applied.  For example, take the case where a new residential tower goes up and thousands of Sims move in.  Now they aren't all going to be going to thousands of different buildings for their jobs, so some of them will be starting at the exact same place and ending up at the exact same destination.  Suppose you've just used Manhatta A* to calculate the best path of one Sim to his or her job.  Now you find that the next Sim is going to the exact same job.  Do you use Manhattan A* to perform the same tedious calculations which give the exact same result to get the Sim to his or her job?  Definitely not.

What you need is a way to remember routes that you've already calculated for the current run of the traffic simulator.  The remembered routes are only good for the current run of the simulator because between runs, the user may have built new roads, torn others down, built or torn down MT stations, etc.  Congestion may have changed, buildings may have grown or been demolished.  So we have to stick to the current run.

The next question is, What do we remember?  We could remember the entire path from start to finish.  But there are an awful lot of these paths, and if we store them exactly, what do we do when Sims one building closer than our origin want to go to our destination job?  Or perhaps to something along the way?  We could store all possible subpaths of the path we calculated, but this starts eating up a huge amount of storage fast.  Simply storing all the subpaths starts taking significant CPU time as well.

Instead, we store a useful subset of the paths - a "coarse grid," as it's technically termed.  What we use for this coarse grid depends depends on what our main mode of travel is.  There are two main travel modes - car and mass transit.  (If pedestrian-only travel stores routes, as I would think they do, they would use the car grid.)  The car grid consists of all road intersections, where here a "road" is anything a car is permitted to travel on, while the mass transit grid uses all the mass transit stations.  So if a Sim car travel route is being calculated for the first time this simulator session, the route between the first intersection through the last intersection is stored in a hash table.  (A hash table has the very useful property that no matter how big it is, storage and lookup times are essentially constant, on the order of nanoseconds.)  All contiguous subpaths of the original path are also stored in the hash table; all eligible subpaths have intersections as end points.  As further Sim car routes are calculated, each time the simulator reaches an intersection, it tries looking it up in the hash table to see if it is a waypoint - an intersection that is part of an already computed path.  If any of these paths go through the intersection and also go in the direction that the Sim is trying to go, then rather than recompute the path over that segmented, the precomputed path is used.  Precomputed paths may be used to calculate a new path that leads part way to the destination, while the remaining distance is then computed with a new path, which, along with the entire new path and any new subpaths, is then added to the database (which is actually the hash table) of precomputed paths.  So very quickly, a set of precomputed paths is built up for the most commonly used routes, saving tremendous amounts of CPU time in calculation.  And it's not even necessary for the simulator to check a path segment by segment; it can take the intersection closest to the origin along with the one closest to the destination, and see if a path has been computed for the entire route.  Furthermore, such a precalculated path may exist even if it has not been calculated for any Sim up until this point, as it may be one of the subpaths that has been stored in previous calculations.

Mass transit paths are calculated in a similar way, again using intersections as a coarse grid. However, in this case, TE lots are also included in the coarse grid.  Since transit switches can happen only at MT stations, only they serve as waypoints; intersections do not.  Otherwise, things work similarly as for cars.  And since everything is heavily optimized, the number of calculations of trips through TE lots is a small fraction of the actual number of trips through them.  Essentially, only one calculation needs to be made for a TE lot for any given path, no matter how many Sims use that path.  When a precalculated route is used, either for cars or mass transit, each square on the route is updated to account for travel by a new Sim.  But since the route is precalculated, no new calculations are needed anywhere, including on those parts of the route that go through TE lots.  Thus the impact of TE lots on the simulator is minimized.

None of the above is my invention; these are all standard programming techniques, and standard applications of the Manhattan A* algorithm.  I used as my main reference the same resource that mott did, namely, Amit Patel's paper.  A fair understanding of math and programming is required for reading this paper, but everything's in there.  Amit makes passing references to things like hash tables and waypoints; I've expanded on them a little bit here.  And while what I've described is not guaranteed to be the exact implementation used in SC4, something very close to it, with essentially the same properties, must be.  Any programmer who knows how to implement a Manhattan A* algorithm, as the Maxis programmers clearly did, will also know of all the methods I mentioned and more, and will use them to optimize the simulator as much as possible.

Now that the basic principles have been laid out, it is possible to use them to come to some very specific conclusions about the usage of TE lots in the game.  Since these conclusions are in contradiction to some of the conventional wisdom about the workings of TE lots, I will state the mistaken beliefs in the form of myths, which is essentially what they are, and then show why they are not true.

Myth #1:  Whenever a Sim enters a TE lot, the Sim's commute time clock gets reset to zero.  Searching for the first appearance of this statement, I found it showing up on a forum here on January 31st.  Since then, it has been repeated in a number of places by several different people, but never with any supporting evidence whatsoever, nor any indication of why it would make sense for the game to do this.  Some people are under the impression that mott said this, but he didn't.  What he did say was this:

QuoteTransit Switches were invented to solve a particular problem:  Sometimes a Sim has to get off a bus, and then walk back the same way he had just come, on the same street.

The problem with that is, a simulated trip cannot backtrack.  The pathfinding system does not allow the same route to be traveled twice during a trip.

The solution was adding the "Transit Switch" property to lots.  Lot-makers may recognize this as the one that makes a lot function as a bus stop or train station, by converting traffic from one form of transit to another.

They also make the Sim "forget" how he got there.

When the pathfinder encounters a Transit Switch lot, it generates a new trip, from the lot to the destination.  This "new" trip is free to try routes that were already tried by the "old" trip.  That way, Sims can walk any direction when they get off the bus, and the backtracking problem is solved.

(I have included the whole quote because I will be referring to other parts of it later on.)  So to sum up, what mott said was that for the sake of backtracking, the Sim must be able to (temporarily) forget how he got to the current point, as the A* algorithms do not allow backtracking.  Nothing was said about forgetting commute time.  And a little analysis will show that if a Sim actually did forget his commute time when entering a TE lot, it would break the pathfinder completely.  For as mott described in this post, paths are calculated by trying out different paths and seeing how the result (i.e., the commute time) compares to the ideal time, and sometimes to other possible paths.  If the commute time is set to zero during the calculation of any single path, such a comparison becomes impossible, as there is no longer a valid trip length to compare.  So under these circumstances, pathfinding itself becomes impossible.

To me, that argument seems airtight.  For anyone not convinced by that argument, there are equally convincing arguments.  For example, I have about a dozen cities filled with RTMT stations.  You can't walk a block without running into one.  Which also means that you'll run into one wherever you drive, or ride the bus, or take the subway.  Now if a Sim's commute time were reset to zero every time they entered one of these stations, it would be getting set to zero repeatedly, and they would never run out of commute time.  But that's not the case at all.  These cities are just as sensitive to the Commute Trip Max Time Property as any others; extensive testing has shown that there's no difference here.  That simply couldn't be true if the commute time were constantly being reset.

So the bottom line is:  A Sim's commute time is NEVER reset when entering a TE lot.

Myth #2:  Whenever a Sim enters a TE lot, the Sim forgets how he got there.  This may seem to be exactly what mott said in the long quote above, and in fact, it is.  But if you recall from the beginning of this post, he also said, "I'm a math major, not a programmer."  So his math and logic are basically correct here, but he was apparently unaware how good programming can completely eliminate this problem.  I have no criticism of mott here whatsoever; he did a fantastic job, and simply made it clear where the limitations of his knowledge were.

So how do we allow backtracking without recalculating paths?  Our main limitation is that we're not allowed to retrace paths we've already taken; this is slightly more generalized than simply forbidding backtracking.  But the only time we would ever want to retrace paths is if we're using a different travel type than in the original traversal.  To use mott's example, the Sim gets off the bus and then walks back along the same road the bus has come.  So what we really want to do is to say that the path is different if the travel type is different.  This is easily done by adding a third coordinate to each location in the Sim's path.  In addition to the standard x and y coordinates, we add a z coordinate, which is a number representing the travel type in use at the time.  Once we do that, the backtracking problem simply disappears, as the Sim is now seen as taking two different routes.  For most of the Manhattan A* algorithm, the x and y coordinates are used in the usual way, and the z coordinate is ignored.  But for seeing whether or not we have traversed a certain square, the z coordinate is examined.  This is very easy to do using the implementation of A* that Amit describes on the second page of his paper.

Looking more closely, it turns out that not only is the method of recalculating paths at every TE lot entrance excessively costly, but it's also insufficient to prevent all backtracking problems.  To take a simple case, look what happens at a standard highway cloverleaf when a Sim drives over the lower highway on the top highway, then takes a right turn (or left, depending on your country) onto the exit ramp leading to the lower highway, merges onto that highway, and then drives under the upper highway.  This happens all the time.  The problem is that it's not allowed by the standard A* implementation that mott references.  The reason is simple:  "Backtracking" in this implementation actually means "traversing any square more than once."  And when the Sim drives under the upper highway, he's actually traversing the same square a second time.  Mott's solution doesn't help us here; the Sim remains on the same network and doesn't pass through any TE lot, so there's no opportunity to recalculate paths.  You could special-case this situation, but unfortunately, there are too many others like it.  You can have rail loops that cross themselves, monorail loops, el train loops, other types of highway interchanges, etc.  You need some method that can handle all these cases automatically.

Fortunately, the coordinate system I described can be easily modified to handle all of these cases.  It does need modification, because all the cases I just described happen with a single travel type.  But what these cases also have in common is that the direction of travel the second time across the re-used square is orthogonal to the direction of travel the first time across it.  So, one solution would be to add a fourth coordinate to the triplet, making this additional coordinate 1 for north-south travel and 0 for east-west travel, or something along those lines.  But since the purpose of this fourth coordinate is identical to that of the third, z coordinate, it would be simpler to combine them.  You could simply use the z coordinate in the way I first described, but use a positive sign for north-south travel and a negative sign for east-west travel.  So then you still have your three dimensions, and all your backtracking problems are solved.

This three-dimensional coordinate system has other benefits as well, which make it a compelling choice for the SC4 implementation.  For example, let's assume that a Sim is walking down the road and reaches a square with a bus stop on one side and a subway station on the other side, and that furthermore, both the bus and subway continue down the road on which the Sim is walking, with the subway running directly under the road.  What route does the Sim take?  In the classic Manhattan A* algorithm, all three forms of transportation - walking, bus, and subway - follow the same path (at least once you get beyond the transit station).  With the standard two-dimensional coordinate system, extra work needs to be done to differentiate among the different travel types that follow the same path.  With the three-dimensional system that I have described, no extra work is needed, as the travel types are all considered to take different paths, and the algorithm handles this case automatically.  This three-dimensional implementation is both the simplest and most efficient that I can think of now, and it would be quite obvious to an experienced programmer.

So the bottom line here is:  By choosing an appropriate coordinate system, a Sim's path NEVER needs to be recalculated, and backtracking is always handled properly.

Myth #3:  RTMT stations are bad for your traffic simulator and/or bad for the game.  This section assumes and build on the conclusions from the previous section.  When cars travel through RTMT lots, they always emerge as cars.  So as long as the Transit Switch Entry Cost is set properly for cars (which is not difficult), RTMT stations are essentially invisible to cars; they behave just like a road or street network tile.  No extra decisions need to be made, and the cost of cars' going through these TE lots is not significantly different than having them travel over network tiles.  Freight trucks are similar, although since their speed is typically a little lower than cars, they travel through the TE lot a little faster than they would over network tiles.  But the difference is not very large, and as long as you don't have RTMT stations every other tile or so (which is a bad idea for many reasons), the average speed of freight trucks is hardly affected at all.  As for pedestrians, generally when they enter an RTMT lot, they board a bus or subway so the Transit Switch Entry Cost works fine in such a case.  In the few cases where they walk across the lot and keep on going, they do end up going much faster than they should across the lot.  But this case is relatively rare, and even when it happens, it should have no significant larger repercussions, especially if the RTMT lot is a 1x1 lot.

As for mass transit, if the costs for passing through a roadside TE lot are usually almost nonexistent, they are almost nonexistent for buses and subways passing through RTMT lots as well.  So RTMT stations are really no worse than other TE lots.  There is one series of experiments that I did last year that provided powerful support for this statement.  I had a half dozen fully developed, highly urbanized, dense CAM cities (five medium tiles and one large tile) which had all been played for a long time, and which contained no RTMT lots.  Once I started using RTMT, I liked it so much that I went through each of these cities and replaced all roadside lots with RTMT lots wherever possible, which was almost everywhere.  This is the only change I made to the cities.  I continued playing each of the cities, and in no case did I notice the slightest difference in performance from before I made the change.  If RTMT really did make the traffic simulator work a lot harder for each station, or even a bit harder, then I should have noticed a large drop in performance when I suddenly filled a whole city with these stations.  But I didn't.  This is also strong evidence that the programming techniques I described (or ones similiar to them), which are all very basic, are actually implemented in the game.

Finally, TE lots in general are a lot more benign than one would think from mott's description.  The reason for this is not that mott is describing things inaccurately, but that there standard programming practices that are able to eliminate unnecessary costs.  Some costs cannot be eliminated; every time you plop a TE lot, you've inserted more branch points into your map, which means more paths for the simulator to explore.  So you don't want to supersaturate your city with TE lots (i.e., one every two or three squares), as this will definitely have an impact on performance.  But as I've tried to demonstrate, and have found from experiments in my own cities, the performance hit from individual TE stations (be they RTMT or otherwise) is a lot less than mott describes.  So having a reasonable number of TE lots in your cities is not going to be a noticeable drag on performance.  And "a reasonable number" here means whatever you need to make your city run properly.  If you find your TE lots are maxing out on capacity, don't just add more of them; use bigger capacity stations.  This is much easier on the traffic simulator, and it's much more realistic.  Also, it's very important to use high quality, properly built TE lots; all the optimization in the world won't help you if your TE lot is broken.

So I hope I've been able to clarify some points about TE lots from a programmer's point of view.  It's not necessary to be miserly about using them; if you use them approximately the way they're used in real cities, or even a reasonable amount more, you'll be fine.  And RTMT lots carry no significant disadvantages over other TE lots.  They also look more realistic than most roadside lots, and make building your city a lot easier.

I have written this post based on my experience and understanding, which I believe to be correct.  However, it is very possible that I have made some mistakes.  I would be very happy to hear about them so that I can correct them.  I would also be happy to elaborate on any points that are unclear.  Thank you for reading this far, and for your patience with the length of this post.


z, your detailed posting contains much food for thought for me and I would like to thank you for it.
I am interested in GLR/tram and quite familiar with adding new network puzzle pieces (in particular tram) to the NAM, but I am not very familiar with the traffic simulator. Trams need stations and all tram stations are TE-Lots, therefore, this discussion is of much interest for me.
So if I understand correctly, it boils down to the question whether the Sim's clock is reset when passing through a TE-Lot. Let the game decide. Maybe somebody will ...
Quote from: z on September 06, 2008, 01:31:17 AM
... be able to set up a city with an extremely small max commute time, place RTMT stations all over, and check whether the Sims travel as far as they wish.
I don't have time in the near future, but hopefully somebody will do this test and report about it.


The test that I proposed, and that you quoted, was really for jplumbley's benefit, since he disagrees with me on this point.  But in truth, as I tried to make clear in my post, this is really a settled issue.  The post was rather technical, so let me try to summarize the most salient points here:  Everyone agrees that the game uses Manhattan A* pathfinding in its traffic simulator.  The heart of Manhattan A* (and A* in general) involves the comparison of possible paths based on their total length.  For this to work, there obviously has to be a valid total length.  And that means, in turn, that a Sim's commute time clock cannot be reset in mid journey, because then there would be no valid total length for the Sim's path.  Using invalid total lengths would break the Manhattan A* comparison functions, which would in turn destroy the traffic simulator's ability to choose reasonable paths for the Sims.  And when using vanilla SC4, elevated stations and monorail would break the pathfinder.  Yet mott, who laid out a strict set of rules for use of TE lots, said, "The Maxis Monorail and Elevated stations can meet the above list of conditions."  And he never claimed that a Sim's commute time clock was reset upon entering a TE lot, or at any other time.  Furthermore, no one has ever shown what use it would be to reset the Sim's commute time clock at every TE station, or why it would be necessary.  And I have tried to show in my original post that I have plenty of experimental evidence that the commute time clock is not reset.

So the bottom line is that resetting the Sim's commute time clock would break the Manhattan A* comparison functions wherever it was done, which would in turn break the pathfinder.  No one has refuted this statement; no one has even tried.  Unless someone can show how Manhattan A* pathfinding can work with the Sim's commute time clock being reset at various points (which appears to be mathematically impossible, based on the algorithm), I believe it is completely safe to assume what I stated in my first post:  that a Sim's commute time clock is never reset.  My cities are all based on that assumption (as are many others), and would not function at all if it were not true.


Ok, I couldn't keep away from this... seeing two of my friends arguing over something that hasn't even been tested properly...

Thus, I set up a new city in a blank region, zoned a residential area and an industrial area on either end of a long road, crossing more than half of a large city.

Before starting to test I let the city develop for 32 years, till everything was static and no more development took place.
The image below is the Census Repository after these 32 years:

Let me, based on this screen, first comment a couple of other posts above...

Quote from: z on September 05, 2008, 09:10:19 PM
The building query numbers are often misinterpreted.  I have to plead guilty to this one myself.  However, at this point, it's possible to say definitively what they are.  The second figure in the Current Occupancy (for residences) or Current Jobs (for commercial or industrial buildings) is the total potential occupancy of the building.  I think this has been pretty obvious to everybody.  For residences, the first figure in this field refers to the actual current occupancy; this means the actual number of Sims living in the building.  It is this number that is used when determining a city's population.  For commercial and industrial buildings, the first figure refers to the actual number of jobs available in the building; it does not indicate how many Sims are actually working there.  The first figure in all cases tends to be fairly close to the second number, unless the building is abandoned, in which case it is zero.  The Prima manual is somewhat misleading here.

The Prima Guide is useless in this respect, and you're correct about most of it. However, I do disagree with the red sentence...
Also for residentials, the first figure is the actual capacity, not the actual number of people living in the house.
Normally, in a thriving city where the population is constantly growing, every vacant house is fully occupied.
The capacity census is performed halfway through each month, and the actual population would fill that capacity by the end of the month, when the actual population census is performed.

However, in a city like mine in this test, where there's no service whatsoever, people are not as keen on moving in.
Thus, you can see that the city has a total population of 1,555 but a residential capacity of 1,802.
1,802 is what you would get if you sum the first number in the query for each residential house in your city.

Quote from: jplumbley on September 05, 2008, 10:50:38 PM
Thisis not necessarily true.  If you noticethe number of Commuters is always less than the numberof occupants.  A portion of the occupants are attributed based on the values in the Population Average Age.  The buildings are assigned an average age based on local Yimby and Nimby factors and a percentage of them are too old or tooyoung to be considered in the "Workforce".  This means that depending on the Average Age of the building and the waythe Sims are portioned that you are looking at 70 to 80% of the occupants being turned into actual commuters to work.

Not quite... the actual workforce is set in the Residential Simulator, with two properties:

  • First, the property Health Quotient to Life Expectancy Curve sets the life expectancy somewhere between 50 and 100 years:
    HQ = 0     ->  Life Expectancy = 50
    HQ = 200  ->  Life Expectancy = 100

  • Secondly, the property Life Expectancy to Workforce % Curve sets the workforce percentage based on the life expectancy:
    Life Expectancy = 50   ->  Workforce 40% of the Population
    Life Expectancy = 100  ->  Workforce 60% of the Population

Thus, as anticipated, in my city with absolutely no health-care, the workforce is exactly 40% of the actual population (not capacity):
620/1555 = 0.40

Then to the myth busting itself...
In this testing I have been using no custom growable buildings, only those by Maxis.
I'm using a rather old version of NAM, May 2007, with NetworkAddonMod_Traffic_Plugin_Standard.
I'm also using CAM 1.0.

After 32 years the city's development has levelled out (due to lack of empty zones).
There is a slight fluctuation in the residential population, due to vacant capacity being available.

The average commute distance is about 140 tiles, which theoretically should give a commute time of: 140 / 31 * 25 = 113,
where 31 is the speed of cars on roads and 25 is the Trip Length to Minutes Display Multiplier
This can be verified with the in-game Commute Time graph:

After this I plopped one of 1dera3's bus blockers halfway along that road.
This only blocks buses and allows all other traffic, from all sides, in and out. The Entry Cost is 0.00.

If the commute clock would have been reset at this TE lot, the Commute Time should have been roughly halved.
However, this was not the case. If there was a drop, it was a very slight one:

At this stage I suspected that the drop was due to the Entry Cost being 0.00.
Thus, I plopped four more bus blockers, and got a confirmation on this:

For yet another confirmation I ploped five more bus stops, now ten of them in total.
However, I purposely left the last leg in the commute unchanged
(no new bus blocker between the last one and the industrial district).

Finally, I plopped five more in the residential area, along the main road that the residential lots are not facing:
This gave a smaller reduction in Commute Time, since not every commuter could take advantage of all lots where the Entry Cost is 0.00:

At this stage I saved the city, exited and edited 1dera3's bus stop to give it an Entry Cost of 0.03226 (exactly 1/31).
I re-entered the city and replopped all bus blockers.
And as a final confirmation, the Commute Time jumped back up onto exactly the same level it had before:

After this I once again save the city and exited, and change the Entry Cost to what mott recommended above, based on the pedestrian speed: 1/3.5 = 0.2857.
This was not a very good idea, as this lead to the Commute Time being far too high, and every citizen left town: