new traffic experiments

[ldog]

Ok, so picking up where I left off last night.

As it became clear even to me, I wasn't making much sense by the end.

A little more about what I mean by "scale". 
To paraphrase Mott "even though the map scale is 16m per tile, the rest of the games engines are still using SC3K scale" I am still trying to understand all the implications of that statement, because there are many. One of the scales is population density.

I am cite an old post made by David Edgren, who no doubt is familiar to everyone here.
http://www.simtropolis.com/forum/messageview.cfm?catid=36&threadid=74819&STARTPAGE=33&FTVAR_FORUMVIEWTMP=Linear#941626
Scroll down past all the pretty pictures to the charts. This was all very interesting to me.
The numbers may be right or wrong, but this was all part of the design theory that led to the 3RR as we know it.
I don't know the game well enough to know if these are realistic figures for vanilla or not. I suspect many of you, even those who have been around a long time really don't know anymore either. The CAM, tons of downloaded buildings that have widely varying capacities, job mods, etc. The figures become very skewed.

Part of my play and design philosophy very closely follows Davids early on. At some point though, David realized that he had to scale out the region to much larger proportions to achieve what he wanted with it. Now I don't know about the rest of you but considering that the 3RR is such a huge project that it has its own section here I think everyone would agree it was a huge success. As I said early on, I personally think it is one of the most beautiful maps I have ever seen (one that my experiments with a 1/4 reduction does not do justice to).

Now the scaling out is also a turning point in philosophy. Obviously I am not questioning Davids decisions. I also am not looking to strictly adhere to and mimic what other people have done. This is not done for the sake of a "3RR what if" In the end I just take what I like and go with it. For myself, for my own play, scaling out the region is not a viable option. It is just too large for my personal preferences, so instead I must look in a different direction. If I am unwilling to scale the map out, then I must scale the game down. I don't need the CAM I need...the TAM! The Tiny addon mod. There is no such mod though.

That also brings up another major mod point. Your play strategy is going to vary greatly if you have the CAM installed or not. Now other than the fact that I don't want to make the population denser or the buildings larger, there are a great many other things I like about the CAM. Ripplejet is a prime example of one of the many great innovators in this community. As mentioned earlier I have remade pieces of the CAM for my own use, and since that discussion with Jason about it also installed some pieces of it as is. I won't ever be putting in the large buildings though.

So one of the fundamental design decisions for me is that the traffic simulator can completely break at a population density that can't be achieved under the conditions for which it is intended. I expect it to work as designed, with populations from 100 to...we are going to take David's figure of 400k for now. I really need to go and decide what that number should be. To me a great map is about half "waste"...water and mountain. So that affects my figures. Also I should still allow for the possibility that it should function as designed even when stressed to the limit  (we have a large tile with no unbuildable terrain).

This of course does not discount intercity commuters by any means either. As I said I don't want a bias for commuters from all over the region. I am not all that impressed with the regional play. That being said I am not trying to eliminate it. So our networks must be able to handle a "reasonable" amount of inter-city commuters as well. Reasonable of course by my own definition. I admit I have not figured that out yet either.

Now sure you should be able to exceed these limits, and it may work, but I would expect you to have to have an unsustainable network. So if some masochist wanted to use it with the CAM they would have a treasury that would bleed money.

[ldog]

I am going to transition from scale into realism a bit now.

One of the other things about the scale of the city map vs the scale of the rest of the game engines and how that stacks up against realism, is that as many others have shown (again I will refer the reader to the original 3RR CJ at Simtropolis, starting around page 31...I am sorry I don't have the patience right now to wait for Simtropolis database so not gonna link)

David through overlaying some real world maps onto game maps shows us one of the fundamental flaws in the scale that don't allow us to achieve reality. We build transit systems that are far "larger than life" in the game, because we have to. Also even though in general the 4k large map is still too small to realisticly have all kinds of highways crisscrossing it and every form of MT; what fun would it be if we didn't have a need for it. So because of design flaws in the game our map has been shot to hell. We of course again have to make tradeoffs between reality, fun and what the game engine is capable of.

Now one of my little issues with reality and MT. To anyone who has rode MT in NYC, a few things are clear about overcapacity. Some people say how can you operate the road, rail, etc at over 100% capacity anyway? I will not bore y'all with a dissertation on the general real world applications of capacity and overcapacity. So strictly speaking about MT...to the average NYer, most of the buses, subways and indeed the LIRR are packed well over design capacity during rushhour. Indeed we have often been packed into cars like sardines standing on each others toes. God forbid someone farts! This is overcapacity as it relates to MT.

Yet it does not cause congestion on the network to any appreciable degree (well...leave the buses out for the moment). Sure the trains may run off schedule a bit (mmmk, yah, like they ever run on time anyway ). The higher volume of people getting on and off means the train stays in the station a bit longer as we override the doors. The amount of trains we run also varies by time of day. We put more trains at shorter intervals during rushhour, but theoreticly (there is an engineer out there reading this no doubt who is going to tell me how wrong I am, I can feel it) it doesn't add to network congestion in the SC4 way. It would if we added too many trains, so therefore we would have to slow them all down, but I have not observed this as a passenger. When the train is actually moving as best I can ascertain it still goes the same speed it goes at rush hour or at 3AM. Now forgetting all the more complicated things, because we know the traffic simulator is far too simple an engine to handle things like schedules, extra trains, long stops. These extra things also wouldn't really add more fun to the game if they were exposed to us, just more work. Also the traffic engine basicly ONLY runs at rush hour. It simulates a commute to work (in fact as we've found it doesn't really even simulate a commute back home, it cheats!)

So one of the things I want to try that I haven't seen done is making the MT (non bus) run at a consistent speed throughout. I think I can scale back capacitys and still achieve game balance. So that el may be at 400% capacity, but it is still going to run at the same speed. So it doesn't need as high a capacity as the roads do to be in balance. Of course now I am have to adjust other parts of the system to compensate for these changes, so we still get the right balance of cars vs buses vs mt. For the people who would just say "well fine, go turn off affected by traffic and try it" it isn't just that simple. I am not going to get valid results with just that simple change. I've learned that much so far. For the people (probably Steve  ) that would say "it is an awful lot of work to go through for something that in the end probably will make no noticeable difference"...you are probably right lol. I want to try anyway. Who knows what I will find. Maybe I will find it does not work but it will give us all some new insight into MT.

I have more ideas of course but I think I have gone on enough for one day.

[ldog]

Actually...  You are right the Simulator runs a route once, but it does the whole round-trip not only the "to work" portion.  This is why the Max Commute Time pertains to the whole round-trip.  A proof of this would be if you used an avenue or a OWR.  The Sim will travel from work in the morning using the right side of the Avenue, but on the return trip home he will then use the left side of the avenue to return (a completely different tile and therefore route).

In other situations, I have had some really strange trips in some of my commute testing in the past... One that comes to mind I thought was actually really interesting.  I had a highway, overloaded it as much as I could and when I did, I added a train line.  The trains at either end allowed for car to train and train to car transit switches.  One thing I observed was Sims travelling to work using the highway, but then using the trains on the way home going from work to the train station by car, then using the train (I guess driving onto it like you can on the TGV between London and Paris), then leaving the second train station in their cars back home.  That was the first time I ever noticed such an event in commuting.  And it wasn't just one Sim doing it it was a lot of them.

Ok, so now I am confused again. That experiment on the omnibus showed that the route is only calculated to, then we just take that time and double it, to simulate the trip back home. There has to be a valid route back home (the highway only allowed us to get to work, we had to go another way home) but it still doubled the highway time. You could make some crazy ass route with streets for the return trip and it didn't effect the commute time. Meaning the engine assumed it was going to take exactly the same amount of time to get home as it took to get to work, regardless of the actual route.

As I said in my reply to Catty, being as this was all pre-RH I thought surely they must have changed this. I ran that little test myself. I even used owr for part of it. My little test got the same results as the original test. If you query a building of course it doesn't show the roundtrip. It only shows the morning. From playing I somehow was under the impression that depending which volume view (morning or evening) you had selected it would show the routes either way from the building query, but in the little city of 10 people it clearly didn't. So that's what I meant when I said the engine cheats.

Are you saying ignore all that and just go off the volume graphs?

The only thing I have to say about this, I'd have to go back a look at the Simulator file again, but the problem I am questioning is, if the Traffic type is unaffected by traffic then how is the game limiting the capacity?  The CvS curve is essentially the thing that limits Capacity on a network by diminishing the Speed on a give route and eventually when it reaches the 30% Speed threshold, prevents any other Sims from travelling that route.  This is why Buses are a "cheat" because they ignore capacity completely.

I thought somewhere around 400% capacity no matter what other factors the network gets saturated? That was one of my assumptions.
The other thing though is since the train (I'm going to just say train when I mean: rail, sub/el, mono) networks are the fastest, they are already priviliged by the pathfinder. So we can use the other methods to take some of that away and still have them run as desired. I think...I am still trying to work out the details of course
So if that key assumption above is wrong, I think it may still be possible to achieve the desired effect. Of course it might not matter either way, might just result in everyone and their mother riding the train. Or no one at all riding the train.

The other reason I feel we have some "play" in achieving this again comes down to gameplay style. MT is expensive. In general a city doesn't add a MT system just because they want one. They often don't add one when they need it. It often has to wait until they REALLY need it. Of course by the time they get it, it is generally inadequate because they need more. And so it gets expanded. But once again the expansion doesn't keep up with the growth. And so we either wind up with an inadequate system that takes some pressure off the network or we (in rare cases) wind up with a system that works almost perfect but then costs a tremendous amount to maintain. I know this is still a somewhat simplistic view (some professional city planner is laughing his ass off right now).

The bus is a bit different isn't it? It doesn't add to congestion but it is still effected by it.
Oh...yah...I see what you are saying. You can add all the buses you want to an already overpacked road.
The thing is the bus is still going to be slowed down by the congestion so it will also become a less desireable route.
Well, like I said, we can only attain so much realism before either A: it is no longer fun or B: things break horribly
I have some ideas about that as well. I think there is some range where the bus preference can be tuned to "keep it real homie". Somewhere in some combination of the bus speed, travel strategy and starting trip cost. Again it is more theory than anything at this point.

The car is the slowest form of transport. It is least favored (well, besides walking) by the pathfinding engine. Especially once congestion starts taking hold. So the things we have to do to encourage more realistic car use are actually pretty heavy handed when you think about it. I think that creates the leeway to screw around with the MT more.

[catty]

As I said in my reply to Catty, being as this was all pre-RH I thought surely they must have changed this. I ran that little test myself. I even used owr for part of it. My little test got the same results as the original test. If you query a building of course it doesn't show the roundtrip. It only shows the morning. From playing I somehow was under the impression that depending which volume view (morning or evening) you had selected it would show the routes either way from the building query, but in the little city of 10 people it clearly didn't. So that's what I meant when I said the engine cheats.

The game it turns out generates a query.txt file in the Program files/Maxis every time you query something, this contains a lot more information than the "query", I've found it very useful information to have, especially when testing 

for details on how it works see the query.txt topic here

http://sc4devotion.com/forums/index.php?topic=8870.0

[ldog]

The game it turns out generates a query.txt file in the Program files/Maxis every time you query something, this contains a lot more information than the "query", I've found it very useful information to have, especially when testing 

for details on how it works see the query.txt topic here

http://sc4devotion.com/forums/index.php?topic=8870.0

Wow thanks again Catty. 

[z]

If you query a building of course it doesn't show the roundtrip. It only shows the morning. From playing I somehow was under the impression that depending which volume view (morning or evening) you had selected it would show the routes either way from the building query, but in the little city of 10 people it clearly didn't. So that's what I meant when I said the engine cheats.

Actually, it just acts in a confusing manner.  You're right in that the query tool doesn't always show the same commute period as the volume view.  But you can see the evening commute; there's a little pair of radio buttons at the bottom of the query tool legend in the upper right of your screen that lets you select the commute period.

The fact that the volume view and the query tool can be out of synch is definitely a poor design.  But you can still get the evening commute data.

[ldog]

Actually, it just acts in a confusing manner.  You're right in that the query tool doesn't always show the same commute period as the volume view.  But you can see the evening commute; there's a little pair of radio buttons at the bottom of the query tool legend in the upper right of your screen that lets you select the commute period.

The fact that the volume view and the query tool can be out of synch is definitely a poor design.  But you can still get the evening commute data.

Uhhhhhhh...ok...so lemme see if I get this straight.

So basicly between what you and Jason are saying. Plus what I've usually observed in game which also contradicts that other test (even though it was done in game as well).

The volume view is the only way to see the evening commute.
The volume view because I only had like 10 residents in that very limited test just wasn't enough to show me anything. Odd though that I could see the freight trucks from just a 2x2 ind-d.

Even still can't ever really trust anything the game shows because all the graphs and views besides being generally inaccurate are also buggy

It's these little things that are generally irrelevant when playing that make modding such a joy sometimes 

Things that you thought you saw when you were playing you realize you didn't really see when you are testing.

The wife wants me to watch a movie with her so it'll have to wait until later.

[z]

The volume view is the only way to see the evening commute.

No; when using the Route Query Tool, clicking the Evening Commute button under its legend will show you its data for the evening commute, which of course is a different type of data from the volume view's.

Even still can't ever really trust anything the game shows because all the graphs and views besides being generally inaccurate are also buggy

I have found the volume data view info and the route query tool info to be quite reliable.  The congestion data view is fairly reliable, but not completely.

[I haven't read everything as it was posted, so I'm just getting to some of this.]

The CvS curve is essentially the thing that limits Capacity on a network by diminishing the Speed on a give route and eventually when it reaches the 30% Speed threshold, prevents any other Sims from travelling that route.

What was actually found by experiment was that 30% was the lowest speed that could be used in the CvS curve without triggering the congestion display bug.  However, it does not prevent any other Sims from travelling that route; the lower speed just makes other routes more attractive to the pathfinder, and the extent of this is determined by the pathfinding heuristic.  If you run Simulator Z Classic in a large city, you can see that routes can be made to carry arbitrarily high amounts of traffic, even after they reach the 30% speed threshold.

[ldog]

No; when using the Route Query Tool, clicking the Evening Commute button under its legend will show you its data for the evening commute, which of course is a different type of data from the volume view's.

I have found the volume data view info and the route query tool info to be quite reliable.  The congestion data view is fairly reliable, but not completely.

The evening commute butto...  *looks up in right corner* ... ...  ... ...  ...

    ...

I knew about this. I did really. I've used it in game. This is of course why I thought I recalled being able to see both directions.
I don't know how I forgot this. Ok, so they did change some things.

The commute time being the same? Display bug then or it is just doubling the morning trip instead of adding the actual morning and evening trip?

I did just go back in and verify with roads and a highway by placing and bulldozing the highway ramps at different times to force different routes during each period.
I can confirm that the commute time is based off the morning. Whatever change I make to the evening route makes no time difference. It doesn't matter if it is slower or faster.
I'm sorry if this is something one of you went over as well, the first time I noticed this was in that Omnibus article Catty linked.

I obviously need to slow myself down because now it isn't even about not knowing things, it is about being stuck on stupid.

[I haven't read everything as it was posted, so I'm just getting to some of this.]

What was actually found by experiment was that 30% was the lowest speed that could be used in the CvS curve without triggering the congestion display bug.  However, it does not prevent any other Sims from travelling that route; the lower speed just makes other routes more attractive to the pathfinder, and the extent of this is determined by the pathfinding heuristic.  If you run Simulator Z Classic in a large city, you can see that routes can be made to carry arbitrarily high amounts of traffic, even after they reach the 30% speed threshold.

So there isn't any hard cap then. Hrmmm.  So maybe there is some tuning that will make my MT idea work, but not as much wiggle room as I had initially hoped.
I would have to arbitrarily make the car more attractive, without it killing MT use altogether. And then they are just gonna prefer whichever MT method is closest and fastest. Come to think of it what was wrong with Monorail in vanilla again?  This probably isn't going to work.

[ldog]

In other situations, I have had some really strange trips in some of my commute testing in the past... One that comes to mind I thought was actually really interesting.  I had a highway, overloaded it as much as I could and when I did, I added a train line.  The trains at either end allowed for car to train and train to car transit switches.  One thing I observed was Sims travelling to work using the highway, but then using the trains on the way home going from work to the train station by car, then using the train (I guess driving onto it like you can on the TGV between London and Paris), then leaving the second train station in their cars back home.  That was the first time I ever noticed such an event in commuting.  And it wasn't just one Sim doing it it was a lot of them.

You know I had to read this a second time to catch this for some reason.
That is pretty incredible. I didn't think the game engine allowed it.
Cool.

[z]

The evening commute butto...  *looks up in right corner* ... ...  ... ...  ...

    ...

I knew about this. I did really. I've used it in game. This is of course why I thought I recalled being able to see both directions.

Don't feel too bad about this.  I did the exact same thing.  It's basically a poorly designed interface.

The commute time being the same? Display bug then or it is just doubling the morning trip instead of adding the actual morning and evening trip?

I'm not quite sure what you're referring to, but the route query tool will often give the same numbers for morning and evening commute, simply because they often are the same.  (That confused me for a while.)  But they are often different too.

I did just go back in and verify with roads and a highway by placing and bulldozing the highway ramps at different times to force different routes during each period.
I can confirm that the commute time is based off the morning. Whatever change I make to the evening route makes no time difference. It doesn't matter if it is slower or faster.

Again, I'm not completely sure of your reference, but the game is designed to calculate commute times only for the morning commute.  For the evening commute, all that is necessary is that there be some valid route from the Sim's job to his or her home; the length of the route is irrelevant.

And now to answer a question of Jason's:

The only thing I have to say about this, I'd have to go back a look at the Simulator file again, but the problem I am questioning is, if the Traffic type is unaffected by traffic then how is the game limiting the capacity?

It doesn't.  Travel types that are unaffected by traffic effectively have unlimited capacity; their nominal network capacity is meaningless.

And going back through to the previous post...

For the people (probably Steve  ) that would say "it is an awful lot of work to go through for something that in the end probably will make no noticeable difference"...you are probably right lol.

Oh, I would never say that!    In fact, I went through much the same line of reasoning as you did when I came up with the final rail capacity numbers for Simulator Z, as discussed in this post:

But what about the rail numbers?...  Look at what the nature of congestion is for car traffic versus something like subway traffic.  With car traffic at rush hour, the more cars you put on the road, the slower everybody goes.  This is reflected in the Congestion vs. Speed curve.  Yet for subways, the more people you have traveling by subway, the more crowded the subway cars get.  But they don't go any slower.  If you have huge crowds of people waiting for a subway train, it may take a few seconds longer to get on and off at stops.  But while the subway train is traveling, which it spends most of its time doing, it always travels at the same speed, regardless of the time of day, which is totally unlike cars.  So the effect of traffic volume on speed is quite different with rails than with road traffic.  This is reflected in the relative capacities of the two types of transportation.  For example, the new Second Avenue Subway in New York City is designed for a daily capacity of 600,000 people.  Meanwhile, directly above the subway line is Second Avenue itself, a four lane, one way avenue.  According to the quote above [in the original thread], this avenue will carry about 1000 cars/lane/hour, or 4000 cars per hour.  But in rush hour, it's going to carry a lot less, as traffic barely creeps along in Manhattan during rush hour.  So the subways (as well as the other rails) can carry vastly more traffic than the roads, especially during rush hour...  And if anything, my rail numbers should be even higher than they are to be realistic.  But once again, realism has to be balanced with what works for SC4, which means that these numbers should be low enough to give some challenge.

In fact, in rush hour, it may take more than a few seconds longer for people to get on and off trains.  Trains spend more time in the station; the average train speed is reduced.  With really bad congestion, trains are sometimes so packed that you can't get on the current one and have to wait for the next, again increasing commute time.

So there is a form of congestion affecting rails that reduces speed; it's simply far less than that for cars or buses.  I took this into account by increasing the ratio of rail capacities to that of other network capacities.

[ldog]

Again, I'm not completely sure of your reference, but the game is designed to calculate commute times only for the morning commute.  For the evening commute, all that is necessary is that there be some valid route from the Sim's job to his or her home; the length of the route is irrelevant.

I was saying I had just verified this myself
This was new information to me, somehow it had not managed to come up in our discussion.

[ldog]

So taking above discussion into consideration.
It is highly doubtful my original course of action for MT would provide the desired effect.

Looking at another approach, let me put the congestion back on the trains, and then do what Steve has done and make the capacity higher.
Ok, so how do I keep the overall use still within a lower limit than the figure we have to use for capacity?
Stations? I know y'all have said they are buggy as hell, but still the station does at some point have an absolute capacity.
So if I stuck with lower station capacity then I should be able to get the same effect?

Or is that where the bugs come in. Does the pathfinder not know that the station can't accept anymore people and just keep trying to route through it anyway?

That is something I think I can verify with testing at this point so off to play I go.

[catty]

Or is that where the bugs come in. Does the pathfinder not know that the station can't accept anymore people and just keep trying to route through it anyway?

That is something I think I can verify with testing at this point so off to play I go.

Look forward to your test results, this is something that came up in RTMT testing and it will be interesting to see if you get the same/similar results to us or even more interesting something completely different 

quote from Z

As I mentioned earlier, it appears that all stations have a fixed limit that is a multiple of their capacity; this multiple has been observed to be as low as four, but has also been observed to be higher than that.  In this case, it appears to be a little over six - the first time I've seen it as a nonintegral value.  But it means that once approximately 68,000 Sims have passed through the station, it will accept no more for the rest of the day.

Cathy

[b22rian]

Hello Idog, 

    Just wanted to introduce myself..
My name is Brian, and I have done a lot of testing for Steve with past versions
of Sim Z..  Ive followed this from where it started back in the sim Z development thread.
and now with the creation of this new thread here.. You have certainly generated a lot of
interesting discussion here which can only benefit those interested and who chose to read this..
I just wanted to offer my encouragement to you in what you are undertaking here...
You certainly have 2 of the best teachers the game has ever seen in the area of traffic
research in Jason and Steve...

thanks, Brian

[ldog]

Look forward to your test results, this is something that came up in RTMT testing and it will be interesting to see if you get the same/similar results to us or even more interesting something completely different 

quote from Z

Cathy

*pokes his head out of the game*
It might be a few days lol. Been building all day. Haven't even taken it off of pause yet. And still not even half done building.
It would probably help if I didn't start building a city from scratch every time I redefine the test parameters but I don't trust my data when I switch engines midstream, because of little things like we saw earlier in the discussion. As I get better at this I hopefully won't feel the need to do this every time.

Thanks for that bit of info about the stations. I seem to remember reading that, but as I think if I have proven anything so far it is how absent-minded I am.
I really appreciate all the help you've given me.

Hello Brian, thanks for the words of encouragement. Nice to meet ya

Evenin' Jason

What did I come out here for again? Oh yeah, rock texture replacement.
*back into game* 

[ldog]

So to clear up some of what was posted around when I got all flustered since I realized I was an idiot and forgot where the morning/evening commute button was...
In regards to one of the links Cathy provided: http://www.simtropolis.com/omnibus/index.cfm/Main.SimCity_4.Commute_Time_and_Pathfinding_Report

I went ahead and reran that test. I don't know if this is all well known stuff or not, it is very relevant for someone just starting into the traffic simulator.
I'm sure Steve and Jason understand this well but I still wasn't clear what I was trying to say above. Sorry no pictures (posting from work), but I will refer to the pictures in the Omnibus.

Even though this was pre-RH it intrigued me.
So looking at section 2, figures b & c we can see that our total commute time =(morning commute x 2). It does not matter if our route home is shorter, longer or the exact same length. The game is going to assume as long as we have a valid route home (see figure d) that it only takes the exact same amount of time to get home as it took to get to work. Now never having played pre-RH I don't know but I believe there was no route query tool correct? So we could only guess what routes sims were taking but we couldn't actually see like we can now.

So I ran the same series of tests myself. Posted. Realized I am an idiot (I get that astonishing revelation a lot, and yet it never ceases to amaze me  ). Ran the tests again.
We all know the commute time graph is buggy. Steve and Jason know it very well. I admit I am still trying to figure out some of the finer points of just how buggy it is.

So as much as we can trust what the commute graph tells us, I also verified that changing the evening route does not affect the commute time.
Taking the highway both ways, I had X minutes (we know the number is wrong but I am going by the position of the line on the graph). Demolishing the ramps allowing us to take the highway home and forcing using roads, streets, etc. The commute time was still X minutes. Forcing traffic to go the other way, rebuilding those ramps and demoing the ramps that led to work, resulted in the commute time going up to Y minutes. I played around with it in various other ways and still the results were the same, only changes to the morning commute route made any difference in the total commute. Using the route query tool (once Steve reminded me where the mode button was  almost done beating myself up for this I promise) I was able to verify that they indeed do take the evening trip on the other road, but it doesn't seem that the time is ever calculated for that route. The pathfinder assumes it is just going to take the same amount of time it took you to get out in the morning.

Now I don't know if this is just one of the afore-mentioned commute graph display bugs or if it is the way the game actually does figure out how long it took. I am assuming Jason and Steve are well aware of this based on above discussions but I just want to make sure I've got it straight now. My questions in above posts and therefore the answers given were not so directly to the point.

[ldog]

Mini-update on testing.
I of course got bored and had to let the game run a bit last night.
Still nowhere near done filling the tile out.
I let it run about 2 years. Population reached 15k. I've got a good mix of highway with avenues and roads feeding in, streets on the blocks and some heavy rail. Nothing else at the moment.
No congestion of course as the network is designed for a much larger city than we have grown to. I am seeing a lot of no job zots though which I thought was odd.

Commute time shows around 40 minutes, which I thought was odd too. I don't have out of towners so I thought the numbers were supposed to be somewhat accurate still.
I used a multiplier of 1 so I thought I should get 1 to 1 for my commute time units. Obviously this is not the case since my max commute is 24. Also as there is no congestion whatsoever and we are cruising at network speed x 1.3 I don't see why the commute time would be long.

Now the internal documentation doesn't make a lot of sense on it. I can't remember it offhand well enough to quote it. As is common, it is an 8-bit register, and that is why we see that number we see so often in the computer world mentioned, 255 (count 0 as a number and we get 256).  At first I thought what was meant was that it would go up to 255 minutes. So one could divide 255 by their max commute time and use that number as a multiplier. That doesn't seem to work. I thought let me just take it as the raw number and leave it at 1. That doesn't seem to work either.

[b22rian]

Hi Lenny ...

             Just finished reading your last post here and this is great work and testing you have done here..
and I had no idea about the finding you have found about commute times.. Obviously we can wait for replies
from either Steve or jason to verify one way or the other whether as you said ..if this is yet another bug having
to do with the "commute time graph". or if you feel bored while your waiting, I have idea you can try or I may
even try it.. if I get tired of waiting for one of their replies  

         Ok here is my idea...
Im sure you are aware that a regular Query on any occupied building will quantify how long commutes are..
So the 3 categories are short , medium and long, and i suppose if you want to call abandonment caused by
commute time , the 4 th category thats fine.. Anyways what you can do is first verify a shorter route with a
typical out and back commute to and from work using the same routing .. ( i would chose a route that is
relatively longer which would be close to falling into the medium commute category..).. than in the way you
were doing in your testing I would than force a different return route.. My idea here is to force a super long
return route.. And than you would than check with a query to see if this changes the route description to
either medium or long .. I think meanwhile since i have some very large cities to look at with some quite complex
routes .. i know many of them have different and longer return trips from work because I recall seeing them..
Ill simply check some of them and see how the length of trip is quantified.. ( short, medium or long..) ?
Obviously the drawback to this would be if the regular query is bugged in terms of quantifying the length of
commutes..

If we dont either from either jason or Steve for awhile, perhaps ill post again  ,

Thanks brian

[RippleJet]

I used a multiplier of 1 so I thought I should get 1 to 1 for my commute time units.

If you by that mean the property Trip Length to Minutes Display Multiplier,
then I believe several tests have shown that it isn't used at all.
Whatever value you give it, the multiplier stays at 25.