• Welcome to SC4 Devotion Forum Archives.

NAM Traffic Simulator Development and Theory

Started by z, August 02, 2008, 05:07:50 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Tarkus

Well, I've done a little preliminary testing on the new "Simulator Z" (as I will call it), and have compared it with data obtained from "Simulator A Hard", and have a few observations--I'll have a little bit more detailed report in a bit, with some pics.

-The region I used for testing has most of its population (roughly 160,000) spread across three adjacent city tiles, which have two routes that travel the entire length of them--one being an RHW (mostly an RHW-4, with the occasional RHW-6S setup for merge lanes at interchanges), the other being an Avenue/TLA-5. There is absolutely no mass transit of any kind in the region.

-With both the "A Hard" and "Z" Simulators, I have noticed sims commuting across multiple city tiles.  The Sims tended to utilize more of the neighbor connections.  Neither resulted in any commuter loops.  The "A Hard", however, did actually seem to allow the commuters to go further into the final city tile of the commute.

-Most of the congestion I saw with "A Hard" was along arterial routes, whereas it was at Street intersections with the "Z" Simulator.

-Simulator Z seemed to result in higher pedestrian traffic volumes for the most part.

-Simulator Z does indeed exhibit an additive congestion calculation (Morning+Evening), which I was able to clearly discern with my modified Congestion DataView (attached here, in case anyone wants to try it--it goes down to 25% and uses a really radical color ramp). 

-The actual Commute Time Graph display showed a dramatic difference--it was dramatically lower with the "Z" Simulator, though this may simply be an the result of the way in which "A Hard" is relaying commute time info to the graph (this would make sense in light of the fact that the Trip Length To Minutes Multiplier is set to 1 in Simulator Z, and 10.54 in Simulator A Hard).

-I have also had a chance to test Simulator Z on both wider RHWs (an RHW-8) and NWM networks (TLA-5s).  I didn't really notice anything with the TLA-5s, as they were nowhere near the theoretical capacity (I'd have to lower the Road Capacity in order to have a more conclusive reading). 

The RHW-8, however, did not function correctly with Simulator Z installed.  Using the RHW-8 with the "A Hard" Simulator allows for a "spreading" effect upon reaching the wider stretch, in which the overall traffic volume is split between the two tiles that make up each half of the highway, as would happen in RL.  With Simulator Z, however, the traffic stayed on the "inside" tile and never attempted to cross over--in effect, the Simulator Z is not compatible with the wider RHWs. 

This is an issue that qurlix, my predecessor on the RHW, ran into when he created an RHW-10 prototype while using the old NAM Simulators.
Overall, Simulator Z struck me as functioning much like the old NAM Simulators (which were basically based upon the same engine as the Maxis, with difference in capacity and pathfinding efficiency), but with a much longer range.  A and Z seemed to ultimately result in some fairly similar patterns in terms of the routing through the region, but the "bottlenecks" in the system were in drastically different places.

I'll have some hard data to show a bit later.

-Alex (Tarkus)

z

#41
Thanks for your comments, Alex - I found them quite helpful.  In response, I have some comments and questions of my own.

Quote from: Tarkus on October 06, 2008, 12:39:28 AM
-With both the "A Hard" and "Z" Simulators, I have noticed sims commuting across multiple city tiles.  The Sims tended to utilize more of the neighbor connections.  Neither resulted in any commuter loops.  The "A Hard", however, did actually seem to allow the commuters to go further into the final city tile of the commute.

When you say, "The Sims tended to utilize more of the neighbor connections," are you talking about both of these two simulators, or just Simulator Z?

The last sentence is somewhat unexpected, given the longer range of Simulator Z.  Do have any idea what would account for this?  It's possible that it's an artifact of the way your test region is set up; more data from others would be helpful here.

Quote
-Most of the congestion I saw with "A Hard" was along arterial routes, whereas it was at Street intersections with the "Z" Simulator.

Yes, I have the intersection effect tuned up a bit higher.  I don't have a lot of intersecting streets, so I didn't notice this as much as you did.  I may have to tone the intersection effect down a bit here.

Quote
-Simulator Z seemed to result in higher pedestrian traffic volumes for the most part.

I've noticed this too; I'm pretty sure it's a direct result of the higher maximum commute times.

Quote
-Simulator Z does indeed exhibit an additive congestion calculation (Morning+Evening), which I was able to clearly discern with my modified Congestion DataView (attached here, in case anyone wants to try it--it goes down to 25% and uses a really radical color ramp). 

Yes, this is how the vanilla Maxis traffic simulator works, too.

Quote
-The actual Commute Time Graph display showed a dramatic difference--it was dramatically lower with the "Z" Simulator, though this may simply be an the result of the way in which "A Hard" is relaying commute time info to the graph (this would make sense in light of the fact that the Trip Length To Minutes Multiplier is set to 1 in Simulator Z, and 10.54 in Simulator A Hard).

The Trip Length To Minutes Multiplier doesn't do anything at all.  Simulator Z comes with its own Commute Time Graph exemplar attached (as mott recommended); the Graph Plot Scale property is what actually determines the graph scale.  I used mott's formula to calculate the number I use for my simulator.  The numbers would be expected to be lower than the standard graph, as Commute Trip Max Time is only 8.5 minutes (one way) in Simulator A.  It's possible that mott's formula is not correct, though, in which case Graph Plot Scale  would have to be adjusted.

Quote
-I have also had a chance to test Simulator Z on both wider RHWs (an RHW-8) and NWM networks (TLA-5s).  I didn't really notice anything with the TLA-5s, as they were nowhere near the theoretical capacity (I'd have to lower the Road Capacity in order to have a more conclusive reading). 

Well, that's encouraging; if I moderate the intersection effect a bit, as I mentioned above, that may be all that's necessary to get it to work with TLA's.

Quote
The RHW-8, however, did not function correctly with Simulator Z installed.  Using the RHW-8 with the "A Hard" Simulator allows for a "spreading" effect upon reaching the wider stretch, in which the overall traffic volume is split between the two tiles that make up each half of the highway, as would happen in RL.  With Simulator Z, however, the traffic stayed on the "inside" tile and never attempted to cross over--in effect, the Simulator Z is not compatible with the wider RHWs. 

This is quite unfortunate.  I had not tried the simulator with RHW-8.  Clearly, I need to fix this.  Does this work with Simulators A and B simply because of the difference in the Congestion vs. Speed curve?  Or is there something else responsible?  Approximately what capacity were these roads running at when you noticed this?

Quote
Overall, Simulator Z struck me as functioning much like the old NAM Simulators (which were basically based upon the same engine as the Maxis, with difference in capacity and pathfinding efficiency), but with a much longer range.  A and Z seemed to ultimately result in some fairly similar patterns in terms of the routing through the region, but the "bottlenecks" in the system were in drastically different places.

When you say "same engine," I'm a little confused.  Isn't there only one engine, namely the Maxis simulator code, with all the simulators merely being adjustments of various properties belonging to it?

My overall results have been different, undoubtedly due to the difference in the cities involved.  When Simulators A and B first came out, I thought, "Great!  I could really use a better simulator!"  So I started running Simulator A (Easy) in one of my cities, which promptly started to fall apart.  So I backed it out.  This is what led to the creation of Simulator Z.

One thing your results do seem to confirm, though, is something that I said early on in this thread:  that Simulator Z is not designed to be a replacement for Simulators A and B.  I think that each simulator has its strengths in certain situations.  You've also identified some areas I need to work on, for which I'm grateful.  It will also be very useful to hear from other people using this simulator in different situations, and I encourage people to post their experiences.  So thanks for taking the time to test this, and to report extensively on your results.

RippleJet

Quote from: z on October 06, 2008, 02:24:55 AM
The Trip Length To Minutes Multiplier doesn't do anything at all.

Some testing performed last night seems to confirm that! ;)


Quote from: z on October 06, 2008, 02:24:55 AM
Simulator Z comes with its own Commute Time Graph exemplar attached (as mott recommended); the Graph Plot Scale property is what actually determines the graph scale.

That's exactly how the RCI graph works as well.
The graph has to be scaled in accordance with the max/min values set in the RCI exemplars.
And there is no information being conveyed from the simulator to the graph about these max/min values.

b22rian

Quote from: Tarkus on October 06, 2008, 12:39:28 AM


-Simulator Z does indeed exhibit an additive congestion calculation (Morning+Evening), which I was able to clearly discern with my modified Congestion DataView (attached here, in case anyone wants to try it--it goes down to 25% and uses a really radical color ramp). 



I'll have some hard data to show a bit later.

-Alex (Tarkus)

Thanks a lot Alex for the new congestion data view..
I tried it in my largest city and seems to work great !
.. and also I see you have figured out how to display the reds now also.. &apls

I certainly didnt expect you to do anything with this..any time soon, as I know you are spending just
about all your time with the RHW.. version 21..
So this is greatly appreciated..and a great addition to the game..

Thanks, Brian

z

Thinking more about Alex's comments, I think I see the solution to the major issues he identified, and possibly the minor ones as well.  The fixes are easy to make; I'll be testing them out on my cities, and if all goes well, I should have an Alpha 2 release later today, or tomorrow at the latest.  So if you're currently running Alpha 1 and it works fine, you can certainly keep running it.  But if you were planning to download it, I'd recommend holding off until Alpha 2.  Also, there's no need to post further results about Alpha 1, as I expect some important behaviors to change significantly with Alpha 2.

MassHelper

Plz include a readme to help out others

:) Mass
SC4 Modders' Assistant and Adviser

z

#46
At the end of this post, I have attached the Alpha 2 release of Simulator Z.  It contains a short ReadMe file containing the basic information needed to install it.

As promised in my last post, this version contains fixes for the main issues that Alex identiied in his testing.  Specifically, it should now support all forms of RHW.  In the previous version, I had spread out travel paths by lowering the Pathfinding Heuristic.  Unfortunately, as jplumbley mentioned and Alex demonstrated, this is not sufficient to spread out the traffic on the wider RHW's.  The reason for this is clear; the modest speeding premium I gave to uncongested traffic, though realistic, was not sufficient to divert the Sims to the outer lanes.  So for now I am doing what is known to work, and making the highest speeding premium 40%.  Fortunately, increasing the speed values on the high end of the congestion vs. speed curve does not trigger the congestion display bugs.  However, I think that Sims should be warned that if they are going to travel at the higher speeds, they should be sure to get themselves high-quality radar detectors.

When thinking about Alex's finding that Simulator A seemed to allow the commuters to go further into the third and final city tile of the commute in his region, the only thing I could think of as a possible cause for this behavior was the speed premium in the congestion vs. speed curve.  With that premium equalized, it will be interesting to see if that behavior persists.

The only other change I made was a slight decrease in the intersection effect, which Alex noted as congestion at his street intersections.  The congestion will still be there, although it will be somewhat less; it's supposed to be there.  Even in intersections that show up as solid red, in this simulator that simply means that for that one square, traffic speed will be reduced by 70%.  That's far less of a delay than a four-way stop would involve.  It also corresponds roughly to the slowdon a car would experience when making a turn.  Unfortunately, the intersection effect is a very blunt instrument, and cannot be adjusted for different networks or different types of intersections (as our friends on the TLA project know all too well).  I have tried to set this at as realistic a value as I could.  I went through my own cities and found a number of street intersections, and none of them was heavily congested - most were not congested at all.  So I think that input from a number of sources will be necessary to decide what is best here.  Another possibility is to raise the capacity of streets slightly; again, user input will determine whether this is done.

So here's the new version; if you're upgrading from Alpha 1, you simply need to remove the Alpha 1 version and replace it with this one.  And Alex, your feedback was extremely valuable, so if you wouldn't mind running the same tests again, I would appreciate it greatly.  And for everyone else, the more people who download this simulator, try it out, and post their experiences (both good and bad), the better this simulator can be made.

EDIT:  This version of the traffic simulator has been superseded.  You can get the current version here.

MassHelper

What are the traffic controller files that are req'd for removal??

P.S. Maybe a cleanitol text file might help out...  :-[

:) Mass
SC4 Modders' Assistant and Adviser

z

All the traffic simulators start with NetworkAddonMod_Traffic_Plugin, and are usually found in the Network Addon Mod folder.  (Another place to check is the z_CAM folder, if it exists.)  Any such files should be moved out of the Plugins folder tree before installing this simulator.

A Cleanitol file will eventually be included if this simulator is formally released; in alpha releases such as this one, where the installation is fairly simple, they are often skipped.  For example, the alpha releases of Simulator B had neither a ReadMe nor a Cleanitol.

MassHelper

#49
alright  :-[

:) Mass
SC4 Modders' Assistant and Adviser

0rion79

Z, your traffic simulator is just GREAT!

I have tested it on some of my largest cities and some of them where affected by commuters loop, even if I have built them placing inter-city connections in the middle of city borders to prevent it, factor that, with Simulator B, was useless.

Also, I have seen that now Sims are much more skilled in finding appropriate jobs for their educational and social level: at last $ Sims go working in farms and dirty industry, that before were ignored by them and, especially, when Sims move out from the starting city, it is because they really know where to go working and don't commute as blind beings, without any destination, but go stright to their new working places.

I can say this because I have played again a smaller reproduction of my own city, Cagliari, that is a dense 350.000+ souls formed almost entirely by residential buildings with commercial facilities at ground floor, while all the industry (no matter what kind) is quite far away and often is just in other provinces.
In fact, before it was affected by "lack" of working places even if Raphael version of Census repository was telling me that it was full of vacant jobs. Well, after replacing NAM simulator B, everything flew fine and I have fixed all problems of unemploymend caused by bad inter-city pathfinding! Sims now are employed even into plopable I-M and I-D lots that, before, where ignored.
Instead, in other cities that were really over-populated, I have been able to recognize that jobs were missing and that it was not the inattitude of Sims to find employment.
If you want, you can take a look to that city here: http://www.simtropolis.com/forum/messageview.cfm?catid=36&threadid=93825&highlight_key=y&keyword1=cagliari

Ah, of course I have even seen some backdraw (or positive effect). it depends from the point of view. In one of my cities, I have a ultra-mega-overuse of train stations, that reached 57.000 Sims at once on the same station. I have even downloaded the Simtropolis Train Station that has a capacity of 30.000 passengers, but 57.000 is just too much! But, at last, I don't have over-used rail lines or subway lines. AT LAST!! :)

Instead, about commute time...
Simulator B easy - Simulator Z
City 1 = 85 >> fro 4 to 7
City 2 = 120 >> 6
City 3 = 250+ >> 20+
City 4 = 300+ >> 15
These are all high-density cities on large maps, that works as connection center among several satellite cities and villages on smaller maps.

I know that Z's graphs are made usind different parameters, but still there has been a sensibile improvement in commute speed. Looking from the graphs, it was like if the game has reseted the commuters phat and has begun to calculate them starting over, from the beginning. If the beginning was 0, even the highest scores reached by the graph where not so far away from the starting score and still not so high as the ones with Pathfinder B that I was using before and then, even if I guess that scores among NAM graph and Z graph cannot be compared directly (at least I can't), over all commute time is much shorter and my Sims don't complain anymore about commute times.

Also, I have tried to play on small and middle-size maps, where commute time became 0.6 or even near to 0. It is like if Z graphs shows only effective commute time between a city and another, like if the time needed for Sims to find work in the city where they have both a flat and a work is not considered.

In fact, I did a test with a city of mine called "new Venetia" that is a huge island in the middle of the river, with no bridges. It is self sufficient and commute time was 0. Instead, when I added a ferry, the commute time began to increase to 10, more or less. It looks like that Z mod has even fixed a nasty problem with ferries, where Sims run into them as lemmings and then were moved by sea fluxes instead than actively looking for employment.

Now, a couple of questions.
1 - what is RHW? I have seen it here and there on this post but I don't know the meaning.
2 - in your new congestion & volume view, I have seen that, when I go to see usage, many streets and even highways turns "red" (or deep orange) in the traffic volume view,, even if they are green in the congestion view,. I remember that, in the volume view, there was a note like "*based on street capacity". What does it mean? If I see an highway turning red in the volume view, and NOT in the congestion view, do I have to worry about?

Thank you! And my best compliments again for your great work! I will keep using it!

MassHelper

RHW = Rural Highway  :-[
As for your second question, my friend, you don't have to worry about the congestion, since they wrote in the Maxis handbook (included with the game) that you can have high volume on a transit path, but you would not have any congestion.
Street cap question...  :-[ not rly sure about that, u might want to ask the transit guru (a.k.a. jplumbley, Jonathan ---> Warrior (Smart kid, :), I know), Alex (Tarkus), or the creator himself (U no who I am talking about... $%Grinno$%))

:) Mass
SC4 Modders' Assistant and Adviser

z

Quote from: 0rion79 on October 12, 2008, 08:20:23 AM
Z, your traffic simulator is just GREAT!

Glad you like it!  And thanks for the feedback.

QuoteAh, of course I have even seen some backdraw (or positive effect). it depends from the point of view. In one of my cities, I have a ultra-mega-overuse of train stations, that reached 57.000 Sims at once on the same station. I have even downloaded the Simtropolis Train Station that has a capacity of 30.000 passengers, but 57.000 is just too much! But, at last, I don't have over-used rail lines or subway lines. AT LAST!! :)

You have a couple of options here.  There are some train stations with even bigger capacities; I have an early one from the STEX with a capacity of 50,000.  Even better, just learn the very basics of Ilive's Reader, and then by adjusting the value of Transit Switch Traffic Capacity in the station of your choice, you can set the capacity to whatever you want.

Quote
Instead, about commute time...
Simulator B easy - Simulator Z
City 1 = 85 >> fro 4 to 7
City 2 = 120 >> 6
City 3 = 250+ >> 20+
City 4 = 300+ >> 15
These are all high-density cities on large maps, that works as connection center among several satellite cities and villages on smaller maps.

I know that Z's graphs are made usind different parameters, but still there has been a sensibile improvement in commute speed. Looking from the graphs, it was like if the game has reseted the commuters phat and has begun to calculate them starting over, from the beginning. If the beginning was 0, even the highest scores reached by the graph where not so far away from the starting score and still not so high as the ones with Pathfinder B that I was using before and then, even if I guess that scores among NAM graph and Z graph cannot be compared directly (at least I can't), over all commute time is much shorter and my Sims don't complain anymore about commute times.

Also, I have tried to play on small and middle-size maps, where commute time became 0.6 or even near to 0. It is like if Z graphs shows only effective commute time between a city and another, like if the time needed for Sims to find work in the city where they have both a flat and a work is not considered.

In fact, I did a test with a city of mine called "new Venetia" that is a huge island in the middle of the river, with no bridges. It is self sufficient and commute time was 0. Instead, when I added a ferry, the commute time began to increase to 10, more or less. It looks like that Z mod has even fixed a nasty problem with ferries, where Sims run into them as lemmings and then were moved by sea fluxes instead than actively looking for employment.

Ah, commute time.  As I mentioned in an earlier post, I used mott's formula to set the scale of the commute time graph.  But I saw a post on Simtropolis a while ago that indicated a different way of computing the proper value.  And although the numbers seemed to be right for my large cities, some numbers seemed too low in others.  And then the data you report definitely sounds incorrect.  So I decided to get to the bottom of this; I did an experiment.

I took an unused large city tile, constructed a road exactly 8 km (512 squares) long, zoned a residence at one end and a business at the other, and put in power and water.  I also temporarily modified my simulator to remove the speed premium so that I would be working with a constant, known speed.  Based on a speed of 50 kph for cars, raw commute time should have been 19.2 minutes.  I ran the simulator, quickly got some buildings and commuting Sims, and the commute time quickly went from zero to...  55 seconds!  Way off.  So I figured out what I would have to do to the graph scaling constant to make it come out right, put that number in, and reran the test track.  This time it came out to 19.2 minutes, as expected.

But what about my cities that had looked OK?  Unfortunately, commute times there went up proportionately as well.  The city I had been working with now had an average commute time of twelve hours, which made no sense at all.  Not only was the average commute time higher than the maximum  ???, but a one-way six hour trip on a road would take a Sim roughly 300 km (183 miles).  So something was seriously wrong here.

I thought, Maybe mass transit worked differently?  So I went back to my test track, ripped out the road, replaced it with a train track, put little stations at each end along with road access, and ran the simulator again.  The commute time graph showed perfectly accurate numbers here, shorter than the road numbers by the exact proportion that trains were faster than cars.

So test cases worked with this number, but real cities didn't.  That was really strange.  I started looking at the commute time for my other cities, and a pattern quickly became evident.  The more intercity traffic a city had, the higher the average commute time.  It got to the point where I could predict the average commute time based on my knowledge of what the city's intercity traffic was.  One city that looked very much like my city with a twelve hour commute tiime, but had the least intercity traffic, had a commute time of 70 minutes.

So this is clearly an SC4 bug, because it means there is no value for the Commute Time Graph scaling factor that works in all cities.  In fact, the proper value differs from city to city, or even in the same city at different times, depending on the level of intercity traffic.  This seems connected to my discovery that I had to increase the maximum commute time well beyond what should have been needed in order to generate large volumes of intercity traffic.

So what to do in this situation?  I have decided to make the Commute Time Graph scaling factor half of what my tests say it should be (i.e., .04 instead of .08).  This will increase the commute times you have seen by about a factor of ten, which will be much more reasonable.  It will also eliminate the zero-lenght commute times (which were just commute times under half a minute, rounded down).  For cities with a small amount of intercity traffic, the Commute Time Graph numbers will be approximately correct.  But the bug I found makes it impossible to make them correct in all situations.

As for other simulators, I don't know what the best value for the Commute Time Graph scaling factor whould be; other tests will have to be done for them.

Quote
Now, a couple of questions.
1 - what is RHW? I have seen it here and there on this post but I don't know the meaning.

As MassHelper pointed out, it stands for Rural Highway.  You can find a huge thread about it in the stickies in NAM Creations.

Quote2 - in your new congestion & volume view, I have seen that, when I go to see usage, many streets and even highways turns "red" (or deep orange) in the traffic volume view,, even if they are green in the congestion view,. I remember that, in the volume view, there was a note like "*based on street capacity". What does it mean? If I see an highway turning red in the volume view, and NOT in the congestion view, do I have to worry about?

In the traffic volume view, unlike the traffic congestion view, there is one scale for all networks displayed.  For each travel type, I picked the network that seemed most appropriate for that travel type's volume.  For example, freight trucks, which usually have a low volume, use street capacity, which is 750 per commute period; this means that you will get red displayed in the freight truck view whenever you have a volume of 2250 (300% of 750) or greater.  However, highways have a capacity of 22,500 per tile per commute period, which means they can turn red if you have just 10% of their capacity used in the freight truck view.  This is unusual, but it can happen.  Such a highway would, of course, show up as green in the congestion view, as it is not congested.  The only time you can use the colors as an indication of congestion is when you are looking at the same network that the travel type is based on, and you are not looking at a view that contains a non-traffic producing travel type (such as buses).  But if you keep this in mind, then, for example, by looking at the Car view, by averaging the colors of the Morning and Evening Commute, you can get a very good idea of what the congestion on a particular road is.  This works in all simulators.

For more information, please see my thread Proposal for a New Traffic Volume View.

0rion79

Well, Z, thanks for the hints.
If I can give you my opinion, I think that you should care just about the inter-city commute time. Usually, cities with no connections have no commute problems, so even if your mod makes commute time very close to 0, it would not be a problem anyway. Instead the game suffers a lot when Sims become really outliers and it is here that the biggest differences are seen. It is not a case that the cities with those outstanding commute times where the huge metropolises that had even 8 connections with other 8 neighbour cities and, even if all connections where green and without congestions, it was simply impossible to obtain shorter commute times.

Else, I don't know if the graph shows the highest commute time or just the average commute time BUT if we assume the second one, it is even true that in rural villages (like the ones where I did my tests and had a 0.6 commute time) very often farmers live just adjacent to their farms and so the commute time is less than 1 minute... or, else, we would set that the graph in your mod only indicates the effective commute time needed ONLY by those commuters that work in a different city than then one where they live.

But anyway, if the game is not suffering for single-city commute time but only about inter-city commute time, then just fix the second one and don't care about the first one, even if it would be a bit less realistic. But for me it would be even less realistic to have a map with cities with no connections! :) So I even expect every player to build at least one connection per city, if not more!!!

Ah, may I know what is the set speed for trains, subway, monorail, el.train and ferry in your mod? use Km/h please.

About trains, I just wished to know if it was "normal" that so deep usage in some of my cities. Since I don't think that I will change traffic simulator now that yours is going so fine, may I know what traffic cost do you suggest for:
"non transit-enabled" stops,
bus stops,
monorail stops,
subway stops,
passenger train stops
multi-transit stops (eg_ train+subway or bus+subway)?

What do you think about modding my stops to force the sims to enter only from the entrance and NOT from every side of them?
Thank you!

z

#54
Well, I will certainly be giving this more thought before I make changes to the commute time scaling.  And I'd be happy to hear from other people about their opinions.  But I should mention that it's not the number of connections to other cities that affects the scaling, it's the volume through those connections.  For example, in my city with the 12-hour commute time, I have hundreds of thousands of Sims commuting to other cities.  It's that number that seems to be associated with the problem, not the number of connections.

As for the meaning of the Commute Time, it's supposed to be an average.

In the end, I think it's useful to repeat something that jplumbley has said many times:  It's not the actual numbers on this graph that are important, but how they change over time.  Clearly, this is made more difficult if the volume of intercity traffic is changing, but that tends to be a long-term process, and the basic principle still applies.

As for the speed of the various travel types, this is all given on the first page of this thread, in the fourth post.  Ferry speeds are not given because they are not controlled by the traffic simulator plug-in, which means they are probably fixed.  If anyone knows what they are, please post.

As for passenger train usage, I have some cities with similar levels of usage.  Since I tried to give real-world values to as many parameters as I could, usage levels such as this are not surprising, since they are common in the real world.

When you are asking for traffic costs for stations, are you actually asking about traffic capacity?  If so, please see the first post in this thread.  As mentioned in the post announcing the Alpha 1 release, I recommend the use of RTMT stations along with the included file in the simulator release; these implement the capacities I recommend, and which have worked well.  For roadside transit stations, I recommend RaphaelNinja's stations, but with doubled capacity.  (You might want to reduce the plop cost on those, as their cost seems to be much higher than similar stations.)

As for modding your stops to force Sims to enter and exit only from one side, I haven't looked into this much personally, but I know that a lot of people recommend it, because it eliminates pedestrians' using the station as a shortcut.

0rion79

#55
Sorry Z, it is my fault: I wished to know how do you suggest to set the tranit switch entry cost. Just to avoid misunderstandment, I mean the value that indicates the time that Sims and/or mass transits vehicles need to cross that mass transit station.
I ask so because in a previous post you have told me that it depends from mass transit speed too! And so, since you have changed some speeds, I would like to know if I should keep my "0,05" value or if I should use something higher or lower.
Thank you! :)

z

#56
There are two cases here.  If you have a TE lot, with a network running through the lot, the tranit switch entry cost should be the inverse of the predominant travel type's speed.  So, for example, all RTMT stations on roads, where cars travel at 50 kph, have a tranit switch entry cost of .02.  This is a neutral value that neither speeds up nor slows down cars.

For roadside stations, where vehicles cannot travel, the main concern is to prevent pedestrian shortcutting.  This can be done by making the tranit switch entry cost the inverse of the pedestrian speed of 5 kph, or .2.

The Maxis lots, and many independently-developed lots, have a tranit switch entry cost of zero.  This can have amusing results.  For a large TE train station, the Sims can all be observed getting off the train at one end of the station, walking to the other end (since this takes zero time) and then all getting back on the train.  This can be avoided by setting the station's tranit switch entry cost to the inverse of the train speed (200), or .005.

It's important to note that tranit switch entry cost is specified on a per tile basis, so you don't have to multiply any of these numbers by the number of tiles in a particular path.

MassHelper

As for the traffic simulator files, z, can you plz get the cleanitol file installed in... (Not trying to annoying, but I am anxious (and desperate.. cause of the traffic overflow I am having in my city) to use the new simulator  and don't want to mess up the game or have any CTDs because of not knowing which files to delete)

TY

:) Mass
SC4 Modders' Assistant and Adviser

0rion79

Quote from: z on October 14, 2008, 01:11:02 PM
For a large TE train station, the Sims can all be observed getting off the train at one end of the station, walking to the other end (since this takes zero time) and then all getting back on the train.  This can be avoided by setting the station's tranit switch entry cost to the inverse of the train speed (200), or .005.

Z, sorry, are you sure that it is .005 and not 0.05? Coego wrote me so in another thread, but about Maxis & NAM standard speed, that are much slower than yours!

Two questions:
1 - what do you mean by "inverse of the speed"? Using your example, what should it be? 0.002?
2 - can you suggest me any alternative program to edit stosp transit switch point, that is NOT SC4tools? it is has some bugs for me and all those hexadecimal values in other tools are too complicated for me!

Ah, in your traffic simulator, RTMT descriptions do not match with effective capacity: I think that you just didn't care about this side! :)

z

Since the train speed in my simulator is 200 kph, the inverse of that is 1/200, which does come out to .005.  Now of course if you have a big station where pedestrians can enter and exit from opposite sides, they'll zip through the station at train speed.  Generally, this does not have a big effect on the game.  But if you limit the pedestrian access to one side of the station (such as the front), you eliminate this problem completely.

I prefer Ilive's Reader for editing exemplars.  For properties that are in hexadecimal, you can just type a decimal value in the field, and the program will convert it to hex.  For converting hex to decimal (or back, when necessary), I just use the standard Windows calculator in Scientific mode.

As for RTMT, please understand that it is completely separate from the traffic simulator!  Cogeo chose the current capacities displayed to be network capacities rather than station capacities.  In the next version of RTMT, I am changing that so that the descriptions show station capacities.  This change has already been made; the RTMT file included with the next release of the traffic simulator will have it.