Sim City 4 Devotion Forums

SimCity 4 Devotion Custom Content Showcase => Network Addon Mod (NAM) => NAM How-Tos and Tutorials => Topic started by: mott on October 25, 2007, 04:47:59 PM

Title: TE Lots, Transit Switches, and You :)
Post by: mott on October 25, 2007, 04:47:59 PM
NEWS YOU NEED TO KNOW
---------------------
These are just some general bullet points that must be accepted and understood before proceeding:

* The "internal" map that the game simulators are using for themselves, would look almost exactly like SC Classic for DOS if you could see it.  Under the hood, this basic game engine has not changed since the beginning. 

* There are no diagonals in SimCity now, and there never have been.  There's no such thing as a Transit-Enabled lot, either.  These are mere display tricks.

* The game carries its own process scheduler, needed for DOS/Win31/9x support, which is why it can't spread across the cores of newer multi-core machines.  It appears to the machine as a single process that cannot be divided.

* The game gives the UI a generous amount of CPU time no matter what.  You can do something that causes the pathfinding and demand/desirability engines to fall into a near-infinite loop, and the UI won't "lag."  Just because your game *seems* to be running OK, doesn't mean it really is. 

* The simulators - pathfinding, demand, all of them - are "perfect."   If they are doing something "wrong," it is a result of wrong information being fed to them.

* Everything in the simulator is related to everything else in it.  If you aren't testing your mods/lots on a default installation with no plugins, played on "hard," you can't be sure you have a true sense of what they do.  The easier settings artificially inflate some of the simulators, and you never know what J. Random BATter is going to throw into a .dat file.  Test "clean."



NEWS YOU CAN USE: "THE RULES" FOR TE LOTS
-----------------------------------------

These are not *my* rules.  These are the *game's* rules.  Everything presented here is a direct, logical consequence of how the game works, due to behavior that is hard-coded in the EXE.  Arguing with the rules will not change them.  Knowing why they exist is essential.

If you follow these rules, you can use TE lots in appropriate situations, and they will not mess up anything else in your game or harm performance too badly (no worse than the Maxis ones do, anyway).

If you choose not to follow them, the resulting lots will cause *something* about the game to start going wrong.  Sure, the first one you plop may seem fine, and the second may seem fine.  As you plop more "bad" TE lots, the negative effects do not just add up, they *multiply*. 

As with all things that affect pathfinding, those "negative effects" usually manifest as errors in the demand/desirability/development engine, that lead to inappropriate development and serial abandonment.  All mods that lie to the simulators will usually end up doing that, one way or another.


So here they are - "The Rules"
If you bend these at all, there *will* be a price to pay somewhere, somehow.


1) One lot == One network == One travel type.
-----------------------------------------
The original design spec for Transit Switch lots never anticipated multiple travel types passing through the switch, and they cannot properly account for them.  Traversal Time and Capacity cannot be properly set on a multi-network TE lot.

* "One lot" means the lot you are making.
* "One network" means you can TE for regular rail but nothing else, road but nothing else, etc.
* "One Travel Type" means that if you TE for a network that allows more than one kind of vehicle, such as roads, you're going to have to "block" all but one of them from passing.  A "Bus Only" lot is OK; a "No Trucks" lot is not.  A TE'd rail station should allow freight or passenger trains to pass through, but not both.  It's OK to let other transit types (pedestrians, for example) into a transit station lot, but they *must* ride the transit. 

This is extremely important, for not adding compounding amounts of error into the pathfinder. 
Maxis/EA did not always follow this rule, and Sims walk through bus stops (for example) as a result.  This is bad in more ways than just looking stupid, but we'll get to that when we discuss performance


2) All paths across the lot must be equivalent. 
----------------------------------------------
Since only one kind of use was anticipated, the lot can have only one "travel time" across itself. 

* Parallel rails are fine, as long as they are the same length (and the same kind of rail; see rule 1). 
* Think carefully before allowing multiple networks; it usually isn't necessary.
* Keep in mind that any vehicle entering a multi-path switch may "jump networks" inside the lot.
* Rule 1 still applies. 



3) If the lot is not square, it must only allow thru travel N/S or E/W, not both. 
-------------------------------------------------
This is a consequence of Rule 2.  Two paths of different lengths *cannot* be equivalent.  Therefore, they cannot be allowed.

* See the Transit Switch properties for the Maxis Elevated and Monorail stations for an example of how this is enforced. 
* Rule 1 still applies. 

Sims riding transit will also only be able to enter the Transit Switch from the chosen set of directions, so the player must provide a path to allow this.  NAM puzzle pieces (such as GLR-on-PedMall) are *very* useful for this purpose.  We need a set for heavy rail, too.




4) If the lot contains a TE'd intersection, it must be no larger than the intersection, and both networks should be the same type. 
----------------------------------------------
This again is a consequence of the other rules about equivalent-paths and traffic-tracking.  however...
By Maxis convention, when two different types of network intersect, they are both assigned the travel time of the faster network on that tile.  Therefore, if the TE lot is nothing but the intersection, the travel time is equivalent in all directions.  It's OK to intersect street with road, etc. in this case.

* Intersection plops are generally a bad idea to be avoided, but people making bus-only lanes may find such lots useful, and should know that it's OK in that specific instance.  It's not much worse than a Maxis El station.  If the intersection lot is also a station, so much the better.  Just try not to do this unless really, you *have* to.
* Rule 1 still applies.


NOTES:
------
* The Maxis Monorail and Elevated stations can meet the above list of conditions.

* The "Big Dig" lots, assuming that they only allow cars to enter, are another "acceptable" (and brilliant, IMO) example of "proper" TE lot use. 
Those lots are a little big for Transit Switches, but as long as the player is aware of the CTD issues with puzzle pieces, no harm done, and they are tune-able.  The "Dig" is *good* in a lot of ways that will become apparent over the next few posts.


Title: Re: TE Lots, Transit Switches, and You :)
Post by: mott on October 25, 2007, 04:48:47 PM
WHAT TE LOTS ARE
----------------

What you see on the screen in SC4 isn't always what you get.  Diagonal networks and Transit-Enabled lots are two good examples.   

A "Road Top Bus Stop," on the game's internal map, looks exactly the same as a regular bus stop.  There is no road under it or on it.  The road ends, there is a bus stop, and the road begins again on the other side.  It looks like a continuous road to the player, but it isn't one, and the simulators themselves know it. 



WHY PUZZLE PIECE HOVERS OVER TE LOTS CAUSE CRASHES
---------------------------------------------------

What the player sees as a "TE lot" is the result of some special coding overrides in the lot, that lie to the network and automata *display* processes.  This way, they are "tricked" into drawing a continuous road for the player, with traffic, instead of displaying the ugly reality (a broken road with a bus stop in the middle of it).

These same lies cause the game to crash to desktop when someone hovers a "puzzle piece" over the lot.  The puzzle-piece preview thinks it's over a network (it believes the lie), so it goes looking for RUL tables so it can auto-orient itself.  Lots don't have the proper tables for this purpose; only networks do.  Null/random pointer, meet desktop.  This is not a "puzzle piece" problem, it's a TE-lot problem, and it's not solvable without modding the EXE itself. 

The underlying point is, the network doesn't *really* go through a TE lot.  That's just a clever display trick.  They're really just Transit Switch lots, like any other.



TRANSIT SWITCHES, EXPLAINED
---------------------------


Transit 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. 
Title: Re: TE Lots, Transit Switches, and You :)
Post by: mott on October 25, 2007, 04:49:32 PM
PERFORMANCE IMPLICATIONS OF TRANSIT SWITCHES
--------------------------------------------

Note the words, "try routes that were already tried."  T

Tranbsit Switches have potentially dramatic CPU-usage implications, because all the other possible routes are *also* still being tried.  These things can and do start multiplying the number of trips that the pathfinder must consider, for each such lot encountered. 

Or the other way: These things reduce (worst case, divide) the number of Sims that can be in a city, before the computer overloads.

For things like train stations and bus stops, this is a necessary cost of having mass-transportation options.  As long as the stations are next to (not on top of) the networks so traffic is not forced through them, the pathfinder can save CPU time (and find better paths too) by avoiding inappropriate Transit Switches.  That means more Sims and less "simulator lag."

Therefore, one of the first considerations of a transit switch, is that it should be *avoidable* if at all possible.  You do not want the pathfinder to enter it unless it thinks it has something to gain by doing so. 

The default Elevated and Monorail stations are therefore wasteful.  The only "saving grace" is that rail presents very few decisions to the pathfinder. Trains can only keep going forward until they hit a station or a track switch, and there just aren't any other options to consider.  The CPU overhead is relatively small.

On a road, *every* tile is potentially an intersection.  This makes calculating paths on roads a lot more time-consuming. 




IMPROVING TRANSIT SWITCH PERFORMANCE
------------------------------------

Computers are faster now, but they're not THAT much faster.  You cannot outrun exponential growth in CPU usage.  All you can do is try not to cause it.

The #1 best thing you can do as a first step, is to minimize the number of transit switches on the map.  Every unnecessary one you take out adds more Sims to the city before it goes into the inevitable "grind."  It's unavoidable with actual transit stations, but anything else, if it can be done another way, it should be. 

If a Transit Switch is avoidable, the pathfinder should avoid it unless it has some reason to consider changing transit modes.  Doing so saves a large amount of CPU time for every unnecessary one avoided.

Unfortunately, the game as-shipped does not exploit this possibility.  Even worse, it tries every Transit Switch it sees, and usually uses it (like when Sims get off the bus and back on again). 

This is the kind of thing people download pathfinding plugins trying to fix, but the problem is not in the pathfinding. 

If there was some way to tell the pathfinder that it takes *time* to wait for a bus at a bus stop, the stupid Sims would stay on the bus they were already on.  Pedestrians would go *around* bus stops, not through them, unless they wanted to ride the bus.

This is why the "Transit Switch Entry Cost" property exists.  It is not a "cost" in money, it is a cost in *time.*  Its purpose is to advertise to the pathfinding engine that it should not consider the transit switch unless it thinks it can save at least that much time by doing so.

Setting it to zero, as the default stations do, advertises to the pathfinder that it should *always* try the transit switch first, because it's a "free move."  The pathfinder is not stupid (far from it).  It is making the correct choice based on faulty information, and your Sims walk through bus stops as a result.

Title: Re: TE Lots, Transit Switches, and You :)
Post by: mott on October 25, 2007, 04:51:17 PM
CHOOSING A TRANSIT SWITCH ENTRY COST
------------------------------------
I am currently experimenting with proper entry-cost tuning, so this information may be refined in the future.  However, in principle, it should make a decent guideline set.

As noted earlier, the default Maxis stations do not have a "Entry Cost."  Therefore, when using custom stations that *do*, one must either patch all the Maxis stations to match, or use only matching custom stations.  This goes for *all* of them.  If you give a bus stop a cost, but not the train station, Sims will work very hard to avoid the bus stops and use the train instead.  It's all-or-nothing.

That said:

In a default Maxis game, the "time cost" of traveling 1 tile is (1/speed).
Therefore, the "time cost" of your lot, however many tiles wide it is, should usually be (tiles/speed).
But not always.  I'm still working on it...

I'll cover the two important cases now though:

* TRANSIT STATIONS:
-----------------
Pedestrians move at 3.5 kph by default, so to walk one tile takes a "cost" of (1/3.5).  Set a Bus Stop's "Entry Cost" to just over that, say (1/3) or 0.3, and pedestrians will not "cut corners" through that bus stop unless they are going to ride the bus.  Ever.  And Sims on the bus won't get off the bus unless it's their stop.

Since transit stations usually serve pedestrians, using a fixed cost of about 0.3 for *all* stations is appropriate, regardless of size.  Otherwise, it would privilege one station over another, based on size of station, and that's nonsense.  Sims shouldn't be allowed to walk through stations without riding anyway, although some of the Maxis stations do.  They shouldn't.

If the transit station is on-network, it becomes unavoidable, so Sims must then "wait through stops" on the El trains and Monorail.  Buses can't be made to wait through stops without littering the map with "bad" TE lots, so there has to be another way to avoid priviliging buses (such as slowing them down about 25% or so in the pathfinding plugin).

Unfortunately, it is impossible to model realistic "wait times" at transit stops.  The maps are just too small.  In 5 minutes, half the Sims could WALK off-map.  If we could play a whole region at once, it would be feasible.  But it's not.

In general: Stations should be just slightly slower than walking. 


* OTHER ON-NETWORK LOTS:
----------------------

In the case of a lot such as "Trucks Only," "Cars Only," and such that do not involve pedestrians, it is more appropriate to match the lot's Entry Cost to the time it would normally take to traverse the network.  The Maxis El-Sub transition piece would be an example of where this is appropriate.

To know what the "Entry Cost" is for the transportation networks themselves (so you can match your lots to them), all you need is a pocket calculator. 

Say you make a TE'd road lot that allows only cars to pass.  Cars go 31 kph on roads, so type in 31 into your calculator and hit the (1/x) button.  That's the "Entry Cost" of moving 1 road tile by car.  Multiply that by the number of tiles that the Sim must travel to cross your lot, and that's your Transit Switch Entry Cost.

You should also set the capacity to match that of roads, which is 1200.

The "Big Dig" lots, despite being technically stations, would be appropriately set this way because of their purpose.

In general: Entry Cost = (Tiles/Speed).  Network speeds (and capacities) are available in the Omnibus, the Prima Guide, pretty much everywhere.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: mott on October 25, 2007, 04:53:00 PM
Tha'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.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: sc4luv2 on October 25, 2007, 04:54:18 PM
Good Info. Was Readin' while you were postin'.  :thumbsup: Now should we move this?? to mod tutorials  ()meeting()
Title: Re: TE Lots, Transit Switches, and You :)
Post by: mott on October 25, 2007, 05:01:37 PM
Have some other informaed eyeballs look at it, especially wouaningaine (sp?)... give it a "peer review" process and then let it go wherever it should be once it's completely correct.  I just want it to be good info so people know for sure what they can and can't do.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: jplumbley on October 25, 2007, 05:23:54 PM
Good Info. Was Readin' while you were postin'.  :thumbsup: Now should we move this?? to mod tutorials  ()meeting()

I dont know if this should be in the Tutorial Section as it is not really a Tutorial, but it is a very informative thread.

Thank you Mott... Now I have a better place to link the TE Lotters out there to when defending my position on TE Lots and Networks.  This was very well written, I read every word and it has given confirmation to everything I have been told and everything I have experienced with TE Lots.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: Filasimo on October 25, 2007, 05:57:56 PM
i stongly agree with plumbey and thank you so much mott for posting this very informative thread *gives mott a karma point* oh snap it dont work anymore  ::) good work man!  :thumbsup:
Title: Re: TE Lots, Transit Switches, and You :)
Post by: RippleJet on October 25, 2007, 06:40:40 PM
This is very well written, mott! And a very good basis for well created custom stations.
My eyeballs couldn't find anything to correct, everything was very easy to follow and easy to agree upon!

I will implement the transit switch entry cost in the formulas for the "X Tool" for the creation of custom stations in the future!
And I suggest that the next NAM changes that property for all in-game stations accordingly! ;)
Title: Re: TE Lots, Transit Switches, and You :)
Post by: cogeo on October 25, 2007, 06:44:19 PM
I think there is something wrong with your scales. A pedestrian walking at 3.5 kph (3500 meters per hour) would actually need 16/3500 = 0.0046 hours (ca 16.5 seconds) to walk through a 16-meters long tile, which sounds very reasonable. The time you suggest (1/3.5 = 0.286 hrs) is prohibitive. But I don't know if SC4 trip times are correctly scaled either.

I have experimented a lot with the Transit Switch thingies (for use in my stations) and I have concluded that the units for the Transit Switch Entry Cost property is indeed hours. Below are the effects of various settings (for 1x1 lots):

- 1.0 or 0.5: very high values, no sims are gonna use this station.
- 0.1: very strong effect. No pedestrians will cut corners through the station. Usage (mean the "real" one) fairly lower compared to that of a similar station with a setting of 0 (the station is quite less "competitive" already).
- 0.05: strong effect. No (or very few) pedestrians will cut corners through the station. Usage somewhat lower, but it's bearable. However having several such stations in a row on the same network/path (eg 5 roadtop stations on the same road) can significantly increase travel times, causing sims to look for alternative routes or even choose to work somewhere else, even in a different city.
- 0.02: Seems this is the "correct" value. Few pedestrians will cut corners. Negligible effect on usage. No traffic problems.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: Crissa on October 25, 2007, 07:07:22 PM
I had been trying to use TE lots to 'interrupt' car traffic flow, but I noticed sims were more likely to get back into their cars than they were the bus - the times for the bus seems to include going to the end of the street and back... (IE, a TE lot at the intersection end of a street the sims would get on the bus as it arrived on the street, not as it left the street)

And I like the look of transit-enabled lots, as well.  Made me wonder if it were possible to program the road network to do a round-about including a TE lot, so that one type of transit would be optimal in one cardinal while the other type of transit was merely interrupted.

-Crissa
Title: Re: TE Lots, Transit Switches, and You :)
Post by: mott on October 25, 2007, 07:17:09 PM
I think there is something wrong with your scales. A pedestrian walking at 3.5 kph (3500 meters per hour) would actually need 16/3500 = 0.0046 hours (ca 16.5 seconds) to walk through a 16-meters long tile, which sounds very reasonable. The time you suggest (1/3.5 = 0.286 hrs) is prohibitive. But I don't know if SC4 trip times are correctly scaled either.

"Time" is relative in SimCity.  So is "Speed."

Try not to think of Pedestrians as moving at 3.5 "kph."  Think of them as moving 3.5 "tiles per step."   Cars move 31 "tiles per step."   And so on.
"Entry Cost" is in Map Steps, not Minutes.

"Max Commute" is the maximum number steps that a Sim can accumulate during a commute trip to work and then back home.

Whatever "Max Commute" is set to, ends up being assigned the value of "255" when passed to the Commute Time graph.   
Therefore, 1 minute = (Max Commute / 255).  The definition of a "minute" depends on Max Commute.

The appropriate place to account for this and scale time back down to reality, is in the Commute Time Graph's exemplar, where a scalar variable is provided for the purpose.  Maxis/EA did not choose to use it (or chose not to), so the Commute Times appear ridiculous to the player, and impossible to interpret.

The formula for setting *that* scalar, is to decide whatever your Max Commute should work out to be in minutes, and using the formula:
Graph Data Multiplier = (Max Commute in Minutes / 255).   That gets you a real-time Commute Time display.  It also gives you the luxury of thinking of Speed in kph, and a Map Step Cost/Entry Cost of 1 == 1 minute on the graph).

Hope this helps.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: Diggis on January 24, 2008, 06:15:01 AM
That is one hell of a topic.   One of the things I got from it is that you shouldn't use road top Mass transit as they really need to allow all road traffic to pass?

What is the effect of having more than one transit type on a lot?  You have said that it's a no go, but not what it will do.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: jplumbley on January 24, 2008, 11:58:12 AM
That is one hell of a topic.   One of the things I got from it is that you shouldn't use road top Mass transit as they really need to allow all road traffic to pass?

What is the effect of having more than one transit type on a lot?  You have said that it's a no go, but not what it will do.

The reason there shouldnt be more than one transit type on a lot is because there is only one Transit Swicth Cost.  This Transit Swicth Cost is added to any Sim passing through the lot.  Ripplejet and I have been discussing how the Transit Switch Cost should be  used in the XTool.  And we have come up with a fairly useful calculation.

First off it is most optimal for a lot to be square not a rectangle, but it still can be a rectangle none the less.  The most important thing about a TE Lot is preventing Sims from using is as a shortcut.  So the easiest way to do this is by making sure the distance walking through the station is slower than walking past the station.  This means there will be one variable when calculating the Transit Switch Cost.  So, the MAXIS Speed for a Sim walking is 3.5 which means each tile has a "hop count" of approximately 0.29 (this is a constant).  Then we take the lot and find out what the length and width are, so if it is a 2x3 lot then we have a 2 length and a 3 width, now put this into that triangle equation you learned in highschool (x2+y2=h2).  So, heres the equation:

0.29 x sq. root(length2 +width2) = Transit Switch Cost

This will allow a sim to walk through a Station along the diagonal only because in RL you would walk through the Station if it was on your way.  I will prevent Busses, Trains, etc from using Station Lots as a shortcut because it is way slower.

Now, we have found one problem with these lots already.  IF the lots are too big, such as Ill Tonkso's rail stations the calculated Transit Switch Cost will be way too high.  These lots will have to be modded under a different set of rules.  For example the best way to do this would be to Transit Enable the lot so Pedestrian access can only be obtained through the south side of the lot (the entrance to the Station).  If this is done we can then calculate the Transit Switch Cost based on the South Side of the lot only, meaning it the lot is 8 tiles wide we will end up having a Transit Switch Cost equal to about 2.3 instead of 3.8 or higher depending on the length of the lot.  This Transit Switch Cost for larger lots may just cause Sims to not use the Transit Network you are building, but it needs to be there.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: wouanagaine on January 24, 2008, 03:46:04 PM
Hey, not sure, I'll have to redo my maths ( quite late for me atm ), but as SC4 does not know diagonals, I'm pretty sure you should use a manhattan distance and not an euclidian one
Title: Re: TE Lots, Transit Switches, and You :)
Post by: Andreas on January 24, 2008, 03:48:04 PM
This information is golden. :) As with many things, I'd say I know the basics of TE'd lots, but when it comes to the details, I'm rather lost - i. e. never cared much about the Transit Switch Cost or simply set it to 0.1, as I found in various lots. Having some kind of calculator (built into the X-Tool or elsewhere) would be very neat. Obviously, you should always use your common sense when figuring out the values, but at least those calculated values are a whole lot better than what Maxis provides with the Plugin Manager...
Title: Re: TE Lots, Transit Switches, and You :)
Post by: jplumbley on January 24, 2008, 03:50:41 PM
Hey, not sure, I'll have to redo my maths ( quite late for me atm ), but as SC4 does not know diagonals, I'm pretty sure you should use a manhattan distance and not an euclidian one


Ripplejet and I discussed this, and it should allow people to walk through a Station lot, but it should prevent, busses, trains etc from jumping.  This is a way we can allow for a nice median between sims walking past the lot and walking through the lot.  The Manhanttan distance will in effect start causing too high Transit Swtich Costs aswell.  Not enough time to explain.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: Diggis on January 25, 2008, 03:16:18 AM
The reason there shouldnt be more than one transit type on a lot is because there is only one Transit Swicth Cost.  This Transit Swicth Cost is added to any Sim passing through the lot.  Ripplejet and I have been discussing how the Transit Switch Cost should be  used in the XTool.  And we have come up with a fairly useful calculation.

OK, without worrying about the maths, if I use a road top mass transit, with the switch set to that of the pedestrians it will cause a slowdown for the vehicle traffic?  Not necessarily a bad thing if you see the effect bus stops have on traffic here.

If I use it with the traffic speed set to the vehicle speed then it will cause the pedestrians to sprint across the tile?  Again not a major as it's only 1 tile.

From what I understood from Motts discussion though is that it should be enabled for only one traffic type, is only busses, or only trucks.  But surely all road traffic is travelling at the same speed, for the network obviously, so that can't be the problem.  I may be confusing the issue here somewhat, I know I am confused.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: RebaLynnTS on January 26, 2008, 10:09:06 AM
Diggis ... You are not alone!
Title: Re: TE Lots, Transit Switches, and You :)
Post by: soulstealer on March 13, 2008, 04: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?
Title: Re: TE Lots, Transit Switches, and You :)
Post by: jplumbley on March 13, 2008, 04:45:34 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.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: RebaLynnTS on March 13, 2008, 09:54:24 AM
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.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: soulstealer on March 13, 2008, 12:22:50 PM
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.


Title: Re: TE Lots, Transit Switches, and You :)
Post by: RippleJet on March 13, 2008, 12:39:55 PM
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... ::)


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.


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...


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... ::)


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:
Title: Re: TE Lots, Transit Switches, and You :)
Post by: jplumbley on March 13, 2008, 03:53:10 PM
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.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: Crissa on March 14, 2008, 12:54:27 AM
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.

-Crissa
Title: Re: TE Lots, Transit Switches, and You :)
Post by: Starmanw402007 on March 28, 2008, 08:10:16 PM
Hey JP, will we be able to do missions with these transits? and NOT timeout on us halfway through the mission?
Title: Re: TE Lots, Transit Switches, and You :)
Post by: RippleJet on March 28, 2008, 08:18:20 PM
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.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: sffc on May 09, 2008, 11:59:29 PM
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
Title: Re: TE Lots, Transit Switches, and You :)
Post by: Swamper77 on May 10, 2008, 12:19:08 AM
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.

-Swamper
Title: Re: TE Lots, Transit Switches, and You :)
Post by: NetPCDoc on June 01, 2008, 12:51:28 PM
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.

BTW:

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)

-NetPCDoc
Title: Re: TE Lots, Transit Switches, and You :)
Post by: z on July 16, 2008, 01:31:08 AM

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.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: z on July 16, 2008, 04:36:42 PM
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?
Title: Re: TE Lots, Transit Switches, and You :)
Post by: z on July 16, 2008, 06:06:39 PM
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.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: z on July 16, 2008, 10:52:00 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.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: z on September 05, 2008, 11:10:19 PM
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:

Quote
That'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 (http://theory.stanford.edu/~amitp/GameProgramming/Heuristics.html).  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:

Quote
Transit 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 (http://sc4devotion.com/forums/index.php?topic=2665.msg81455#msg81455), 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.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: Chrisim on September 07, 2008, 04:19:44 PM
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 ...
... 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.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: z on September 07, 2008, 05:14:33 PM
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.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: RippleJet on September 11, 2008, 11:03:47 PM
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:

(http://i232.photobucket.com/albums/ee198/RippleJet/ZvsPlum-Census32years.jpg)

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

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.


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:



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.

(http://i232.photobucket.com/albums/ee198/RippleJet/ZvsPlum-JobsandPop32years.jpg)

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:

(http://i232.photobucket.com/albums/ee198/RippleJet/ZvsPlum-CommuteTime32years.jpg)

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:

(http://i232.photobucket.com/albums/ee198/RippleJet/ZvsPlum-CommuteTime38years.jpg)

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:

(http://i232.photobucket.com/albums/ee198/RippleJet/ZvsPlum-CommuteTime43years.jpg)

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).

(http://i232.photobucket.com/albums/ee198/RippleJet/ZvsPlum-CommuteTime45years.jpg)

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:

(http://i232.photobucket.com/albums/ee198/RippleJet/ZvsPlum-CommuteTime48years.jpg)

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:

(http://i232.photobucket.com/albums/ee198/RippleJet/ZvsPlum-CommuteTime53years.jpg)

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:

(http://i232.photobucket.com/albums/ee198/RippleJet/ZvsPlum-JobsandPop58years.jpg)
Title: Re: TE Lots, Transit Switches, and You :)
Post by: z on September 12, 2008, 05:12:43 AM
My hat's off to you, RippleJet - that's a beautifully and precisely designed, executed, and documented experiment, from start to finish.  For me, the math I did was completely conclusive, and the testing I did of cities in the aggregate, complete with commute time graphs that showed the same pattern that yours did, supported those conclusions entirely.  But there's nothing like a highly controlled test case, such as the one you used, to make something completely clear.  I am very grateful to you, and I'm sure that what you've done will be of help to all those who work with TE lots.

As for the Transit Switch Entry Cost, basing it on pedestrian speed would seem to work for roadside transit stations.  For TE Lots, as you found, it needs to be set much lower.  For RTMT, through experimentation Cogeo found that a value of 0.02 worked best for these lots; it essentially made them have no effect on commute time for cars.  It turns out that this value translates to something very close to the speed of cars through the lots in the current simulators.  The value you used for Transit Switch Entry Cost essentially does the same thing, adjusted for the lower speed of cars in the vanilla simulator.  But Transit Switch Entry Cost needs to be based on the type of transit lot and the travel type speeds, as your experiment so clearly showed; no single value is best for all cases.

As for the building query numbers, what you say makes perfect sense, and I would like to edit my post to reflect what you have shown.  What I stated in my post was based on my tests, but they were clearly only a subset of the tests you ran, which showed a more complete picture.  So one final question before I edit this post:  Is there a way to determine the actual occupancy of a particular building?

Once again, thanks for all the work you did here, which will be quite beneficial to many.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: JoeST on September 12, 2008, 05:27:53 AM
z: the actual number of ocupants is calculated by the number of people in the transit query. I think

Joe

EDIT: didn't read Tage's post properly, silly me. its about 40-60% as Diggis states below.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: Diggis on September 12, 2008, 05:30:44 AM
z: the actual number of ocupants is calculated by the number of people in the transit query. I think

Joe

Nope, from what I got from Tage's post thats 40 - 60% of the total depending on life expectancy.  The rest are babies or retirees.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: RippleJet on September 12, 2008, 05:50:33 AM
So one final question before I edit this post:  Is there a way to determine the actual occupancy of a particular building?

As Joe and Shaun already pointed out, no... :(
The route query shows the workforce, but also this number is a rounded integer.
And the total occupancy of that house then depends on the life expectancy in it
(which we also cannot know what it is).

Besides, I'm pretty sure the game calculates all residents as floats, not integers.
Thus, there are probably some fractional inhabitants in all buildings... ::)


The rest are babies or retirees.

And those modding SimCity at work and testing all through the night... :D
Title: Re: TE Lots, Transit Switches, and You :)
Post by: Crissa on January 17, 2009, 01:19:53 AM
Still leaves me wondering why the bus routes with RTMT run through the lots instead of away from the lot.  If they went away from the lot to other lots, it'd make sense, but for some reason, busses load up people and then go in the direction the people came from even when there's no connecting roads let alone bus stops in that direction.

Busses seem to require a continuous loop past a bus stop (or through a RTMT lot), and then follow the road making no turns unless it has no other choice.  Also, people seem to only get onto busses that arrive past the stop the first time - so if more than one bus loops past, or a bus loops past more than once they get on the first time, ride to the end to the street, then back past the bus stop.

In the real world, this would mean people would be getting on and off the bus every two blocks (a minimum required by the american disabilities act), basically a second network atop the first. But that doesn't happen in SC.

Which leaves me wondering how to make busses work at all in SC.  The busses seem to take no turns, which mean of it would be shorter to turn left to get to the next bus stop, they just don't do that, the busses never seem to optimize their loops.

-Crissa
Title: Re: TE Lots, Transit Switches, and You :)
Post by: z on January 17, 2009, 02:18:40 AM
Are you talking about the automata (the animated buses), or the actual bus routes?  It sounds like the former, because in actuality, there are no buses in SC4 (or any other type of vehicles, for that matter).  When a pedestrian Sim reaches a bus stop, he or she just starts acting like a single-passenger bus until the destination bus stop is reached, whereupon the Sim starts acting like a pedestrian again.  There are no buses loading up people, and there are no buses driving by.  And once a Sim gets on a bus, there are no stops until the destination bus stop is reached.

I've also seen buses make optional turns all the time; if they didn't, there'd be something seriously wrong with the traffic simulator.  If you can demonstrate what you're desribing with actual bus routes using the route query tool, please post a picture.  Thanks!
Title: Re: TE Lots, Transit Switches, and You :)
Post by: djvandrake on August 17, 2009, 12:46:54 PM
Sorry for reviving a discussion that's been quiet for 6 months, but I just read this entire thread and I'm unclear on a few things that I think could have a big impact.  This thread is very enlightening and I'm grateful to those who have contributed so much effort. On to the question.

From the discussion, I gather that having a single lot be enabled for multiple types of a transit switch is bad, true statement?  And this is due to the propensity of pedestrians using the lot as a short cut, forcing you to set the transit switch cost too high for the higher speed types of transit (i.e. HSR or monorail).  Since only one cost can be assigned, then there's no way to make a station efficient for high speed rail and prevent pedestrian shortcuts.  So why does it matter if a ped uses the station as a shortcut?  How would this be a large negative to their pathfinding?  If I locate my station in an area where pedestrain shortcuts is not a big issue, then is there any reason why I can't make a large station have switches for HSR, Bus, and Subway?    I have seen lots like this before and they seem like such a boon to efficiency, yet I've not had the opportunity to test them out.

What I have done is created a custom lot for a large HSR station.  It has a high passenger capacity (70,000) served by 4 lines.  The lot is 8 x 14 width to length.  Having the lot be transit enabled for rail traffic only, the transit switch cost would be essentially zero based on the speed of the rail.  Where I run into huge problems is serving the sims after they leave the station.  I can ring the station with bus stops, and they all go to the closest two stations and completely overwhelm them causing a bottleneck. (Closest to the end of the station where the trains enter, in this case the west side (long axis) and the bus stops are on the nort and south of the 8 tile width).  I've built a smallish test region where I have two cities that are served only by HSR.  7,000 sims commute into the station and either walk or take the bus once leaving the station, but again they all choose the bus-stops at the nearst point and overwhelm it.

Would it not make much more sense to transit switch enable my large station for HSR, AND for Bus AND for Subway with all the switches having the same capacity?  This way all the traffic that enters the station via the HSR isn't trying to leave the station via two small bus stops?  And if this station is located such that through traffic not related to those transit switches would be minimal, then would it not be best to set the transit entry cost based on the speed of the buses?

Thank you.

Edit:  http://sc4devotion.com/csxlex/lex_filedesc.php?lotGET=1610 (http://sc4devotion.com/csxlex/lex_filedesc.php?lotGET=1610) Here is a link to a multi switch type of station available on the LEX like I referred to above.  Mine is essentailly the same.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: z on August 18, 2009, 05:47:49 AM
From the discussion, I gather that having a single lot be enabled for multiple types of a transit switch is bad, true statement?

Not really.  Although Mott initially said something along these lines, it has become clear in the intervening time that these transit switches are not so much "bad" as rather buggy and difficult to work with.  The game was not designed with them in mind.  But they can be made to work properly; for example, RTMT uses a lot of them.

Quote
  And this is due to the propensity of pedestrians using the lot as a short cut, forcing you to set the transit switch cost too high for the higher speed types of transit (i.e. HSR or monorail).  Since only one cost can be assigned, then there's no way to make a station efficient for high speed rail and prevent pedestrian shortcuts.

Shortcutting is one problem, but it's not really all that serious if the transit switch entry cost is set properly; in the case you mention, it should be set to .96/speed, where "speed" is the speed of the HSR or monorail.  The pedestrians may move through the station too fast, but this does not have a real effect on game play, especially in Simulator Z.

Quote
  So why does it matter if a ped uses the station as a shortcut?  How would this be a large negative to their pathfinding?

For traffic simulators other than Simulator Z, the commute time limit is set low enough so that this shortcutting can throw off various pathfinding calculations in a way that can have some effect on the overall game play.  Nevertheless, no one has ever shown that these differences are significant.

Quote
  If I locate my station in an area where pedestrain shortcuts is not a big issue, then is there any reason why I can't make a large station have switches for HSR, Bus, and Subway?    I have seen lots like this before and they seem like such a boon to efficiency, yet I've not had the opportunity to test them out.

No, you should have no real problems.  In fact, I think that this is definitely the way to go.  Transit switch points are buggy, though; ones that look like they should work often don't, especially the more complex ones.  I suggest that you look at the transit switch points in RTMT V3.60 for guidance when this version is released.  And personally, I wouldn't worry about the pedestrian shortcuts in any case, as long as you set the transit switch entry cost as I described above.

Quote
What I have done is created a custom lot for a large HSR station.  It has a high passenger capacity (70,000) served by 4 lines.  The lot is 8 x 14 width to length.  Having the lot be transit enabled for rail traffic only, the transit switch cost would be essentially zero based on the speed of the rail.  Where I run into huge problems is serving the sims after they leave the station.  I can ring the station with bus stops, and they all go to the closest two stations and completely overwhelm them causing a bottleneck. (Closest to the end of the station where the trains enter, in this case the west side (long axis) and the bus stops are on the nort and south of the 8 tile width).  I've built a smallish test region where I have two cities that are served only by HSR.  7,000 sims commute into the station and either walk or take the bus once leaving the station, but again they all choose the bus-stops at the nearst point and overwhelm it.

I can see where this would be a problem.  Basically, your pedestrians are traveling at monorail speed, even if you take my suggestion about the TSEC.  Having multiple bus stops around the station complicates things considerably; there's no easy way to get that right.

Quote
Would it not make much more sense to transit switch enable my large station for HSR, AND for Bus AND for Subway with all the switches having the same capacity?  This way all the traffic that enters the station via the HSR isn't trying to leave the station via two small bus stops?  And if this station is located such that through traffic not related to those transit switches would be minimal, then would it not be best to set the transit entry cost based on the speed of the buses?

Yes, you're exactly right with the first part of your solution.  However, there's only one transit switch point per station, and only one capacity.  The capacity of 70,000 that you chose should be about right for such a station.  But it's important, especially with monorails, that the TSEC be set according to their speed.  Otherwise, you'll see a real dropoff in their usage.  True, this TSEC is too high for buses, but it's only for a few squares, and it should have no ill effects.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: djvandrake on August 18, 2009, 12:08:43 PM
Thank you Z for your reply and advice.  Much appreciated.  I did further testing with my station and enabled it for bus transit switch and that made a huge difference.  Sims now go to all 4 corners to catch a bus depending on where their eventual job destination is, and that alleviated a lot of the traffic bottleneck.  Subway didn't work well at all, and I may separate that out _it also caused my menu to malfunction so I couldn't see usage numbers  &ops).  I've got the station serving 18,000 now, and it flows smoothly serving as a bus station too.

Speaking of RTMT V3.60 that you mentioned.....Is there an anticipated release date?  I just started using them in my cities after reading this thread and they're wonderful.  &apls  I'm still not clear if the capacity numbers I see include the cars that pass through the lot as well as the users of the buses. But, from query of the commute path to nearby employment, I can see the station is getting a good deal of use.  I'm now a big fan of these RTMT stations.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: z on August 20, 2009, 04:28:42 AM
Thank you Z for your reply and advice.  Much appreciated.

You're welcome!

Quote
Subway didn't work well at all, and I may separate that out _it also caused my menu to malfunction so I couldn't see usage numbers  &ops).  I've got the station serving 18,000 now, and it flows smoothly serving as a bus station too.

Subways are by far the most difficult parts of transit switch points to get right - they're notoriously buggy.  If that's your only problem, I can give you a file with a set of transit switch points that will work for your station.  But I don't understand what you mean by your menu malfunction.  Are you talking about the queries?  What exactly did you do here?

Quote
Speaking of RTMT V3.60 that you mentioned.....Is there an anticipated release date?  I just started using them in my cities after reading this thread and they're wonderful.  &apls  I'm still not clear if the capacity numbers I see include the cars that pass through the lot as well as the users of the buses. But, from query of the commute path to nearby employment, I can see the station is getting a good deal of use.  I'm now a big fan of these RTMT stations.

I'm glad you like RTMT!  There is no release date for V3.60 as such - release dates are illegal in SC4.  ;D  However, I think it's safe to say that you'll see it sometime next month.  And the capacity and usage numbers include everything passing through the lot.
Title: Re: TE Lots, Transit Switches, and You :)
Post by: djvandrake on August 20, 2009, 12:14:01 PM

Subways are by far the most difficult parts of transit switch points to get right - they're notoriously buggy.  If that's your only problem, I can give you a file with a set of transit switch points that will work for your station.  But I don't understand what you mean by your menu malfunction.  Are you talking about the queries?  What exactly did you do here?


Yes, I am referring to the queries.  I'm not experienced enough yet to understand how I broke it or how to fix it.  %confuso  I've now manged to do the same thing with my RTMT lots.  :-[  I love the functionality of them, but I'm really picky about appearance, and the little blue bus shelter just didn't do at all.  (I know size and space is a real issue for them) I edited all the lots in LE and put in the bus shelter that I've used throughout my urban areas (a nice blue and silver glass shelter) and after doing so my query menus don't work at all.  When I query the lots I get the sound effect and something generic but the custom menu for RTMT that shows usage isn't there.  I use the RH drive, no custom textures version of the lots with NAM simulator Z. ( :thumbsup:)

I would be very interested in those subway transit switch points too.   I'm debating making a few custom type super subway stations that can handle the traffic from the station (like a 1 x 4 with multiple stairs and such) since I've now become hopelessly addicted to the lot editor.  ::)

Thanks again!  ;D

Quote
I'm glad you like RTMT!  There is no release date for V3.60 as such - release dates are illegal in SC4.  ;D  However, I think it's safe to say that you'll see it sometime next month.  And the capacity and usage numbers include everything passing through the lot.

Looking forward to it!!!
Title: Re: TE Lots, Transit Switches, and You :)
Post by: z on August 20, 2009, 04:12:21 PM
The queries are controlled by the property "Query exemplar GUID" in the exemplar, which either points to a standard Maxis query, or to a custom query, which would exist in the form of a "UI" subfile somewhere, along with one or more associated PNG files.  It's in this area that you must have messed something up.

Following is the type of switch point that you'll need, taken from an RTMT station.  The one change you'll have to make to the transit switch point is to change all occurrences of "el train" to "monorail," but then everything should work.

Transit Switch Point   0xE90E25A1   Uint8   76   Outside-to-Inside,North+South,Drive Car,Drive Car,Inside-to-Outside,North+South,Drive Car,Drive Car,Outside-to-Inside,North+South,Ride Bus,Ride Bus,Inside-to-Outside,North+South,Ride Bus,Ride Bus,Outside-to-Inside,North+South,Freight Truck,Freight Truck,Inside-to-Outside,North+South,Freight Truck,Freight Truck,Outside-to-Inside,North+South,Ride El Train,Ride El Train,Inside-to-Outside,North+South,Ride El Train,Ride El Train,Outside-to-Inside,All Sides,Walk,Walk,Outside-to-Inside,North+South,Ride Bus,Walk,Inside-to-Outside,All Sides,Ride Subway,Walk,Outside-to-Inside,All Sides,Walk,Ride Subway,Inside-to-Outside,North+South,Walk,Ride Bus,Outside-to-Inside,All Sides,Walk,Walk,Inside-to-Outside,All Sides,Walk,Walk,Outside-to-Inside,All Sides,Ride El Train,Walk,Inside-to-Outside,All Sides,Walk,Ride El Train,Inside-to-Outside,All Sides,Walk,Ride Subway,Outside-to-Inside,All Sides,Ride Subway,Ride El Train   
Title: Re: TE Lots, Transit Switches, and You :)
Post by: djvandrake on August 20, 2009, 08:21:13 PM
Wow!  That was a bit more that I expected, and very glad to have expert advice.  Thanks again Z.  :thumbsup:
Title: Re: TE Lots, Transit Switches, and You :)
Post by: z on August 21, 2009, 12:28:58 AM
You're welcome!  That's just what you get when you use the Reader's "Copy all properties to clipboard" function.  But I'm so used to copying switch points around for RTMT stations that I forgot to remove the through road traffic switches for you.  Here's the corrected switch point (you still need to make the substitution I mentioned above):

Transit Switch Point   0xE90E25A1   Uint8   76   Outside-to-Inside,North+South,Ride El Train,Ride El Train,Inside-to-Outside,North+South,Ride El Train,Ride El Train,Outside-to-Inside,All Sides,Walk,Walk,Outside-to-Inside,North+South,Ride Bus,Walk,Inside-to-Outside,All Sides,Ride Subway,Walk,Outside-to-Inside,All Sides,Walk,Ride Subway,Inside-to-Outside,North+South,Walk,Ride Bus,Outside-to-Inside,All Sides,Walk,Walk,Inside-to-Outside,All Sides,Walk,Walk,Outside-to-Inside,All Sides,Ride El Train,Walk,Inside-to-Outside,All Sides,Walk,Ride El Train,Inside-to-Outside,All Sides,Walk,Ride Subway,Outside-to-Inside,All Sides,Ride Subway,Ride El Train
Title: Re: TE Lots, Transit Switches, and You :)
Post by: b22rian on September 20, 2010, 06:57:15 PM
I just wanted to say, that I read this thread for about the 10 th time..
And its my favorite thread in all of Sim devotion..

I would like to belatedly thank all those great people in our community who contributed to this thread..

And My special thanks go out to Z (Steve) and Mott, for creating with much time , patience and hard work..,
some of the best postings that have ever been posted on devotion . And in there painstaking efforts to make one
of the the complex areas in our game understandable for all of us  &apls

Thanks much , Brian
Title: Re: TE Lots, Transit Switches, and You :)
Post by: Wiimeiser on January 12, 2011, 03:56:24 AM

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.


I wonder if EA knows about this issue?
Title: Re: TE Lots, Transit Switches, and You :)
Post by: Tarkus on January 12, 2011, 02:40:08 PM
I wonder if EA knows about this issue?

They do.  Paul Pedriana (lead programmer for SC4) even posted about it over at ST a few years back.

-Alex
Title: Re: TE Lots, Transit Switches, and You :)
Post by: Wiimeiser on January 13, 2011, 04:37:02 PM
Really? Can you point me to that particular post?