NAM Traffic Simulator Help

[Tarkus]

Paul, you can do it by re-installing, or you can also download the Mac version, which just has the files loose, so you can just drag the desired simulator option in.

-Alex (Tarkus)

[el_cozu]

I have a question... I noticed that the capacity for road, OWR and AVE are the same... Is the avenue gonna be double the OWR capacity?... cuz it is 2 tiles wide and I read somewhere that the capacity is established by tile and not by number of lanes...

I hope you can answer this one please...

[Tarkus]

I have a question... I noticed that the capacity for road, OWR and AVE are the same... Is the avenue gonna be double the OWR capacity?... cuz it is 2 tiles wide and I read somewhere that the capacity is established by tile and not by number of lanes...

I hope you can answer this one please...

Yes, that is correct.  The capacity is on a per-tile basis.

-Alex (Tarkus)

[paroch]

Hi Alex - thanks for the answer - I'll download the mac version and save the files outside of plugins til I need them.

Paul

[el_cozu]

Road / OWR / Avenue: 5600
Highway / El-Highway: 10800
Rural Highway: 10800


Wait a minute... if the avenue is gonna be double... that means the capacity for the Easy Simulator for AVE is 11200........ higher than a Highway......

but if the Avenue is 5600... i don't understand why Im using an Avenue if the road has the same capacity

[Tarkus]

Road / OWR / Avenue: 5600
Highway / El-Highway: 10800
Rural Highway: 10800

Wait a minute... if the avenue is gonna be double... that means the capacity for the Easy Simulator for AVE is 11200........ higher than a Highway......

but if the Avenue is 5600... i don't understand why Im using an Avenue if the road has the same capacity

Actually, highway, being a two-tile network, is set up exactly like an Avenue, such that the capacity over the full span of the network will actually be 2x that amount (21600).  An RHW-2 will have a capacity of 10800, but an RHW-4 will have a capacity of 21600 (as it is a two-tile network, albeit a "separable" one). 

And Roads and Avenues do not have the same capacity--Avenues, being twice as wide as Roads, will have 2x capacity.  The advantage Avenues had over Roads before, with the default Maxis Traffic Simulator, and the old NAM Plugins, has diminished with the new Plugins, as if it were not done this way, the TLA-7 and AVE-6 that will eventually be a part of the NWM mod would actually have less capacity than an Avenue.  So things were equalized across the board--Road=OWR=1/2 Avenue and Maxis Highway=Rural Highway (which also gives one reason to build RHW-6Cs when they want 6-lane highways as opposed to Maxis Highways--higher capacity).  The new Traffic Plugins were purposely designed to allow for better functionality of the RHW and NWM.

Hope that makes sense.

-Alex (Tarkus)

-Alex

[el_cozu]

actually... it does make sense... thanks again lol 

[z]

Simulator "A" has been designed by JPlumbley to extend the original travel distances set by the MAXIS Simulators.  For example in the original game the MAXIS Simulator allows the Sims to walk up to 7 tiles, but with Simulator "A" the Sims will walk upto 43 tiles to get to work.  This change in travel distance is due to the calculations used to allow Car Traffic to travel one full distance of a large city tile (512 tiles) on Avenues. 

Simulator "B" has been designed by Mott to work with the original travel distances set by the MAXIS Simulator.  For example in the original game the MAXIS Simulator allows the Sims to walk up to 7 tiles, therefore in Simulator "B" the Sims will walk upto 7 tiles.  Simulator "B" has also been re-calculated to be more balanced and provide better pathfinding overall.

I've been staring at Simulators A and B, and I don't see where you get the walking-to-work figures of 43 tiles for Simulator A and 7 tiles for Simulator B.  Both simulators use a walking speed of 5, and Simulator B has a longer Commute Trip Max Time.  Could you please explain how you derived these numbers?

To be more specific here, I see that you get the number 43 by multiplying 5 by your Commute Trip Max Time of 17, and then divide by 2 to get a one-way trip.  But if you perform the same calculations with Simulator B, you get 60, not 7.

Other modifications to both Simulators include changes to the follow properties with minor variation:

Congestion to Accident Probability - Revamped the probability curve.
Congestion vs. Speed - Made use of this, not used to full potential by MAXIS.  Sims will now look for better routes if the network is over congested.
Trip Length to Minutes Display Multiplier - Used in calculations for time displays on Commute Time Graph.

A number of people, including myself, have tried varying Trip Length to Minutes Display Multiplier, even changing it by many orders of magnitude, and yet we never see any effect on the Commute Time Graph at all.  Do you know for sure that your number is definitely affecting the Commute Time Graph?  (I.e., have you tried different numbers and seen the scale on the graph change?)  If so, is there something special you did to make this work?

[z]

What you say about Trip Starting Cost by Travel Type for Car or Mass Transit makes perfect sense.  But once again, there's the perennial SC4 question, What units are we talking about here?  The Maxis documentation for these properties says that they're "starting overhead cost in time."  It would seem to make sense that this is the same unit of time used in Commute Trip Max Time.  The values of 1 and 1.95 for penalties then seem significant compared to the original Maxis value of 6 for Commute Trip Max Time.  But if you increase Commute Trip Max Time, as both Simulators A and B do, shouldn't you increase these penalties proportionately?  Otherwise, they lose most of their effectiveness.

Then there's the simple Trip Starting Cost by Travel Type property, which currently isn't documented here.  This seems to be a straightforward penalty for using a car; it gives the Sim time to get to his or her car, maybe clear some snow off it, back it out of the driveway or garage, etc.  This is a fixed amount of time, so it seems that it should not vary with Commute Trip Max Time.

[z]

I've been doing some closer examination of the new traffic congestion graph.  Certainly it's accomplished its main goal; network congestion starts showing up when it first happens, instead of at 175% or so.  But I've noticed an unexpected side effect.  Transit stations (of all kinds) used to start turning yellow as soon as they exceeded 100% capacity.  Now they're completely green until they reach about 175% of capacity, at which point they turn just a tiny bit yellow - just enough to see.  This, of course, is exactly the problem that networks used to have.  Very strange.  Has anyone noticed this?  You might want to look into it, as it's basically as serious a problem as the one that was fixed.

[z]

Well, there's good news and bad news about the station congestion problem.  The good news is that it has nothing to do with the new traffic congestion graph.  I took a look at the exemplar for this graph for the first time, and sure enough, it's extremely simple; I didn't see how changing numbers here can cause the problem I described.

After your recent explanation of network capacity and why the new congestion graph was superior to the old, I finally switched over to it permanently.  It was shortly after this that I noticed the station congestion problem, and since I hadn't seen it with the old graph, I thought it was associated with the new one.  I don't have many congested stations, so this problem is somewhat difficult to notice.  But when I switched back to the old graph, I did find stations well over capacity that were still showing green, just as with the new graph.  So the problem had nothing to do with the graphs.

As for what caused this problem, well, I've made many changes to my traffic simulator.  So, I slowly backed them out, one by one, and after each change I ran the game on a city where I knew where congested stations were.  I backed out the changes that were the most recent and seemed the most likely first, but none of them were the problem.  So I kept backing out changes, starting up the game, and running the city, until I found the change that made the difference.  It was the last change that I thought could have anything to do with this problem.  Sure enough, though, once I backed out that change, station congestion started showing up properly again.

The bad news is that the change is the congestion vs. speed curve.

I had been using a congestion vs. speed curve that was somewhere between yours and Maxis', though it was a lot closer to Maxis'.  Well, I reasoned, if my curve causes this problem, then your curve should cause a problem at least as bad, and possibly worse.

It does.  In fact, with your curve, stations with 275% usage still show completely green.  That's as congested a station I could find, so I think it's safe to say that with your curve, you basically can't see congested stations on the traffic congestion map (old or new).

OK, the hard part was done, but there still was the question, What about our curves triggered this behavior?  One clue that I had was that whatever it was, it was present more in your curve than in mine.  The first thing that struck me was that you have a lot of data points where the first coordinate is non-integral; Maxis has none, and I have one.  So I removed mine and tried again.

That wasn't it.

OK, you use the ability to speed in a number of data points, which Maxis doesn't do at all.  I have one such point.  I removed it and tried again.

That wasn't it.

This was starting to get puzzling.  Maybe it's a combination of speeding and non-integral first coordinates?  No.  Hmm, what's left?  The number of data points!  Good guess, but wrong.

By this time, I had regressed my curve to the point where it was almost identical to Maxis'.  There was now only one difference.  It was clear that that difference had to be the significant one, and it was.

The lowest speed Maxis uses in its curve is 0.3.  I used 0.05; you use 0.  It turns out that once you start going below 0.3, you start messing up the congestion display of MT stations.  I have no idea why.  But your use of zero most likely results in their never showing congested no matter how packed they may be.  (Also, even if you decide not to fix this problem because you feel that maintaining the current congestion vs. speed curve is more important, you really don't want to use zero as a speed, as that creates a Simgularity (sorry about that!     ).  If the Sims ever reached that level of congestion, traffic would come to a dead halt, as you have mentioned.  But with a speed of zero, there would be no way for traffic to start moving again, ever.  You would have a permanent traffic jam.  The only way to get rid of it would be to demolish the underlying network.)

So that's the story with the congestion vs. speed curve.  You can use it to let the Sims speed, you can use non-integral first coordinates, and you can use as many data points as you like, from what I can tell.  But if you use speeds below 0.3, you'll mess up the display of MT station congestion.  I don't know exactly how far below 0.3 the effect kicks in, but my guess is that it's pretty close.  One thing I can tell you is that when I changed my lowest speed from 0.05 to 0.1, it had essentially no effect.

Hope this helps...

(BTW, do you know how the games handles situations where the congestion level is between data points?  Does the simulator fit a curve to the points, does it do straight line interpolation, or does it just use the point directly below the actual congestion level?  Also, what does it do for points beyond the end of the data set?  These things would be useful to know, for obvious reasons.)

[Streetlight 725]

Is there a another link to download this mod.The download link said that the file was locked.I want to download it.

[Tarkus]

Is there a another link to download this mod.The download link said that the file was locked.I want to download it.

It's included in the April 2008 NAM.  Just scroll down on the Traffic Simulator options, and you'll find all the various versions of the A and B Simulators (they're at the bottom of the list).

-Alex (Tarkus)

[z]

For a while now, I've been noticing various anomalies with the new Traffic Congestion View.  Once I got the new Traffic Volume View working, I could see much better what was going on.  (If you're interested, the new Traffic Volume View is now available for download at the bottom of its thread.)  Here's the relevant information you give about the new Traffic Congestion View:


My recent research contradicts what you state here.  Looking at the original Maxis Traffic Congestion View in all my cities, I find no instances where it underreports congestion at all, much less waiting until the 175% to 200% thresholds you report.  So I have to ask, Where did you get these numbers?  The only numbers I know of relating to capacity are the traffic volume numbers, and of these, only the morning commute numbers are available.  Please correct me if I'm wrong, but neither the evening commute nor the total daily commute numbers can be directly accessed.  So not only do I not understand how you determined the 175% and 200% numbers, but I don't understand how you calibrated your color ramp.  What numbers did you use to do this?  The one thing I can say for sure is that the percentages you show in your diagram of the color ramp do not match up with what actually shows up in the game.  The reason I can say that is that my new Traffic Volume View allows me to estimate evening commute numbers within about 10%; combined with the exact morning commute number, which is available, I can get a very good idea of what the total daily volume, and therefore the congestion, is.  And it just doesn't match up using the new Traffic Congestion View.  Using the orignal Maxis view, though, it does.

[z]

Thanks for your very detailed response.  It makes it completely clear exactly what the problem is here; you've been using bad data.  As a result, your color ramp is incorrect.

First, let me try to clear up some ongoing misunderstandings and state what we do agree on here, which is what I've believed from the start:

1. Congestion is defined as the amount of traffic that a network is carrying for a one day cycle that is in excess of the network's capacity.
2. This cycle is composed of the morning and evening commute periods, but the congestion depends only on the total traffic, and has nothing to do with its distribution between these two periods.

Where the problem arises is here:



Now I see where you got the 175% and 200% numbers from.  There is an underlying assumption, most evident in the lines highlighted by you in the quote above, that each increment in the first coordinate of each data point in the color ramp is equivalent to 10% of the network capacity.  For example, in the first boldfaced line you compute the congestion represented by pure yellow with the following formula:

HEX 1A = 26 x 10% = 260% Congestion

The whole problem is that this 10% assumption is just plain incorrect.  This is very easy to demonstrate.  Look at the original Maxis color ramp.  The next color after their pure yellow (0x99ffee00) is a yellow with a slight orange tinge (0x99ffcc00).  The coordinate for this color is 0x33.  Using your formula:

HEX 33 = 51 x 10% = 510% Congestion

That looks awfully high.  But it gets worse.  The next color moves toward the orange by an increment half as much as the first; its value is 0x99ffbb00.  And its coordinate is 0x4d.  Once again, using your formula:

HEX 4d = 77 x 10% = 770% Congestion

Now this is starting to look silly.  Nobody gets that much congestion.  And we're only half way between yellow and orange.  But still it gets worse.  Much worse.  I won't drag you through all the steps, but the spacing between coordinates is pretty even, and look where we end up, at pure red.  The color is 0x99ff0000, and the coordinate is 0xff.  Once last time, using your formula:

HEX ff = 255 x 10% = 2550% Congestion

Whoops!  I seriously doubt that anyone has ever experienced that much congestion in the history of the game.  Nor do I think that you would maintain that this is the correct number.  In fact, in a recent post in response to a question of mine, you said, "[Maxis] made the congestion color ramp show red at 250%... capacity."  From what I have seen, this is about right.  It's certainly easy enough to test by doing road queries, which you did.

So if increments in the first coordinate don't represent 10% of network capacity, what do they respresent?  I have no idea.  And it's not for lack of trying to figure it out.  I thought, "Maybe they just start the graph at 100%, and each increment is 1%."  That would mean pure yellow was 126%, which sounds about right.  But pure red would be 355%, which is definitely too high.  I've thought about various other possibilities that are more likely, but there's no need for me to go into them unless you want me to.  The bottom line is this:  I've learned that the color ramps in both traffic data views are unpredictable when looked at over their entire range.  Over short spans, they do appear linear, but that linearity cannot successfully be extrapolated end to end.  At least not by me.

Your color ramp is faithfully built on the assumption that one increment in the first coordinate represents 10% of network capacity.  So it tops out at 28 (0x1c), which gives it a range of about 11% of the range of the Maxis color ramp.  Traffic volume up to 100% still shows up as green using your color ramp, which gives some credence to the argument that the color ramp actually starts somewhere around 100%, and not at zero.  But the rest of your color ramp is still terribly compressed compared to the original.  According to what I've seen, red shows up much too early, and even though you have more oranges in your color ramp than Maxis, you see far less orange using your color ramp because the scale is just too compressed.

So what do I think should be done?  All the testing I've done shows me that the original Maxis color ramp (and therefore the congestion view) is basically correct as is.  When I look at traffic volumes for both the morning and evening commute on a given route where only one network is active, I can predict with reasonable accuracy the color that will be shown by the Maxis view.  And it doesn't start turning yellow at 175% to 200%; it starts turning yellow right over 100%.

---------------------

There is one mistake I made in my earlier posts.  In your post, you said:

When you are querying the Road it will show you the Traffic only for what ever commute time you are on.

I was quite sure I had tried out the Evening Commute button in all three places it exists when querying roads, and I had always gotten the morning commute value.  When I saw this line, I thought, "Well, I'd better double check my facts before I challenge jplumbley yet again."  Sure enough, the route query tool does exactly what you say.  So I must have remembered wrong.  My apologies.  Fortunately, I always knew I was dealing with the morning commute number, so this didn't affect anything I did.  This will certainly make testing easier, though.  Too bad Maxis didn't synchronize the commute period between the Traffic Volume View and the route query tool - that would have made a lot of sense.

And once again, my apologies for writing so much...   

Please, make sure you are keeping any criticism constructive in tone.  -Alex (Tarkus)

[b22rian]

Hi ...

Ive been following this thread with great interest.. And both of you guys are bringing up some good points..
and its helping with my understanding all this..And I'm enjoying the learning process with it all..
With your last post Z I'm finally beginning to understand how the numbers work and the points you made
in your last posting are well taken..

   Having quite a large city now and I'm using motts' sim B on hard difficulty .. and actually visually it had
crossed my mind I'm not seeing too many yellows and oranges .. I'm playing on a large map and still most
areas show in the green.. but there is more red in the map than there are oranges and yellow which seems to
on the surface anyways confirm what you have been saying in your post.. i pay quite a bit of attention to traffic
in my games, and yes it does make sense to me that as things eventually become gradually congested you should
start out seeing more yellow and oranges.. which over time will become "reds"... Not have things jump kinda quickly up to reds... Which could indicate the colors are a bit condensed in the graph..

  But to be honest from a 'gaming sense" if this in fact the case ... and this is how i see the game . not speaking for anyone else's viewpoint on it.. I don't see it as a big problem .. Because wanting to play this aspect of the game as well as i can, I dont see the harm by being alerted by reds, which tell me that i need to make changes in my game...

  I just hope that in time we can all work together on these "issues"  and continue to improve these aspects..
and try to follow the leads of people like Mott and j plumbley whom we owe so much to for the wonderful
improvements they have made in the path finding engine of this game and their excellent traffic sims..

Thanks Brian

[z]

I've discovered another problem with the new Traffic Congestion View.  For those traffic simulators that enable the proper display of mass transit station congestion, the Maxis Traffic Congestion View starts showing station congestion at 101%, while the NAM Traffic Congestion View doesn't show any congestion at all until around 120%.  All the stations I tested were roadside stations, not RTMT.

[z]

Jplumbley,

I finally have some good news about the Traffic Congestion View.  Last night I spent some time looking at mott's original post on the subject, and I saw where all the problems have come from.  What mott said in his post was completely correct, as usual; the problem is that he stated one of his findings ambiguously, in a way that was easy to misinterpret.

First, let me say that I am just as impressed by mott's work as everyone else here; I think much of what he did was absolutely brilliant.  I have absolutely no disagreements with anything he said about the Traffic Congestion View (nor anything he said about TE lots, either, although that's a subject for a different post).  I am sorry that you got the impression that I disagreed with him, and I will do my best to correct that impression.

First, here's what mott actually said:

I changed the congestion graph too, and got it working with an arbitrary number of color steps at arbitrary usage.  Annoyingly, the 0-255 scale seems to be such that 0=0% and 1=100%, 2=110%, 3=120%, etc.    Things turn yellow at 100% usage, then start sliding through the oranges until they hit bright red at around 200%.  The ramp-to-red happens quickly, but with the settings we're looking at, 100%-200% is the most info-critical range.  It's in the .dat so you can play with a working one.

Mott noticed the same thing here that I mentioned in my last post, namely that the graph effectively starts at 100%.  So I think we can take that as a given, especially as a quick check of the evidence backs it up.  But then mott mentions the 10% increments that you have built into your graph.  This was very puzzling at first, as there's no question that they lead to the impossibly high numbers that I mentioned before, and therefore cannot possibly be right.  Mott's a very sharp guy; he would have known this.  So I figured there had to be a different interpretation of what he was saying.

There's only one other interpretation I could think of, but sure enough, it works out perfectly.  The 10% differences he's talking about are not per unit of the first coordinate, but are instead per cell of the color ramp.  Starting with an index of zero, cell 1 is pure green; we know that for sure.  And in his quote, mott says "1=100%".  Counting cells, the "2 = 110%" is the pure yellow, the "3 = 130%" is slightly orangish yellow, etc.  The clincher comes when mott says that bright red occurs in the chart "around 200%".  If you're counting cells, and assume a 10% difference between each cell, then sure enough, bright red occurs at exactly 210%.  Furthermore, this concurs completely with my experimental work, where I've been able to find bright red at levels as low as 216%.  Probably if I looked long enough, I'd find them going down to 210%.

So the coordinates don't need to be changed. According to mott's formula, changing the red to 0x1c, as it is in the current NAM Traffic Congestion View, would result in having bright red start at 110%.  (I've actually seen it at 111%.)  This is why the NAM Traffic Congestion View view looks so compressed.  By the same measure, 210% is the highest threshold it's possible to get for bright red, as it is represented by the highest possible coordinate, 0xFF.

This leaves just one piece of the puzzle left.  First, here are the lines from mott's post that immediately follow the previous quote:

BTW, the format of those color values is:  OORRGGBB.  OO = Opacity (00 = transparent, FF=opaque).  The game uses opacity 99 for color overlays on the Traffic Congestion data view, so they are just under 50% transparent.  So, Pure Red should be coded as 0x99FF0000, pure green is 0x9900FF00.

This is the color scheme that I had independently arrived at, and described in the "Technical Notes" section near the end of my Traffic Volume View thread.  However, it's different from what you quoted me, which using mott's convention, was RRGGBBOO.  It appears that you used this second scheme when adding some colors at the beginning of the color ramp.  If the second scheme were correct, it would gradually increase the green in the color ramp, but instead, it gradually increases the red, which does not seem to have any noticeably effect on the color.  However, what it does do is push the green part of the color ramp above 100%.  Meanwhile, by cutting the yellow coordinate from 0x1a to 0x0d, the yellow is pushed closer to the green.  So the yellow is narrowed from both ends, which is why much less yellow is seen in this Traffic Congestion View.

Using mott's numbers, with pure green at 100%, then each increase in the first coordinate of each data point represents an increase of 0.3846% (instead of the 10% you used).  This means that by adding the extra green colors, the green part of the spectrum now goes up to 103.85% instead of 100%, while pure yellow now appears at 104.61% instead of 110%.  This explains why all the different greenish-yellow shades are gone.  And with red at 110%, there's not much room for orange, either.

So what to do?  As mott said in the first quote above, "The ramp-to-red happens quickly, but with the settings we're looking at, 100%-200% is the most info-critical range."  Once again, I agree completely.  But this means that the original Traffic Congestion View was fine just the way it was, especially since it's not possible to get a higher threshold for red.  So I would strongly suggest restoring the original view, which is the only one that fulfills mott's requirements.  Your idea of adding additional oranges to the view was a good one, but it's not at all necessary, as I found while working on my Traffic Volume View, because the program interpolates the missing colors just fine.  And the indices in the color ramp are set so as to allow room for these interpolated colors.  The one change that could be reasonably made is something that I saw you suggest a while ago, which would be to add a legend showing what percentage of congestion each color represents.  The legend could also be expanded into a finer detail.  I know you're very busy, so I would volunteer to do this, if you like.  My experience with the Traffic Volume View would make this quite simple.

I have tried to make a compelling case that is internally consistent, consistent with observed data, and in complete agreement with mott's findings.  Please let me know what you think.  Thank you.

[Tarkus]

z, thank you for the detailed post on the datapoints used by the simulator.  I have been following the Simulator and DataView research going on here from a distance since mott was around . . . albeit, not particularly well, since it's not my area of expertise, and I hadn't really messed around with those too much (other than very limited tweaking for the NWM some time ago).  However, I have had a chance to look over the related exemplars some now, including undertaking a few experiments of my own.

The idea that the Congestion DataView does not allow for color differentiation until 100% is indeed a bit of a letdown--I share your and mott's frustration there.  It would effectively render the Congestion DataView relatively useless compared to the Volume DataView.  However, from an experiment I just did, I now believe that the 0x00000001 data point in the Color ramp isn't 100%.

Just out of curiosity, I took the default Maxis Congestion DataView exemplar, and changed the associated color value from the pure green (0x9900FF00) to the pure red (0x99FF0000).  The result was quite unusual and unexpected.  Every single road in the city had turned red, even if it had no traffic, and the road that was slightly over capacity was actually showing up a reddish-orange, even though it was still listed as the greenish-yellow (0x99FFEE00).  I was not able to test it with any farther-over-capacity networks, but judging by the initial results, I would tend to believe that the result would be a switch from green-to-red to red-to-green.

So, my hypothesis is now that the 0x00000001 data point serves two functions: 1) defines the color at 0% capacity and 2) defines the other colors that come after it in some way.  Whether or not the 100% endpoint for 0x00000001 can be changed, I'm not certain, though from what both you and mott are saying, it sounds like it can't.

If I am interpreting this right, it means we still do not know the associated percentage values of the other data points 

I hope that made at least some sense.

-Alex (Tarkus)

__________________________________________________
Edit as of 7:26pm US Pacific Daylight Time:

I've done some more experimentation, and I believe I have "cracked the code" with the Traffic Congestion View.

It seems that it is possible to assign a different color to traffic congestion values less than 100%, and I have figured out the formula for the data point values.

It appears it is not based on a fixed percentage rate, like 10% or 0.3846%, but rather, the values correlate to percentages by Base 16 Logarithms. 

The first clue to this was my aforementioned discovery that changing the color associated with 0x00000001 changed the color for roads that were at 0% capacity.

log₁₆1=0

log₁₆256=2

Considering that the basic definition of a percentage is that it is 100 times a decimal number, that 2 is really a 200%.  (Technically, the top part of the original Maxis ramp was 255 (Hex=FF), so its Base 16 Logarithm is actually something like 1.9985, which, for all intents and purposes, can be rounded up to 2.)

So, the issue with the original NAM graph was not that there was a 100% minimum causing it to get compressed . . . it was that the data points were too close together and the highest point was too low.

This is how the original Maxis graph was distributed.  Variable x corresponds to the datapoint.  (Decimals rounded to two significant figures)

Maxis Congestion DataView Points

x (Hex)	x (Dec)	log16x	% of Capacity
1	1	0	0%
1A	26	1.18	118%
33	51	1.42	142%
4D	77	1.57	157%
66	102	1.67	167%
80	128	1.75	175%
99	153	1.81	181%
B3	179	1.87	187%
CC	204	1.92	192%
E6	230	1.96	196%
FF	255	2.00	200%

So really, the Maxis graph has no differentiation between 0% and 118%, and the congestion coloration covers an 82% range.

Here's how the NAM Congestion Graph jplumbley designed looked with the current Data Points:

NAM/jplumbley Congestion DataView Points

x (Hex)	x (Dec)	log16x	% of Cap	Intended % of Cap
1	1	0	0%	10%
4	4	0.50	50%	40%
9	9	0.79	79%	90%
B	11	0.86	86%	110%
D	13	0.93	93%	130%
E	14	0.95	95%	140%
F	15	0.98	98%	150%
10	16	1.00	100%	160%
11	17	1.02	102%	170%
12	18	1.04	104%	180%
13	19	1.06	106%	190%
14	20	1.08	108%	200%
15	21	1.10	110%	210%
16	22	1.11	111%	220%
17	23	1.13	113%	230%
18	24	1.15	115%	240%
19	25	1.16	116%	250%
1A	26	1.18	118%	260%
1B	27	1.19	119%	270%
1C	28	1.20	120%	280%

So, the distribution there is actually quite good up until about 5 data points in, where it gets compressed, such that the points are only 1-2% apart, topping out at 120%.

I think the scale that jplumbley had originally intended is a good one, so I've begun calculating new points to closely approximate his as much as possible.

Theoretically, the way the values are formatted, as 32-bit unsigned integers (Uint32) with 8 figures, it should theoretically be possible to create 3 or more digit hex numbers, which can correlate to the values beyond 200%.

-Alex

[b22rian]

Here's how the NAM Congestion Graph jplumbley designed looked with the current Data Points:

still working on it . . .

I can't wait...!

Tarkus, you are utterly amazing man !