[jplumbley]

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.

[mott]

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?

[Shadow Assassin]

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.

[jplumbley]

@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.

[mott]

@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.

[wouanagaine]

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.

[Shadow Assassin]

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

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.

First 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?

[jplumbley]

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.

@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]  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.

[mott]

@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.

[mott]

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.

[Shadow Assassin]

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...

[Tarkus]

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.  

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)

[Diggis]

 

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

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  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.

[jplumbley]

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

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  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.

[mott]

@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.

[Tarkus]

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)

[Shadow Assassin]

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.

[mott]

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.

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. 
 

[mott]

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.

[rickmastfan67]

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.