• 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 2 Guests are viewing this topic.

z

The CvS curve is just a variable number of points on a two-dimensional graph, which are interpreted as line segments by the game.  The points can theoretically have any values greater or equal to 0.3, but in practice, they tend to fall near a straight line.  However, taken as a whole, they don't form any curve that can be described mathematically.

One of the uses of the CvS curve is to improve the performance of the pathfinder.  Ideally, you want the CvS curve to assist in tie-breaking for A*, but not have too many points, as that increases the number of necessary calculations.  I did a number of experiments that determined that the ideal number of points for this curve in SC4 is six, with the slope of each succeeding line segment being at least slightly different from its neighbor.

ldog

Quote from: z on December 07, 2009, 06:33:21 PM
The CvS curve is just a variable number of points on a two-dimensional graph, which are interpreted as line segments by the game.  The points can theoretically have any values greater or equal to 0.3, but in practice, they tend to fall near a straight line.  However, taken as a whole, they don't form any curve that can be described mathematically.

One of the uses of the CvS curve is to improve the performance of the pathfinder.  Ideally, you want the CvS curve to assist in tie-breaking for A*, but not have too many points, as that increases the number of necessary calculations.  I did a number of experiments that determined that the ideal number of points for this curve in SC4 is six, with the slope of each succeeding line segment being at least slightly different from its neighbor.

Not disagreeing with you here (although I use between 4 and 7 points; I have still been trying various things out) but I'm curious if you got the same results as I did trying lower than .3
I found it had no effect (except performance which may or may not have been impacted but it wasn't a condition I was observing at the time)
Congestion display still goes red at .3 and it does not seem to get any redder (is that a word?), pathing and traffic volumes also didn't change.

z

This is completely consistent with what I found.  Congestion doesn't get any redder when you use values below .3; just the opposite typically happens, although some or all of the red may remain, depending on your congestion level.  Normally, congestion starts showing up when the network volume exceeds 100%.  This threshold gradually rises as the value of the lowest point in the curve drops below .3.  This is true even if the volume of none of the networks gets as low as that associated with the lowest point.  The net result is that less congestion is shown than actually exists, with the result becoming more pronounced the lower the lowest speed value is.

ldog

Quote from: z on December 08, 2009, 12:24:03 PM
Normally, congestion starts showing up when the network volume exceeds 100%. 

Not quite true actually. Remember one of my experiments: http://sc4devotion.com/forums/index.php?topic=9179.msg288758#msg288758
Bottom of the page, you might have missed that one the first time. The CvS seems to be even more important to the proper functioning of the simulator than what has been said.

Also my latest tests I've been trying something a little different. I decided to try a CvS that is basicly doubled.
So 200% gives 1.0 speed, 600% gives .3 speed (extrapolate in between).  It works I suppose, in that it makes the effective capacity higher before congestion kicks in, although I have not been able to observe it probably screws with the lane changes. Although TBH I have trouble observing more than a single lane used (and have never seen 3) on the (even heavily congested) highway most of the time each direction even with the same CvS curve as Sim Z.

z

By "Normally," I meant the standard Maxis simulator, as well as all other simulators except Simulator A, where congestion starts showing up when network volume exceeds 75%.  The CvS curve is very important to the proper functioning of the simulator; I don't think that's ever been in dispute.  The congestion that it provides is very important to the pathfinding part of the simulator.  It's possible to change it so that congestion doesn't happen at all, as you showed, but of course, no one actually does that in production simulators.

One point that I was making earlier when I said that I thought that the PH was the single most important property in the simulator is that if the PH is too high, the importance of values in other properties may decrease.  In this case, the higher the PH, the less effect congestion (and by implication, the CvS curve) has on routing.

Your other test results and interpretation also make sense for the CvS curve, although such settings would effectively redefine what capacity and congestion meant if they were actually used.

As for the highway lanes, I assume you're talking about the Maxis highway; I have not seen what you describe there.  Since there's only a single tile for each direction, the cars per lane would not be affected by the traffic simulator directly; it's more a function of the automata.

If you're talking about the RHW, again, I haven't seen this problem, and this has been tested thoroughly.  Simulator Z using the same speed premium as Simulator A here (30%), and this premium has been shown to be quite sufficient to provide excellent lane spreading.

ldog

#405
Quote from: z on December 08, 2009, 05:01:58 PM
As for the highway lanes, I assume you're talking about the Maxis highway; I have not seen what you describe there.  Since there's only a single tile for each direction, the cars per lane would not be affected by the traffic simulator directly; it's more a function of the automata.

If you're talking about the RHW, again, I haven't seen this problem, and this has been tested thoroughly.  Simulator Z using the same speed premium as Simulator A here (30%), and this premium has been shown to be quite sufficient to provide excellent lane spreading.

I was, I remember you saying somewhere that the Maxis highways had 3 lanes each way. No, of course I'm not talking about the automata. Talking about the route query. For example on a road, you can see an arrow going each way (1 each direction), on a crowded OWR I will see 2 arrows (going the same direction of course). On an ave, the same effect on each tile. Highway I have on occasion seen the same effect as on the Ave. I've also seen pedestrians walk down both sides of a road (street, owr, what have you). Now it is not clear to me if this is just a graphical artifact or if it means separate paths actually being traveled on the same tile. This is what I assumed y'all were talking about in prior discussions about spreading into lanes.

RHW I really don't have enough experience with to make any statements about. I played around with them only briefly, when I first installed the NAM, back when I actually played instead of playtesting. The only piece of the NAM I have installed (when not testing Mark's region) is the zone dataview.

Oh...
Quote from: z on December 08, 2009, 05:01:58 PM
Your other test results and interpretation also make sense for the CvS curve, although such settings would effectively redefine what capacity and congestion meant if they were actually used.

Capacity yes, congestion no. Capacity could be much lower and still provide the same overall capacity. Why bother then? Just trying to follow out some thoughts about capacity and see what kind of difference it makes. One of the things that stands out is besides the fact that congestion is caused by both morning and evening commute volumes it is also static as far as time is concerned; every single sim that travels along a given network is considered to be there at all points in time (and twice if they cross the same path going home). Obviously our sims must all be traveling at close to the speed of light and we have severe time dilation problems  :P (sorry, was doing a little "light reading" today  :o unintended pun there too). While I have made very little forays into real world traffic engineering (it is a very complex subject that I don't really have the time nor the inclination to devote myself to, and I don't think the traffic simulator does the subject justice, or even comes close for that matter) I think capacity in the game and capacity in the real world work very differently.

And I'm rambling again...

Anyway, another pet idea is that if capacity does top out at some point eventually (like say 1000%) it would make sense to set the 30% speed mark around that level, and then scale back the capacity as appropriate.

ldog

A bit of testing reveals that network capacity is indeed unlimited.
I cut capacity to 1/10th across the board. I also jacked the CvS so that it was at 1000% that speed was reduced to 30% and ran it a bit.
Just to be extra sure I then went to 1500% and ran a bit.
With a base capacity of 400 for rail I had about 78000 passengers on some segments.

By the way saw a bus station go to 615% (I didn't bother re-modding my stations for this). Did not see any train stations that high but 1 thing I will say, I think when setting TSEC it should be done based on 30% speed since congestion may not affect the station but it does affect shortcutting through it. As congestion goes up the station becomes more desirable to shortcut across if the TSEC was set according to normal speed.

z

Quote from: ldog on December 08, 2009, 05:31:20 PM
I was, I remember you saying somewhere that the Maxis highways had 3 lanes each way. No, of course I'm not talking about the automata. Talking about the route query. For example on a road, you can see an arrow going each way (1 each direction), on a crowded OWR I will see 2 arrows (going the same direction of course).

Although there is one path per lane on the Maxis highway, the route query arrows aren't related to those paths; instead, they seem simply to be related to routes.  Take a look a the following picture:



As you can see, the highway is not particularly crowded on the far side, yet there are three route arrows for cars and one for buses - more than the number of lanes.  This would seem to rule out a correlation between the number of route arrows and the number of lanes in use.  It would also mean that the values in the CvS curve do not affect the number of arrows you see.

QuoteOn an ave, the same effect on each tile. Highway I have on occasion seen the same effect as on the Ave. I've also seen pedestrians walk down both sides of a road (street, owr, what have you). Now it is not clear to me if this is just a graphical artifact or if it means separate paths actually being traveled on the same tile.

The automata follow the paths; by using the "drawpaths" cheat, you can see that indeed it does mean that separate paths are being traveled on the same tile.

QuoteThis is what I assumed y'all were talking about in prior discussions about spreading into lanes.

No, spreading only applies to multiple-tile roadways going in the same direction; right now, the RHW is the only example of this.

Quote
RHW I really don't have enough experience with to make any statements about. I played around with them only briefly, when I first installed the NAM, back when I actually played instead of playtesting. The only piece of the NAM I have installed (when not testing Mark's region) is the zone dataview.

I should simply add here that shortly after I made my last post, I realized (and it was also pointed out to me independently) that the 30% speed premium of Simulator A is not identical to the 30% speed premium of Simulator Z, since Simulator A has 100% of nominal speed at only 75% capacity.  This makes its speed curve steeper for low speeds than Simulator Z's.  However, my own tests have shown that spreading works fine in Simulator Z with its CvS curve.  Again, the PH plays an important part here.  With a higher PH, Simulator Z's CvS curve might not produce satisfactory spreading.

I also tested lower values for the speed premium, specifically 20% and then 25%.  Even going down to 25% was enough to reduce spreading to uneven levels.  So considering that Simulator Z uses perfect pathfinding, I can say that 30% is the minimum speed premium between 0% and 100% capacity that produces even spreading on the RHW.

QuoteOne of the things that stands out is besides the fact that congestion is caused by both morning and evening commute volumes it is also static as far as time is concerned; every single sim that travels along a given network is considered to be there at all points in time.

Yes, we only see a total for each commute period, and I've seen no reason to believe that the simulator divides things any finer internally.

QuoteDid not see any train stations that high but 1 thing I will say, I think when setting TSEC it should be done based on 30% speed since congestion may not affect the station but it does affect shortcutting through it. As congestion goes up the station becomes more desirable to shortcut across if the TSEC was set according to normal speed.

I disagree here; many experiments have shown that there are severe penalties for setting the TSEC too high; i.e., the Sims will often stop using that transit line.  On the other hand, shortcutting has not been shown to have any real impact on game play.  I think that the best way to set the TSEC is to set it to .96 divided by the nominal speed of the fastest travel type that actually passes through the TE lot.  This will eliminate shortcutting in many situations, and reduce it in others.  In cases where shortcutting does exist, it can be minimized or eliminated by designing the TE lot well.

ldog

Quote from: z on December 08, 2009, 07:56:57 PM
Although there is one path per lane on the Maxis highway, the route query arrows aren't related to those paths; instead, they seem simply to be related to routes.  Take a look a the following picture:

As you can see, the highway is not particularly crowded on the far side, yet there are three route arrows for cars and one for buses - more than the number of lanes.  This would seem to rule out a correlation between the number of route arrows and the number of lanes in use.  It would also mean that the values in the CvS curve do not affect the number of arrows you see.

The automata follow the paths; by using the "drawpaths" cheat, you can see that indeed it does mean that separate paths are being traveled on the same tile.

No, spreading only applies to multiple-tile roadways going in the same direction; right now, the RHW is the only example of this.

I should simply add here that shortly after I made my last post, I realized (and it was also pointed out to me independently) that the 30% speed premium of Simulator A is not identical to the 30% speed premium of Simulator Z, since Simulator A has 100% of nominal speed at only 75% capacity.  This makes its speed curve steeper for low speeds than Simulator Z's.  However, my own tests have shown that spreading works fine in Simulator Z with its CvS curve.  Again, the PH plays an important part here.  With a higher PH, Simulator Z's CvS curve might not produce satisfactory spreading.

I also tested lower values for the speed premium, specifically 20% and then 25%.  Even going down to 25% was enough to reduce spreading to uneven levels.  So considering that Simulator Z uses perfect pathfinding, I can say that 30% is the minimum speed premium between 0% and 100% capacity that produces even spreading on the RHW.

Yes, we only see a total for each commute period, and I've seen no reason to believe that the simulator divides things any finer internally.

I disagree here; many experiments have shown that there are severe penalties for setting the TSEC too high; i.e., the Sims will often stop using that transit line.  On the other hand, shortcutting has not been shown to have any real impact on game play.  I think that the best way to set the TSEC is to set it to .96 divided by the nominal speed of the fastest travel type that actually passes through the TE lot.  This will eliminate shortcutting in many situations, and reduce it in others.  In cases where shortcutting does exist, it can be minimized or eliminated by designing the TE lot well.

Thanks for the info. Recent observations make me suspect that the arrows just had to do with how it was drawn and not actual lanes (I disagree with the 4 arrows conclusion; the bus is a different travel type but it uses the same path as the cars, so it could be 2 lanes of cars only and 1 lane of car and bus HOWEVER as you point out the volume is pretty low, especially since I'm guessing Z ultra...that isn't even enough to hit your first CvS marker is it?) , and of course since I don't use the RHW I really couldn't figure out what the hell y'all were talking about. Interesting that the pedestrian route query arrows will generally follow the sidewalks though (which is what the drawpaths in your picture shows).  :-\ I'll have to play with the drawpaths. I have never seen automata go into 3 highway lanes, let alone more than 2 route query arrows (counting 2 car and 2 bus as 2 not 4).  &Thk/( NAM team modify the Maxis highway ruls? That would be a good reason I wouldn't see it.

Quote from: z on December 08, 2009, 07:56:57 PM
I disagree here; many experiments have shown that there are severe penalties for setting the TSEC too high; i.e., the Sims will often stop using that transit line.  On the other hand, shortcutting has not been shown to have any real impact on game play.  I think that the best way to set the TSEC is to set it to .96 divided by the nominal speed of the fastest travel type that actually passes through the TE lot.  This will eliminate shortcutting in many situations, and reduce it in others.  In cases where shortcutting does exist, it can be minimized or eliminated by designing the TE lot well.

I'm still torn on that. Sometimes it does; ped speed 1km, TSEC .96 (horrible disaster) and sometimes it doesn't; 3.5km and TSEC .27 seems to work just fine...in theory they should be equivilant but they aren't apparently.  What I'm talking about though is offline stations with parallel routes; the amount of trains that will shortcut through the station instead of staying on the rail skyrockets. TE lots that allow through car traffic are also horrible about that, regardless of the PH sometimes it seems (I mentioned that in a pm about a week ago I think).  ??? Come to think of it, my train stations TSEC is .27 trains shouldn't shortcut through them at all either.

z

Quote from: ldog on December 08, 2009, 08:27:30 PM
I'm still torn on that. Sometimes it does; ped speed 1km, TSEC .96 (horrible disaster) and sometimes it doesn't; 3.5km and TSEC .27 seems to work just fine...in theory they should be equivilant but they aren't apparently.

The basic speed structure is hardwired into the game in some places; I'm not sure if we've found them all yet.  For example, whether or not a commute is deemed long or short is based on absolute times; if you move your speed structure down too far, you get too many long commutes, which result in lowered desirability for the residentials, which then may result in downgrading.  This is even if you have an unlimited commute time and a perfect PH.  If you look at the speed structure in Simulator Z, you'll see that the road speeds are higher than the Maxis ones, but the rail speeds are lower; overall, it more or less evens out.  This seems necessary for optimal performance.  So using speeds that are calibrated for the PH that you're using shouldn't give problems.

Quote.  What I'm talking about though is offline stations with parallel routes; the amount of trains that will shortcut through the station instead of staying on the rail skyrockets.

That's why I said "the nominal speed of the fastest travel type that actually passes through the TE lot."  For stations like the Maxis train station, the train is unaffected by the TSEC, so you can set it a lot higher.

QuoteTE lots that allow through car traffic are also horrible about that, regardless of the PH sometimes it seems (I mentioned that in a pm about a week ago I think).

Yes, such lots can certainly be a problem.  Great care has to be taken in placing them; otherwise, the route through them may be much shorter than any alternative route.  The TSEC may need to be set on an individual basis for such lots.


z

Quote from: sumwonyuno on December 06, 2009, 04:01:03 AM
The Capitalis City Council and Citizens Against Virtually Everything are in an uproar.

You have one of those groups in your city too?  They seem to be everywhere.  And always in an uproar.  ::)

QuoteYou might want to try rezoning the commercial areas in Obama's neighborhood to high density to see what traffic patterns occur for Makiki residents and westbound freeway commuters.  Same thing for the Waikiki city tile.  (I'm assuming you know the places I'm talking about  ;)).

Not exactly, but I did rezone the southern area of commercials just above the industrials.  This did not produce skyscrapers.  I think I understand the reason why; it appears that the destination finder produces a bell-shaped curve of destinations when you plot Sims vs. distance.  I'll be going into this more in a later post.

QuoteAs for the eastern suburbs, I'm talking about Sector 24, 25, 26.  All commuters should be going west.  I don't believe it's me mistaking the morning/evening route query.  Assuming you haven't resaved the city tiles, try Sector 25, and don't unpause.  Query the avenue and it should say ~11000 cars westbound and ~7000 eastbound.  Those 7000 eastbound shouldn't be going to Sector 26, because there's isn't that many jobs out there.  It probably has to do with some legacy issue in my region.

Sector 22 <- 23 <- 24 <- 25 <- 26 <- 18 is the general pattern I'm aiming for, but it's not what is happening in the game.

I looked into this a fair amount, and found exactly what you did.  The predominant traffic flow is in the direction that you mention, which is good, but as you said, there are still thousands of commuters going the other way.  Where are they going?  It's hard to say.  To be honest, some of this doesn't make sense to me.  Once the avenue traffic splits up into road traffic in Sector 26, it's much harder to see who's coming and who's going.  There certainly aren't any jobs to speak of in Sector 18 - certainly not enough to account for even a fraction of the 7000 eastbound commuters.  All I can say at this point is that this does not appear to be a traffic simulator problem, nor does there appear to be an eternal commuter loop here.  What's actually going on would take a lot more investigating, though.

QuoteFeel free to do testing on the one-way road modifications on my region.

I did, and the results were very useful.  With Simulator Z Ultra, there was a definite increase in jobs in your downtown city, although it wasn't huge; in fact, it was fairly anemic.  Other capacity levels of the simulator didn't show a change, however.  This is consistent with my other testing showing that a 30% increase is significantly below optimal for these roads.  All my testing and calculations show that 50% would be a far better number here, both for one-way roads and for the NWM.  I'll be explaining this in detail in a later post.  In the mean time, has anyone else done much testing with the new one-way road settings?  If so, is there any reason to think that a 50% number would have negative effects, based on such testing?

On a related note, I looked more into what I've been calling the "intrinsic" advantage of one-way roads over two-way roads, which we've been mentally adding on to this 30% number.  When I look closely, though, it seems that it most situations, there is no intrinsic advantage at all.  It seems that it exists only in rather rare commuting situations.  It's certainly possible that I'm missing something, but I don't see what.  If someone sees what this intrinsic advantage is, could they please point it out here?  Actual numbers would be extremely helpful.

ldog

#411
Quote from: z on December 11, 2009, 07:51:15 PM
On a related note, I looked more into what I've been calling the "intrinsic" advantage of one-way roads over two-way roads, which we've been mentally adding on to this 30% number.  When I look closely, though, it seems that it most situations, there is no intrinsic advantage at all.  It seems that it exists only in rather rare commuting situations.  It's certainly possible that I'm missing something, but I don't see what.  If someone sees what this intrinsic advantage is, could they please point it out here?  Actual numbers would be extremely helpful.

Steve, are you talking about in real world or in the game? In the real world the intrinsic advantage is I think as Mott pointed out that of allowing uncontrolled left turns (no oncoming traffic to go against) so we only need traffic controls for cross traffic. Since intersections in SC4 don't work the same as in the real world, I would say in SC4 they have no intrinsic advantage. Which is why they need greater speed and/or capacity to give them some advantage.

The same thing goes for the avenue since it basicly is a much more expensive pair of OWR. And then so it needs advantage over 2 OWR and/or it needs to be reduced in cost (plop and maintenance)

Quote from: xxdita on December 11, 2009, 07:58:20 PM
But according to the Census Repository, both cities have roughly 2,000 commuters coming in. Any ideas on how to deal with the hobos?

??? Who says this game isn't realistic!

Seriously though, wow. Are we sure the census repository isn't misreporting?
What are the freight counts by the way? Maybe it counts freight as commuters?

z

@sumwonyuno:  I believe I have found your problem.  It seems to have been a simple problem of the cities being out of synch.  I simply ran Sector 26 for a few years, and the eastbound/northbound morning commuters dropped from 7000 to 683.

@xxdita: Freight train stations aren't supposed to allow passengers.  Have you verified with the route query tool that your commuters are actually coming in on the trains?  I understand that there's nowhere else that they could come from, but this is SC4...

[About the "intrinsic" advantage of one-way roads over two-way roads...]
Quote from: ldog on December 11, 2009, 08:13:12 PM
Steve, are you talking about in real world or in the game?

In the game.

QuoteI would say in SC4 they have no intrinsic advantage. Which is why they need greater speed and/or capacity to give them some advantage.

That is my thinking exactly.

QuoteThe same thing goes for the avenue since it basicly is a much more expensive pair of OWR. And then so it needs advantage over 2 OWR and/or it needs to be reduced in cost (plop and maintenance)

It's not quite the same, since you can't have timed stoplights for a two-way avenue that work the same as for a OWR.  But I've already mentioned the possibility of having faster avenues as an alternative to the standard ones (for suburban and exurban areas, for example), and I'll be going into this more in a post that will be coming soon.

RippleJet

I've split this topic and moved the discussion regarding the Census Repository and extrapolated demand to this place. ;)

ldog

Quote from: z on December 11, 2009, 08:38:41 PM
It's not quite the same, since you can't have timed stoplights for a two-way avenue that work the same as for a OWR.  But I've already mentioned the possibility of having faster avenues as an alternative to the standard ones (for suburban and exurban areas, for example), and I'll be going into this more in a post that will be coming soon.

Yeah, I had thought about that. The minute you make an intersection across an avenue it is no longer exactly the same; since the pair of OWR do not need to be adjacent to each other (which the ave is). Even an intersection of only 1 lane of the ave (so we can make a righthand turn to get off ave, and adjoining network can make a righthand turn to get on ave, but you cannot go across the ave; no left turns) is a somewhat different effect.

sumwonyuno

#415
Yes, this group is present in every place you go, opposing things for political, ideological, and (secret) financial reasons, taking forever on resolutions that I support, and constant deferrals... those elected City Councilmembers!!... Oh, you mean the C.A.V.E. people (well there are always C.A.V.E. people on every City Council)  :P

Anyways, I think when you rezoned some areas, there wasn't any growth probably because of desirability factors.  The commercial area you're talking about is fairly stable.  I tried demolishing the industrial areas by Kaka'ako Waterfront Park.  The megalots came in and there were thousands of commuters that came to work there (compared to a few hundred before).  I didn't stay long to look if the general traffic pattern changed from the city-tile-skip paradigm.  I'll be waiting to see what you have for that bell-shaped curve.

Ahh, I was suspecting that (synchronization of cities) was to blame for the weird destinations.  I guess I have to wait much longer for the synchronization to work itself out.


The City & County of Honolulu, a Mayor Diary based on Honolulu, Hawai'i.

mark's memory address - I've created a blog!

z

#416
Release of Simulator Z v2.0 Beta 1

At the bottom of this post, I've attached the first beta release of Simulator Z v2.0.  Some of you may recall that at one point, I said there never would be a V2 of Simulator Z.  The reason I changed my position here is that during my testing, I discovered that the differences between recent versions of Simulator Z (starting with v1.2) and earlier versions of Simulator Z, including all those released with the NAM, was greater in important areas that the difference between Simulator Z v1.0 and other simulators.  This is why the major version change seemed justified.  It also emphasizes that this is a significant upgrade, and strongly recommended for all Simulator Z users.  Full documentation of why the various changes were made will come in following posts.  However, as these posts will be fairly long and take a while to write (this includes the one describing more details about the destination finder), I decided to release the actual simulator now, with a brief description of its changes.  This way, people can start trying it out and giving feedback immediately.

The changes in v2.0 compared to the previous v1.3 are as follows:


  • After doing a lot of testing with the one-way road speeds and capacities, I found that although a 30% increase helped, the effect it produced was still fairly anemic.  Instead, a 50% increase seems to be about the right number here, both from an experimental and theoretical point of view, and both for roads and NWM.  As a result, in this release the speed and capacity of one-way roads has been raised to be 50% higher than for two-way roads.  I'll be devoting my next long post entirely to an explanation of why this was done.
  • All highway speeds were reduced by 10 kph.  This has two benefits:  It almost exactly offsets the increase in speeds for the one-way roads, and it also causes the destination finder to concentrate more on finding local jobs before looking to neighbor connections.  In the case of sumwonyuno's major city, it helps both in increasing the local job population and in reducing the excess pedestrian traffic.  This second effect will be explained more fully in the post on the destination finder.
  • Bus speeds have been increased by 10% on most networks; this brings them to about where they were in the original Maxis simulator.  However, the ratio of bus speeds to car speeds is still lower than in the Maxis simulator.  In a test city on a large tile that is saturated with bus routes and bus stops, bus usage increased from 10% more than car usage to 20% more than car usage.  By deciding how many bus stops to place in a city and how far apart to place them, the player has great control over the relative usage of buses in a city.  Bus stops placed two to four blocks apart will result in progressively lighter bus usage, while bus stops placed every block will result in bus usage that is close to the maximum possible.  While the results still do not accurately portray bus usage in every type of city, they are a step in that direction; it's not clear how much better it is possible to do than this in a single simulator.  Once again, a wider range of bus usage will be available in Simulator Z using a future version of the NAM tool.  I would be very interested in feedback on this particular change.
  • Through many tests, I discovered that the Customers/Traffic Noise Coefficient, which controls the effects of traffic noise on businesses (positive) and residences (negative), was out of balance in all the traffic simulators, including the original Maxis simulator.  I rebalanced this parameter, with the effect that commercial businesses should get more of their proper share of commuters.  This also had the effect of eliminating all the remaining abandonment due to commute time in all but one of my cities; most people should no longer see this effect starting with this version of Simulator Z.  Abandonment due to lack of demand can still occur, and its mechanism is unchanged.
  • I have enclosed updated versions of the Traffic Volume Views to reflect the changes that were made to the street capacities in v1.3.

Although this is a beta release, as with previous beta releases of Simulator Z, it has been tested thoroughly and you should find it to be quite solid.  Please give it a try, and let me know what you think.  Thanks!

k808j

Sure, I'm game for a little beta. Remove the other beta versions first?

L i s t e n  T o  O u r  F a m o u s  T h e m e
http://www.supload.com/listen?s=PVfnXk">We Are Borg

z

#418
Quote from: k808j on December 15, 2009, 09:49:46 PM
Sure, I'm game for a little beta. Remove the other beta versions first?

Yes, the v2.0 version should be the only version in your plugins folder.

z

#419
One-Way Roads:  Part Two

In a series of posts starting here, I began discussing the requirements for one-way roads, how they behaved in real life, and what ideal settings for them would be in a traffic simulator that did not conflict with the NWM.  Based on a number of factors, I had originally proposed an increase of 50% of both speed and capacity for these roads.  After some discussion, I decided to make an initial release using a 30% increase to see if that would be sufficient.  All my tests showed that it wasn't by a significant amount; furthermore, I received no feedback from anyone to the contrary based on experience with this release.  As a result of my own tests, further research, and a lack of feedback to the contrary after the initial release, I changed the increase of speeds and capacities over standard roads to 50% with the release of Simulator Z v2.0.  I would like to explain the additional factors in making this choice.

First and foremost, the 30% increase was much smaller than that experienced in corresponding one-way roads, and just did not make enough of a difference.  The "intrinsic" advantage of one-way roads over two-way roads in SC4, due to the fact that volume is computed on a per-commute cycle basis and congestion is computed on a per-day cycle, turned out to be low to nonexistent in the most common cases.  Furthermore, with one-way roads, the distance traveled by Sims is often a little bit longer, as they often have to travel extra either at the beginning or end of their journey on a one-way road.  This also tended to cancel out any intrinsic advantage these roads had, and in some circumstances, would make trips using them slower than trips using two-way roads of equivalent speed and capacity.

I had mentioned earlier that capacity and speed increases in the real world for one-way roads were generally rated in the 67% to 75% range;  Maxis used a 100% capacity increase with no speed increase, which is more or less equivalent to this.  I remember playing the vanilla game with the Maxis numbers, which seemed fairly realistic, and not that far off ideal.  They would reduce congestion significantly in an area, but if traffic were really bad, these roads could easily get congested themselves.  This seems to be proper behavior for one-way roads.  From this point of view, a 50% increase is definitely on the conservative side.  These numbers all correspond in real life to one-way roads with timed lights, which produce the "green wave" that Alex described earlier.

I also found a smaller set of references describing a smaller set of speed increases for one-way roads.  Upon closer examination, these appeared to be for what we would call streets in SC4.  In these examples, there were no timed lights, and the road width was small.  These would be best served in SC4 by one-way streets, which would have the speed and capacity of regular streets.  It is my understanding that construction of such streets is possible, and I would urge some interested and capable party to create them.  In the mean time, their position can be filled by regular streets or one-way roads, depending on the situation.

A big point has been the question, How suitable is this for NWM?  Again, looking at the real world, it would seem to be even more important for NWM than for regular roads.  Wide one-way roads almost always come with timed lights, and thus enjoy the full 67% to 75% capacity and effective speed increase described above.

One reason I chose the 50% speed increase is that it works out very well for fast avenues, which are typically found in suburban and exurban areas.  Right now, these avenues would have to be built by hand out of one-way roads, but the NWM project might be interested in constructing full-blown versions of these avenues, as a new speed tier would be very useful in the settings I mentioned.  A 50% increase would mean that in Simulator Z, instead of a speed of 50 kph (31 mph) for cars, fast avenues would have a speed of 75 kph (46 mph).  Suburban and exurban avenues typically have a speed of 40 mph (65 kph) to 50 mph (80 kph).  Although 75 kph appears to be on the higher side of this range, a closer look show that it's not.  Higher speed avenues, especially on the upper end of the speed range, tend to have stoplights placed farther apart, and this tends to raise the average speed on these avenues compared to the speed limit, especially in comparison with city avenues.  So this makes the 75 kph speed much more in the middle or even lower part of this range, depending on the avenue.  (We also have to remember that SC4 speeds do not correspond exactly to RL speeds; it is the ratio that is important here.)  Therefore, the 50% increase seems ideal for creating fast avenues, and I would urge the NWM folks to seriously consider this as an alternative avenue type.  In the mean time, users can create such fast avenues themselves.

Is there a possibility for abuse here?  Of course!  Players can cheat in many ways, and this will introduce yet another.  It is impossible to prevent cheating.  Yet when used as intended, these higher speed one-way roads are not cheating at all, and merely represent a better representation of real-life traffic.  Since that's what the traffic simulator is trying to do in general, it seems quite appropriate to use them.