RH Commute Testing...

[the7trumpets 10]

Please forgive me, Larsz, for re-doing your topic.  I just wanted to make it easy to read and follow, with a full checklist and other information in the beginning.

 

Welcome to the home of Rush Hour commute testing.

This thread will cover all aspects of the Rush Hour commute engine, including (but not limited to) the pathfinding engine, travel speeds, and inter-city travel.

 

 

I will be maintaining and updating a report including all discoveries we have made once they are understood and corroborated.  Please click here to access this report.

 

Please have a realistic expectation for the 'new' pathfinding engine in Rush Hour.  It is obvious that they had to rewrite it, since it now includes morning and evening commutes.  However, it is unclear how many under the hood changes they made to the actual code.  MaxisFrank and MaxisKevin (producers of SimCity4) have both stated that the heuristic for the pathfinding engine was set where it is for performance reasons.  So don't expect perfect pathfinding.

 

I am thrilled that so many people are excited about exploring the commute engine in Rush Hour.  However, in order to keep this thread easily understandable and productive, I ask a few things from all valuable contributors to this project:

 

• Read the entire commute time and pathfinding report to familiarize yourself with some things we found about the original game, and enough of the travel time testing... thread to familiarize yourself with some of the testing methodology we found helpful.
  
  
• Review the current version of the  Rush Hour Commute Report so that we don't have to keep going back over issues that have been covered.  We will happily answer questions, but the reason for me keeping this report is so that most questions can be answered before they are asked .
  
  
• Post as clearly as possible, using cropped screenshots labeling what you are reffering to, text formatting, colors, and being as analytical as necissary to explain your findings.
  
  
• Be respectful to maxis.  They wrote the pathfinding engine and all the things about this game in the first place.  We are doing this in order to better understand what the mechanics of the game are, so that our community can in turn, create better cities.  Excess unfounded complaining will not get us anywhere closer to our goal.

 

Our Tasks:

These are the tasks we need to do, roughly in this order, since some of them are dependant on previous findings.  This list will be updated as we accomplish tasks and find new ones that we need to do.

• Verify travel speeds

The speeds in the original SimCity4 were the kph speeds in the dat file, divided by 10.  This was an attempt to account for the unrealistic situation where every sim works at the closest available job to thier home.  We need to verify what the new speeds are for all network types, and find out whether they are constant or variable, dependant on how far the sim has to travel, or other factors.

• Verify the route querry tool's authenticity and accuracy

  While I would love to jump in testing the pathfinding engine using the route querry tool, we cannot afford to assume anything.  Therefore, we must use the travel speeds we discovered in the first phase to verify whether the route querry tool tells us the routes that the sims are actually using or not.

• Study the effectiveness of the new pathfinding engine as compared to the old one

  This will be good to give us an impression of how much better the new pathfinding engine is, and what it strengths and weaknesses are.  It is very likely imperfect, since maxis had to make the game playable on the lowest system requirement of a 500MHz processor.

• Test interchanges for correct traffic flow

  I have seen some screenshots suggesting that sims cannot go either way on an avenue when they exit from a highway.  Even though visually, it does not look like the sims would be able to do so, in practice avenue/highway interchanges allow people to go both ways.  Also, some issues of sims being able to access diagonal highways without onramps and other things need to be addressed and fixed, if possible.

• Test inter-city commuting

  We should verify whether sims can or cannot travel through one city to work in another, empty or populated.  Also, we should verify how thier commute time is affected, whether it's a simple addition of the existing travel speeds, or whether inter-city travel speed is increased to allow for further regional commutes.

• Test Mass Transit usage requirements

  Ombedor did an outstanding experiment showing that as far as the pathfinding engine is concerned, the corners of the Mass Transit buildings are the only parts of the lot that does something, since with the old pathfinding engine, the sims entered the station from one network type, and exited on any network tile bordering that same tile of the Mass Transit building.  This needs to be verified and/or updated for Rush Hour.

• Verify Tile dimensions

This is rather minor, but it is still up to debate whether tiles are considered 16m or 15.625m, making 64 tiles equal to 1km.  Once we have travel speeds confirmed, this should be fairly easy to determine.

 

 

I think that just about does it.  If there are any new ideas, let me know and I'll add them to the list.  Right now I'm off to my neighborhood 24 hour wal-mart to hopefully pick up a copy of Rush Hour!

[the7trumpets 10]

Looking at the other thread, many of you have started drawing conclusions (and worries) using the route querry tool.  While I agree it is probably accurate, I feel uneasy using it for determinations of the pathfinding engine until we verify it's validity.  Here is my list so far of commute times per tile.  I started testing the one way roads, but they got a little weird (more later).

 

This is the methodology:

 

In this example, it would be a 6 tile commute, and a 5 step commute.  From the numbers I'm getting,  it looks like the steps are the same as in the original game, starting at the netwrok tile adjacent to the house, and ending at the network tile in front of the job.  For the other tests, the distance was simply increased.  There is a windmill above the screenshot providing power.

 

 

It should also be noted that the behavior observed previous to Rush Hour of the sims randomly switching between walking and driving if they were within 10 tiles simply did not happen, at least within 5 years.  I had to de-zone and rezone the residential lot in order to get times for driving and walking.  So, when the lot grows it still chooses whether to drive or walk, seemingly randomly, but it doesn't switch to different modes, like it did prior to Rush Hour.  Previously, this behavior was halted by usisng the pathfinding modd, and the sims always drove since it was faster.

 

I've been getting errors trying to post this, so I'll put the table in the next post and see if that helps.

[the7trumpets 10]

Here is the first half of the table:

 

one way		round trip		split steps		Minutes
tiles	steps	tiles	steps	AM	PM	walking	street	road	one way	avenue	freeway
1	0	2	0			0	x	x
		3	1
2	1	4	2			6	1	0
		5	3
3	2	6	4			13	2	1
		7	5
4	3	8	6	3	3	20	3	2	2
		8	6	4	2				3
		9	7
5	4	10	8			27	4	3
		11	9
6	5	12	10			34	5	3
		13	11
7	6	14	12			41	6	4
		15	13
8	7	16	14			48	7	5
		17	15
9	8	18	16			54	9	6
		19	17
10	9	20	18			61	10	6
		21	19
11	10	22	20				11	7
		23	21
12	11	24	22				12	8
		25	23
13	12	26	24				13	9
		27	25
14	13	28	26				14	10
		29	27
15	14	30	28				16	10
		31	29
16	15	32	30				17	11
		33	31
17	16	34	32				18	12
		35	33
18	17	36	34				19	13
		37	35
19	18	38	36				20	13
		39	37
20	19	40	38				21	14
		41	39
21	20	42	40				22	15
		43	41
22	21	44	42				24	16
		45	43
23	22	46	44				25	17
		47	45
24	23	48

[the7trumpets 10]

And, the second half:

 

 

one way		round trip		split steps		Minutes
tiles	steps	tiles	steps	AM	PM	walking	street	road	one way	avenue	freeway
31	30	62	60				34	23
		63	61
32	31	64	62				35	23
		65	63
33	32	66	64				36	24
		67	65
34	33	68	66				37	25
		69	67
35	34	70	68				38	26
		71	69
36	35	72	70				40	27
		73	71
37	36	74	72				41	27
		75	73
38	37	76	74				42	28
		77	75
39	38	78	76				43	29
		79	77
40	39	80	78				44	30
		81	79
41	40	82	80				45	30
		83	81
42	41	84	82				46	31
		85	83
43	42	86	84				48	32
		87	85
44	43	88	86				49	33
		89	87
45	44	90	88				50	34
		91	89
46	45	92	90				51	34
		93	91
47	46	94	92				52	35
		95	93
48	47	96	94				53	36
		97	95
49	48	98	96				54	37
		99	97
50	49	100	98				56	37
		101	99
51	50	102	100				57	38
61	60						68	47
71	70						80	54
81	80						91	61
101	100						102	69

[the7trumpets 10]

One Way roads are going to be a bit testy   Basically, you get different results depending on which way the commute is broken up AM/PM wise.  For the one that I included data on, the commute time was 2 minutes when it was broken up into 3 steps AM / 3 steps PM, and 3 minutes when it was 4 steps AM / 2 steps PM.

 

Also, in the shot below, it seems to suggest that the part of the pathfinding engine which determines whether there is a connection (no car zot) does not take walking into account:

 

The initial setup:  As you can see, the one way road is not connected back to the front of the sims' house.  This setup results in a no car zot.

 

   

The morning and evening commute paths using the route querry tool.  It shows that the sim is walking, and this is corroborated by the commute time being the same as with the 3 tile walking time of 13 minutes.

 

So, reguardless of whether the sim is going to, or can walk to work, they need to be able to drive to work.  Otherwise, the zone will develop, but get a no car zot immediately.

[Marc Collins 36]

We should verify whether sims can or cannot travel through one city to work in another, empty or populated. Also, we should verify how thier commute time is affected, whether it's a simple addition of the existing travel speeds, or whether inter-city travel speed is increased to allow for further regional commutes.

No one respects or values 7's work on pathfinding more than me!

I have little time to contribute to testing, but just by chance, the layout of cities in my pre-existing region allowed me to notice right away that sims were travelling from one city to another, through a third city (because it happpened to be a convenient, less congested route)--using MT and cars! You'll have to trust me (based on my prior contributions), but I am 100% confident that sims can not only travel through one city to work in another, but can pass through a second city on their way. They can do this using cars and buses.

I have also used a ferry between cities successfully, but those cities are adjacent to each other.

The biggest problem with RH in my view isn't the pathfinding any more, but the continued predilection for sims to work at the closest job to home. That is completely unrealistic and distorts the whole flow of traffic and transit and congestion by artificially reducing it by a factor of about 10! I realise it may be very difficult or too resource intensive to have sims finding jobs spread more randomly all over the place, but until they do, the whole area of pathfinding and commute time is operating in la-la land.

I also found remarkably little change occur after removing the perfect pathfinding mod and then installing RH and then operating my cities. This was certainly not the case in reverse, when I first started using the perfect pathfinding mod in SC4 the change was dramatic. It isn't perfect now, but the pathfinding (or the effect of the pathfinding combined with whatever other changes) in RH is significantly better than SC4. To charaterise it as unchanged, or just as bad (and it was bad before 7's mods), is very misleading I believe. But you guys will get to the bottom of the truth I have every confidence!

Marc

[ed_diaz 10]

woohoo! way to go 7th... keep it up. i gotta keep an eye out on this thread for sure .... cant wait for the mods

[DarkMatter 21]

"is obvious that they had to rewrite it, since it now includes morning and evening commutes."
- 7th

I have a hard time beleiving that statement. For several reasons, but largely because of what I experienced when I installed RH. My cities reverted from a traffic system that worked well with your fix to working EXACTLY as they did before your fix. It surprised the hell out of me, but I beleive its because of the fact that the pathfinding engine was not rewritten (which has been backed up by the statement that Maxis made about solving the rolling NJZ bug), but tweaked. I think its important that we keep in mind that things may not have been fully rewritten, and work toward finding what tweaks have been made.

There were always evening commutes, but they wern't as accurate as the morning commute. RH didn't add them, it simply improved them. What it looks like (testing will proove or disproove this) is that the return commute uses the same heuristic as tne morning commute now, rather than what seemed to be an adjusted commute heuristic before (one less accurate).

I also beleive that if Maxis truely wanted to invest in a full rewrite of the pathfinding engine, they would have done a better job. I have more confidence in them thah that. If this is truely a rewrite, I'm sadly surprised that the new engine offers results that are only slightly or no better than their previous engine. Based on what I've seen so far, were looking at a tweaked engine, with fewer bugs (i.e. no more rolling NJZ bug) than the previous version.

[DarkMatter 21]

Oh, forgot to ask. One of the things I'm VERY curious to know is if Maxis fixed the commute time x10 bug or not. That was one of the main bugs discovered before in the previous engine, and it would have been a major things fixed in the current version "rewrite", as 120 minute commute times in cities that have jobs within walking distance of every residence is something that needs to be addressed.

[Larsz 7]

I had hoped you would begin your own transportation thread! I don't have the patience for testing when RH is so new and exciting!

 

I didn't follow any testing rules, but I wanted to make some observations concerning pathfinding. I downloaded and plugged in DM's pathfinding mod, the "Better" pathfinding.

 

Here is a before shot using the Route Query:

 

And here is after a year:

 

Like I said before, I realize this isn't a controlled experiment and the route query may need to be verified but by my observations, the Pathfinding Mod worked. It wasn't a magic bullet but my commute time dropped about 10-15% and higher capacity networks were used more often.

 

I'll shut up now

 

 

 

[ed_diaz 10]

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

On 9/25/2003 11:33:08 PM Larsz wrote:

I had hoped you would begin your own transportation thread! I don't have the patience for testing when

RH

is so new and exciting!

 

I didn't follow any testing rules, but I wanted to make some observations concerning pathfinding. I downloaded and plugged in DM's pathfinding mod, the '

Better

' pathfinding.

 

Here is a before shot using the Route Query:

 

 

And here is after a year:

 

 

Like I said before, I realize this isn't a controlled experiment and the route query may need to be verified but by my observations, the Pathfinding Mod worked. It wasn't a magic bullet but my commute time dropped about 10-15% and higher capacity networks were used more often.

 

I'll shut up now

 

 

 

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

im happy they worked for you.. someone else DL the same mod and was saying nothign happen to his.. oh well.. i know for me it worked great!!!!.. sims took the "fastest" route first no matter what and thats what i like to see. cant wait for the full mod with changed speed limits... (more realistic speed limits of course)

[DarkMatter 21]

Another thing I wonder is wether the pathfinding engine takes into account congestion when it chooses a path. My guess is no, because testing congestion for each tile would take up too many cpu cycles, but its something we can test for anyway. Even if RH doesn't take congestion into account, we can formulate an optimal spec on how such a feature would ideally work in a future expansion (when faster computers are available....we have Intels Prescott comming out soon! *wooot!*) or a future version of the game.

[the7trumpets 10]

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

On 9/25/2003 11:16:58 PM DarkMatter wrote:'is obvious that they had to rewrite it, since it now includes morning and evening commutes.'

- 7th

I have a hard time beleiving that statement. For several reasons, but largely because of what I experienced when I installed

RH

. My cities reverted from a traffic system that worked well with your fix to working EXACTLY as they did before your fix. It surprised the hell out of me, but I beleive its because of the fact that the pathfinding engine was not rewritten (which has been backed up by the statement that Maxis made about solving the rolling NJZ bug), but tweaked. I think its important that we keep in mind that things

may not

have been fully rewritten, and work toward finding what tweaks have been made.

There were always evening commutes, but they wern't as accurate as the morning commute.

RH

didn't add them, it simply improved them. What it looks like (testing will proove or disproove this) is that the return commute uses the same heuristic as tne morning commute now, rather than what seemed to be an adjusted commute heuristic before (one less accurate).

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

Well, perhaps I was not specific enough.  Since the file formats for SC4Path files did not change (ie, the old ones were not rewritten too much), I doubt the entire engine was rewritten.  However, I would not be surprised in the least if the number of paths for roads, streets, rail, and subways were doubled by new sc4path files, or new info appended to old sc4path files.  Care to find out DM?  My hunch is that since maxisfrank said the old pathfinding engine should have 'flipped' the paths for walking, but it wasn't in one instance, that the old engine relied on this 'flipping' of paths for many of the networks.  With one way streets now, there must either be new sc4paths to cover the ones that would have been made by flipping, or a flag on paths for one way streets to tell the simulator not to flip them.  Perhaps this is the new value in the sc4path 1.2 spec.

 

Concerning your question about whether it takes into account congestion, even the old pathfinding engine did that.  It appeared to use speed limits after adjusted for congestion, potholes, and any other factors (toll booths?)  It just never worked with the stock heuristic.  I did some experiments and proved it, but I can't remember where they were posted.  However, I don't want to assume anything, so I will likely test this again with Rush Hour.

 

More testing to come shortly, I'm glad you guys are enjoying this, and thank you for your patience, I just want to make sure we're doing a full-proof job of it so we don't make wrong assumptions and come to wrong conclusions.

[ROBO1964 0]

Well things I have seen that are definately different:

1.)$$$ Sims will take the bus. I had a $$$ residential and had 46 people taking the bus and 23 using their car.

2.)Also people seem to be able to take their car to the bus or subway or elevated Rail station.

So they have made some substantial changes to the pathfinding but now 7trumpets can make it perfect.



Here is the screen of 2 people using their car to get to a bus stop.

[Ombedor 23]

Remember that bus stations normally provide two jobs.  The two people driving to the bus station are the two people that work there.  Anyone that wants to pick up a bus at the bus stop has to walk to the bus stop, or drive to a parking garage and then walk to the bus stop from there.

[DarkMatter 21]

"Concerning your question about whether it takes into account congestion, even the old pathfinding engine did that.  It appeared to use speed limits after adjusted for congestion, potholes, and any other factors (toll booths?)  It just never worked with the stock heuristic.  I did some experiments and proved it, but I can't remember where they were posted.  However, I don't want to assume anything, so I will likely test this again with Rush Hour."

 

Hmm...not sure were talking about the same thing. I think...think, heh....what your talking about is the traffic simulator took into account the increase in time due to congestion, potholes, stoplights/signs, etc. What I was talking about is weather the pathfinding engine actually takes the amount of congestion into consideration when BUILDING a path, or rather tracing a path from the destination to the source. I'm wondering if the path thats built after the algorithm reaches the destination will be not only the fastest in terms of allowed road capacity and travel speed on that road, but will also be on a road that has the lowest congestion possible while providing the fastest trip. Does any of that make sense?

 

The way it looks, I would have to say no, congestion isn't taken into account, because roads that are somewhat congested in a city with X sims only get more congested in a city with Y sims. What I would like to see, either in a future expantion or future game, is a pathfinding engine that does just that, take the amount of current congestion into account when building a path. Of course, if taking the congested route gets you to work the fastest regardless, take it. And I guess other factors should be included too. In real life, people will take congested routes to/from work even if its slow, simply because thats the route they take. Also, only a small percent, lets say 15% in SC4 terms, would actually be concientious enough to look for a faster route. To be realistic, such factors would need to be taken into account to realisticly implement alternate, less-congested paths, not to mention reduce cpu usage (only searching alternate paths for 15% is a lot quicker than searching alternates for everyone). Ok...I'm rambling....if you need me to clarify more, let me know.

[the7trumpets 10]

Sorry DM, I did mean that the pathfinding algorithm takes congestion, and any other speed limit altering thing (potholes, toll booths) into account when calculating the fastest path.  However, you cannot observe this without changing the heuristic value, since the sims usually use the most direct route no matter how much slower (and more congested) it is.  Basically the pathfinding engine uses transit speeds AFTER they have been adjusted by other factors (congestion, potholes, toll booths).

 

Hope that makes sense, but as I said before, I'll test this again for rush hour, so hopefully it will be more clear then.

[DarkMatter 21]

So if a road is congested above its limit, and 6 tiles away is a road thats not congested, the pathfinding engine will take that into account and use the less-congested road?

[the7trumpets 10]

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

On 9/26/2003 2:58:47 AM DarkMatter wrote:

So if a road is congested above its limit, and 6 tiles away is a road thats not congested, the pathfinding engine will take that into account and use the less-congested road?

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

Yes.  It will find the fastest path, according to the road speeds that have been changed by congestion and/or other factors as opposed to assuming a normal uncongested speed limit all the time.

[edit] It will only find the fastest path if the heuristic is changed.  With the stock value of the heuristic, this is not always true (and almost never true) [/edit]

[Ombedor 23]

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

On 9/26/2003 2:58:47 AM DarkMatter wrote:

So if a road is congested above its limit, and 6 tiles away is a road thats not congested, the pathfinding engine will take that into account and use the less-congested road?

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

I happen to have a test city perfectly suited to testing this, and I've been working on putting together some screen shots over the last few mintues.  Look for something soon.  What I'm finding is very interesting.

[DarkMatter 21]

Ah...ok. Even with a fixed heuristic in RH, using 0.0028, the sims still don't seem to find less-congested routes all the time. Maybe taking the congested route is faster, but there were a couple roads on one of my maps that were hardly used at all, and went right into the heart of a main commerce area. Two other roads were used heavily and in the red, but this one was green. I worry about lowering the heuristic any lower, because performance is becomming adversely affected.

 

Looking forward to your findings Ombedor.

[Ombedor 23]

Ok, as promissed.

 

Here is the setup:

 

This city is designed to grow fast.  It has a bunch of medium density residential on the left and industry on the right.  The grid network is entirely roads so that there won't be any congestion in either of the two zoned sections.  The two connectors, however, are lowly streets and all the traffic must use one of the two to get to work.  Furthermore the top connector is guaranteed to be a longer path than the lower connector for all residents.  Like I said, this city was designed for exactly the test you are talking about DarkMatter.  If the engine always does shortest path then the top connector should never see any traffic.  If the7trumpets is right, then the top connector should start seeing traffic once the bottom one is too busy.

 

 

Now let's see what happens when we let the simulation run on an unmodded copy of RH.  Following are a sequence of images just showing the traffic on the two connectors at key moments as time progresses.

 

 

Initially all the traffic goes to the lower connector.  Note that even though we are below 100 cars on the street that we are already seeing a lot of orange on the congestion display.  I think that's because when you add in the evening commute there are really 190 trips crossing that street each day, which puts the street at 190% of capacity, making it run at about 68.5% of normal speed.

 

The next two pictures show that traffic will take the upper connector.  Both shots were taken while the game was paused at the same moment in time.

 

 

 

So, you get the idea of how I'm doing this test.  Rather than posting a ton of screenies, I'll just post a table showing the rest of my results as I let the city develop and the roads become more congested.

 

Lower usage / Upper usage

124 / 16

125 / 47

123 / 72

189 / 136

834 / 139

1366 / 138

2194 / 143

 

At this point it seems like the lower connector is taking all new traffic and the upper connector is stuck at around 140 vehicles for the morning commute, or 280 vehicles / day. If my theory about the congestion level being the sum of the morning and evening commute (which these tests seem to validate) is true, then the upper street is just slightly below the maximum congestion level of 300% at which point there are no further penalties to travel speed.  The lower connector is clearly way past saturation no matter how you count cars.

 

Even though traffic is moving slightly faster on the upper connecter, it is a slightly longer path.  So at the end the two paths were probably about equal in terms of travel time, but travel distance seems to take over at that point and all additional traffic takes the more direct route.

 

Summary (for an unmodified copy of RH):  Given two uncongested streets the shortest path was always taken.  Once the shortest path reached a high enough level of congestion to affect travel time, new traffic took the less congested alternative.  However, once both streets reached the saturation point (the point where additional traffic no longer affects travel time), all additional traffic took the shortest route.

 

[the7trumpets 10]

Great test ombedor!

 

Looking at your screenshots, the lower path is at 21 steps, and the upper path is at 29 steps.  From this, we can do some math and glean quite a bit of information as to the effectiveness of the stock RH pathfinding engine in this situation.  I'm pretty sure your observation of congestion equalling both morning and evening (or morning doubled) is correct.  The testing I've done so far corroborates this, but I'll do some more formal testing and submit it.

 

 

The Math: (please bear with me)

 

Case A (there is a linear function between the speed limit reduction points defined in the traffic exemplar)

 

248 cars = 248% congested.

65-30 = 35 (percent speed reduction between 200% and 300% congestion)

35 * 0.48 = 16.8 (percent speed reduction lower than 65%)

65-16.8 = 48.2% speed reduction

 

21 steps on a road (looking at the above table) = 24 minutes

24 minutes / 0.482 [speed reduction coefficient] = 49.79 minutes

 

So, the Case A commute time for the lower path at 124 cars AM commute is 49.79 minutes.

 

 

Case B (the speed limit reduction is flat until it reaches the next datapoint in the exemplar)

65% speed reduction from traffic exemplar

24 minutes / 0.65 [speed reduction coefficient] = 36.92 minutes

 

So, the Case B commute time for the lower path at 124 cars AM commute is 36.92 minutes.

 

Upper path:

16 cars = 32% congested, no speed reduction.

29 step street commute = 32 minutes.

 

 

So, if Case A is true, the pathfinding engine is starting to get the clue, but not very much.  If case B is the way it is, it's very close, but still not quite there.

 

I'm drawing a blank on how to test whether the speed reduction is a stairstep type reduction (case B) or a linear reduction, with straight lines between data points (case A).  If anyone has any ideas, or can't understand me, let me know.

 

 

Ombedor - could you re-run the test with the heuristic set very low?  Perhaps abou 0.0009, just to make sure it will find the best path?  If you need me to, I can send you a plugin, or maybe just use DM's temporary mod on the mod page.  This should give us a clue of which case (A or B) it is.

[Ombedor 23]

A few things t7t.

 

First, I'm pretty sure that congestion is not just the morning commute doubled, but actually morning + evening, which makes a difference when the two commutes use different paths.

 

Second, just to clarify, the extra 8 tiles in the upper connector were roads in my test, so that will affect your speed calculation.  Since they are roads, however, they never became congested.

 

Third, yes I can do more tests on this with the heuristic set low.  I set the heuristic to zero.  Basically the behavior is similar, but the top connector starts getting traffic sooner and the distribution more even.  Here are a few data points.

 

Lower / Upper

7 / 0

48 / 0

73 / 8

88 / 66

90 / 71

123 / 119

146 / 139

176 / 143

240 / 143

528 / 143

844 / 150

1154 / 146

1724 / 167

2037 / 144

[Starky 0]

Hey hey all!
First off, let me say that as a member here, I truelly appreciate all the hard work and hours that everyone puts in to make SC4 and RH more enjoyable. And this is not a critisism but a question about the testing done by Ombedor. Looking at your pics, the top road and the bottom road have the same intersection (that gets congested). Would it be more valid to use two streets that did not share an intersection? I know this is a minor point, but from my experiences (certainly not as broad or large as others posting here), I typically try to keep seperate routes on seperate intersections. Again, thanks for all your time and efforts.


Edit :: OK, looking again, I dont see the intersections as congested. I guess this is because the intersections are roads while the streets are....streets! My bad...

Hasta!
Stark Out!

[qbert2 9]

I setup a test city to see how the congestion was calculated.

http://hick.org/~qbert/sc4/congestion>Pictures

Picture 1 shows residential only connected to the place of work via one-way roads. This forces the sims to use the long street as the only way home. There are roads going perpendicular to the one-ways because I needed them to help the zones develop but do not allow for the sims to travel back.

Picture 2 shows the morning commute using the route query tool.
Picture 3 shows the evening commute using the route query tool.
Picture 4 shows the commute time.

Picture 5 is displaying the congestion for the Morning commute.
Picture 6 is displaying the congestion for the Evening commute.
It appears that congestion is the same regardless of which option you select but I

[+Guest]

Larsz, I am surprised the Sim's in your test took the avenue, as it has lots of intersections which would slow traffic.

[disk_error 38]

One thing I have noticed about the commute sim is it takes way to long for the sims to get places. I played the large city tutorial and got it up to 40k, not one single place had a short commute. 90% of all places had a long commute, and I am getting lots of abandoment becuase of it. I saw a medium commute (very rare) the sim only drove 6 tiles! This in my opinion is way out of whack.

 

[ed_diaz 10]

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

On 9/26/2003 4:43:20 PM disk_error wrote:

One thing I have noticed about the commute sim is it takes way to long for the sims to get places. I played the large city tutorial and got it up to 40k, not one single place had a short commute. 90% of all places had a long commute, and I am getting lots of abandoment becuase of it. I saw a medium commute (very rare) the sim only drove 6 tiles! This in my opinion is way out of whack.

 

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

maybe the street he was taking had lots of traffic thus extending his "commute time" thus getting medium commute.. theres a difference between actual commute time and the distance sims work.. for example a sim could work 12 tiles away..but could still have a long commute if it takes the sims long to get there (high traffic, lots of intersections etc..) .. just wanted to mention that, thanx

[ed_diaz 10]

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

On 9/26/2003 3:09:11 PM qbert2 wrote:I setup a test city to see how the congestion was calculated. 

Pictures

Picture 1 shows residential only connected to the place of work via one-way roads.  This forces the sims to use the long street as the only way home.  There are roads going perpendicular to the one-ways because I needed them to help the zones develop but do not allow for the sims to travel back.

Picture 2 shows the morning commute using the route query tool.

Picture 3 shows the evening commute using the route query tool.

Picture 4 shows the commute time.

Picture 5 is displaying the congestion for the Morning commute.

Picture 6 is displaying the congestion for the Evening commute.

It appears that congestion is the same regardless of which option you select but I