SC4 Devotion Forum Archives

SimCity 4 Devotion Custom Content Showcase => Network Addon Mod (NAM) => NAM Creations => Topic started by: mott on October 13, 2007, 01:27:51 PM

Title: Commute engine tweaking for NWM
Post by: mott on October 13, 2007, 01:27:51 PM
Some of the NWM team members have made mention of changing network speeds in the NAM to make the new RHW/MIS/TLA/1-way networks better interact with each other.  This is probably a good idea - I've long suspected that some of those "pathfinding" plugins are effectively redundant or ill-advised.  They were made a long time ago, after all, and much has been learned since.

I've done a lot of research in the pathfinding area, and if you don't mind, I'd like to brain-dump on this topic. 

First, background: It always bothered me that Sims can drive directly to a job, as this makes realistic traffic patterns (and parking garage use) somewhat difficult to achieve.  So I set up my game so that only pedestrians can reach jobs; if they want to drive to work they're going to have to park nearby and walk from there, just like in real life.  When I did this, I found I had to re-balance the entire transportation system:  The parking lots needed an "entry cost" so the Sims can't all use the same parking space, then that privileged transit so I had to give all the stations an entry cost too, then the Sims all headed to neighbor connections to avoid the parking and transit delays so I had to make transit-enabled on-network delay lots (toll booths) to slow down off-map commuting, and it all had to balance.  Then congestion curves had to be dealt with... and I think I finally got it all working correctly. 

I wouldn't turn this mod loose on the general public for obvious reasons, not the least of which is that it requires patching every custom transit station a person wishes to use and I really don't care to support it among the "plop nothing but CO$$$ towers and wonder why they abandon" crowd.  But I learned a lot about how to balance the commute networks from doing it, and this NWM project has just approached something I might be able to contribute to.

So, getting on with the interesting NAM-related info:

I really think the "network speeds" as set in the commute tuning exemplars are NOT in kilometers per hour, despite the Reader's assertions.  Rather, given a speed s, the "map distance" for a vehicle/pedestrian to travel over 1 tile is (1/s).  On a transit-enabled lot, the "Transit Switch Entry Cost" applies instead, counted once for the entire lot.  So the commute engine just adds the numbers up, per-tile (and per-lot, for transit-enabled lots) until it either reaches the Sim's job, or hits the cumulative maximum commute (default: 6).

There is an additional maximum mass-transit trip length.  This is described by the Reader as "Maximum mass transit commute raw trip length," but what it really represents is the maximum map distance a pedestrian will go on foot in search of a transit station before he gives up and drives instead.  In a default Maxis installation, pedestrians have a "nework speed" of 3.5, and the maximum "raw" mass transit commute distance is set to 4.  Divide that 4 in half to account for the evening commute, and you have a maximum "map distance" for a pedestrian's initial trip from home to a transit stop being 2.  At a map distance of 1/3.5 per tile walked, that works out to about 7 tiles, which happens to be about as far as a Sim will go to reach a bus stop. 

No wonder the 10x commute speed plugin doesn't speed up pedestrians - they'd walk up to 70 tiles at 10x speed!  To fix this and get it back to 7 tiles, without affecting anything else, divide the maximum raw mass transit trip entry by 10 after accelerating the pedestrians.  It's 4 by default, so replacing this with 0.4 will set the peds back to their original maximum distance.  (I usually set it to (1.6), so that the Sims will walk up to 28 tiles (about 1/4 mile), which is the 5-minute walk that real transit planners expect that people will take to reach transit).  Again, this does not shorten the Sim's trip one he reaches a bus or train.  It's only for that first walk to the initial station.  The Sims won't have to walk at turtle-speed, distorting commute times any more.  I doubt that this was known when the plugins were made?

Next, we can look at roads.  Defaut speed 31, so each tile has a "step cost" of 1/31.  The maximum commute distance is 6, divide by 2 to account for the evening commute back home, and that's three.  To get to 3 in 1/31 increments, that's 93 tiles - this is why on large maps, Sims at one side of the city have trouble reaching jobs on the other side until there are highways or at least avenues.  The 10x speed plugin makes it 930 tiles max commute on road, which is good enough to get across 3 or 4 large city tiles (or as little as 2, if it's a worst-case diagonal commute all the way across the large cities).  It sure solves people's no-job zot problems.

This is where the "Transit Switch Entry Cost" property of transit switch lots (such as train stations and bus stops) comes in.  There is no unit of measure given for this property, but it is analagous to the "step cost" of going through a network tile.  It's just the "map step cost" for traversing the lot.  Large transit-enabled lots require some very careful tuning of this value, lest they function as "teleporters" (too little cost) that suck all traffic through them, or as "blockers" (too much cost) that Sims would prefer to go around. 

Transit enabled lots get complicated this way, because their "transit switch entry cost" in transit switch lots is directly related to network speeds and max commute!  The moment you increase speeds by 10, you also increase the relative  "transit switch entry cost" by 10!  Driving takes 1/10 the time it used to (on road, it went from 0.031/tile to 0.0031/tile), but that Toll Booth at the edge of town has the same .02 cost it always did, and your Sims will now drive 10x farther to avoid it!

So - change the speeds, and you really have to mod every transit switch lot that has an "entry cost" to compensate.  The 10x speed plugin needs a 1/10 delay Toll Booth (0.02 entry cost), in order to remain "balanced."  The only other Maxis lot that has an entry cost is the Ferry Terminal, but that's controlled by the EXE apparently.  So the 10x speed plugin is going to make ferries 10x slower relative to the other modes of transit, and there's nothing to be done about it as far as I know right now.  Ferries are the transportation of last resort anyway.

Now, looking at the commute time graphs that people always wonder about, what is a true "minute" in this context?  The answer is, "It depends."

The game calculates commute time by looking at how much of a maximum commute trip is used.  Say, the total map step cost of a commute trip is 3, which is exactly half of the default maximum 6.  This ratio 3/6 is projected onto a scale of 0-255, yielding 127, which is then presented to the user as 127 minutes.  There are at least two places (the pathfinding exemplar and the map exemplar) where opportunities to scale this value are presented; set the multipliers to 1 and you'll see the raw 0-255 commute time projection.

Which means: If you use the "10x Commute" version of the plugin, you just changed what a "minute" is!  Now that Sim's trip is 3 tiles out of a maximum of 60, projecting to 12.7 on a scale of 0-255, and you should see 12.7 "minutes" on the graph and have divided every "Transit Switch Entry Cost" by 10 (a toll booth is .02 of 60 now, not .02 of 6).  If you used the 10x Speeds version instead, you see the same commute time effect on the graph, but have also in effect multiplied every "Transit Switch Entry Cost" by 10, relative to other routes.

Increasing network speeds also reduces freight trip lengths, while increasing max commute does not.  Since dirty industry and farms can't abandon, this is pretty much irrelevant, except that the higher speed version gives realistic freight trip times and thus lets industry develop much farther away from connections and/or rail/seaports.  [BTW, anyone know how to make it so dirty industry will abandon with lack of demand again, like it did in pre-patch SC4 vanilla?  Any chance on farms too?]

So what's a "commute minute?"  That depends on the maximum commute, and the network speeds.  We already know what the dimensions of a tile are (approx. 64 tiles/km, 100 tiles/mile), and we know what time is.  Knowing those constants, we can work backward to figure out what the network speeds and max commute should be.  As these two variables are dependent on each other, we just need to "peg" one.

I find that the 10x speed mod is the best for realistic time reports, as it also affects freight trips, so we'll use that for a baseline.  If we let pedestrians walk at a speed of "40" (just to make the math easier; default is 3.5 so 10x would be 35), that's a "step cost" of 1/40 per tile.  In real life, an adult human walks about 5 tiles/minute, so one minute would be a "map distance" of 5/40 (1/8), or 0.125 "map steps."  So what should the "maximum commute" be?  Let's say 1.5 hours each way, for a total of 3 hours.  If a minute is a "map cost" of 1/8, then 180 minutes is a "map cost" of 180/8, or 22.5!  Set the max commute to 22.5, the rest of the network speeds to 10x values, and a  (uncongested) Maxis toll booth's 0.2 delay will work out to something around 90-100 seconds delay to slow down, pay the toll, and re-accelerate again, which isn't that far off from reality.  Commute time and real time converge, and you're "balanced."  Pick different speeds, and re-work it.  Or, pick a different max commute and determine the needed speeds from that.  It doesn't matter; they're dependent variables.

Doing this same math, the 10x Speed, 10x Commute version of the NAM pathfinding plugin has a highway step cost of 1/1000 and a maximum commute of 60, which works out to a 30,000 tile commute on an unobstructed highway.  That's 480km/300 miles!  And monorail allows twice that!  As everything is relative, an uncongested toll booth takes around 12 seconds to traverse with this plugin, and will have very little effect.  I'm not surprised that people report "freezing" problems with this one as their cities grow!

The ultimate point is, if there's messing about to be done with the NAM pathfinding plugins anyway, I don't think it's necessary to have so many of these "Max Commute" and "Max Speed" versions, since the two settings are intimately related.  We could probably knock it down to a few major variations (The Maxis default 6, 12, and 24 max commutes have been good values in my testing; they're easy to translate to minutes and at 10x speeds, a max of 24 is sufficient to model all of the greater Los Angeles are to scale).  Lot makers could then be supplied with the proper "Entry Cost" constants required for things like the RTMT lots to balance with the various pathfinding plugins so they don't privelege one route over another.  That would also require overriding every Maxis transit exemplar to have balanced delays so as not to privilege other transit types and stations over the RTMT ones, but that's quite easy. 

This is getting long, and somewhat hard to follow probably, so I'll wrap it up here and take questions if there are any.  I hope I wrote something that's useful to someone.  Or at least, comprehensible.
Title: Re: Commute engine tweaking for NWM
Post by: Meastro444 on October 13, 2007, 02:03:43 PM
if this is implemented, ive read nearl anytihng, and it is very interesting.

i hope you can make it into a mod, because it makes it so much more realistic.
did you had to mod every station you had into this 'mod'?

if yuo do release it, i'd be gratefull!
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on October 13, 2007, 02:20:46 PM
Hello Mott,

This has been a very well thought out and presented post.  I have read it and followed you on most of it.. hehe.

Now, I like your thuroughness and amount of thought you have put into this!  It covers pretty much everything that I can think of.  If you would so like, it sounds like a good task for you to come up with a good balanced network Pathfinding Simulator.  And then with a very good explaination as you have here Im sure the Transit Stations will be able to be modified to work within the structure of this new Pathfinding Engine (build it they will come).

I have one question for you.  With the Network Widening Mod, we have decided to equalize Road, OWR and Avenue Networks.  The reason for this is because for the wider networks like TLA-7 it needs a 3-tile base network, which is impossible.  But we have found a way for the overrides to work on 3 Road networks side by side.  Now, in theory TLA-7 would have a greater speed and capacity compared to a normal avenue or at very minimum it would be equal speed and capacity per tile.  So, due to the implementation we would be required to equalize all the Road and the Avenue network.  This will obviously throw off the balance to an extent.  What are your thoughts on this?  I dont see much in the way of a workaround for this implementation.
Title: Re: Commute engine tweaking for NWM
Post by: Shadow Assassin on October 13, 2007, 06:39:41 PM
Mott's just given us the reason for why the 10x pathfinding simulator makes pedestrians walk a ridiculously long distance to their work. Sure we'll get healthier pedestrians, but it doesn't really work?

QuoteI doubt that this was known when the plugins were made?

I doubt it was known, too. It's mainly because the NAM team had different objectives in the creation of the modified pathfinding engine. In fact, I think they implemented a lot of T7T's original work in the NAM, modifying it further to provide options.

It's most likely we'll have to retain the original NAM pathfinding modifications, then adding the stuff that you've been working on.

QuoteAny chance on farms too?

I find that farms actually can abandon due to lack of demand. Dirty industry, on the other hand... can be very difficult to abandon, but it is really dependent on demand. There are additional things that come into play, such as traffic.

Quote(uncongested) Maxis toll booth's 0.2 delay will work out to something around 90-100 seconds delay to slow down, pay the toll, and re-accelerate again, which isn't that far off from reality.

Might wanna point out that this may not really work with electronic tollbooths. :P I find that realistically, we take about 60-70 seconds to pay the toll (unless we're hunting around for change/or gave the toll attendant a $50 note, in which they have to give us the change)... I suppose 90-100 would work great.

Finally, this possibility would allow busways to work quite well. In the past, I've found that buses don't like taking the dedicated busways I've set aside for them... even if it's the quickest route through the city tile, which can most likely be attributed to the transit-enabled tile entry cost.... Sims won't use the buses because it's "too slow".

What would happen if I set the entry cost for the blocker lot (which allows only buses and pedestrians) to 0? What would be the effect of doing so? I'm kind of trying to encourage buses to use the busway as a favoured route to get to places. I have the network set up so that there are direct connections between major areas and residential areas.
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on October 13, 2007, 06:54:06 PM
Quote from: Shadow Assassin on October 13, 2007, 06:39:41 PM
What would happen if I set the entry cost for the blocker lot (which allows only buses and pedestrians) to 0? What would be the effect of doing so? I'm kind of trying to encourage buses to use the busway as a favoured route to get to places. I have the network set up so that there are direct connections between major areas and residential areas.

The entry cost of 0 would mean there is no cost added to using that transit enabled lot.  The would then become a "shortcut"...  The cost of the tile is probably set at 1.  If a bus travels at 31 tiles for 1 minute then your bus will go out of its way by 31 tiles to avoid using the transit enabled lot.  If there is no cost for that tile then the entire trip is actually considered as Distance-the number of tiles for the TE Lot because there is no cost for travelling through the number of tiles of that TE Lot.
Title: Re: Commute engine tweaking for NWM
Post by: Shadow Assassin on October 13, 2007, 09:48:14 PM
Ah, exactly what I wanted to hear!

That'll fix the little bus lane issue I'm having, which I mentioned earlier.
Title: Re: Commute engine tweaking for NWM
Post by: flame1396 on October 13, 2007, 10:47:34 PM
Interesting... I read it all thinking it was Tarkus... lol.
Title: Re: Commute engine tweaking for NWM
Post by: mott on October 13, 2007, 11:41:21 PM
Sorry for my absence after posting; unexpected company... wow, someone thought I was Tarkus?  I'll take that as a compliment, thank you. :)

And it just occurred to me that a default Maxis toll booth is 0.2 delay, not 0.02.  Apologies for that. 

@Maestro: If people really want to try this "make them park and walk" mod idea, I'm willing to roll up whatever I can.  I'm having a bit of trouble getting the congestion response set just right at the moment, it's not hard, it just takes a couple of hours of play-testing to fully evaluate each modification.  Fortunately, when I find the right curve, it should be useful to jplumbley for the TLA project. 

@ShadowAssassin: A transit switch entry cost of zero would just make your bus-blocker a "free tile,"  taking no time to traverse, and being immune to congestion delay.  Buses and peds don't generate congestion anyway (by default), so it really doesn't matter that much.  If you want to be completely accurate, whatever your bus speed is set to on that network type, divide 1 by that, and set your transit-switch entry cost to the result, rounded down so the bus lane is always just slightly faster than the road next to it.  In a default game, 0.03 should be close enough, 0.003 if you use the 10x speed mod.   Oh, and there's a way to make toll booths (and everything else) faster if they are under 100% use, the same way they can be slower if over 100% use, so your estimated numbers may yet see the light of day.  Sure, faster than 70-90 seconds or so, as long as it's a mostly empty road so you're not waiting for the idiot in front of you to find his other quarter.  :)

@jplumbley: I see the issue with speeds, and I'd be honored to roll something up for you.   While I was tuning parking lots, I realized that the same way congestion slows down traffic, lack of congestion can be used to speed it up.  An open road, no traffic... people *speed.*   I've found that by setting the response curve to increase speeds by 25% on an open road (or under-used parking lot, train station...), and slowing to the speed limit as usage nears 100%, makes Good Things happen.  For example: since zones can radiate congestion in their immediate vicinity, it slows the Sims down when going through areas that have "frontage," even before the road is fully saturated.  And through traffic starts using the bypass route (if any) that much sooner.   I think your answer may lie in this area.

EDIT: And if you widen a road (say, convert a 2-tile OWR-5(?) into a 3-tile OWR, the traffic will redistribute evenly across the tiles, usage % will drop, and the speeds will increase.  I think that's what you want?   

As for capacities, the way I see it, what's important is whether cross-traffic can make uncontrolled left (or right, UK) turns in front of oncoming traffic - real-world nominal lane capacity is ~1200 vehicles/hr if such turns are allowed, ~1800 per lane if not.  So I'd say those are good numbers to start with.  As for speeds, the slightly lower lane capacity of a TLA combined with the congestion radiated by any frontage (if present) will slow cars sooner on TLAs as traffic increases, even if you set the network speed the same as on all the other types.  And if there's no frontage, then there's no need to use a TLA in the first place, so the capacity mismatch won't matter.   It's just a matter of tuning the capacities, congestion response curves, and the amount of congestion radiated by zones.   Road usage itself will do the rest. 

One thing I need to figure out, is if it's possible to change the congestion display chart colors, so that green is 0% usage, yellow 100%, and red 200%, instead of the current situation where they don't turn yellow until 200% or red until 300%.  By the time usage nears 100%, it's time to start thinking about upgrade options SOON, so 100% should be yellow.  In the real world, 200% usage means walking speed, that should be red, and the yellow warning color should appear long before then.  I tried just making 200% usage the "new 100%" by dividing all capacities in half, but this messed up traffic noise and commercial desirability so I'm going to have to go back and do it correctly.   At least I'm *close* to getting this all right.  :)

I have to do family stuff and then prep a few work-related things for Monday; I should have some free time to mess with this some more on Tuesday and Wednesday.
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on October 14, 2007, 10:43:39 AM
Mott gets a  :thumbsup: +Karma from me!

I really like the idea of "Park and Rides" actually being Park and Rides, or the fact that you have to deal with parking in a downtown area.  In SAM I tried to make parking a bit more desirable by making a draggable parking lot in which sims could actually use as a street.  The downside to it is I cannot make it function as a parking lot due to limitations on a T21 Exemplar (Network Lot).  If you get this mod setup, I gaurentee I will use it.

I never knew you could allow people to speed, that is freaking cool!  I see MAXIS usedit to an extent... They used it to decrease traffic when a network is becoming congested.  They started it little late on that one!

Original MAXIS Stats of the Congestion vs Speed property:
0, 1 = At 0% capacity traffic travels at 100% speed
1, 1 = At 100% capacity traffic travels at 100% speed
2, 0.65 = At 200% capacity traffic travels at 65% speed
3, 0.30 = At 300% capacity traffic travels at 30% speed

So, lets use my home "highways" as an example.  The speed is 100 km/h on the highways, but in about 0 to 50% capacity people go anywhere from 120 to 150 km/h, the average being somewhere between at about 130 to 135 km/h.  When capacity is nearing 75% I would say the cars generally are about 110 to 120 km/h.  But when we get to 100% saturation I would have to assume we are starting to lose speed and I would say we'd be about 95 km/h.  At probably around 125% capacity we are running down around 75km/h, at 150% capacity I would say we are down to 50 km/h and at 200% I would say around 20 km/h.  There is no way our highways hit 300% capacity it would be a parking lot and in most cases this would be the cause of an accident.

JPlumbley's suggested stats:
0, 1.4
0.25, 1.3
0.5, 1.2
0.75, 1.1
1, 0.95
1.25, .75
1.5, .5
1.75, .35
2, .2
3, 0 = This one will make it so no road will ever be able to reach 300% capacity because it will be a dead stop.

Now, Mott.  I would like to make it so that sims can travel to the opposite side of a large tile, which means a travel distance of 512 tiles and 1024 diagonally from corner to corner.  512 tiles I think should be the equivenlent of travelling at 60 km/h on a surface road or avenue.  So by this logic, the travel distance of a highway at speed 100 km/h should be equal to 853 tiles.  A street of 40 km/h would equal about 341 tiles.  And a pedestrian at 5 km/h 4would equal 43 tiles of travel.

So, how do we get to these numbers.  Well, lets make the speed equal to the REAL km/h.  Here would be my suggestions:

Walking Speed = 5,0,0,5,0,0,5,0,0,0,5,0,0
Driving Speed = 60,0,100,40,0,0,60,0,0,0,60,100,100
Bus Speed = 55,0,90,35,0,0,55,0,0,0,55,90,90
Truck Speed = 55,0,90,35,0,0,55,0,0,0,55,90,90

Now, we go into adjusting the Max Commute to equal the distance we have just calculated.  Since 512/60 = 8.53 that would equal about a 17 Max Commute Time value for the there and back trip.

In real life, the maximum amount of time someone will commute is normally between 1 hour and 1 and a half hours.  So if we were to estabilsh that 512 tiles is the distance you could travel in 1 and a half hours then you would get travel distance of 341.33 tiles in 1 hour.  This, I think if I did my calculation correctly works out to be a Trip Length to Minutes Display Multiplier with a value of 10.54.
_______________________________

On another note, I have notice that there is a Transit Switch vs Funding multiplier.  Now, the thing about this property we should be able to control the TE Lot Switch Cost with this property and Standardize the Lot Switch Costs at the same time.

For example we set it up so that the Switch Cost for ALL lots be based on the number of tiles and the type of lot it is.  So if the maximum distance through atTE Lot is 1 tile then the Transit Swicth should be equal to 1*1 for a station, but if it is 2 tiles then it should be 2*1 for a station.   Then, for the Transit Simulator we change the multiplying values to suit the plugin you are installing.  This will keep all Transit Station (TE Lots) inline with the editing of the Traffic Simulator.
_______________________________

EDIT:  I have just done a test of my numbers from a scratch city.  I setup a Large city tile where, on one side I had all residential and the other side I had all I-D and CS$.  I did not build education because there was no need for this test.  I made 2 connections, one by Avenue and one by G-Highway.  I havent played for very long about 50 years of game time and made it to population 12,000.  I have CAM installed but that will have no effect on commutes.

In the beginning I built more development so that the Avenue was directly through the middle of the developement and the highway would be an offset of 12 tiles extra to travel.  At first I had about 75 to 85% of my commuters using the Avenue, but as I began to expand that number became much closer to 50%.  The simulator was working alot better in my opinion and sims were actually using the highway.  Commute times started at around 70 minutes and by 12,000 people I had around 95 minutes.  This increase in time was due to two things, more commuters on the road and that development was expanding outwards away from the Avenue and Highway.  If there was no change in the average distance I would expect that the time change would not be all that drastic, but it would still be up around 80 minutes compared to 70 minutes.

This new simulator seemed to spread the sims out alot better and they travelled the full 500 tiles or so to get to work.  It looks as if it will allow for the "downtown" atmosphere where you can have suburbs at one side of the tile and a downtown business district on the otherside.  It will also keep everything in balance.

The pathfinding looks realistic too.  I tested putting 2 busstops in, one for sims to get on and one to get off and walk to work.  They walked about 15 tiles or so away.  They could walk further but the Commute Time was probably a bit too far and the car would have been faster anyways.  This will allow you to atleast not have a busstop on every block and allow you to have a semi-realistic bus layout.


Oh... and I havent added the park and ride thing yet either.  It would be nice to force your sims to park in a downtown parking lot and then walk the rest of the way to work.  That will be my next test.
Title: Re: Commute engine tweaking for NWM
Post by: ssc4k on October 14, 2007, 12:04:49 PM
i don't get what jplumpley said but im sure its nice... i think :P
Title: Re: Commute engine tweaking for NWM
Post by: mott on October 14, 2007, 07:12:06 PM
@jplumbley:

Well, I'm a little ahead of schedule so I just want to check in with you.  Sounds like you've got it figured out pretty well already - and that "speeding" thing works wonders, doesn't it?  I first discovered it when I was trying to make Sims start using the next parking lot over, before the first one had saturated.  What it did to commute patterns in general was a pleasant surprise.

Reverting to the original Maxis "speed" settings was a good idea, as I think I just figured out what the "pathfinding heuristic" magic number is about, and staying inside the general Maxis-supplied range of values is probably a good idea.  So I'll work from the numbers you supplied.  90 minute max commute each way sounds about right - it's exactly the amount of time it would take to walk a large city tile across the diagonal, and back.  Perfect.   It's all simple algebra from there, really.

The more I think about it, the more I like the idea of keeping road/TLA the same basic speed as the rest, but having them carry 1/3 fewer vehicles (2400/tile vs. 3600, for example).  Then if a one-way pair (or equivalent) enters town and becomes a TLA, you'll need to widen the road an extra tile to a TLA-7 to maintain that same 3600 capacity each direction.  The middle lanes would be less affected by frontage-related congestion, too, so traffic would prefer them slightly and through travelers would tend to move into the centermost lanes.  That's  realistic, but would people complain about the width requirement?

On the congestion vs. speed front, I did some research in my area... the Eastshore Freeway (design speed 50 MPH) moves at 65-70 when clear (only at 3:45 am), the design 50 when saturated to 100%, and 12-15 when at 150%, call that 1/4 speed at 150% use?  The San Diego Freeway down in LA does hit 200% usage, and as the joke goes, it's called the 405 because you're doing 4 or 5 mph.  1/16th design speed, then, at 200%, and 1/64th at 300%?  By 1/64th speed, it's be faster to walk, or nearly so.  I've had good luck with these ratios in my testing.

Oh, and I found where I can make congestion show up sooner on the data view, to support the above numbers.  100% use will now be bright yellow, 150% an ominous glowing orange, and 200%, pure red.  At least, as soon as I can figure out the 0-255 scale it's on internally.  Currently, pure yellow is usage 0x1A, or 26.  I think that color hits at 260% normally; I'll have to trial-and-error it. 

You mentioned accident rate.  There are three entries for this in the commute tuning exemplar.  These are:

* Accident probability (range 0-1, default 1).  The probability that an accident that should happen actually will.  This can be used to scale the global accident rate without affecting the other tuning ratios. 

* Congestion vs. Accident Probability curve.   Maps congestion to an accident probability.  I'm thinking 100% usage should have 4x the accident rate of an open road, and 150% usage 16x, 200% usage 64x, something like that?  Any ideas here?

* Capacity vs. Accident Probability curve.  Maps capacity to accident probability.  The highest-capacity road is the Maxis highway, which should probably have 25% the accident rate of a normal road, if I remember real-world accident statistics properly, and the RHW and 1-way/ave, what, maybe half?  Not sure here.  Roads and TLAs should probably have more accidents than the networks with medians, due to the uncontrolled turns, so setting the road capacity to something different than 1-ways  - even if it's only a single vehicle difference - would allow us to make divided roads safer than undivided ones like TLA.  Those response curves don't have to be smooth and even, so by making each network type even just a single vehicle different in capacity, we can give them their own unique accident rates.

Any thoughts about what the general default accident rate for a regular road at 100% usage should be, or what the curves should look like?  I wish I knew what the unit was here... probability of an accident occurring (per trip?  per tile?  probably per tile, I think, but what's the time frame?  Probability of an accident per second?  Minute? Hour?  Day?).  At least it we get the curves set up correctly, the global scalar can be used to tune the rate up or down.

The "Map Distance To Minutes" multiplier (default 25) seems to be what the "map distance" is multiplied by to determine the freight trip time that is given when you query industrial zones.  This is clearly on a 0-255 scale since with no connections, you see freight trips of 255 minutes.    Someone made a mod that gives you detailed query info for all zone types; I need to check to see if it's used there as well - if so, we need this multiplier to be tuned correctly as well, in order to avoid causing R$$$ abandonment issues based on perceived commute time. 

The "transit switch cost vs. funding" curves would allow players to make transit stations relatively faster or slower with funding.  The problem is, it also leads to rail damage if the slider is set below 67%.  By default, you don't have to keep your transportation funding any higher than that to avoid damage (there's a curve for funding/damage as well that can be altered though).  We could probably have some fun with the funding/delay curve in the 67%-120% funding range, if we wanted to.

Traffic noise is going to be a balancing act, since a resident's "noise" is the same as a business's "customers."  This should be fun.

Thanks for the good karma, and I'll give you a chance to respond, then I'm going to make an alpha version for you to bang on.  Less talk, more do, and all that. :)

PS: One neat consequence of the "park and ride" mod: If it's impossible to drive anywhere because there are no parking facilities, all the Sims will walk to work.  There can be no road neighbor connections or they'll drive off-map, but passenger ferries are OK.  This makes no-car, transit-only cities possible, except you can't get garbage deals due to lack of road connections.  In any case, with the park-and-ride mod, you'll at least be able to decide when (if?) cars are "invented."  Until you plop that first parking lot or make a car-based neighbor connection, they haven't been, and people just walk.  I'm not sure how R$$$ Sims would react to this.  A little cheat-testing may be in order to find out.
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on October 14, 2007, 08:54:59 PM
Quote from: mott on October 14, 2007, 07:12:06 PM
Well, I'm a little ahead of schedule so I just want to check in with you.  Sounds like you've got it figured out pretty well already - and that "speeding" thing works wonders, doesn't it?  I first discovered it when I was trying to make Sims start using the next parking lot over, before the first one had saturated.  What it did to commute patterns in general was a pleasant surprise.

As it turns out in my testing of the simulator I wrote based on the calculations I posted earlier, my sims will not reach 200% capacity on the road system.  In fact if forces them to use busses if the road becomes too congested.  I had more than 50,000 sims in my test today and I had total about 24,000 commuters across town.  There was 1 avenue, 1 G-highway, 1 rail and 1 monorail.  The rail and monorail combined had about 3,000 commuters.  Car traffic was sitting at about 6,800 on the highway and 3,500 on the Avenue.  The bus traffic on the avenue was breaking 4,200 and on the highway about 5,700.  I had saturated the Avenue and Highway with cars and anything I added was going to the Rail, Monorail or Busses.

I looked back at the Capacities of the Avenue and the Highway which were respectively 2,500 and 4,000 commuters per tile.  Since the Highway had a higher speed it would explain the little bit extra capacity % it was able to handle before becoming saturated.  Also, due to the over-saturated road there speeds were way down to less than 50% normal speed (this includes the busses) so the time as I added more and more sims started going off the charts.  Im not sure why I wasnt starting to get abandonment, the commute time was over 200 minutes due to the amount of traffic and the distance they were required to drive.

Anyways...

Quote from: mott on October 14, 2007, 07:12:06 PM
On the congestion vs. speed front, I did some research in my area... the Eastshore Freeway (design speed 50 MPH) moves at 65-70 when clear (only at 3:45 am), the design 50 when saturated to 100%, and 12-15 when at 150%, call that 1/4 speed at 150% use?  The San Diego Freeway down in LA does hit 200% usage, and as the joke goes, it's called the 405 because you're doing 4 or 5 mph.  1/16th design speed, then, at 200%, and 1/64th at 300%?  By 1/64th speed, it's be faster to walk, or nearly so.  I've had good luck with these ratios in my testing.

Oh, and I found where I can make congestion show up sooner on the data view, to support the above numbers.  100% use will now be bright yellow, 150% an ominous glowing orange, and 200%, pure red.  At least, as soon as I can figure out the 0-255 scale it's on internally.  Currently, pure yellow is usage 0x1A, or 26.  I think that color hits at 260% normally; I'll have to trial-and-error it. 

On the Congestion vs Speed, I dont know how far we need to look into this its something relative to driving styles around the world but it will be very close in every situation.  I think we need to find something that will fit within the guidelines to prevent traffic from overuse of one road and look for more options when it gets overused.  MAXIS did not implement this well, in fact the numbers I implemented from above seemed to work very well throughout my developement test.  Sims, tended to follow the the quickest way and held a fairly even split amoungst the different options.

But, you failed to mention the name of your Congestion Color property.  Do tell!!  Id like to play with it.

About Accidents... They are a fairly random occurance, we probably have on average 4 on major highways across the GTA a day, for those who live in the GTA obviously there are those messed up day where there are many more but then there are oter days where there might not be any.  I would not consider a bumper banger as a type of accident for SC4.  For Congestion vs Accident Probability, I think it would be best to trial and error this one.  The stats I would tend to use would be low.

Congestion vs Accident Probability:
0% = 0% chance
25% = 1% chance
50% = 3% chance
100% = 9% chance
200% = 25% chance

You dont want the chance of an accident to be too high as it would cause accidebts on all roads.  I would also assume the accident rate is per commute (Mornig then Evening) or 2 per day.

Quote from: mott on October 14, 2007, 07:12:06 PM
The "Map Distance To Minutes" multiplier (default 25) seems to be what the "map distance" is multiplied by to determine the freight trip time that is given when you query industrial zones.  This is clearly on a 0-255 scale since with no connections, you see freight trips of 255 minutes.    Someone made a mod that gives you detailed query info for all zone types; I need to check to see if it's used there as well - if so, we need this multiplier to be tuned correctly as well, in order to avoid causing R$$$ abandonment issues based on perceived commute time.  

Well for this one I already calculated it to be 10.54 with my previous post and suggestions in that post.

Quote from: mott on October 14, 2007, 07:12:06 PM
The "transit switch cost vs. funding" curves would allow players to make transit stations relatively faster or slower with funding.  The problem is, it also leads to rail damage if the slider is set below 67%.  By default, you don't have to keep your transportation funding any higher than that to avoid damage (there's a curve for funding/damage as well that can be altered though).  We could probably have some fun with the funding/delay curve in the 67%-120% funding range, if we wanted to.

What I meant by using this property, we can use it as the variable.  By standardizing the TE Lots to have certain Switch Costs per tile we can adjust this property by the factor the "Max Commute Time" or "Speeds" have been multiplied.  I hope that makes a little more sense.

You were saying earlier that you dont want to have to manually change all the TE Lot to conform. Well this is a way we can have the updated once to be standardized and then never have to touch them again.


BTW, have I mentioned that you didnt tell me the property name of the Congestion Color so thar I could play with it?

Keep up the good investigations, we should have a new simultor built that is really balanced and works well for the game.  One property I would like to find is the on that handles the Cost of entering a neighbor.  I thought I saw it once but I havent seen it recently.
Title: Re: Commute engine tweaking for NWM
Post by: RippleJet on October 14, 2007, 10:23:11 PM
Quote from: mott on October 14, 2007, 07:12:06 PM
PS: One neat consequence of the "park and ride" mod: If it's impossible to drive anywhere because there are no parking facilities, all the Sims will walk to work.  There can be no road neighbor connections or they'll drive off-map, but passenger ferries are OK.  This makes no-car, transit-only cities possible, except you can't get garbage deals due to lack of road connections.  In any case, with the park-and-ride mod, you'll at least be able to decide when (if?) cars are "invented."  Until you plop that first parking lot or make a car-based neighbor connection, they haven't been, and people just walk.  I'm not sure how R$$$ Sims would react to this.  A little cheat-testing may be in order to find out.

A car-free city is possible already today (with just RH), and this is how I'm usually playing:
- The roads from residential areas only go to border crossings, and likewise in all cities.
- The roads to commercial and indstrial areas are blocked for everything else but pedestrians.
- Freight from industrials go out of town by rail (every industrial lot has direct access to the railroad).
- All commute within the city is handled by subways, and even R§§§ are willing to take the subway if that's the only option.
Title: Re: Commute engine tweaking for NWM
Post by: Tarkus on October 14, 2007, 11:10:47 PM
Mott, this is a very insightful and intriguing post, and I'm still making my way through all the information here. :D  You did good. :thumbsup:

I'm in total agreement about equalizing the Road/OWR/Avenue capacities and speeds--otherwise, the TLA-5 would end up with 40% of the capacity of the normal Avenue, which doesn't make any sense at all.  In general, I kind of thought that the advantages that Maxis gave the OWR and Avenue networks were unrealistic given the number of lanes they had in comparison to the Road network. 

The settings I'm currently using with my prototype NWM Simulator have the Road/OWR/Avenue capacity set to 1500, and the speed set to 70, assuming a kilometer-per-hour measurement (based on what Swamper77 had told me).  The game has been acting quite favorably with the new settings, though I do need to do more testing.  I'll get some screenies up soon. 

I haven't really messed with any of the other settings yet, though seeing what you've done here, I may just have to try it. ;)  My methods of building cities and transportation networks is also rather "unorthodox" at times, so I'm looking forward to comparing some notes. :)

And I too want to know what this congestion color property is.  It would be nice to have an even more accurate Traffic DataView. ;)

A lot of what you've found out here is very reassuring news for those of us working on the NWM, too. :)

-Alex (Tarkus)
Title: Re: Commute engine tweaking for NWM
Post by: mott on October 15, 2007, 01:22:58 AM
@Ripplejet: Quite right; I'd forgotten about the "blocker" lot method.  Correction: Park-and-Ride Mod will let you do walking-only cities without having to plop blocking lots all over the place.  Instead, you'll get to plop parking lots all over the place to allow driving.  Would you like fries with that micro-management?  ;D

@Tarkus: If it weren't for the NAM Team, my game would have been on a shelf under a pile of dust for years now.  I am very glad to be able to give something back.  I love where the RHW/MIS is headed too; you're just one set of left-exits away from perfection!  *poke*  (everyone has a "pet feature" they lobby for; I'll pick "left exits.") EDIT: I'll also close my parentheses, and question whether teasing the guy who just gave me karma is really a good idea. ;)

@jplumbley: The exemplar you seek is a type 0x10 called "DataView: Traffic."  It is located in SimCity1.dat; its TGI is 6534284A:690F693F:4A0B6809. 

In that file, the property you probably want to look at is the one called "Colour ramp."  It has 24 reps, formatted as 12 value pairs.  The first element in a pair is an integer in the range 0-255 that represents "usage" somehow, and the second is a color value.  Where "100% usage" occurs on a scale of 0-255, I have not yet properly determined.  All I know for sure is that 0 = no color at all, 1 = pure green, and 1A (26 decimal) is the pure yellow, and those are the first three pairs.  The remainder is a long slow transition through shades of orange and into pure red, which occurs at 255 usage.  The only way I can think of to determine for sure what 100% is on this scale, would be to alter the table so it changes from green to red instantly at some known point, then run a test city and see what % usage is required to get there, then adjusting and re-running the test.  I have a feeling that 100% = 10 (decimal), or somewhere near it.  This table really only needs 3 or 4 entries in it: none at no usage, green at the first vehicle, yellow at 100%, and red at 200%, and red again at the 255 marker, whatever % that is.  Maxis stops adding time penalties after 300% usage so people can get away with some incredible congestion, hence all those shades of orange-red that we won't need because it's just not going to be possible to get there with our special little mod, is it?  Good, it shouldn't be. 

There's also a 9-rep listing of "legend colors" that is nothing but a list of RGB values for the color scale presented to the user in the dialog box that appears in the Traffic View.  It will probably need some adjusting too - and maybe changing of the legend so instead of "low usage" to "high usage" it's "0 - 300%", or something like that, with the appropriate color scale presented to the player.

On another topic, your experience with congestion causing bus usage reminded me that a while ago, I modded my pathfinding file so that buses were slower than cars, not faster.  I'd forgotten that I'd done this, and it will change the results you see with buses versus what I see.  If you're feeling experimental, try setting bus speeds to be about half of the driving speeds and see what changes. 

I did it because there's no way to force bus riders to wait through stops like there is for the rail stations that let you drag tracks through them.  (Except the road-top bus stops, but those have other implications that I'd rather avoid).  Sims preferred to stay on the bus than pay the additional time cost of transferring to the train, because there was no time cost involved with waiting through stops.  So I slowed the buses down to reflect frequent stops, until it was faster to transfer to the train than to stay on the bus.  This is unrelated to the tuning changes you need, but I thought I'd mention it because it does change how the Sims react to traffic.

Also I made pedestrians generate traffic and also be affected by it, so drivers will avoid pedestrian-heavy streets, and pedestrians will prefer not to walk on busy streets if they can help it.  All those pedestrians getting off the subways and buses and crossing the street ties up traffic there.  It's a much more realistic model of how transit stops affect street traffic than the Maxis no-traffic-at-all model, or the one-bus-per-Sim disaster that occurs if you change it so buses themselves generate traffic.  Buses don't generate traffic in my game, but all Sims walking around the stops do.  If other people would want this to happen, I don't know.  I like it, and it helps keep pedestrian-mall commercial areas alive.  It also un-privileges driving vs. transit a little bit after I slowed down the buses.   Networks that don't allow pedestrians, such as highways and RHW, take on a new dimension of usefulness.

To further un-privilege drivers vs. transit, there's the "commute trip starting cost by transit type" property in the pathfinding exemplar, and its related entries for car-preferred and transit-preferred trips by transit type.  This is where that hefty time penalty for forcing Sims to use transit instead of driving is assessed.  You'll notice that for the car-preferred strategy, there's a huge trip starting cost for taking transit.  In my game, I removed the penalties, because I don't think artificially inflating commute times is the proper way to reflect people's preference for driving.  Instead, I gave driving a penalty of 1 minute to 90 seconds (I'm still experimenting with it) to reflect the time it takes to open the garage or walk to where you parked, start and warm up the car, pull out... this is assessed whether you wanted to drive or not.   And by the time you've done that, your neighbor who rides the bus has walked to the bus stop on the corner, if it's only 5 or 6 tiles away.   The time it takes to walk to the bus stop and wait for the bus to come is the same whether you wanted to ride the bus or not, and the game already models that reality and it priveleges driving because walking is so slow.  I'll bet that's why Maxis made the buses so fast in the first place, to make up for it.  There are better ways.
 
Now, if you'll excuse me, you said you found a file that contains a setting for the cost of commuting off-map?  That would be very helpful indeed.  If you say you saw it, I have a good idea where to start looking, so I'll just go fishing for it.
Title: Re: Commute engine tweaking for NWM
Post by: Shadow Assassin on October 15, 2007, 03:25:47 AM
QuoteCongestion vs Accident Probability:
0% = 0% chance
25% = 1% chance
50% = 3% chance
100% = 9% chance
200% = 25% chance

There should still be a very small probability of accidents happening on roads with 0% traffic. After all, quite a few single-car accidents happen from time to time. Maybe it could be set to 0.05% or thereabouts?

Still, I'd recommend this:

0% = 0% chance
50% = 3% chance
100% = 7% chance
150% = 14% chance
200% = 25% chance

That'd make a very nice curve, and would be more or less similar to real world data. This takes in account the speed of people (there may be a margin of error), which is why the crash rate isn't exponentially higher for capacities above 100%. It could be adjusted according to what people want, so long as the ratios remain the same.

Anyways, mott, are you able to send me your transit mod? I'd like to try it out and see how it plays region-wide in one of my regions.
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on October 15, 2007, 05:12:29 AM
Quote from: mott on October 15, 2007, 01:22:58 AM
On another topic, your experience with congestion causing bus usage reminded me that a while ago, I modded my pathfinding file so that buses were slower than cars, not faster.  I'd forgotten that I'd done this, and it will change the results you see with buses versus what I see.  If you're feeling experimental, try setting bus speeds to be about half of the driving speeds and see what changes. 

I did it because there's no way to force bus riders to wait through stops like there is for the rail stations that let you drag tracks through them.  (Except the road-top bus stops, but those have other implications that I'd rather avoid).  Sims preferred to stay on the bus than pay the additional time cost of transferring to the train, because there was no time cost involved with waiting through stops.  So I slowed the buses down to reflect frequent stops, until it was faster to transfer to the train than to stay on the bus.  This is unrelated to the tuning changes you need, but I thought I'd mention it because it does change how the Sims react to traffic.

Also I made pedestrians generate traffic and also be affected by it, so drivers will avoid pedestrian-heavy streets, and pedestrians will prefer not to walk on busy streets if they can help it.  All those pedestrians getting off the subways and buses and crossing the street ties up traffic there.  It's a much more realistic model of how transit stops affect street traffic than the Maxis no-traffic-at-all model, or the one-bus-per-Sim disaster that occurs if you change it so buses themselves generate traffic.  Buses don't generate traffic in my game, but all Sims walking around the stops do.  If other people would want this to happen, I don't know.  I like it, and it helps keep pedestrian-mall commercial areas alive.  It also un-privileges driving vs. transit a little bit after I slowed down the buses.   Networks that don't allow pedestrians, such as highways and RHW, take on a new dimension of usefulness.

To further un-privilege drivers vs. transit, there's the "commute trip starting cost by transit type" property in the pathfinding exemplar, and its related entries for car-preferred and transit-preferred trips by transit type.  This is where that hefty time penalty for forcing Sims to use transit instead of driving is assessed.  You'll notice that for the car-preferred strategy, there's a huge trip starting cost for taking transit.  In my game, I removed the penalties, because I don't think artificially inflating commute times is the proper way to reflect people's preference for driving.  Instead, I gave driving a penalty of 1 minute to 90 seconds (I'm still experimenting with it) to reflect the time it takes to open the garage or walk to where you parked, start and warm up the car, pull out... this is assessed whether you wanted to drive or not.   And by the time you've done that, your neighbor who rides the bus has walked to the bus stop on the corner, if it's only 5 or 6 tiles away.   The time it takes to walk to the bus stop and wait for the bus to come is the same whether you wanted to ride the bus or not, and the game already models that reality and it priveleges driving because walking is so slow.  I'll bet that's why Maxis made the buses so fast in the first place, to make up for it.  There are better ways.

;)  I have "un-privilaged" busses already, and they are actually set at close to 10% less speed than cars.  When traffic speed is reduced due to congestion, which busses are affected by, the gap narrows and almost becomes equivelant to driving.  But, the real reason I think I was getting increased bus useage was because my raods just couldnt handle more traffic.  At 200% they would be driving at 20% of the speed so, 12km/h on Avenue and 20km/h on Highway.  The useage was already up in the 175% range and I think the Simulator was essentially preventing the traffic from getting any denser.  This is something we havent really seen before because the Congestion vs Speed Property wasnt implemented properly and this new model is preventing more than 175% of cars because it will be just way too slow.  Now, I can later test lowering the bus speed more to say 20% less and see what the difference is, but to be honest I dont think it will be all that much.

I like the concept you have discussed about the "un-privilaging" of cars.  It makes more sense because Johnny Simalot will walk to a nearby work or grab a nearby bus rather than drive.  I dont know about making the Ped Traffic add to usage, as there would be mixed views across the Community, but I for one would be willing to test it out.  My worry for that would be downtown areas where there will be ALOT of commuters especially with Stage 15 Towers where you can have 20,000 Residents or Workers in a building.  That may cause a traffic nightmare and for a city to work you may need a way around it with Ped Traffic (which doesnt add to usage).  Also, if you think about it your park and ride or park downtown and walk to work would end up screwing you over in the end, making downtowns virtually unattainable because you only have a limited amount of capacity to your roads.

I definately will be playing with the Congestion Colors tonight, that is for darn sure!

Quote from: Shadow Assassin on October 15, 2007, 03:25:47 AM
There should still be a very small probability of accidents happening on roads with 0% traffic. After all, quite a few single-car accidents happen from time to time. Maybe it could be set to 0.05% or thereabouts?

Still, I'd recommend this:

0% = 0% chance
50% = 3% chance
100% = 7% chance
150% = 14% chance
200% = 25% chance

That'd make a very nice curve, and would be more or less similar to real world data. This takes in account the speed of people (there may be a margin of error), which is why the crash rate isn't exponentially higher for capacities above 100%. It could be adjusted according to what people want, so long as the ratios remain the same.


Hey SA, I dont think you need 0.05% at 0% capacity because, technically there is no traffic and no cars to actually get in an accident.  As this makes a curve anyways it can stay at 0% chance of an accident because at 1% Capacity it will have an Accident Probability of something like 0.1%, I dont wanna actually do the math to work it out but you know what I mean.  Again as i stated earlier, this will be subjective all the time I just threw some numbers there that were guesstimates and are pretty close anyways.  If you notice I multiplied the Capacity by 2 and the Accident Probability by 3 roughly for each increment, making a fairly smooth curve already ;).
Title: Re: Commute engine tweaking for NWM
Post by: Starmanw402007 on October 15, 2007, 08:47:49 AM
I've been monitoring the progress of these project. I admit that there are some things I dont understand either  $%Grinno$%. But Keep Up the Great Work anyways! &apls &apls &apls &apls :thumbsup:.

Your Friend;
Mayor Of Steven's Point & Maxiston
(Proud To Be Cities Of Sim Nation!)
Title: Re: Commute engine tweaking for NWM
Post by: mott on October 15, 2007, 12:13:39 PM
Hi all, my meeting went well and I'm just one trip to East Oakland to pick up printed materials away from being free, yay!  Just wanted to check in.

Completely O/T: I couldn't find the off-map commute time cost setting.  But while I was looking for it, I found the LUA script that generates those stupid green track checkers around train stations.  So I isolated it into a patch, and commented out the line that makes the track checkers an occupant of train stations.  So now they're gone.  This is not an "invisible model" trick - the game just doesn't make them any more, at all.  I've attached it if anyone wants to give it a test run, and if it works for everyone else, I'll upload it over at ST once we're assured that it's OK for general public consumption.

If any of you are playing with the network speed adjustments right now, I think staying close to the Maxis values for network speeds rather than the 10x speed range is a good idea.  At least, if I'm right about what the magic number known as "Pathfinding Heuristic" represents.  If I'm right, the fact that "perfect pathfinding" occurs at a Heuristic of ~0.003 is not an accident or a coincidence, and it is directly related to Maxis's network speed settings.  Staying close to Maxis's speed scale is probably best, until I can do more research onto that heuristic.  I don't think anyone's ever explained the exact purpose of the number, other than that it has something to do with pathfinding accuracy, and a value of 0.003 does very good things compared to Maxis's magic value of 0.09.  When people pick constants out of thin air, they don't choose 0.09 or 0.003.  These numbers had to be arrived at as a consequence of something else.

Procrastination over.  Me, truck, boxes, freeway, (paycheck!), now.  See you guys in a few hours. 
Title: Re: Commute engine tweaking for NWM
Post by: wouanagaine on October 15, 2007, 02:28:24 PM
Heuristic is a term used in A*, a known algorithm for pathfinding. Google for A Star or A* and you'll find tons of reference

The heuristic is a fonction used to estimate the distance to the goal from a point. The estimation can be biaised in order to get to the goal quickly ( leading to poor pathfinding ) or by exploring a a lot of possible paths ( leading to poor performance ).

I have not look into the pathfinding examplar, so I just throw ideas, but 'Heuristic pathfinding' may be that biased factor.
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on October 15, 2007, 03:33:17 PM
Well, Im tired and I am gonna have a nap.  I thought for those who are interested in this thread and to see how it will affect your Pathfinding to this point here is a little preview...

Obviously this file is not intended for wide spread use yet, it is mostly intended for the others who feel they can contribute to the converstation.  So, dont blame me if you download it and your dont like it.
Title: Re: Commute engine tweaking for NWM
Post by: mott on October 15, 2007, 04:56:54 PM
Quote from: wouanagaine on October 15, 2007, 02:28:24 PM
Heuristic is a term used in A*, a known algorithm for pathfinding. Google for A Star or A* and you'll find tons of reference

BINGO!!! Thank you, you are a lifesaver.  That's just what I needed.   We're looking at an A* algorithm, using the Manhattan Distance approach.   I can work from there, and it means that this "speeding" idea is a very, very good one.  It should greatly reduce the number of perfectly equivalent routes on the map at any given moment, which is that many fewer tiebreakers to compute.  Tiebreaking is expensive.

Oh for those who want to try my park-and-ride thing: I have heavily modded my files to do other things besides just park-and-ride, and I haven't forgotten about you nice folks.  In order to make up a "clean" version of park-and-ride for you that doesn't have other unwanted radical mods in it (some of which I know aren't properly tuned yet).  I have to re-balance the mod from scratch so I know that everything I didn't change is still default, basically.  This leads to me having to get this speed/congestion/heuristic math figured out anyway in order to re-balance, and since *that* is also useful to people making the NWM components like TLAs, it has priority.  Turning a properly-tuned pathfinder into a properly-tuned park-and-ride pathfinder is the easy part.

Looks like jplumbley just upped a file while I was typing.  I'd best have a look then, eh?

Title: Re: Commute engine tweaking for NWM
Post by: Shadow Assassin on October 16, 2007, 12:46:40 AM
With the heuristic, it's possible that Maxis arrived at 0.09 because it most likely provided the best balance between performance and accuracy on the systems that were most common at the time of the development of the game (2002... even though the game was released in 2003, the coding would've most likely been finished at the end of 2002, because there is a six-week gap [usually] between completion of development and release, due to publication requirements - allowing for the printing of CDs and the like. It's also why they say that the images in the manual may be different upon release). Nowadays, since we have more powerful systems now, we can afford to reduce the heuristic to a value that provides more accurate pathing. Calculating the path does require a fair whack of CPU power. This is why SC4 is still able to bring CPUs to their knees with great ease... four years after the game's release.

Jason, what exactly does your file do? It might help if you explained its function. :P
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on October 16, 2007, 03:12:12 AM
@SA  It is a culmanation of the calculations I did on the previous page with my suggested stats.  It changes the Speed vs Congestion, Speed, Map Distance to Minutes, Max Commute Time and one or two other values.  What I found was traffic balances amoungst the networks and maxes out around 175% capacity before people only add by using busses.
Title: Re: Commute engine tweaking for NWM
Post by: mott on October 16, 2007, 03:37:46 PM
@jplumbley:  Had a look at the file you posted.  One important point: Never let the speed of a network drop to zero with congestion.  It can trap Sims coming in from off-map with no way to route around the blockage, and there's no way to convey that information back in to the originating city.  This throws the pathfinder into panic-mode and confuses the demand and desirability simulators.  Make congestion slower than walking, and that should be enough to avoid the problem.   I loved the congestion/speed curve; that should work wonderfully for what you're trying to do with the TLA..  I'm modding your file right now to make a few adjustments that you'd asked for.  It'll be up in a few hours... but first...

---
I took a crash-course in A* pathfinding last night, courtesy of the Stanford Math Department Website.  :)  Here's what I learned:

First off, the conventional wisdom of "higher heuristic = less CPU/RAM, lower = more CPU/RAM" is true only in a very  general sense.  The whole point of the heuristic approach is that if you get the heuristic close enough, the algorithm ceases to be exponential.  It becomes linear, and it can actually use less CPU and RAM than a dumber algorithm would, while finding better routes too.   It's not about "bigger" or "smaller," but about "closer."

Here's what's going on inside the pathfinder (I hope this is comprehensible...):

Suppose a Sim is at point A and wants to go to point B.  The pathfinding engine computes the Manhattan distance between the two points (E/W tiles traversed  + N/S tiles traversed).   This number of tiles is then multiplied by the "heuristic," to obtain the "expected" time cost of the A-B trip.  So, the heuristic is what you think the total step cost of an arbirtary trip will really be on the real map, divided by the number of tiles that would be traversed on a direct Manhattan path between the two points.

The best-case is that you get it exactly right: The actual per-tile step cost of reaching the goal by the most time-efficient route, is exactly the time you had guessed it would take to traverse the "Manhattan Distance" between the two points, at a per-tile step cost of the heuristic.  In this case, only the very best route was traced by the pathfniding engine, it was found on the very first try, and comparison against the heuristic told the algorithm not to bother trying to beat it. Bulls-eye. 

The odds of being exactly right on an arbitrary map with variable speeds, are much smaller than the odds of being struck by lightning.  We can only hope to be close enough, most of the time, for things to work as well as possible considering that we cannot know the layout of a user-drawn transportation system in advance, or how much of the trip will be accomplished at what speed.

So, the better question is, "how close is close enough?"  It turns out that there's a formula for this:

First, pick an arbirtary trip on the map, and compute the total error between the heuristic guess and the cost of the real optimum path.  That is, the difference between the (Manhattan Distance * Heuristic) estimate, and the actual total step cost of the best route for that trip.  (Remember that "step cost" is (1/speed) on networks, or the "Transit Switch Entry Cost" of transit switches).   Just subtract actual total step cost of a trip from the "expected" step cost, and ignore the negative sign if there is one.  Or vice-versa.  It doesn't matter since we only care about the absolute value.  That's your total accumulated error for the trip.  If the error is exactly zero, you need to consider a less perfect test case. 

Assuming error is not zero, look at the actual trip cost and the accumulated error.  If either of these are less than 1, slide the decimal point over on both numbers, until they are both greater than 1.  Scaling them like this is OK, just make sure that it's done the same for both.  We'll call these "adjusted error" and "adjusted actual cost."   [We're doing this to avoid inequality-reversal confusion in the next step.]

Now set your calculator on "scientific mode," key in that "adjusted error" amount, and then hit the (e^x) button.  If the result is smaller than the "adjusted actual" trip cost, the algorithm may have tried a few bad turns here and there, but it realized it had done so at the next intersection encountered, and did not expand those paths any further.  You again found the perfect fastest route, and CPU/RAM use remained linear (*not* exponential).  In the worst-case, you matched the default Maxis setting's performance, you may have improved on it, and you likely found a better path too.

To put it another way, as long as the error between the (heuristic * manhattan-distance) prediction and the actual trip cost is between zero and the natuiral logarithm of the actual trip cost, you get "perfect pathfinding," AND optimal CPU/RAM use also.  [Again, it's OK to just slide the decimals over on both numbers until they're both above 1, to avoid the inequality-reversal confusion that can occur when using fractions with log() and exp().]

Now, what if you guess wrong?  What if (e^|adjusted error|) > adjusted actual cost?  That depends on whether you guessed too high or too low, but CPU use will probably increase either way, compared to a "good" guess.

If you guessed too high (actual trip was much faster than predicted), the algorithm starts taking a straight line toward the destination for as far as it can regardless of network speeds, and will start to detour around obstacles at the last possible opportunity.  If the "bad" over-guess was high enough, a zig-zag becomes indistinguishable from a straight line, as long as it's heading generally toward the destination.  CPU use increases a bit compared to a smaller heuristic, because every perceived "equivalent" choice at every intersection along every dumb zig-zag has to be expanded and examined, and that eats CPU and RAM in an exponential manner.  The algorithm will find *a* path to the destination.  It is not guaranteed to be an optimal path, it may be a ridiculous one, and it may take more CPU and RAM to discover than a better path would have, given a smaller heuristic. 

The default Maxis heuristic of 0.09 assumes that any given  trip will take the same amount of time as a direct path would at a speed of 11.   Anything faster than that, and you start seeing zig-zags and dumb choices because how much faster than 11 a route averages does not matter - it's considered the same as any other route that beats a direct route at speed 11. 

If you guessed too low (there is no route as fast as the predicted one), the algorithm ends up re-tracing the map in search of the better route that it expects to exist.  It's like a tiebreaking situation again, except this time, all of the known "good" routes are re-considered and it will, worst-case, check every possible path on the map trying to improve on the best route known.  The algorithm does this as efficiently as it can be done, and it will always find the optimal route,  but it's exponentially-growing in terms of CPU and RAM use as the estimate gets farther from reality.

The NAM's "perfect pathfinding" valiue of 0.003 will pretty much always find the best route on a large city tile, no matter what.  It will use a lot of RAM and CPU if there are many equivalent routes, though.  Interestingly, making the very first Sim to use a road start slowing it down immediately (like the "speeding" mod does) tends to reduce the number of potentially equivalent routes on the map at any given moment, resulting in less CPU and RAM use in the most common cases, not more. 

Conclusion:
The "better" pathfinding version of the NAM plugins still allows some zig-zagging in my experience.  The "perfect" version (heuristic 0.003) doesn't inherently use nearly as much CPU or RAM as it's advertised to in most cases, finds the optimal path in just about every case possible, and will actually receive a performance improvement from the "speeding mod" whereas the default Maxis value would not.  It may actually exceed Maxis's performance in many common cases with that mod.   Stick with the 0.003 heuristic for now, I'd say.  Especially if you want to see the true results of any speed/congestion mods.  Or anything else that's usually faster than 11.
Title: Re: Commute engine tweaking for NWM
Post by: wouanagaine on October 17, 2007, 12:15:09 AM
Seems you've been to Amit Patel webpage :)

One note however, where did you find that the A* in SC4 use manhattan distance ? the manhattan distance is quite ok for a 4-arity graph based on a grid, but I think SC4 use a 8-arity graph as diagonal paths are allowed. After some more relfexion, I'm even not sure at all that SC4 use a grid based graph, as it would be a very non optimal representation of the network graph as at most you may have 25% of your map used for network

in the A* the biased factor will either let the algorithm explore more nodes ( ie the "open" list will be big ) so it will surely discorver the better path, or be directed to the goal ( the "open" list will be small ) which leads to not so good paths.

However, from my experience ( around 8 years in A* :p ) I never used such small value for heuristic. I useally set it in the range of [0.5;1.5]. a 0.003 value in my various implementations will certainly result in exploring almost every nodes, which is not appropriate in my context.
Title: Re: Commute engine tweaking for NWM
Post by: Shadow Assassin on October 17, 2007, 01:36:50 AM
Quotethe manhattan distance is quite ok for a 4-arity graph based on a grid, but I think SC4 use a 8-arity graph as diagonal paths are allowed

Might want to point out that SC4 only calculates diagonals by moving up/down and then left/right on the tile. That's why commute times are slightly longer when you use diagonals, because it's not as efficient from the SC4 point of view. So, diagonals would be written as (2 * 1/speed), most likely.

I doubt SC4 would use a grid-based graph. It's probably average commute time over the occupied network tiles.

QuoteFirst off, the conventional wisdom of "higher heuristic = less CPU/RAM, lower = more CPU/RAM" is true only in a very  general sense.

Keep in mind that back in 2002, computers were most likely running 1Ghz processors with 128-256MB of RAM. When you reach 3Ghz and 1GB worth of RAM, I doubt that CPU/RAM requirement for pathfinding would matter so much anymore. There's probably a point in the A* graph where that becomes irrelevant (CPU speed vs. accuracy). With the advent of dual-core processors, this definitely would not matter, since one CPU can be dedicated to just running the game, and the other one is used for running other Windows processes, meaning no other variables would interfere with the processing of routes.


Whew, this is a big balancing act, isn't it?
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on October 17, 2007, 04:59:21 AM
Quote from: Shadow Assassin on October 17, 2007, 01:36:50 AM
Keep in mind that back in 2002, computers were most likely running 1Ghz processors with 128-256MB of RAM. When you reach 3Ghz and 1GB worth of RAM, I doubt that CPU/RAM requirement for pathfinding would matter so much anymore. There's probably a point in the A* graph where that becomes irrelevant (CPU speed vs. accuracy). With the advent of dual-core processors, this definitely would not matter, since one CPU can be dedicated to just running the game, and the other one is used for running other Windows processes, meaning no other variables would interfere with the processing of routes.

I dont know about that...  With the amount of custom content along with other things, we have increased the general usage of both the CPU and the RAM.  Things like complex LODs use multiple polygons, instead of 5 sided boxes for BATs and other type of models, these begin to add to the strain on the computer you have.  Then, add mods like CAM, it allows you to get higher than before known numbers of population in your city.  The higher population, the higher the strain on your computer when calculating paths, especially if you have more than 500,000 sims in your large city tile you will have essentially 250,000 commuters.

BTW, mott, have you looked at the property that deals with the amount of population to commuters?  I forget what it is called but the default setting is at 2, I noticed when I looked at it, it read backwards in my mind and it sounded as if it meant there were 2 cars per Sim, but I am sure it is more or less 2 Sims per car.  This should have been tied to the average age of Sims in the city but we cant do that, so, I am wondering if the number of travels can be reduced if we raise this number.  Im not sure of the effect it would have or what we would be trying to simulate, but who knows.

Quote from: mott on October 16, 2007, 03:37:46 PM
@jplumbley:  Had a look at the file you posted.  One important point: Never let the speed of a network drop to zero with congestion.  It can trap Sims coming in from off-map with no way to route around the blockage, and there's no way to convey that information back in to the originating city.  This throws the pathfinder into panic-mode and confuses the demand and desirability simulators.  Make congestion slower than walking, and that should be enough to avoid the problem.   I loved the congestion/speed curve; that should work wonderfully for what you're trying to do with the TLA..  I'm modding your file right now to make a few adjustments that you'd asked for.  It'll be up in a few hours... but first...

OK... well...  I understand that this would be a problem if the sims actually cared to find a job in the new city tile.  Please visit my post in the following link as to why it doesnt matter and might be a good thing.  [linkie] (http://sc4devotion.com/forums/index.php?topic=2688.msg81351#msg81351)  It will prevent the eternal commuters "maybe" to some extent...

About this what I have observed, is that the Sims will avoid to all costs adding traffic beyond 175% Capacity with the model I have setup, it just becomes to darn slow.  If you add multiple routes, sims will take them first and spread out.  If you then add busses, it doesnt matter how far the bus stop is they will walk and ride to work rather than take a road with 175% capacity.  Busses dont add to congestion so, they will always be able to pass through the traffic.  Traffic will never reach 300% because the simulator wont allow it, and if the highway crossing the border is too high in capacity already it will not bring the network to a dead stop, it just wont, because it nulifies any capacity of that Road in that effect and then will re-distribute anyways (re-opening) the road to traffic.  This will now force the user to plan routes a little better because if there is sufficient capacity to an area the area will probably start to dilapidate or abandon, Im not sure on this though, we would have to test this controlled with no busses.

Oh, I played with the data map thing... I broke it... I went online and changed the HEX codes for the colors... I went back into the game and it doesnt recognize the colors I put in.  It seems as though you have to stick to the set of colors that are there, but we can edit the % they start to show up yet.  What I did notice is that most of the colors are based off of the green spectrum FFFF00 with minor changes, so if you see ones like 99FF0000 or 88FF0000, then these are some of the green colors I would believe.
Title: Re: Commute engine tweaking for NWM
Post by: mott on October 17, 2007, 11:11:38 AM
@sa: If moving on the diagonal is twice the cost of moving on the orthogonal, then that is the textbook definition of "Manhattan Distance."  Calculating a separate diagonal path at the same cost as walking the edges would just present an equivalent path to the pathfinding algorithm, and that would have to be forwarded for tie-breaking every single time with no possible improvement in the outcome for having done so.

Guys, it's 4-ary.  Why would Maxis realize that they didn't even have enough CPU to do a properly tuned heuristic 4-ary search, then go add a bunch of extra calculations for diagonals that they knew they wouldn't have CPU for either?  All a "diagonal road" is, is a clever texture/automata hack that hides the underlying 90-degree turns from you, the same way the diagonal streets roundabout mods do.  And that's all.  From a pathfinding perspective, on the "raw map" used internally, a diagonal road is still made of alternating 90-degree turns, and calculated as such.  What you see in-game is just a lot of pretty pictures.

As for what the diagonal two-tile networks are hiding from you, try to draw two parallel diagonal streets adjacent to each other with the diagonal streets plugin, and note the braided-intersection pattern that results.  That, plus turn-prevention, is what a diagonal avenue really is.  Diagonal Highways too.    Once there are TLAs, OWR-5s, and RHW/MISs, I'm never using diagonal two-tile networks again.  They pass all traffic traveling both directions through a single tile, and have half the capacity they should because of it, and then you have to use bogus congestion curves to make them work at all and it messes up everything. 

===

@jplumbley:  Interesting...

I haven't finished the documentation for it yet, but here's an alternate version of the "path mod" to play with.  It has a nifty characteristic: A "Transit Switch Entry Cost" of 1 happens to represent 1 minute.  That should make the lot-makers' lives easier.

I'm upping it for you now because 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.

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.

Example is in the .dat file, along with the exemplar for the Commute Time Graph.  There's a multiplier in that graph that converts the 0-255 commute time range it sees (255 = Max Commute), back to minutes.  The copy of this graph in the .dat is matched to the pathfinding tuning settings being used by the pathfinding engine.  I did some testing, and that graph is pretty close to real-life values now.

The only thing that will still lie to you about commute time is the Freight Trip Time query that industrial zones report.  The game seems to make that number up, based on its own separate vision of reality and how healthy the city is for industry, the size of the city map, and other things.  This was done in the RH EP or an early patch, IIRC, so that these numbers could be scaled based on the size of the map being played.  I have yet to see that map-distance-to-minutes setting actually used, anywhere.  I've set it to wild arbitrary numbers (1! 1000!  0.001!) with no noticeable effect.  I even tried doing the 10x speed mod thing just to see what that did - in my test city, freight trips dropped down to something resembling "reality," but within a game year those indistrial queries were reporting close to the same trip time numbers as before.    I have SC4 Vanilla around here somewhere, I should check it sometime and see if the setting is used there.

Enough talk.  File.  I'll explain it in the next post.  For now, at least you can pick through the two graph exemplars looking for treasure. ;)
Title: Re: Commute engine tweaking for NWM
Post by: mott on October 17, 2007, 06:20:42 PM
Hi all; apha-test 2 is ready.  This one might even play nice in existing cities.  Maybe.

The .ZIP now contains a README that documents every setting in the pathfinding exemplar, what the default is, what it was changed to (if changed), and notes why it was done (or not).

Basically, I used jPlumbley's speed and congestion ideas, plus the "speeding," and gave the roads a slight nudge downward so Sims will be a little more likely to use that bypass.  Oh, and trucks will pretty much avoid streets if they can, and buses won't use them at all.  I can change this, but since so many people use TE lots to keep these vehicles out of neighborhoods anyway, I figured it was OK to change it so the the trucks would try to stay on the arterials if at all possible, and buses can't stray from the arterials, so you'll have something closer to "bus lines" now.  If you love this or hate it, let me know.

Peds: 5 kph.  Cannot "speed."
Streets: 35 kph cars, 20 trucks, 5 buses.  1200 Cpacity.
Roads:  50 kph cars, 45 trucks, 45 buses.  2400 capacity.
1W/Av  60 kph cars, 55, trucks, 55 buses 3600 capacity
RHW  100 kph cars, 90 trucks/buses, 3600 capacity
HW    100 kph cars, 90 trk/bus, 5400 capacity

El/Sub 60 kph, 4800 capacity.
Rail    90 kph, 4800 capacity.
Monorail 150 kph, 9600 capacity (irrelevant)

All vehicles except Ped and Monorail will speed up to 40% on an empty road.  He will slow to the given speeds at 100% usage.  At 150% usage, speeds are 1/2 normal, 1/4 at 200%, walking-speed at 300%, and essentially impassable by 400%.  Transit Switch lots (stations) that have a Transit Switch Entry Cost are also affected.  Of the default ones, this is exactly none of them so it's irrelevant.

The intersections were lighting up with congestion too soon before, so I fixed that.  The Congestion Data View goes yellow at 100% use, deep orange through 200%, then bright red. 

Peds will walk at least 12 tiles now (more sometimes, and there's an ordinance that should up it another typical block or so), so you can have your bus stops a more realistic distance apart.  And increasing transit funding above 100% now makes transit stations slightly faster, up to 25% (if a Transit Switch Cost is present, which by default it is not, but we'll get to that later.  For now anything times zero is still zero so don't bother wasting money on it unless you're hacking your lots.)

I'm pretty sure that a "Transit Switch Entry Cost" of 1 is working out to exactly 1 minute on the graph now, and the commute time graph has been altered to refelect real-world travel times at a scale of 100 tiles/mile and 64 tiles/km.  Needs play-testing.

Oh, I set the "heuristic" thing to 0.025, which assumes Sims can average 40kph directly to their goal, somehow.  Shouldn't eat too much CPU once a city has some population built up.  Let me know how it works out.
Title: Re: Commute engine tweaking for NWM
Post by: Shadow Assassin on October 17, 2007, 10:27:18 PM
Have you thought about these speeds:
Street - 40kph
Road - 60kph
Avenue/OWR - 70kph
RHW - 110kph
HW - 100kph (you could make it 110 too if it's better)

The rail-based networks would be the same. Would this require a re-balance, or is it okay? I just like these numbers better because they're roughly on par with what it's like here in Australia.

As for the bus idea... I like it, it should be quite good for clearly defining routes, since I use streets for residential areas.

The commute time graph is bang-on scale, since that's SC4 scale. 16m was used because it could easily be translated to both metres and miles. I've got a post somewhere exploring this...
Title: Re: Commute engine tweaking for NWM
Post by: Tarkus on October 17, 2007, 10:32:39 PM
mott, this is some absolutely amazing work you've been doing.  You've really torn the Traffic Simulator apart, and it's amazing what you've found. :thumbsup: 

The only potential issue I see is with the Road network not being equalized with the OWR and Avenue, which will mean that the TLA-5 will have a disadvantage compared to the Avenue and parallel OWRs. 

-Alex (Tarkus)
Title: Re: Commute engine tweaking for NWM
Post by: Diggis on October 17, 2007, 11:08:18 PM
 ()what()

I just read this, or tried to.  I'm going to stick to textures I think...  :P

What I understood of the first post made perfect sense, and I think I understood it.  but when Mott and Jason started trading theisi (thesisiss?) there was more than a little of this  :sleeping: going on as I'm hungover.

One thing that did stick though is the park and ride system.  Is it possible to add a parking garage to a lot that is CO$$$ and limit access only to those who work in that building?  Some buildings do have parking garages.
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on October 18, 2007, 08:02:38 AM
Quote from: Diggis on October 17, 2007, 11:08:18 PM
()what()

I just read this, or tried to.  I'm going to stick to textures I think...  :P

What I understood of the first post made perfect sense, and I think I understood it.  but when Mott and Jason started trading theisi (thesisiss?) there was more than a little of this  :sleeping: going on as I'm hungover.

One thing that did stick though is the park and ride system.  Is it possible to add a parking garage to a lot that is CO$$$ and limit access only to those who work in that building?  Some buildings do have parking garages.

Theoretically this should be possible.  The have been experiments where growable CO Towers have had subway connections added to the lot.  There are 2 "downsides" to the lots that is known:

1. They are static and non-upgradeable.  If one grows it is basically considered Historic at all times and will never upgrade.  Now, I dont know if this is true with parking lots but for the ones with subways they will never upgrade.

2. If a subway Growable CO Tower grows it will require Subway connection.  You never know where these will pop up and if they do and it doesnt land on your designated subway line you will have to move your line to accommodate this new station.  If you do not connect the subway station you will get that annoying Subway has no connection news thing all the time.  Parking Lots will probably not have this issue, but we have never tested it, so what would we know what to expect.

Remember these lots have only been experimental at this point in time and more research would b required to implement them as a whole.
Title: Re: Commute engine tweaking for NWM
Post by: mott on October 19, 2007, 01:13:29 AM
@Tarkus: You may be right... I slowed down the roads just a little bit, because of a common situation that kept coming up while I was play-testing.  When I had a road through a commercial district and built an avenue "bypass" route around it, through traffic still went through the commercial district because it was the same speed as the bypass, and had a slightly more direct route.   The bypass only saw use one the "old road" was saturated with traffic.  So I figured that slowing the road/TLA down slightly would make traffic prefer the more-improved routes with medians, that prohibit cross-traffic turns.  Also, by requiring at least a road in order to use buses, and making roads the equivalent of a high-speed rural expressway, we force an expressway-speed road everywhere the user wants to have buses.  It would tend to draw regional commuters into residential neighborhoods.  So in theory they should all match but for gameplay reasons, I'm not so sure it's the right thing to do.  It's really annoying not being able to have proper traffic light delays, which is what real-life bypass users are trying to avoid. 

@Shadow: Don't forget that this mod also lets Sims "speed" 25% on empty roads.  So the first Sim to use a road will actually drive 62.5 kph on it (around 40 mph). 

@Diggis: Sorry, there's no way to make it so only Sims who work in a particular building can use a transit switch like a parking garage.  Fortunately, there is a way to make it so all buildings that offer jobs also provide "free parking" for the Sims who work there, and no one else.
Title: Re: Commute engine tweaking for NWM
Post by: Tarkus on October 19, 2007, 01:24:50 AM
Actually, mott, that is a very good point you made about keeping the Road speed slightly lower.  The TLA will have a bit of an advantage when it comes to commute times anyway because the commuters will be able to use the turn lane and cross the median, which they can't do without a cross-street on the Avenue network.  The speed/capacity differential might actually equalize things in that case. 

As far as traffic signal timing, there is an exemplar somewhere that I've come across that affects it.  If I remember right, there's three different settings, one for Road, one for Avenue and one for Street (the three networks a traffic signal can function on). 

-Alex (Tarkus)
Title: Re: Commute engine tweaking for NWM
Post by: Shadow Assassin on October 19, 2007, 03:24:19 AM
Just tested out mott's commute mod. It works beautifully.

Buses will still go on streets, but only to bus stops, rather than taking huge shortcuts, which is a big improvement. I wish I could take pictures, but the game crashed.  :'(




And this was my first time playing in about a month and a half.
Title: Re: Commute engine tweaking for NWM
Post by: mott on October 19, 2007, 03:47:06 AM
Quote from: Tarkus on October 19, 2007, 01:24:50 AM
Actually, mott, that is a very good point you made about keeping the Road speed slightly lower.  The TLA will have a bit of an advantage when it comes to commute times anyway because the commuters will be able to use the turn lane and cross the median, which they can't do without a cross-street on the Avenue network.  The speed/capacity differential might actually equalize things in that case. 

Wow, I hadn't thought of that.  All other things being equal, the TLA would present a more direct route any time a Sim's job was on the other side of the street!  Exactly a 50% chance.  Slowing them down to account for this is the right reason to do it.  That it solves my bypass problem is just a pleasant side-effect. 

Sims making cross-traffic turns on a TLA-5 are going to count as usage and reduce the capacity of the oncoming traffic lanes where they cross.  Without a TLA alpha I can't be sure, but I'd bet on it.  The pathfinder works on a per-tile basis so we get that extra bit of realism for free. :)   Maybe I should increase road/TLA capacity to 3600, since the turns will be properly simulated.  Slowing down traffic lets a road carry more cars anyway, since they can be closer together at lower speed.

Quote
As far as traffic signal timing, there is an exemplar somewhere that I've come across that affects it.  If I remember right, there's three different settings, one for Road, one for Avenue and one for Street (the three networks a traffic signal can function on). 

Are you thinking of the one in the Automata exemplar, that says how long (in seconds) the different networks get a green light?  If so, that just controls the pretty pictures that the user sees (how often the traffic light props change states).  It has no other effect, unfortunately.   The only setting I found for intersections in the pathfinder was the one for reducing capacity at an intersection. 

Title: Re: Commute engine tweaking for NWM
Post by: mott on October 19, 2007, 04:22:08 AM
Quote from: Shadow Assassin on October 19, 2007, 03:24:19 AM
Buses will still go on streets, but only to bus stops, rather than taking huge shortcuts, which is a big improvement. I wish I could take pictures, but the game crashed.  :'(

Thanks for the report, sorry about the crash.  I haven't had crash problems with the mod, and pathfinding plugins usually don't cause CTDs.  With this game you never really know though.  I guess I'll treat it like a UFO sighting for now.  Saw something, not sure what it was... if other people crash the first time they run it also, it might be the graph mods I put in there.

Those buses were just barely faster than walking, BTW. ;)  If people want to still have bus stops on streets, I can speed them up a little faster.  As long as street speed is about 40% of road speed, they'll almost never cut a corner on streets except in the most extreme circumstances.  And buses will still get off those streets ASAP.

Pictures are a good idea.  They also give me glimpses of how other people play and what a "typical" map looks like, which helps me tune the pathfinder for our purposes.  CJs are good for this too.  I should go scan some.
Title: Re: Commute engine tweaking for NWM
Post by: rickmastfan67 on October 19, 2007, 04:25:20 AM
Quote from: mott on October 19, 2007, 04:22:08 AM
CJs are good for this too.  I should go scan some.

Go look @ Tarkus's one.  He's got some crazy traffic patterns in his. LOL. ;)  Plus he has maps. ;)
Title: Re: Commute engine tweaking for NWM
Post by: Shadow Assassin on October 19, 2007, 07:13:23 AM
QuoteThanks for the report, sorry about the crash.  I haven't had crash problems with the mod, and pathfinding plugins usually don't cause CTDs.  With this game you never really know though.  I guess I'll treat it like a UFO sighting for now.  Saw something, not sure what it was... if other people crash the first time they run it also, it might be the graph mods I put in there.

It had nothing to do with the pathfinding mod. The game ran for about two hours - I'd think it would've crashed earlier if it was the pathfinding mod. Probably was a little accident involving a TE lot and puzzle piece.

And on the bright side, it seems to have reduced abandonment and improved demand a little bit. Traffic's much more balanced, too, with multiple routes being used more or less equally.

Oh, and game performance when it comes to pathfinding has improved quite significantly from what I was using before (one of the NAM pathfinding mods). It gets updated considerably quicker. Occasional no-car zot, but they go away extremely quickly once routes are calculated. This will work well on a pre-existing region, but it may require a re-thinking of the way you do things.
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on October 19, 2007, 07:28:09 AM
Quote from: Shadow Assassin on October 19, 2007, 07:13:23 AM
This will work well on a pre-existing region, but it may require a re-thinking of the way you do things.

The only way this will really overly effect your city in a negative manner is if your traffic system is setup extremely BAD.  If you use alot of busses, then your shouldnt be overly effected, but this will spread the sims out a bit.  If you have too few options for sims to get to work, then there may be issues finding a way to work and you might gain abandonment, but this is due to the fact you were a poor planner and not due to the fact that the mod doesnt work.


As for your question earlier SA about reworking the Mass Transit systems.  I myself will be looking at a balancing act with these, I dont know how Mott feels about them.  But I will be at very minimum making a personal mod of these networks, I dont like the default 2000 Capacity of the Rail and Subway networks and will definately be re-calculating them.  The TE Lots for the Stations will also be adjusted in my own game because they require a new Transit Switch Speed.  We shall see what I find when I dig through that later.
Title: Re: Commute engine tweaking for NWM
Post by: cammo2003 on October 19, 2007, 08:27:56 AM
Quote from: jplumbley on October 19, 2007, 07:28:09 AM
The only way this will really overly effect your city in a negative manner is if your traffic system is setup extremely BAD.  If you use alot of busses, then your shouldnt be overly effected, but this will spread the sims out a bit.  If you have too few options for sims to get to work, then there may be issues finding a way to work and you might gain abandonment, but this is due to the fact you were a poor planner and not due to the fact that the mod doesnt work.


As for your question earlier SA about reworking the Mass Transit systems.  I myself will be looking at a balancing act with these, I dont know how Mott feels about them.  But I will be at very minimum making a personal mod of these networks, I dont like the default 2000 Capacity of the Rail and Subway networks and will definately be re-calculating them.  The TE Lots for the Stations will also be adjusted in my own game because they require a new Transit Switch Speed.  We shall see what I find when I dig through that later.

I've always felt that a capacity of 2,000 was too low... Especially given a single 8-car train here in Sydney carries that much.
Title: Re: Commute engine tweaking for NWM
Post by: mott on October 19, 2007, 01:55:37 PM
How do I feel about Mass Transit modding?  I'm for it!  What do we want to change? 

I like to make my Sims wait for the train to arrive (Entry Cost), I took away the "income per tile" setting for the rail networks and charged the Sims a fare at the station instead.  Rail capacity is 9600, minimum, in my own games.   

The a02 version I posted on the previous page has all the rail networks to 4800 capacity, and the monorail 9600.  I didn't raise it past that, in case it would be too radical for existing cities and then people wouldn't play-test it.  Because we're being so strict about enforcing congestion delays, it might actually help keep things in balance.  At least the rails are a "safety valve" in case of a population explosion.

Once we've proven to ourselves that the "Max Commute Time" is set high enough to allow all the Sims to reach their jobs on reasonably uncongested roads, and we have good network speeds chosen, we can give the lotmakers their Entry Cost to Real Time conversion charts, with suggested values for achieving desired effects. 

I'm very close to being able to report on the full implications of Transit Switches and TE lots (this info is needed for the Park-and-Ride mod - funny I was researching this when the argument about it broke out).  There are a few special conditions under which a TE lot is OK to use.  The Maxis Elevated, El-Sub transition, and Monorail stations meet the conditions.  Most road-top lots don't.  But some of them do and others could.  I'm documenting this too, to go with the charts.
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on October 19, 2007, 02:45:19 PM
Alright, well for the Mass Transit...  Things that need to be modded would be as you said the Station Lots and the Network Capacities.  The following quote is from a Post I made in the BSC Private Site during the CAM Testing, I have done capacity calculations on the networks.  Im glad I found this.  (From May 07)

Quote from: Jason (jplumbley) on May 08, 2007, 07:09:59 PMHey... I had a talk last night with Alex (Tarkus), about this mod and its effects it will have at higher stages on the capacities of the transit networks.  We both see that it will more than likely have a great impact on you transit network.

Right now, if you notice, when you get to stage 8 and you have a downtown area that it already starts going red or yellow, unless you only use bus traffic.  The thing is there seems to be a trend amoung the larger buildings at stage 8, the majority of their occupants tend to use the same type of transit network, be it, subway, rail, drive or walk.  On average 2500 occupants of a 4000 occupant building will use this same type of travel method.  Unfortunately, vanilla levels are set so that even one of these buildings can overload any network.  Specifically things like a 2000 capacity subway or rail system.

What Alex and I have talked about is re-working these levels in a mix between reality based and SC4 measurements.  We have changed the capacities to hold a higher capacity and the speeds have been raised to reflect a better scale between the useage of the networks (hopefully).

For cars we use a very basic formula... nothing like Tage's logarithmic formulas for CAM.

We stated that, the average length of a car is about 3-4m in length and that the average distance between the cars when travelling is 3-4 car lengths.  This equals an average of somewhere in the range of 13m per car to pass.  If we take the speed the car is travelling, we can get the average capacity of the road per lane per hour.  So if the travel speed is 60 kms/h we get a total capacity of 4615 cars per lane per hour.  Each tile has 2-lanes meaning that the tile average would be 9230 cars per hour.

I hope you followed that.

Here are the stats that we have come up with for a proposal for initial testing:

Street Capacity:6152

Road/OWR/Avenue Capacity:9230

ANT/Highway Capacity:15384

Rail/Subway/EL Rail/Monorail Capacity:16800

So, now I bet your going to ask why we have decided to put Roads/OWR/Avenues with the same stats.  Well, it an easy answer.  The work that Alex, Memo and I have talked about for widening networks (functional turning lanes, wider OWRs, wider avenues, etc.) will benefit by the number of RUL texture overrides that will be created equal to each other.  This allows Alex to place a road next to a OWR and have an RUL that will change it into TLA-5 and place two roads next to each other for the median-less avenue Memo created.  Having the networks with the same stats will mean that there are more possibilities of combinations.

Well, I come to the end of my rant.  I hope this was enlightening and useful.

I am going to update the Pathfinding Simulator (I made) again and give it another upload here later.  This time I will include the RHW stuff and Im gonna steal some of your new additions from your file Mott.


EDIT:  Attached now is the new updated one of my new Pathfinding Simulator.
Title: Re: Commute engine tweaking for NWM
Post by: mott on October 19, 2007, 04:31:32 PM
@jplumbley:  I completely followed the CAM-related post above.  It's not a problem.  Since we're going to mod all the stations anyway, we can pick any baselines we like.  The only thing I would change, would be to "round off" the capacities to even multiples of 100.   Usage queries report to the player in actual trips and not percentage-of-use, so it's just not intuitive to have 100% use be 6152 or something like that.  Make it an even 6000 so the player doesn't get confused.  Besides that... um, OK.  Let's put a CAM-compatible one on the stack. 

I figured out how to change the way the game calculates commute length as far as the sims themselves are concerned (like where the breakpoints for "short" "medium" and "long" commute are when you query a zone).  These things can be changed at a very low level, so it propagates through the desirability calculations and advisor messages, really everything.  So there is no need to mess with network speeds and maximum trip lengths to affect those things.  It's really better if we don't.   If we want any Sim who can find a job in his own city to have a "medium" commute, and a "short" one if he's close enough to walk... no problem.  That's not in the pathfinding engine though; it's based on separate calculations.  And we control the vertical, we control the horizontal....

Oh, don't forget to copy the graph exemplars too.  The real-time thing doesn't work without it, and the congestion one is required because the Maxis defaults are too grainy to provide the kind of data the player needs, with the congestion-enforcement we're using. 
Title: Re: Commute engine tweaking for NWM
Post by: Shadow Assassin on October 19, 2007, 06:10:59 PM
QuoteIf you use alot of busses, then your shouldnt be overly effected, but this will spread the sims out a bit.  If you have too few options for sims to get to work, then there may be issues finding a way to work and you might gain abandonment, but this is due to the fact you were a poor planner and not due to the fact that the mod doesnt work.

Well, more people use cars than buses. Initially when I put the mod in, there was a downward spike across all transport types (ped, bus, car, rail), but soon after it went back to normal. There was no abandonment, though. If anything, there was a reduction in abandonment.
Title: Re: Commute engine tweaking for NWM
Post by: mott on October 19, 2007, 07:17:06 PM
Thanks for the play-testing reports, SA!   :thumbsup:
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on October 19, 2007, 07:29:15 PM
Quote from: Shadow Assassin on October 19, 2007, 06:10:59 PM
Well, more people use cars than buses. Initially when I put the mod in, there was a downward spike across all transport types (ped, bus, car, rail), but soon after it went back to normal. There was no abandonment, though. If anything, there was a reduction in abandonment.

That spike in reduction of transportation might have been many of the dilapidated buildings "rejuvenating" and the all the "new" sims would require to find new jobs and new paths, which would explain a momentary lapse of reduced capacity if it was a city-wide occurance.

What was congestion like before the my new mod, and what was it like afterwards?  Waht was your city population?  And what mod were you using before, Id like to know what the capacities of your roads were before.  I think these ones are a bit high to be honest and will make it too easy to balance your transit system.  If we were to reduce it 25 to 50% it may work better and provide a bit more challange, but not until you reach a city size of probably around 250k.  This is probably the optimal place to make the transit system to become challenging is after population of 250k.  Large city tiles definately hit 1 million quite often, so this may be a good place to start...
Title: Re: Commute engine tweaking for NWM
Post by: mott on October 19, 2007, 09:03:23 PM
When the simulator re-checks a commute and notices that a faster route is available, it tells all the commuters nearby to check their routes again also.  Since every commuter sees an improvement, this "word-of-mouth" quickly spreads, every Sim's trip is wiped off the map, and the pathfinder starts over re-calculating all of them.  If the volume graph updates itself while this is happening, you see this drop in volume, followed by a correction back to normal volumes once all the trips have been re-checked. 
Title: Re: Commute engine tweaking for NWM
Post by: Shadow Assassin on October 19, 2007, 10:23:45 PM
I'll admit that I did it in a large city tile with 20,000 sims. But the city was extremely spread out. I'll try it in a large city with 500 or 600k population and see what happens.

I was using the 10x speed, 10x capacity, 5x commute time mod with the better pathfinding. I'm happy with the results so far, but it's early days yet.
Title: Alpha 03 is here!
Post by: mott on October 22, 2007, 04:26:05 PM
Hi all;

Since the play-testers are having so much successs with the last pathfinding file, I've formalized the changes and rolled them into a nice pretty new alpha 03, yay!

Here's what you get:
* "Demand stalling" and "false abandonment" problems are *much* improved.
* Buses and trucks stay off your streets as much as possible
* "Commute Penalties" for transit types are gone.  As long as Sims can get to work, the player is not penalized.  [No-car and no-transit cities are possible now.  It's a simulator, not a dictator.]
* Commute Time Graph appears in Real-Time minutes, that make sense with the game's scale.
* Speed-Capacity balancing for NWM, RHW, "Big Dig" and HSRP network support is included.
* Grand Rail Station bug fixed - no other patches needed to correct it.

There's also optional pieces:
* First alpha of "Park and Ride" mod (sims cannot drive directly to work; must park and walk.  All mods must be mis-named, as a rule, so "park and ride" then.)
* Corrected radii of *all* civic buildings to match game scale and original design intent (rewards too).  Opera House capacity bug fixed.  Water treatment covers whole city.
* Slope/Tunnel mod that matches the NAM "puzzle piece" slopes.  Also fixes "$100 bulldoze" problem w/puzzle pieces.  Strange place for THAT fix to be, eh? 
* New, proper-Entry-Cost-adjusted Maxis transit station patches.  Yes, ALL of them.  Sims won't walk through them any more, unless they're getting on/off transit.
* Automata plugin so cars aren't appearing and disappearing all the time.  At "turtle" speed vehicles move at true scale speeds.

There are terse, but sufficient, READMEs also.  Lots of minor little adjustments. You guys are smart, you'll figure it out.  Have fun, and as always, report back!  I can't guess at everything people are going to try.
Title: Re: Commute engine tweaking for NWM
Post by: Shadow Assassin on October 22, 2007, 08:12:38 PM
QuoteSlope/Tunnel mod that matches the NAM "puzzle piece" slopes.  Also fixes "$100 bulldoze" problem w/puzzle pieces.  Strange place for THAT fix to be, eh?

I'm not sure what this means... what's the slope grade on this?
Title: Re: Commute engine tweaking for NWM
Post by: mott on October 22, 2007, 10:52:47 PM
Quote from: Shadow Assassin on October 22, 2007, 08:12:38 PM
I'm not sure what this means... what's the slope grade on this?

The same exemplars that the slope mods change, also contain the networks' "build cost" and "bulldoze cost."   So to fix the problem with Puzzle Pieces costing $100 each to bulldoze, I had to make a slope mod because those $100 bulldoze costs add up when you're playing a real game on "hard."  Then the matter of what to set them to came up...  As long as I was letting people play with Park-and-Ride I figured I might as well throw it in the .zip as an "option."   

IIRC, I ended up going with 6 for rail and monorail, 9 for highways and el/sub, 12 for road and 18 for streets.    Still pretty steep, not quite as ugly as the defaults.  Plays nice with "sunken highways" though.
Title: Re: Commute engine tweaking for NWM
Post by: wouanagaine on October 24, 2007, 02:28:12 PM
Hi mott

I gave some tries to your mod ( everything installed ) and I'm reporting some strange things:

fresh region, RHW CAM NAM SAM installed,
first city created:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg519.imageshack.us%2Fimg519%2F9582%2Ffootonlygr9.jpg&hash=7addb5cc82f96de57ddb45c6a4493f2cec05db6a) (http://img519.imageshack.us/img519/9582/footonlygr9.jpg)

noone use cars, which I found a bit drastic

I have a RHW lines, but noone seems to get thru it ( using it or using a street/RHW instersection), I had to change the RHW to road for making the intersection so that sims get to the industrial jobs

Feel free to ask if you need more infos

Take care!
Title: Re: Commute engine tweaking for NWM
Post by: mott on October 24, 2007, 02:57:51 PM
@Wouanagaine:

That sure looks like the ParkAndRide plugin... There's a folder in the package called ParkAndRide, containing an alternate pathfinding file.  If installed, it will override the other path plugin, with the one that forces Sims to use parking lots.  Easy way to tell, just plop a parking garage on that map and watch them all drive to it. :)

Looks like I need to re-package - people aren't nearly as good at reading my mind as I had assumed.  My fault.

Like the ANT, the RHW does not allow pedestrians.  Should this be changed?
Title: Re: Commute engine tweaking for NWM
Post by: wouanagaine on October 24, 2007, 03:02:01 PM
I should have read your explanations better

Indeed, I think an installer with options and such like the NAM will do it well for final release

As RHW, keep it that way, I'll try with parking, it should solve the problem

great job  &apls
Title: Re: Commute engine tweaking for NWM
Post by: Andreas on October 24, 2007, 03:21:50 PM
Quote from: mott on October 24, 2007, 02:57:51 PM
Looks like I need to re-package - people aren't nearly as good at reading my mind as I had assumed.  My fault.

Trust me, I know that feeling... :D  Even my installers were some kind of mystery to a few fellow BSC members. ;)
Title: Re: Commute engine tweaking for NWM
Post by: mott on October 24, 2007, 03:22:17 PM
Quote from: wouanagaine on October 24, 2007, 03:02:01 PM
I should have read your explanations better

And I should have followed modern packaging protocols.   ::)

Thank you so much for the A* pointers.  I'm a math major, not a programmer.   You and Mr. Patel saved me a lot of time.

The reason the heuristic is so small, is that Maxis uses an unusual step-cost range:  [0.005, 0.25]
The "step cost" for a car to move one tile on a road is ~0.03.  Therefore, a good heuristic would be somewhere near there.
(Just to finish that conversation).
Title: Re: Commute engine tweaking for NWM
Post by: mott on October 24, 2007, 03:28:52 PM
Quote from: Andreas on October 24, 2007, 03:21:50 PM
Trust me, I know that feeling... :D  Even my installers were some kind of mystery to a few fellow BSC members. ;)

LOL

You guys are very smart, but still...  hiding an override in a sub-folder is just *mean*.   ;)
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on October 25, 2007, 08:13:17 AM
Hey Mott... Awesome work.  &apls  &apls  &apls

I cannot wait to test out your Park and Ride System... Now, I will get some practice playing with the Transit Switch Costs of the bus stops, trains stations etc.  And... I will charge those sims an arm and a leg to park $20 a car for downtown parking... hehe.  Man this will be very good!  You will be able to control the number of cars coming downtown by the number of parking spaces you create, if there arent enough parking spaces the sims wont be able to reach work unless they walk or ride mass transit.  Some, PED blockers may be required though for major roads leading into downtown from subrubs so the sims dont walk 1000 tiles.
Title: Re: Commute engine tweaking for NWM
Post by: mott on October 25, 2007, 01:01:45 PM
@jplumbley: 

People won't walk 1000 tiles unless it's faster than driving or riding transit 1000 tiles.  If someone really can't drive or ride transit to work, that long pink arrow is a lot more helpful for troubleshooting, than a no-job zot is.  So I'd consider *not* blocking them when testing Entry Cost mods, just to make sure you haven't done something that Sims would go too far avoid if they could.   I also have it tuned so an "Entry Cost" of 1 appears as 1 minute on the graph, so we don't have to do mental gymnastics to interpret test results.

In the MaxisStationFixes file, I patched all the transit stations and parking garages to have an Entry Cost of 0.3 (toll booths 0.5).   So any Sim who rides transit gets a 0.6 total extra time cost added to his trip; 1.2 if he transfers to another form of transit.  Parking lots are 0.3, so I added a "start cost" of 1 to all car trips, for a total 1.3 overhead.  Driving and parking or taking a transit trip with one transfer should be roughly equivalent.  Since the Sims who use transit move so slowly on foot, it may be necessary to add even more starting cost to car trips, to give the transit users a "head start."   But congestion does that anyway; all handicapping the pedestrians does is cause people to use transit to avoid congestion sooner.

If I understand this A* thing, the "Entry Cost" causes the pathfinding algorithm to place transit switches lower in the search queue than the current zero value does.  This should actually save CPU while being "smarter."  The pathfinder is not forced into checking destinations for every bus stop it encounters any more; it just marks their locations and comes back to them if it determines that there might be something to be gained by entering them after all.  The bus stops that lead somewhere useful will be at the top of the search queue at that point.... All this stuff we're doing with congestion curves and "speeding" and Entry Cost should save the pathfinder a lot of work.  Too bad the game is so hard to benchmark.

^--- If any of the above is wrong, our resident programmer will pipe in and correct me, I hope, before I do something that causes people pain.  All the problem sets I'm used to solving start with "Assume an *arbitrary* algorithm"  and not any specific one in particular... :D

If you really need to block peds, a single tile of ANT/RHW will do the job without putting a TE lot on the map.  Even better - how are the ped-mall lots blocking all the other traffic?  If "blocker" puzzle pieces are possible, that's the way to do it.  I have a report coming on TE lots, and no one is going to enjoy it very much I'm afraid.
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on October 25, 2007, 01:29:35 PM
Did I mention, I hate TE Lots when used as Network tiles?  I am very passionate about this topic so... Your report will be music to my ears.

In fact it is possible to block traffic with the TE Lots.  There are a few different Blocker sets out there as it is blocking Trucks, busses, cars, etc from entering a certain tile.  I dont use them, I was just saying that, if there is no parking left and there is no mass transit from Wouanagaine's test it shows that the sims will still goto work, but walk as far as they need to, to get there.  ::)

Please, hurry with that report.  I HATE  :angrymore: TE Lots for network tiles and I will have even more concrete proof of it when your done.
Title: Re: Commute engine tweaking for NWM
Post by: Tarkus on October 25, 2007, 01:46:00 PM
Quote from: jplumbley on October 25, 2007, 01:29:35 PM
Did I mention, I hate TE Lots when used as Network tiles?  I am very passionate about this topic so... Your report will be music to my ears.

Same here. ;) 

-Alex (Tarkus)
Title: Re: Commute engine tweaking for NWM
Post by: mott on October 25, 2007, 01:46:58 PM
Quote from: jplumbley on October 25, 2007, 01:29:35 PM
Please, hurry with that report.  I HATE  :angrymore: TE Lots for network tiles and I will have even more concrete proof of it when your done.

You're on.  I already wrote it up as a text file, so I'll just cut/paste it into a new thread.  TE lots are _ugly_.  Even the Maxis ones.

Edit: Max Commute in the ParkAndRide is 24 I think... at 5 kph (or 5 tiles-per-step, in pathfinding terms) they *should* walk no more than 5*24=120 tiles.   Unless there's something hard-coded to treat pedestrians differently.  Strange.
Title: Re: Commute engine tweaking for NWM
Post by: JoeST on October 25, 2007, 01:50:03 PM
Especially the maxis ones... they didn't do anything right did they lol
Title: Re: Commute engine tweaking for NWM
Post by: XieChengnuo on October 31, 2007, 08:04:07 PM
Hi guys,

I'm a relative newcomer to the world of simcity 4, but when I found this mod, I was absolutely delighted, and downloaded it with great expectations.

So I've been building my quaint little town now, and I've came across some odd things:

First, I found I had a great deal of no-job zots as I was developing my city (the way it's designed is that one region is a bedroom community with only a few commercial jobs, and the other town has all the industry and pollution).

At first I thought it was because I didn't have enough connections, or the commute was too long, so I did whatever I could to shorten it, and I played a fair amount of time on both cities to make sure that that maximum commute time thing was dealt with... but no go.

Then I found this mod and tried it out, but still, no go!  Now here's the interesting thing.  When I *demolished* a certain avenue connecting our regions, all of a sudden all my no job zots disappeared and they all got commute times of "short"...

It's really strange...

So I thought that that fixed it all.  But then when I started making residential communities a bit farther out, I started getting the no job zots again.  Again I tried everything I could, building more jobs, making the commute times shorter but to no avail.

So I started destroying random roads in the hope that the same miracle would happen, and lo and behold... when I destroyed every road out of a community, so that the commuters were forced to take the train to work, it worked.  All the no job zots disappeared.

It doesn't really make sense to me that destroying their path out actually allows them to get a job... the even stranger thing was that, even though this isolated community had a road to get to the train station, they all went by foot - even going many many many squares away!  Only one house took the car. 

So I was like ... ok now I can build the perfect city, and I just made more and more and more and more houses, I made tons of houses, all making sure that it was isolated and they only way they would have to get to work would be through this train station.  And it worked.  Residential demand stayed high so I could build as many houses as I wanted (and people somehow found a way to move into them), there was no pollution (because feet don't generate pollution), no congestion (because pedestrians don't cause congestion), I was making tons of money, people were finding jobs...

But it all seems a bit hokey, don't you think?

I've installed the following plugins:

NAM (radical ordinance setting thingy)
ground light rail and some train stations (but i don't use any)
bridge height changer (i don't have any bridges)
bluish greenish oceans
BSC texture pack, and of course (i don't think any textures are used from here)
your mode beta 0.3 with all the options.

Will a save file help you simcity gurus at all?  How would I get it to you?  (My cities, all zipped up together is a total of 3.99 MB)
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on October 31, 2007, 08:15:44 PM
Hello XieChengnuo,

There are two versions in the last zip file Mott created.

One has the general Traffic Simulator fixed up with our calculations and additional changes.  This will be the one you will probably want to install for the time being.

The second one is one that doesnt allow cars to reach job destinations only pedestrians can do that.  What is required is that you make use of parking lots for sims to drive downtown, park and walk the final leg of their journey.  This is an idea Mott had to add a little more realism and make it a bit more challenging at the same time.  This one works fine, but you have to have parking lots.

Hope this helps.
Title: Re: Commute engine tweaking for NWM
Post by: mott on October 31, 2007, 08:29:04 PM
Actually, the word "avenue" stuck out at me... are we sure this isn't the famous "U-turn at edge of city" problem?  Or an off-by-one-tile problem in the other city?
Title: Re: Commute engine tweaking for NWM
Post by: dragonshardz on November 01, 2007, 06:12:12 PM
watching this thread. Looks good guys.... not much else to say....
Title: Re: Commute engine tweaking for NWM
Post by: XieChengnuo on November 01, 2007, 06:48:09 PM
Quote from: mott on October 31, 2007, 08:29:04 PM
Actually, the word "avenue" stuck out at me... are we sure this isn't the famous "U-turn at edge of city" problem?  Or an off-by-one-tile problem in the other city?


Can you tell me more about this "U-turn at the edge of town" problem?  Would there be a way for me to send you the savegame?  I'm hoping it can help you with your testing and stuff.

By the way, great job you guys, you guys are awesome *thumbs up*
Title: Re: Commute engine tweaking for NWM
Post by: mott on November 01, 2007, 07:15:20 PM
Quote from: XieChengnuo on November 01, 2007, 06:48:09 PM
Can you tell me more about this "U-turn at the edge of town" problem?

First, just a in-game picture of the problem area would help a lot.  I think I have had the problem you describe also, a long time ago before there were mods.

There's something strange that can happen with two-tile networks.  Sometimes when an avenue or highway leaves a city - say on tiles 99 and 100 - it appears in the other city on tiles 100 and 101.  Then the Sims get stuck.

The "U-turn problem" happens when housing is facing an avenue - Sims can only go one direction when they leave home.  If there is nowhere for the Sim to turn around, he can be forced off-map into the neighbor connection.

Hope this helps.
Title: Re: Commute engine tweaking for NWM
Post by: XieChengnuo on November 02, 2007, 07:43:05 AM
I think the non-aligning thing may have been it because I tried to take some screen pics with the avenue and without the avenue, but when i connected it again, it started working again.

There are still some residual people without job zots though.  But thank you guys so much for the help and for the mod, I will try to do further testing. :)
Title: Re: Commute engine tweaking for NWM
Post by: Starmanw402007 on November 02, 2007, 10:39:32 AM
Not sure if this ? applies. But was wondering this. How many Lanes will we be able to play with in the NWM? or is that top secret? LOL.

Your Friend;
Mayor Of Steven's Point & Maxiston
(Proud To Be Cities Of Sim Nation)
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on November 02, 2007, 12:01:57 PM
Quote from: Starmanw402007 on November 02, 2007, 10:39:32 AM
Not sure if this ? applies. But was wondering this. How many Lanes will we be able to play with in the NWM? or is that top secret? LOL.

Your Friend;
Mayor Of Steven's Point & Maxiston
(Proud To Be Cities Of Sim Nation)

Well, with Avenues, we are currently working one TLA-3 (one tile) and TLA-5 (two tiles), we would like to in the future get a TLA-7 (three tiles) working but that is a ways away and will only happen after TLA-3 and TLA-5 are done.  Other Avenues we should be able to make easier after the TLA projects, these will be Ave-6 (three tiles), Medianless Ave-8 (three tiles), Medianless Ave-4 (two tiles), Medianless Ave-6 (two tiles).  Obviously, RHW is in this big batch, RHW-2 (one tile), RHW-4 (two tiles), RHW-6 (three and four tiles), RHW-8 (three and four tiles) and RHW-10 (four tiles) will all eventually be made.  Now, Alex is working on RHW-MIS right now, along with RHW-2 and RHW-4.. I havent seen what he has for RHW-10 yet, but anyways.

What should you expect to see in the next release?

RHW-2
RHW-4
RHW-MIS (some sort of release)
TLA-3
TLA-5
A few new SAM additions including (Avenue Intersectios fixed, Roundabouts, OWR Intersections, two new Dirt Textures)
Revised RTL Plugin (hopefully, if not the existing will not be compatible with TLA-3 or TLA-5)

BTW.. Christmas is so far away, I dont want to be working on this stuff until then, I would prefer to get it out sooner than later.  But, of course, there is still lots to do.
Title: Re: Commute engine tweaking for NWM
Post by: wouanagaine on November 10, 2007, 01:22:43 AM
Time to revive this thread :)

I'm playing a lot with rurality, making small/mid sized town, and as I really like the drive&park mod for my downtown, it is a bit frustrating to have either everyone goes to farm job by feet or have to plop parking around the farm

I hope you can find a solution
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on November 10, 2007, 05:48:14 AM
@Wou.. Its all or nothing.  There is a property that has 1 rep for each Traffic Type.  It is a Boolean operation 1= Traffic Type can reach destination, 0= cannot reach destination.  The only thing I can think of is making a ploppable parking lot which looks like a wheat field or something.
Title: Re: Commute engine tweaking for NWM
Post by: wouanagaine on November 10, 2007, 09:18:08 AM
Well that may be the only solution then, thx for the tips
Title: Re: Commute engine tweaking for NWM
Post by: mott on November 10, 2007, 10:22:39 AM
I use a modified version of the "Rural Parking V2" lots from the STEX - I'd post a link, but unfortunately ST is timing out right now.  There's a 1x1 dirt parking lot in that set, and it looks OK around farms. 

I'm busy with RL, digging through the work backlog that piled up while SoCal was on fire, and moving to a larger apartment.   I'm around, just a little slow to respond.
Title: Re: Commute engine tweaking for NWM
Post by: Starmanw402007 on November 12, 2007, 11:13:05 AM
I'm not sure if this was asked before. But here it goes. How soon could we expect a Beta Version of the NWM?
Just Curious. :)

Your Friend;
Mayor Of Steven's Point & Maxiston
(Proud To Be Cities Of Sim Nation!) :)
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on November 12, 2007, 11:16:51 AM
Sooner than later.  ::)
Title: Re: Commute engine tweaking for NWM
Post by: Starmanw402007 on November 12, 2007, 11:47:36 AM
Cool, Just Keep Up the great work with it :thumbsup:

Your Friend;
Mayor Of Steven's Point & Maxiston
(Proud To Be Cities Of Sim Nation!) :)
Title: Re: Commute engine tweaking for NWM
Post by: debutterfly on November 12, 2007, 12:17:20 PM
Sooner than later...lol...Tarkus says sooner is far away like 2008 so I will be surprised if it came out this month. Also will the U-Turn problem be fixed by the TLA? I saw the pathfinding for the TLA and it seems like it would rid the game of the U-Turn problem...Also will the TLA replace the Avenue or will it be like the GLR starter piece? And I like pictures every now and then even if it isn't that exciting. I just like to see the progress first hand. Oh and what do you program in...I thought I heard C or C++.
Title: Re: Commute engine tweaking for NWM
Post by: Tarkus on November 12, 2007, 12:41:55 PM
You should know by now that we don't set specific release dates. :D  We like to surprise people. ;) 

debutterfly, the TLA-3 is based on a puzzle drag like the GLR and SAM starter pieces, while the TLA-5 is based on a side-by-side override (like the RHW) but with the Road network.  It will indeed be a solution to the U-Turn problem, as cars can cut across the TLAs width with the included crossover paths.  As far as asking for development pics . . . well, again, we like to surprise people.  But I haven't really had anything at all to show on the TLA end--it's been of low priority to me as of late, since I've been putting all my focus into getting the new RHW version with the Modular Interchange System (MIS) ready. 

As far as what we program in, we actually haven't had to use any programming languages at all for these projects--it's mainly been through syntax Maxis set up with the game's internal files that we've learned. 

Hope that answers some questions.

-Alex (Tarkus)
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on November 12, 2007, 12:47:44 PM
Quote from: debutterfly on November 12, 2007, 12:17:20 PM
Oh and what do you program in...I thought I heard C or C++.
We dont program in any real language, it is essentially "IF = THEN" statements which we define in the RULs Overrides for the Network system, which were provided by MAXIS when they released the game.  We are just taking advantage of the abilities of the RULs that others have overlooked or felt were not worth persuing.
Title: Re: Commute engine tweaking for NWM
Post by: mott on November 12, 2007, 01:58:04 PM
There's a clear explanation of RULs, written by the person who invented them, at:

http://www.mathematica-users.org/webMathematica/wiki/wiki.jsp?pageName=Road_rules

A quick read through this page will explain why it takes so long to get the new networks working properly. ;)
Title: Re: Commute engine tweaking for NWM
Post by: debutterfly on November 12, 2007, 02:05:15 PM
I will be majoring in Math and Computer Science so I will definitely look in to learning this. I would like to be of some help if you need any on algorithms or if-then statements. I've made simulators before so this shouldn't be too hard for me to learn. btw I taught myself Java, TI-Basic, QBasic, Visual Basic and I'm only a freshman.
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on November 12, 2007, 02:17:22 PM
Quote from: debutterfly on November 12, 2007, 02:05:15 PM
I will be majoring in Math and Computer Science so I will definitely look in to learning this. I would like to be of some help if you need any on algorithms or if-then statements. I've made simulators before so this shouldn't be too hard for me to learn. btw I taught myself Java, TI-Basic, QBasic, Visual Basic and I'm only a freshman.

Sounds like you are ambitious, very good.  :D

The following link will help you understand the most basic RUL the one I deal with most frequently.  RUL 0x10000002 Tutorial (http://sc4devotion.com/forums/index.php?topic=2500.0)
Title: Re: Commute engine tweaking for NWM
Post by: Starmanw402007 on November 12, 2007, 03:54:03 PM
Well, I like Surprises anyways.  :).

Your Friend;
Mayor Of Steven's Point & Maxiston
(Proud To Be Cities Of Sim Nation!). :)
Title: Re: Commute engine tweaking for NWM
Post by: debutterfly on November 13, 2007, 04:45:27 PM
how far will sims travel before saying "forget it" and abandoning their homes? let's start with 60mph.
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on November 14, 2007, 05:28:02 AM
Quote from: debutterfly on November 13, 2007, 04:45:27 PM
how far will sims travel before saying "forget it" and abandoning their homes? let's start with 60mph.

This is a very loaded question.  It depends on a number of variables determined in the Traffic Simulator.  Mott has explained how this calculation is done in the very first post of this thread, in fact the first 2 pages are a high recommended read if you want to learn more about the Traffic Simulator itself.  The following quote is the explaination you are looking for from Mott's post on the first page:

Quote from: mott on October 13, 2007, 01:27:51 PM
I really think the "network speeds" as set in the commute tuning exemplars are NOT in kilometers per hour, despite the Reader's assertions.  Rather, given a speed s, the "map distance" for a vehicle/pedestrian to travel over 1 tile is (1/s).  On a transit-enabled lot, the "Transit Switch Entry Cost" applies instead, counted once for the entire lot.  So the commute engine just adds the numbers up, per-tile (and per-lot, for transit-enabled lots) until it either reaches the Sim's job, or hits the cumulative maximum commute (default: 6).

There is an additional maximum mass-transit trip length.  This is described by the Reader as "Maximum mass transit commute raw trip length," but what it really represents is the maximum map distance a pedestrian will go on foot in search of a transit station before he gives up and drives instead.  In a default Maxis installation, pedestrians have a "nework speed" of 3.5, and the maximum "raw" mass transit commute distance is set to 4.  Divide that 4 in half to account for the evening commute, and you have a maximum "map distance" for a pedestrian's initial trip from home to a transit stop being 2.  At a map distance of 1/3.5 per tile walked, that works out to about 7 tiles, which happens to be about as far as a Sim will go to reach a bus stop. 

No wonder the 10x commute speed plugin doesn't speed up pedestrians - they'd walk up to 70 tiles at 10x speed!  To fix this and get it back to 7 tiles, without affecting anything else, divide the maximum raw mass transit trip entry by 10 after accelerating the pedestrians.  It's 4 by default, so replacing this with 0.4 will set the peds back to their original maximum distance.  (I usually set it to (1.6), so that the Sims will walk up to 28 tiles (about 1/4 mile), which is the 5-minute walk that real transit planners expect that people will take to reach transit).  Again, this does not shorten the Sim's trip one he reaches a bus or train.  It's only for that first walk to the initial station.  The Sims won't have to walk at turtle-speed, distorting commute times any more.  I doubt that this was known when the plugins were made?

Next, we can look at roads.  Defaut speed 31, so each tile has a "step cost" of 1/31.  The maximum commute distance is 6, divide by 2 to account for the evening commute back home, and that's three.  To get to 3 in 1/31 increments, that's 93 tiles - this is why on large maps, Sims at one side of the city have trouble reaching jobs on the other side until there are highways or at least avenues.  The 10x speed plugin makes it 930 tiles max commute on road, which is good enough to get across 3 or 4 large city tiles (or as little as 2, if it's a worst-case diagonal commute all the way across the large cities).  It sure solves people's no-job zot problems.

This is where the "Transit Switch Entry Cost" property of transit switch lots (such as train stations and bus stops) comes in.  There is no unit of measure given for this property, but it is analagous to the "step cost" of going through a network tile.  It's just the "map step cost" for traversing the lot.  Large transit-enabled lots require some very careful tuning of this value, lest they function as "teleporters" (too little cost) that suck all traffic through them, or as "blockers" (too much cost) that Sims would prefer to go around. 

Transit enabled lots get complicated this way, because their "transit switch entry cost" in transit switch lots is directly related to network speeds and max commute!  The moment you increase speeds by 10, you also increase the relative  "transit switch entry cost" by 10!  Driving takes 1/10 the time it used to (on road, it went from 0.031/tile to 0.0031/tile), but that Toll Booth at the edge of town has the same .02 cost it always did, and your Sims will now drive 10x farther to avoid it!
Title: Re: Commute engine tweaking for NWM
Post by: debutterfly on November 14, 2007, 07:10:39 AM
got it...thanks
Title: Re: Commute engine tweaking for NWM
Post by: Starmanw402007 on November 14, 2007, 05:39:35 PM
RHW-10 (four tiles), is probably what I'll need for my traffix problems  :D. Of Course when it becomes available. Until then, Those Sims of Steven's Point will have to play Demolition Derby :D $%Grinno$%.

Your Friend;
Mayor Of Steven's Point & Maxiston
(Proud To Be Cities Of Sim Nation!)
Title: Re: Commute engine tweaking for NWM
Post by: theloolix on December 09, 2007, 08:01:42 PM
i've enjoyed this thread very much.  thanks, mott & jplumbley; it's shed a lot of light on some issues i've been confused on.

lately, i've been playing around with building a city/region based on the reference design presented in http://carfree.com/ and its corresponding book.  the looped city design has helped me give some direction when trying to build a city on a large tile, and as someone who hasn't driven a car in over 10 years the idea of a car-less city intrigues me.

so, i figured this park and ride plugin would be a great match for my new region.

first, i tried out the carfree design with a single large city, and my districts were about 17 tiles squared.  i used the monorail instead of subway so that i could see the trains going by.  with the park-and-ride plugin, i would get no-car zots on many of the zones (http://off.net/~jacob/sc4/District%20City-Jan.%2014,%20321196379199.png) in these districts and then abandonment (http://off.net/~jacob/sc4/District%20City-Jun.%2013,%20321196379392.png).

this happened at about 52k residents, and i could no longer get any residents to move in, despite there being ample demand.

i switched to the normal a03 traffic plugin, and started over with the same district layout, and had no problem getting my city to over 150k residents.  i'm not sure whether cpu usage or something else is the culprit, but i thought i'd let you know about this.

i've moved on to trying to build a region-size city (16kmx16km is just about the recommended city area by that book), but subway capacities are causing a problem.

i have two cities; one with a few residential district, and the other with a residential district near the border with the first city, and with some industrial districts to the south (so most residents from the first city commute through the residential district in the second before reaching their place of employment). 

after the subway stations in the residential district reached about 110%, the traffic volume (http://off.net/~jacob/sc4/SSW%20Residustrial%20Locality-Sep.%2026,%20091197256651.png) and commute time (http://off.net/~jacob/sc4/SSW%20Residustrial%20Locality-Sep.%2026,%20091197256623.png) graphs started to go a little crazy.  my experience with monorails had been that sims had no problem using stations until about 500% capacity, and the monorail tracks themselves were just about always green on the traffic chart.  are monorails and subways this different, or is this an artifact of the traffic plugin?

also, is the capacity for a station only the number of sims entering/exiting that station, or does it count through traffic?  the carfree book suggests that a metro can handle 20k people per *hour*, so even the 4800 seems pretty low.  (i believe that 20k is in one direction, but i may be mistaken).

there was also mention of another plugin in some thread with this:

> Rail/Subway/EL Rail/Monorail Capacity:16800

but i cannot locate that now; what was that, exactly?

thanks for your time and sorry if i've rambled a bit.
Title: Re: Commute engine tweaking for NWM
Post by: theloolix on December 10, 2007, 07:05:54 AM
And one more thing i forgot:

when i had a lot of monorail usage with the a03 plugin, there was a lot more air pollution from a monorail than i'd expect.
Title: Re: Alpha 03 is here!
Post by: jplumbley on December 10, 2007, 12:55:03 PM
@theloolix

I will start with the Capacity question you had:

Mott if I remember correctly did not edit the road capacities.  I made some calculations based on RL systems way back when and copied my post here and that is where the 16800 capacity came from.  These capacities are actually included in the CAM Pathfinding update.  Unfortunately the CAM Pathfinding file was not updated with the new information that we found out in this thread due to CAM being released before this thread was even thought of.

I have done some experimenting with the Capacity values.  It seems that these are just as important as everything else when attempting to balance your network system.  If they are too high then people will not spread out and use "uncongested" routes and becomes unrealistic.  If they are too low, it will prevent developement when you get to larger cities because your transit system just cannot handle the traffic.  There seems to be a fine balance and from my testing, the MAXIS values are a little low, but they are not too far away from the proper balance, I cant remember the exact values but I have a fairly balanced Pathfinding engine for a Large City tile.  It is unreleased and will stay that way until atleast the next release of NAM.

My suggestion if you would like to change the capacities for cities 100k+... Set your Capacities to:

Rail/Monorail/Subway/El-Rail:  10,000
Street:  2,500
Road:  6,000
OWR:  6,000
Avenue:  6,000
Highway:  8,000
El-Highway:  8,000
DirtRoad (RHW):  8,000

These numbers will give you a fairly stable and semi-realistic level.  Obviously, there is more testing needed and these numbers are not necessarily going to work 100%.

My only suggestion is that, if you start having capacity issues it means you do not have enough routes for sims to use.  The more routes you have the better your Traffic System and Traffic Simulator will work for you, if you are using the one Mott and I have developed here.

Subway system haywire:

Yes, sir!  Thats what happens when population grows.  I would put my money on your population is spiking in the same fashion.  What can happen is you have created demand for your residents and you need more sims in your region.  But, when your Subway System starts becoming over used it will start slowing your Sims down and could possibly make some of them have long commute times.  If the commute is too long they will abandon and you will have incidentally "recreated" the demand which is a vicious cycle.

What Mott and I have done in this thread is "forced" Sims to use other routes by playing with the Speed vs Congestion.  When you capacity reaches beyond 100% the speed of the network will begin to reduce.  In fact a model I worked up and I think Mott has instituted into his a03 release follows a chart like this:

Congestion:  0%   25%   50%    75%   100%  125%  150%  175%  200%
Speed:      140%  130%  120%  110%  100%  75%    50%   25%   0.1%

This means that if your Congestion is at 110% the speed of the network is approximately 90%.  So if your Sims travel at 150 km/h the actual speed will now be 135 km/h.  Hence and increase in commute time.  When I tested it with 0% speed at 200% capacity I found that sims would start walking or using busses at 175% capacity.  The reason for this is that the busses and walkign do not add to congestion and will not reduce the speed.  Because your Subway system may support a much larger area the Sims may not want to use the network because the commute time is just too far due to the congestion.  What happens when you add a new Subway line?

Monorail Air Pollution:

This is something I dont agree with either.  Monorails are generally electric and do not give off pollution along the length of their lines.  I am not sure why MAXIS included this in the Monorail system but they did.  I have not looked into removing it, just havent had the time.

Abandonment Issues with carless City:

I dont think this was a CPU usage issue.  There are many things that could have contributed to this just playing the game.  With all Pathfinding Engines before the ones created in this thread there are fatal flaws.  Some of them these fatal flaws show earlier than others and at some point the Simulator will just prevent people from reaching work.

The new Traffic Simulators in this thread are much more stable than the MAXIS and NAM created ones.  It is advisable (even though only Alpha Stage) to use the ones from this thread. 
Title: Re: Commute engine tweaking for NWM
Post by: dragonshardz on December 10, 2007, 03:32:07 PM
Question: What dat do I load in the Ilive Reader to change those values? Also, what tags inside the dat do I need to change and what value do I change them to?
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on December 10, 2007, 04:03:23 PM
@Dragonshardz

If you download one the last zip in this thread (page 3 half way down posted by Mott) it will give you a couple of options for the Pathfinding Engine we have developed here in this thread.  Basically, the main difference between the two is the park and ride feature.  Mott has tested out a park and ride aspect to the game, basically it doesnt allow cars to reach their destination, Sims now must park and then walk the rest of the way or ride a transit system.  This will force you to use parking but will be a little more realistic for some.  Now, you must remember that the other one is a Standard MAXIS Engine tweaked to be with the values we have calculated here and tweaks here and there.

There is only one file in this DAT so this would be the DAT you need to open with iLives Reader.
Title: Re: Commute engine tweaking for NWM
Post by: dragonshardz on December 10, 2007, 04:07:30 PM
ok thanks.

Quick question: If i have a slope mod already installed, should I remove it or not?
Title: Re: Commute engine tweaking for NWM
Post by: RippleJet on December 10, 2007, 04:14:25 PM
Quote from: dragonshardz on December 10, 2007, 04:07:30 PM
Quick question: If i have a slope mod already installed, should I remove it or not?

The slope mod has nothing with pathfinding to do.
It only determines the maximum allowed slopes when dragging a network.

So, keep it if you like it! :thumbsup:
Title: Re: Commute engine tweaking for NWM
Post by: dragonshardz on December 10, 2007, 05:12:07 PM
another question: In re:Monorail pollution, where would i go to modify that? one of the simcity base dats?
Title: Re: Commute engine tweaking for NWM
Post by: Filasimo on December 10, 2007, 05:15:34 PM
DS: again this is for discussing commute engine tweaking for the network widening mod, please if you have any questions unrelated to the topic please post your question here: http://sc4devotion.com/forums/index.php?board=11.0    thanks and have a nice day!!  ;)
Title: Re: Commute engine tweaking for NWM
Post by: dragonshardz on December 10, 2007, 05:17:59 PM
all right, sorry. I think i'll just have to have a look around the SC4 dats and stuff.

testing and modding (slightly) the a03. just messing with the capacities of the networks as posed in a previous post.
Title: Re: Commute engine tweaking for NWM
Post by: Twalin on December 11, 2007, 06:08:21 PM
this question was prompted by the "distance penalties" thread but this seemed like a more appropriate place to ask.

Mott

can you clarify more what you were saying about the 5x commute engine in the NAM, I decided to reinstall the NAM based on the information you have  presented in this thread and the distance penalties thread.  I am specifically referencing

QuoteThe "2x/5x/10xSpeed" versions should not exist.

5x Commute is a *very* good choice though.  The internals of this game are still working at SC3K scale, 255 tiles = 16 km.   Raising the Max Commute by 4x, makes the simulators match the visual scale being presented to the user.  The game gets a whole lot more intuitive, and playable, as "desirability" and "commute distance" is considered more at a neighborhood scale, consistent with other aspects of gameplay.  5x Commute is close enough for the magic to happen.

As a bonus, at "normal" speed, the "perfect" or "better' pathfinding actually works.

Although the NAM controller options are

Standard Pathfinding
Better Pathfinding
Perfect Pathfinding

each with variations of adding 2X or 5X capacity, 10X commute, or 10X speed.

I understand what you are saying about the speed mods being bad, but was hoping you would share your thoughts on the capacities, or which of the variations would be most beneficial.


P.S.... I should add... all you guys on the NAM team etc. are crazy... but thank you for doing what you do... you've reinvented one of my favorite games, and I love playing it again.
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on December 11, 2007, 06:37:45 PM
@Twalin

At the moment the one which I would choose is either the Standard or the 2x Capacities.  It really depends on what the size of your city is.  If your population is between 50k and 150k I would go with Standard, if it is between 150k and 300k I would go with 2x Capacity, if it is over 300k it may be a good idea to go with 2x capacity but I think you should still be able to get away with 2x Capacity if you keep adding different routes.

The reason for the lower capacities is because it will start forcing your sims to use different routes.  But, I will try and upload an update of my Pathfinding Engine (similar to Motts) in the near future.  After some testing.
Title: Re: Alpha 03 is here!
Post by: theloolix on December 14, 2007, 02:46:09 PM
Quote from: jplumbley on December 10, 2007, 12:55:03 PM

Abandonment Issues with carless City:

The new Traffic Simulators in this thread are much more stable than the MAXIS and NAM created ones.  It is advisable (even though only Alpha Stage) to use the ones from this thread. 

thanks for your prompt reply!

in this case, this *was* with mott's new simulator; but i only had abandonment with the "park and ride" version; the one that also added pedestrian congestion.  i suspected cpu because i think mott mentioned it would be more cpu intensive?  i don't know for sure.  also, i think i turned down the graphics options and that helped for maybe another 10k residents, but i don't remember exactly so can't say.

as for the subway capacities, i guess we'll have to agree to disagree there; 10k is way too low.  the carfree book suggests that a good metro could actually provide for 57k per hour, per direction, so i've bumped up my metro capacity to 50k.  perhaps i should bump up the cost as well.

i guess what i'd be most interested is a car-free ordinance.  it'd disable cars (i've modified mott's plugin to do this already), disable metro fares, and maybe increase health a little bit?

one other comment for mott:

wrt. the radius changes for civic buildings, i feel like the radii are a little too big now, and it makes the game too easy.  this is especially so for the higher capacity schools, which you'll never need to spend money on buses if you're zoning above low density.  (although why i need buses when i spend so much on a metro i do not understand).

anyway, thanks and keep up the great work.
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on December 21, 2007, 05:20:22 AM
@theloolix

Sorry for the slow reply.  I havent really come up with an answer and every so often when I had a chance tried to think about it.

I cant really comment on your specific situation because, I dont know what is going on.  I can guess what is happening but, I need a few pictures to show me a few things, such as, the area of abandonment, the Traffic Data maps, information about mass transit, etc.

If I were to guess.

"Park and Ride" forces the sims to be pedestrians when they enter their work.  Every TE Lot has a maximum capacity, so if the designed maximum capacity for a TE Lot is 1000, then the actual maximum capacity is 10,000 because TE Lots allow upto 10x the maximum capacity defined.  So, lets say you have 1 parking lot servicing a densely populated downtown area that holds more than 20,000 but your parking lot can only service 10,000 at max.  Due to this shortage of parking spaces you will get abandonment because the sims cannot reach work.

Another scenario might be that you have sufficient parking, but the parking lots are spaced too far apart in your downtown area and the radius of the walking Sims from their cars to their work is too great.  Due to this some Sims will refuse to goto work due to the fact that its too long of a walk.

But you are using subway systems.  So, this likley isnt the case.  I dont know for sure but I dont think that the CPU is being over worked.  There are too many things to think about with this Simulator.  Its not just NAM, its everything.

Man, looking back at your pictures now, I just noticed something important.  You 17 tile blocks are cool.  There is one fatal flaw in the design though.  Mott based his "Park and Ride" mod off the original MAXIS distances.  MAXIS allowed Sims to walk approximately 7 tiles to reach thier destination (the Monorail Station).  If you count only the middle stage buildings are within that radius but the others within that area are the only ones able to reach the Monorail station within 7 tiles of walking.  Everything else is not connected because the sims cannot reach the Station in their determined walk time.

A way to fix this is by putting a parking lot next to the station so it becomes a true park and ride.  OR by upping the "speed" of the pedestrian (not suggested).  OR by allowing the Monrail Station to have Car to Monorail and Monorail to Car transit switches.   I would go with option 1... less hassles, no modification, etc.
Title: Re: Commute engine tweaking for NWM
Post by: LunarMongoose on December 31, 2007, 09:36:20 AM
I just discovered this thread earlier tonight, so first of all want to say thank you for all the fantastic work that's been done here.

That being said, something to mention if no one has considered it yet. The DemandCreated exemplar field -- which I finally became clear on the functioning of thanks to a thread over on Simtropolis about making an entire region with zero C or I zoning, just residential plus tons of civic buildings -- gives buildings "Civic Jobs" that sims work at but which aren't taxed and don't really show up anywhere. The quantities are generally small and only present on civic and some reward buildings in vanilla, but could still lead to some extra NJZs with your ParkAndRide setup as ppl don't normally realize civic buildings *have* jobs (at least I didn't) and thus won't think to put parking garages near their police stations, etc.

One easy thing you could do would be to add car-to-ped TEing on the vanilla civic buildings that alrdy show as having distinct parking lots, or else remove all the DemandCreated stats though that'll affect game balance a little.
Title: Re: Commute engine tweaking for NWM
Post by: Starmanw402007 on January 13, 2008, 08:08:14 AM
Just Curious, how are u guys coming along with the NWM? Havent heard anything at all from this project LOL.

Your Friend;
Mayor Of Steven's Point & Maxiston
(Proud To Be Cities Of Sim Nation!)
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on January 13, 2008, 08:14:05 AM
We released RHW v20 and MIS.

Currently an ALPHA of my RTL Plugin is in a test run.  TLA-3 and TLA-5 currently depend on the new RTL Plugin being released.
Title: Re: Commute engine tweaking for NWM
Post by: kassarc16 on January 13, 2008, 02:46:17 PM
Mott,

Since you asked awhile back, I've got some feedback on your RealTime version of the mod. I've noticed a lack of automata being spawned. I don't have huge traffic levels yet, but a road with 1000+ cars on it seems a bit empty now.

Great job on this folks! Can't wait for the TL mods!
Title: Re: Commute engine tweaking for NWM
Post by: grudy on January 24, 2008, 01:54:54 PM
I'm new to this thread, but I can't wait to try Alpha 03!  Anyway, I currently have the NAM, and was wondering which files I need to delete from it and which I should keep.  Aka is there only one pathfinding file to be deleted, or others too?
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on January 24, 2008, 02:01:23 PM
Quote from: grudy on January 24, 2008, 01:54:54 PM
I'm new to this thread, but I can't wait to try Alpha 03!  Anyway, I currently have the NAM, and was wondering which files I need to delete from it and which I should keep.  Aka is there only one pathfinding file to be deleted, or others too?

TESTERS *Needed* - Traffic Simulator (http://sc4devotion.com/forums/index.php?topic=3508.60)

That thread is where all the work from this thread is being implemented.  A new Simulator File will be released sometime in the coming weeks or so and it will be a replacement for all the current ones in NAM.  This new file will be a NAM supported Simulator and there will be a few versions to choose from like the original NAM files, but will be much more balanced.  Be patient and you will recieve the greatest gift of all, a balanced Simulator.
Title: Re: Commute engine tweaking for NWM
Post by: Starmanw402007 on February 02, 2008, 04:48:32 PM
Hey Jp, whats in this nwm anyways? I've always been curious about that LOL.
Title: Re: Commute engine tweaking for NWM
Post by: JoeST on February 03, 2008, 01:34:57 AM
Network Widening Mod...

Joe
Title: Re: Commute engine tweaking for NWM
Post by: SC4BOY on February 03, 2008, 03:33:48 AM
I am not sure whether this is an appropriate forum, but my question deals with the interactions of the engine tweaking (which I am a fan of) and also the old High Speed Rail Project (HSRP beta). I have the following plugins in my folder as I use the HSRP in some of my regions (in many respects for the same reasons people play with the engine tweaking.. hehe)

(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg441.imageshack.us%2Fimg441%2F9638%2Fhsrpfilesdl8.jpg&hash=dadd45de2c4853a440c7c0913205750619ab48b6)

What is the proper way to use this HSRP mod AND to toy with the engine tweaking mods too? If you wish to know the contents of any of these files, I'll be happy to attach them or email them.. I'm pretty sure only one of the files contains the "speed/commute" mods.. the rest are for appearance, slopes, and the track mechanics I think. Thanks

If this belongs on the Plumbley "Testers Needed" thread or its own thread, feel free to move it.. sorry.
Title: Re: Commute engine tweaking for NWM
Post by: Starmanw402007 on February 03, 2008, 08:35:36 AM
Joe, I know that. I meant; what will be in the modd itself LOL.
Title: Re: Commute engine tweaking for NWM
Post by: jplumbley on February 03, 2008, 08:42:57 AM
Quote from: SC4BOY on February 03, 2008, 03:33:48 AM
I am not sure whether this is an appropriate forum, but my question deals with the interactions of the engine tweaking (which I am a fan of) and also the old High Speed Rail Project (HSRP beta). I have the following plugins in my folder as I use the HSRP in some of my regions (in many respects for the same reasons people play with the engine tweaking.. hehe)


What is the proper way to use this HSRP mod AND to toy with the engine tweaking mods too? If you wish to know the contents of any of these files, I'll be happy to attach them or email them.. I'm pretty sure only one of the files contains the "speed/commute" mods.. the rest are for appearance, slopes, and the track mechanics I think. Thanks

If this belongs on the Plumbley "Testers Needed" thread or its own thread, feel free to move it.. sorry.

I am not totally sure which file it would be in, but my guess from the looks of it would be in the main DAT, which is a bad thing.  Basically, you are going to want to take my file and put it in the main directory and put a z_ in front of it for now.

If you can post a link to the HSRP Beta file, I can tell you for sure.
Title: Re: Commute engine tweaking for NWM
Post by: JoeST on February 03, 2008, 08:50:13 AM
I believe it is the widening of the selections of the networks, it includes the RHW and SAM and other new networks
Title: Re: Commute engine tweaking for NWM
Post by: SC4BOY on February 03, 2008, 11:07:22 AM
Quote from: jplumbley on February 03, 2008, 08:42:57 AM
I am not totally sure which file it would be in, but my guess from the looks of it would be in the main DAT, which is a bad thing.  Basically, you are going to want to take my file and put it in the main directory and put a z_ in front of it for now.

If you can post a link to the HSRP Beta file, I can tell you for sure.

Well for now I've simply taken them out. While I was doing your "test thread" I found it clearly overrode the test. I didn't feel like sorting through it to test as the city I am testing the engine on does not have an HSRP.

HSRP Beta 1 Download (http://www.simtropolis.com/stex/details.cfm?id=16426&v=1)

I'm pretty sure it is the HSRP.dat file. As I recall the only major impact they made on the parameters werre to set the speed to rather high level and the commute distance too (maybe not this? forgot).. the number that I recall from the thread (the full thread is available on ST) was 6000 for speed.. however that translates.. I recall it was rather high.. it was not for city travel but rather intercity.. the goal to allow 4 tile commutes via the HSRP.. it is quite impractical for short hops for a number of reasons.
Title: Re: Commute engine tweaking for NWM
Post by: mightygoose on February 03, 2008, 02:10:19 PM
hmm maybe that belongs in the RAM board???
Title: Re: Commute engine tweaking for NWM
Post by: Tarkus on February 03, 2008, 02:34:17 PM
Quote from: Starmanw402007 on February 03, 2008, 08:35:36 AM
Joe, I know that. I meant; what will be in the modd itself LOL.

Well, the whole NWM concept was really thrown around a lot more before the NAM went modular--it was originally going to be an umbrella containing the RHW, TLA/Wider Avenues, and Wider One-Way projects.  The RHW, however, has continued to be released as a separate project.  While this is in part due to the fact that the other components have not been developed anywhere close to the point of a public release yet, the RHW is getting to be large enough in filesize that by RHW v22 or v23, it will be pushing 10MB easily.  (My current v21 test file, which is still in a pre-alpha stage, is already at 5MB.) 

So there's a good chance that there won't be an NWM mod, but rather, the TLAs and Wider OWRs as separate, optional NAM components, though we are still quite early in the development on those two projects, and we're not sure yet. 

Hope that answers your question, Steven. :)  Don't worry, the stuff will get released somehow eventually. ;)

-Alex (Tarkus)
Title: Re: Commute engine tweaking for NWM
Post by: Starmanw402007 on February 05, 2008, 12:04:20 PM
Thanks tarkus, I have patience for this new modd. Like I said in my last post. I was just curious thats all.