• Welcome to SC4 Devotion Forum Archives.

A Guide to the Operation of the Traffic Simulator

Started by z, February 20, 2010, 07:48:37 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Trias

Quote from: SC4BOY on May 17, 2010, 11:06:14 AM
I doubt this is true. I expect you will find a 4x4 area that triggers high customers (probably the 4x4 that contains the "foundation lot") Since it is known that the game classes traffic elements like noise and customers in 4x4 groups, it may be that the 4x4 (recall that the basis of the 4x4 groups starts in the NorthWest corner of the map.. at least that is my recall.. NOT at the lot boundaries) is totally inside the 8x8 (or any larger lot size), but not solely due to the larger lot size. It may turn out that builders of large lots should practice good game practice with respect to the tile they use as the "anchor tile" of their lots.. I don't know about that.. I'm pretty sure there are currently  no guidelines in this respect.
At the very least I expect more investigation is required here before a conclusion is justifiably drawn.
If you can control the anchor point for the lot, this indeed will not be true. For most lots, it is somewhere near the middle, in which case the 4x4 and surrounding tiles can be completely enveloped by the lot.


Quote
This is based on your own aesthetics, not on what should be good game practice. This would unnecessarily constrain players to using network capacities (or conversely submitting to restrictive customer levels) based on mathematical "prettiness" not game function. What is the "right" value?... hard to say, but just as with network capacities I expect it will  vary considerably depending on what the player's goals are for his city/region.

Aesthetics has nothing to do with it. It is about preserving game functionality. For high values for the customer coefficient there will only be a very small range on the network capacity, in which the amount of traffic makes a difference with respect to desirability. From a gameplay perspective this range should be fairly wide. The actual effect on desirability should be controlled the developer properties, not by the traffic coefficient.

SC4BOY

Quote from: Trias on May 17, 2010, 12:30:04 PM
If you can control the anchor point for the lot, this indeed will not be true. For most lots, it is somewhere near the middle, in which case the 4x4 and surrounding tiles can be completely enveloped by the lot.


Aesthetics has nothing to do with it. It is about preserving game functionality. For high values for the customer coefficient there will only be a very small range on the network capacity, in which the amount of traffic makes a difference with respect to desirability. From a gameplay perspective this range should be fairly wide. The actual effect on desirability should be controlled the developer properties, not by the traffic coefficient.

The problem is that there isn't a "right" network capacity.. there is no problem in keeping max flexibility (ie 128 as the middle) however many people during the development and use of a region (and from city tile to city tile) will have a wide range of needs in this respect.. and I would say to err on the "busy" side is far preferable.. it isn't rocket science anyways.. ;)

z

Quote from: Trias on May 17, 2010, 08:12:50 AM
As to the optimal value for the customers traffic noise coefficient... If we look at the original value for the coefficient and the network capacities, we see that at the maxis defaults traffic will saturate at roads with 200% capacity. To keep the sensitivity to traffic also at higher capacities, this relationship should be conserved. That is the coefficient should take as its value:

128/(road capacity)

Obviously, on its own this will cause cities with high network capacity settings to have troubles with commercial desirability. This means that in an ideal situation that the desirability response curve on traffic should also be adjusted. This is somewhat beyond the scope of the traffic simulator, but could be done for a mod like CAM (that is messing with the developers anyway, with all associated problems that causes).

You're proposing a formula that you admit will cause problems with higher capacity simulators, but you propose to fix this new problem by modifying additional exemplars.  I don't think that that's the right approach.  Instead, I'd like to take a look at the assumptions underlying your coefficient formula and see how they correlate with the realities of the game.

Although it's true that your formula works for the Maxis simulator's roads, it doesn't for that simulator's avenues.  People who have used the Maxis simulator a lot know how advantageous the extra capacities of the avenues are, and so they get used a lot, largely to get around the rather restrictive capacities of roads.  If you use the avenue capacities, then the formula to derive the Maxis coefficient from these would be:

C = 307.2/(avenue capacity)

As more recent traffic simulators have identical capacities for roads and avenues on a per-tile basis, this is not an issue for them, but it does show that the original formula by itself is insufficient to describe what's happening in the Maxis simulator, and will give coefficients that are too low if applied to more recent simulators.

There is also the assumption that the basic properties of the Maxis simulator are close enough to all other simulators that a formula that works for the Maxis simulator will work for them all.  I don't think that this is true at all.  The low capacities of the Maxis simulator, combined with extremely poor pathfinding abilities, mean that the cities that will work acceptably with this simulator are just a small subset of cities that can be built with later simulators.  The pathfinder is especially significant here.  With the Maxis simulator, the pathfinding abilities are so poor that you have to tightly interweave your zones and generate lots of traffic in the hope that enough of your Sims will eventually find their way to work.  In a perfect pathfinding simulator, by contrast, it's possible to have spread-out zones and very light traffic, and still have all the Sims find jobs.  So perfect pathfinding means that larger cities can run well with less traffic than before, which means that that formula is no longer applicable - it will always generate coefficients that are too low.

The formula also assumes that road traffic volume rises in direct proportion to road capacity, which is not the case.  Some people pick capacities that are very high simply because they want to concentrate on other parts of the game, and not get bogged down in traffic.  For those people, much or even most of their network capacity may go unused.  But even for those people who try to keep their capacities strictly realistic, the proportionality is not direct.  Capacities are usually picked as some percentage of maximum volume - maybe 80% or 90%, so that there's still some realistic congestion.  But cities grow unevenly, and though parts of a city may experience great growth, other parts may not grow at all, or grow very little.  So the spread in traffic volumes tends to widen with city size, and the growth of the median traffic volume is much less than linear; from what I've seen, it's more near a logarithmic growth.

Then you have to add the other effects of growing cities.  Bigger cities tend to have more rapid transit and highways, which don't contribute to road noise (at least in SC4).  They also tend to have more tram systems.  Trams may look a lot like buses, but they're actually built on el rail, so they don't contribute to road noise either.  All of the factors mentioned in the last two paragraphs tend to flatten the effect of city size on road noise.

Originally, I also thought that the coefficient should decrease with increased network capacity, although in a way that was slower than linear.  In early versions of Simulator Z, the value of the coefficient for the Low, Medium, High, and Ultra versions of the simulator was .10, .08, .06, and .04, respectively.  (Note that Ultra has essentially twice the capacities of High.)  For many cities, this worked fine; I ran all my cities on Ultra with no problem.  But some people began having problems getting workers for certain jobs, and it quickly became clear that the low coefficient was the source of these problems.  Experiments with these cities convinced me that a single value for all simulator capacities was appropriate after all.  Further experiments, plus understanding of how the original coefficient was tied to the limitations of the Maxis pathfinder, led me to the current value for the coefficient (.25).

The current value has worked out quite well as a default, but it's also clear that different cities would have different optimal values.  Even more than the size of the city, they layout of the city plays a big role.  However, there's no way to incorporate that into the traffic simulator.  Fortunately, Trias, your excellent experimental work has defined the behavior of the coefficient well enough so that it has been possible to incorporate its setting into the Traffic Simulator Configuration Tool, and people can set it to whatever they want.  I think the current default value for the coefficient plus the configurability option works as well or better than anything else I can think of.

Trias

Quote from: z on May 18, 2010, 12:45:43 AM
You're proposing a formula that you admit will cause problems with higher capacity simulators, but you propose to fix this new problem by modifying additional exemplars.  I don't think that that's the right approach.  Instead, I'd like to take a look at the assumptions underlying your coefficient formula and see how they correlate with the realities of the game.

[...]

The current value has worked out quite well as a default, but it's also clear that different cities would have different optimal values.  Even more than the size of the city, they layout of the city plays a big role.  However, there's no way to incorporate that into the traffic simulator.  Fortunately, Trias, your excellent experimental work has defined the behavior of the coefficient well enough so that it has been possible to incorporate its setting into the Traffic Simulator Configuration Tool, and people can set it to whatever they want.  I think the current default value for the coefficient plus the configurability option works as well or better than anything else I can think of.

My opinion is that using customers/traffic noise coefficient to regulate customers is a bad idea. Take for example the .250 value in the Z simulator. This value means that the traffic effect saturates around 1000 cars. This means that having 1000 or 5000 cars pass the doors of a C zone makes absolutely no difference for the desirability of the location. This is not how the game simulator should (and was designed to) work.

What is controlled by the CTNC is effectively the range of traffic that effects desirability. The magnitude of the effect is controlled by the "Traffic effect" property of the developer examplars. You can effectively influence the magnitude of the effect bu rescaling the range, but comes at the cost of making the range shorter.


z

Trias, you make a very persuasive case.  So I took another look at the whole issue to see if I could come up with an improvement over the current approach that would be simple to implement, and I think I have.

First, I reviewed the relationship between network capacities and network usage.  Again, it was easy to think of all the cases where the choice of a simulator's capacity was just based on the preferences of the player, and not the characteristics of the city.  There are people who will always pick a High or Ultra capacity, regardless of the city size, and there are people who will always pick Low or Classic for the challenge of it.  And then there's everything in between.  So I continue to believe that it's not possible to draw any consistent correlation between simulator capacity and actual network volume.

This would seem to imply that we are forced into a "one size fits all" approach here.  If that's the case, then which size?  Scaling for Ultra is clearly too high; there are relatively few cities that actually need Ultra.  On the other end, Classic has a somewhat restricted niche; it's fairly limited in the size of cities it can serve without generating overwhelming congestion.

The Low capacity, on the other hand, is described as being suitable for low- to medium-sized cities, and can in fact function effectively in even larger cities.  So I think that if we scale for the Low capacity simulator, we should end up doing rather well.

Trias, one of the points you raised that I found particularly interesting is that in the default Maxis simulator, customer count tops out at about 200% of road capacity.  This means that, according to your figures, a business won't even reach the "medium" customer level until roads are already congested at 119% of capacity; a "high" customer level comes only with serious congestion, at 168% of road capacity.  By themselves, these thresholds seem suspiciously high.  But then consider avenues, where you would expect many of your biggest businesses to be.  Here, customer count tops out at 83% of avenue capacity, with medium and high levels occurring at 50% and 70% of avenue capacity, respectively.  Not only do these seem to be more reasonable levels, but the medium and high thresholds are both suspiciously round numbers.  The fact that a medium customer count occurs when avenues reach exactly half their capacity does not look like an accident to me.  So I suspect that the CTNR is based on the Maxis simulator's avenue capacity, not its road capacity.

Starting with Simulators A and B, the capacities of the various road networks was normalized, and in Simulator Z, as with its immediate predecessors, road and avenue capacities are identical.  (There's a slight exception for the Classic version, but it's not significant in this discussion.)  It just so happens (and this really is a coincidence) that the road and avenue capacities for Simulator Z Low are identical to the Maxis avenue capacity.  Well, this would seem to make things easy.  Why not just use the Maxis value of .128 for the CTNR?

Originally, I raised the CTNR from this value because a value that low caused problems in certain cities.  But that was before I found the new value for perfect pathfinding.  As I've mentioned before, perfect pathfinding has a huge effect on the whole traffic simulator, much more than the incremental value that you would expect.  And I think that now, a value of .128 might work just fine.  I've run a preliminary test for 30 years on one of my most sensitive cities, the Near South Side of Chicago, and changing the CTNR to .128 had no effect whatsoever.  This was somewhat surprising; I expected some effect.  When I repeated the test with a CTNR of .011 (which is what you get if you're using the Ultra capacity and use the formula "CTNR = 128/(road capacity)), 100,000 CO$$$ jobs disappeared immediately - 15% of the total.  Nothing else changed; apparently the workers just went to another city for jobs.

But the lack of any change after I dropped the CTNR to .128 is extremely encouraging.  I next plan to try this value in sumwonyuno's region.  This is an extremely unusual region, and if this value works there, it will probably work everywhere.  If it does work there, I would then ask other people to try this value in the NAM Simulator development thread.  (Readers of this thread can certainly try it now, if they wish.)  If there are no problems then, I would make it the default for the simulator.

It's true that this isn't a perfect solution, but I think it would be a big improvement, and fortunately people can change this constant to whatever they want in the Traffic Simulator Configuration Tool.  I would say that this solution falls into the 90 - 10 category; it solves 90% of the problem with 10% of the work (or less) that a more complete solution would require.  Although I agree that the Traffic Effect property in the developer exemplars could be used to implement a more complete solution, it's not clear to me that it would make enough difference to be noticed.  Also, it introduces a number of complexities.  On one hand, there are the eight exemplars in which this property exists in arrays of varying length.  We would need to decide in each case whether to use the same size of array or a different one, and if so, what size, and what should all the values be.  To do this properly is a big job in itself.  But it's complicated significantly by the fact that the CAM already uses its own copy of these exemplars.  Even though we know we can count on Tage to be completely cooperative and modify them the way we want  :), what about all the people who have CAM installed already?  And then what about the people who install CAM 2.0, which is going to have multiple versions, each with its own set of developer exemplars?  What happens when people want to change their version of CAM, and then the traffic simulator, or vice versa?  These problems can all theoretically be solved, but it does get very messy.  I don't think the amount to be gained would justify it, but I'm open to looking at hard data.

In the mean time, I will proceed along the lines I described above, and I expect to be able to at least cut this constant in half.

Trias

Seems very reasonable to me.

Within the limited scope of just the traffic simulator messing with the developer exemplars seems unrealistic, and we are sort of stuck with a one size fits all approach for the different flavours of the simulator. At the very least, it doesn't make much sense to increase to coefficient over the maxis default, when (with most simulators) we are increasing capacity to accommodate higher amounts of traffic. Placing the value around the maxis default makes sense.

Messing with the developer exemplars, is more something up CAM's alley. Since CAM is basically messing with the fundamental scales of the game, CAM might require a different value for the CTNC then vanilla RH, combined with appropriate rescaling of the 'traffic effect' curves.  I'll try to talk to the development team for CAM 2.0, and notify them of our observations.

SC4BOY

Quote from: Trias on May 18, 2010, 04:08:16 AM
My opinion is that using customers/traffic noise coefficient to regulate customers is a bad idea. Take for example the .250 value in the Z simulator. This value means that the traffic effect saturates around 1000 cars. This means that having 1000 or 5000 cars pass the doors of a C zone makes absolutely no difference for the desirability of the location. This is not how the game simulator should (and was designed to) work.

Saturation of the commerce effect is not only reasonable, but reflects real life.. Increased traffic is indeed a good thing to a point, then at some point, it becomes a nuisance.. too much noise, too hard to get in and out, too much waiting in line, parking saturates, etc etc.. Of course personally I think this is a lot of niggling over nothing, but the saturation approach is certainly one I'll use in my simulation and feel confident in it (if it isn't the default one already). The game actually never was intended to reflect the finesse you're trying to imply here.. It's only displayed after all as low, med, and high (and med is essentially absent) so basically it is a binary effect and you're trying to give it some subtle meaning.. In actual game-play it just isn't that important. Either your commerce is generally well-located or it isn't... there are few shades of grey.

Trias

Quote from: SC4BOY on May 19, 2010, 03:51:10 AM
Saturation of the commerce effect is not only reasonable, but reflects real life.. Increased traffic is indeed a good thing to a point, then at some point, it becomes a nuisance.. too much noise, too hard to get in and out, too much waiting in line, parking saturates, etc etc.. Of course personally I think this is a lot of niggling over nothing, but the saturation approach is certainly one I'll use in my simulation and feel confident in it (if it isn't the default one already). The game actually never was intended to reflect the finesse you're trying to imply here.. It's only displayed after all as low, med, and high (and med is essentially absent) so basically it is a binary effect and you're trying to give it some subtle meaning.. In actual game-play it just isn't that important. Either your commerce is generally well-located or it isn't... there are few shades of grey.


Don't believe too much what you query tells you. It might display as low, med or high, but in the mean time the simulator actually translates the traffic to a value between 0 and 256, which then translates in a continuous way into a plus or minus on the desirability for the zone. For the most sensitive zone types (CS$$$) this value is the range -40 to +40. (which is a huge difference) In the maxis defaults these highest values are only attained for your most congested roads and for busy (but uncongested) avenues. So at least in the maxis default settings, this is not a binary effect. In the default simulator, there are in fact many shades of grey.

However, with the higher network capacities, and the higher CTNC setting of 0.250, even an uncongested street can saturate the traffic effect to its maximum value. The effect becomes effectively binary, as for larger buildings even the people going in and out of the building are enough to saturate the effect.


SC4BOY

Quote from: Trias on May 19, 2010, 07:09:00 AM
... this value is the range -40 to +40. .

I of course am fully aware of this.. my point was not that it doesn't exist, but that from a game perspective, it simply doesn't make a much difference. I have been playing the game for almost 10 years and have no problem developing HUGE commerce areas with no problem whatsoever. Exactly what do you think all this fiddling will gain you in a practical game-play way?


Trias

Quote from: SC4BOY on May 19, 2010, 12:58:36 PM
I of course am fully aware of this.. my point was not that it doesn't exist, but that from a game perspective, it simply doesn't make a much difference. I have been playing the game for almost 10 years and have no problem developing HUGE commerce areas with no problem whatsoever. Exactly what do you think all this fiddling will gain you in a practical game-play way?

More differentiation in desirability.

In a practical game-play way, this means that you will have to consider traffic as a desirability factor for a longer part of the game.

(Also, of course you have no problem developing huge commerce areas, because the customers bonus is pretty much always maxed out once commerce develops.)

SC4BOY

Quote from: Trias on May 20, 2010, 01:03:24 AM
(Also, of course you have no problem developing huge commerce areas, because the customers bonus is pretty much always maxed out once commerce develops.)

No they are rarely maxed except in limited high traffic areas. In fact I'd say that in any given city tile, I rarely have more than 25% or so of the commercial lots operating with "high" customers, sometimes MUCH less.. still no problem with playing the game. I don't think you have verified your hypotheses with actual game play.. use them in actual cities you have built and report the changes in commercial development and demand.

z

I am sorry to report that changing the Customers/Traffic Noise Coefficient from .250 to .128 broke sumwonyuno's Capitalis region.  This was not entirely unexpected.  The Capitalis region is modeled on one of the Hawaiian islands, and is a rather faithful rendering of that island in SC4.  With some notable exceptions, commercial businesses tend to be small, spread out over a wide area, and connected by streets.  Traffic along these streets is generally quite low in SC4.  With a CTNC of .250, the businesses develop a modest but fairly stable base of customers.  With a CTNC of .128, many (if not most) small businesses go without customers for months at a time.  Although perfect pathfinding improved the customer level for a CTNC of .250, it did not do the same when the CTNC is .128.

There are several issues I would like to address here.  First, why did Maxis choose a value of .128 for the CTNC if it could produce such negative results in situations like these?  As Trias has documented, the value of .128 makes a lot of sense for the Maxis simulator from a theoretical point of view.  And in the Maxis simulator, the pathfinding was so poor that the pathfinding would have been the limiting factor in a region such as Capitalis; those businesses were never going to reach a satisfactory customer level regardless of the setting of the CTNC.  So for the Maxis simulator, a value of .128 for the CTNC was quite reasonable, but for the NAM simulator, it's not.

I think that another important issue is that although I believe Trias' experimental results and basic conclusions about the way the CTNC works to be absolutely correct, so far we have been looking at these in isolation.  When looking at just some of the other factors that enter into commercial desirability, a very different picture emerges.

For example, the Traffic Effect property in the developer exemplars shows that traffic volume levels have the biggest effect on desirability for CS$$$.  But in actual game play, their biggest effect is on CO$$$.  I gave an example in an earlier post where drastically reducing the CTNC had a large negative effect on a city's CO$$$ population, but nowhere else.  The reason for this discrepancy can be seen if you look at the Desirability Data View map.  In general, desirability for CS$$$ is much higher overall than for CO$$$.  That explains why a smaller change in CO$$$ desirability can have a bigger effect in the game than a larger change in CS$$$ desirability.

There also has been the assumption that the relationship of customers to desirability is strictly linear, and the Traffic Effect properties support that view.  But there are strong second-order effects that destroy the linearity of this relationship.  The number of customers for a given business is directly proportional to traffic volume, at least until the cap has been reached.  The number of customers, in turn, contributes to determining the number of workers employed at that business.  But what is the traffic volume, really?  It is actually the number of workers traveling to businesses - not customers, as customers are not modeled as part of the traffic flow.  So as the number of customers increases, the number of workers increases, which in turn increases the number of customers, and a nonlinear positive feedback loop is created.  What this means is that the CTNC has the additional function of determining the strength of this feedback loop, and the simple linear description that we've been using is insufficient to describe what's actually happening.

My conclusion is that we are best off leaving the default value of the CTNC where it is, at .250.  Trias' objections are still valid; this limits the usefulness of this property, although the feedback effect makes it less clear to what extent it is actually limited.  The most important thing is that the default value of the CTNC should not break existing cities, or make it impossible to build various realistic cities; Capitalis fits both of these categories.  It's important to note that by using a value of .128 for the CTNC, a region like Capitalis simply cannot be made to work properly; there is no workaround that will compensate for the negative effects of the low CTNC.  Any change to the simulator's default parameters must not create such a situation, and that's why I'm leaving the CTNC at .250 for now.  If it can be shown experimentally that there is a better value for the CTNC that does not cause this type of problem, I'm certainly open to changing it.  But I think that some of SC4BOY's arguments need to be considered here; by the time you get to the higher customer levels, there are so many factors affecting desirability that it's not clear how much effect the CTNC really has at that point.

Meanwhile, for those who want to use a value of .128 for the CTNC (or any other value, for that matter), the value can be easily changed in the Traffic Simulator Configuration Tool.

Having come to this point, I think that this subject is well enough understood that I can revise the original post in this thread to reflect the current understanding of the CTNC.  If any other discoveries are made, further updates can be made as well.

Trias

Quote from: z on May 29, 2010, 04:02:17 PM
I am sorry to report that changing the Customers/Traffic Noise Coefficient from .250 to .128 broke sumwonyuno's Capitalis region.  This was not entirely unexpected.  The Capitalis region is modeled on one of the Hawaiian islands, and is a rather faithful rendering of that island in SC4.  With some notable exceptions, commercial businesses tend to be small, spread out over a wide area, and connected by streets.  Traffic along these streets is generally quite low in SC4.  With a CTNC of .250, the businesses develop a modest but fairly stable base of customers.  With a CTNC of .128, many (if not most) small businesses go without customers for months at a time.  Although perfect pathfinding improved the customer level for a CTNC of .250, it did not do the same when the CTNC is .128.
Was that in plain NAM, or were there other mods involved like CAM?

CAM drastically increases the desirability threshold for high and medium wealth zone types. Making low desirability a much bigger issue in development.

Quote
There also has been the assumption that the relationship of customers to desirability is strictly linear, and the Traffic Effect properties support that view.
Actually it does not. Some developers have non-linear response curves to traffic. I can't remember which ones but I believe they are the commercial zones.

Although, I still think it is, as a general principle, a bad idea to fix a problem caused by the developer examplars by change the traffic simulator. Keeping the default value as it is may be a good idea for regions that are relying on it.

z

Quote from: Trias on June 02, 2010, 05:13:25 AM
Was that in plain NAM, or were there other mods involved like CAM?

It was a fairly vanilla region, but it did have CAM.

QuoteCAM drastically increases the desirability threshold for high and medium wealth zone types. Making low desirability a much bigger issue in development.

My personal experience has always been that CAM 1.0 made development somewhat easier in my cities.  But that's a purely subjective observation, not broken down into factors such as desirability, etc.  So in the interests of thoroughness, I went back to Capitalis and de-CAMified it.  ("De-CAMified"?  Whatever.)  I then ran the exact same experiment for the exact same time period (50 years), checking in at many points along the way.

The results were identical to when CAM was installed.  So I am guessing that the desirability threshold was raised in CAM to offset other factors, and that's why this experiment and my experience in general has shown that CAM does not have a negative effect on development.

QuoteKeeping the default value as it is may be a good idea for regions that are relying on it.

In theory, this makes sense.  In practice, though, can you demonstrate any cases where this change makes a difference on the high end?  My experiments with this coefficient have shown that it takes large changes in it to get any effects at all.  In a previous example I related here, reducing the coefficient by 99.5% had no effect whatsoever on the CS$$$ population of a city of two million, and that's the commercial type where the biggest hit in desirability comes.  As I related, the only effect the change had was to drop the CO$$$ population by 15%, which is not huge considering the magnitude of the change in the coefficient.  On the other end of the scale, raising the coefficient from 0.250 to 2.000 caused a steady but modest expansion in job growth over a number of decades.  On the other hand, the same city showed absolutely no change in the Pop & Jobs graph when the coefficient was changed between .250 and .128.

In other words, my testing has not shown any problems here, and it has shown that there are problems with the .128 figure.  Before looking for a better solution, I would want to know that a problem really exists, and what its magnitude is.  If you can demonstrate that with actual in-game data, I'd be happy to take another look here.  Otherwise, it appears to me that the current default value is correct, and for people who want a different value, it's easy enough to change with the Traffic Simulator Configuration Tool.

toja

#34
In the past few weeks I played around with the Congestion vs. Speed-Property. I'm not sure if I've found out something new, but maybe it's a helpful piece of information for somebody.  ;)

What I'd like to explain is the Congestion-Dataview - as far as I know, it's still a little bit unclear, what congestion exactly means in SC4. So I decided to examine congestion with the help of Query.txt for the following situation:



I've used a plain SC4-deluxe installation with a slightly modified Congestion vs Speed-Property:



And here's the result:



Well, I think it's obvious that there is some kind of mathematical relationship. My first thought was, that Maxis could have used an exponential function to calculate congestion. But after a while I found that the speed part of the Congestion vs Speed-property is the independent variable in the congestion funtion, like here: f(x) = 1/x.

As you know, SC4 calculates the time cost to cross one tile with the following formula:

time cost  = 0.96 / speed           (f(x) = 1/x)

Now the Congestion vs. Speed-Property comes into play:

time cost = 0.96 / (speed * speed multiplier)

If you use this formula to calculate time cost (congestion), you get the following result (speed=50):



The only thing left to do for the game to get a congestion value, is to scale the values for time cost to the interval [1; 255] where speed multiplier < 1.

Conclusion: congestion in SC4 measures the (extra) time cost to cross one tile depending on traffic volume – and that is what is the congestion-dataview displays.


pepsibottle1

#35
Hey Z, how can I change all of these finer details? A lot of them are not in the traffic controller and I'm thinking I'd have to use the Ilives reader. Just want to do some tinkering. First off, Also, the NAM presets automatically come with the perfect pathfinding, right? Just wondering.

Also, personally, I want to get more of the lower class citizens riding mass transit and the middle and higher class driving. I was just pondering, is there a value that can be adjusted to change the fiscal cost in simoleans that sims pay in order to use a certain form of transportation? Honestly, I wanted to make driving more expensive in order to acheive this effect due to the fact that the cost of driving is rather expensive (gas, insurance, car payments) and many people with low income jobs cannot afford to do so.

With that said, I'd like to share what I see in my city on a daily basis. Here in RL Norfolk, VA (where I live), mass transit (Busses) are dominated by the lower class because of desireability. Admit it, riding the bus isn't the preferred way to get to work, especially if those who ride it are of the particularly "shady" nature. We had a story on the news about a month ago on how cops were starting to crack down on the transfer bus stops as a hotspot of drug activity and violence. Needless to say, you don't see many people riding the bus if they don't have to.

However, we have just recently completed our light rail system, "The Tide". Basically, it is 7.4 miles in length and runs from Virgina Beach to Downtown Norfolk. Along the route there are several stations along with a "park and ride" garage in Virginia Beach. Although hampered by delays and other problems, the system has been a tremendous success. I264, which runs from the Virginia Beach Oceanfront to Downtown Norfolk (of which "The Tide" runs parallel to) has seen a drastic decrease in traffic during the morning and evening commutes, although traffic is still fairly heavy. Unlike the bus system, many of those who work downtown (higher end office jobs) use the tide religiously as their means of transportation to and from work, and the lower class presence is less than that on the busses. That can be attributed to the higher $2.50 fare compared to the $1.75 for busses.

Concerning walking distance, I'm 17 and just recently I got my driver's license! In the past, I had to use the bus at times as transportation. Even though I live about 2 blocks from the stop, I much prefer driving over taking the bus. The reason being is the overall atmosphere on the bus (sleezy) and quite honestly, walking 3 blocks in the heat or cold is a pain in the rear especially when the busses seem to be some 15 minutes off of their schedule at times. If I had the chance, I'd always wait for my parents to come home and give me a ride somewhere. Now that I have a car, I just drive everywhere. That's because Norfolk is thankfully much less congested than a city such as Chicago or New York. I think that mass transit is pretty much a given there. In fact my steparents whom I live with now, both well paid government workers, lived Long Island from 1996-2000. They used the Subway religiously, simply because it was easier and faster than driving. It was expensive as hell and crowed as a mofo, but it pretty much what you had to do over there. Over here in Norfolk however, they just drive everywhere because it's far less crowded.

Phew, that was a mouthful. Sorry if that was long but I just wanted to throw in my 2 cents into the matter. Again, thanks for the great guide and I'll work on some experiments into the simulator.

Great post, printed this out as reference.
I love Simcity 4!

Glazert

Pepsibottle1, There is a Traffic Simulator Configuration Tool, which should enable you to tweak to your heart's content.

pepsibottle1

Quote from: Glazert on October 06, 2011, 10:27:02 AM
Pepsibottle1, There is a Traffic Simulator Configuration Tool, which should enable you to tweak to your heart's content.

Yeah, but there are some details not included within the editor.
I love Simcity 4!

noahclem

Short answer: Yes, you have to use ilive's reader to adjust those other properties and the process is relatively straightforward. The effects of tinkering around there are not so straightforward however.

Quote from: pepsibottle1 on October 06, 2011, 12:12:52 PM
Yeah, but there are some details not included within the editor.

The traffic simulator includes all variables that are considered safe to adjust. Altering other properties can have unpredictable, detrimental, and/or counter-intuitive effects. That's not to say you shouldn't do it, just that you shouldn't have too high of expectations.

z

I think Noah gives an excellent answer to the original question.  I'll just add a few more details.

Quote from: pepsibottle1 on October 06, 2011, 08:26:44 AM
Also, the NAM presets automatically come with the perfect pathfinding, right?

Yes, that's correct.  The added costs in compute time compared to the original Maxis traffic simulator is insignificant.  The Maxis simulator happens to be the fastest ever used (by a small margin), but it is also the worst by far in producing results.

There are three types of properties that are not included in the Traffic Simulator Configuration Tool.  The first are those properties that affect only the automata, and not the traffic simulation itself.  One example would be the Congestion to Accident Probability, which determines how frequently the automata have accidents based on how congested the network is.  There are a number of these properties, both in the traffic simulator and in the automata controller.  At one point, there were tentative plans to add a second tab to the TSCT where all of these properties could be adjusted; the main reason this hasn't happened is (as usual) lack of manpower.  But you can safely adjust any of these properties to your heart's content in the Reader; as they affect only the automata, you can't get into any real trouble with them.

The second type of properties not included in the TSCT are those properties that have a known effect on the traffic simulation, but are already set to their optimal values.  Hundreds of hours went into testing these properties and their various combinations, and it's fairly unlikely at this point that any significant improvements can be wrung out of any changes to them.  Some properties behave in a non-intuitive fashion (for example, lowering the speed of the rapid transit networks from their original Maxis values reduced abandonment due to commute time - but only until the current speed was reached), while other properties interact with still others where no interaction would be expected.  To top it all off, these latter interactions tend to be nonlinear.  For these reasons, modifications to this group of properties is not recommended.  Even a few of the properties in the TSCT may have a negative on the traffic simulation when they are changed, but this is well advertised, and these changes are quite predictable.

The third type of properties not included in the TSCT are those properties that are either known to have no function, or may have a function but the function is unknown.  Changing these properties will probably have no effect; if it does, please let us know.

QuoteAlso, personally, I want to get more of the lower class citizens riding mass transit and the middle and higher class driving. I was just pondering, is there a value that can be adjusted to change the fiscal cost in simoleans that sims pay in order to use a certain form of transportation?

No, because the Sims don't actually have money.  Toll booths and the various transit networks collect fares, but the Sims don't actually pay them.  This is why adjusting the income from your transit networks doesn't affect their usage.

Instead, the best way to accomplish what you want is simply to change the "Mass Transit Usage" section of the TSCT.  You can either select one of the pre-existing distributions, or you can create one of your own.  There are limits to what can be done here, as this is basically a handicapping system, but by manipulating these figures and building enough mass transit and stops, you can get a large number of Sims out of their cars.