Problem with Commuters

[z]

Ahh but this would be two destination/path processes. As we've discussed before once the path exits the city tile it was "successful". The path to the 3rd city was a whole different destination/path process totally unrelated to the first.

I don't understand your conclusion; to me, the situation I described seems completely analogous to the tollbooth situation, but with a long looping route replacing the tollbooth.  Could you please explain what you're saying in a little more detail?

From what I've seen in a couple of my cities, the destination finder works from the west to the east,
probably picking the tracts (which are 4×4 tiles) in consequtive order, starting in the northwest corner,
going down south, and then up to the next column of tracts.

That's fascinating; from your pictures and description, the effect is quite evident.  But from your two examples, it would seem that an equally plausible explanation is that the pathfinder starts with the most distant sources and works inward.  This would make sense, as one of the things you want to do is minimize commute time, and giving the most distant sources the first shot at the destinations would help do that.  Does this make sense to you?  If so, it would certainly be easy to design a test to see which one of these explanations is correct.

If I'm not mistaken, this might have some implications on e.g. sumwonyuno's Capitalis,
where, if I recall correctly, the main stretch of cities was west to east.

As I mentioned in one post, the main problem with his intercity traffic seemed to be that one city hadn't been run in too long a time; once I ran it for a few years, everything was normal.  Having played with his cities quite a bit directly, I can't say that I saw any evidence of a west to east functioning of the destination finder.  In his Downtown city, when I bulldozed a large swath of his residences, they actually filled back in from east to west.

[RippleJet]

But from your two examples, it would seem that an equally plausible explanation is that the pathfinder starts with the most distant sources and works inward.

In the first example the unemployment started in the southeast corner,
which is farthest away from the commercial and industrial districts.

This would make sense, as one of the things you want to do is minimize commute time, and giving the most distant sources the first shot at the destinations would help do that.  Does this make sense to you?  If so, it would certainly be easy to design a test to see which one of these explanations is correct.

It wasn't difficult to test that in Dublin.
Instead of building a seaport at the eastern shoreline, I built a package loading central in the west,
between the industrial and commercial district (the green area under the route query).

The six consequtive images below show how the port upgraded twice,
and how cargo found its way to it starting, once again, in the west:

As I mentioned in one post, the main problem with his intercity traffic seemed to be that one city hadn't been run in too long a time; once I ran it for a few years, everything was normal.  Having played with his cities quite a bit directly, I can't say that I saw any evidence of a west to east functioning of the destination finder.  In his Downtown city, when I bulldozed a large swath of his residences, they actually filled back in from east to west.

This is of course easy to show in Dublin, where I suddeny cut off all neighbour connections.
Thus all freight from every industry lost their destinations, and had to find them anew.

It won't be as apparent in a "normal" city where growth happens all across the area.

To test the same in a residential district, would mean that you'd need to
disconnect all connections going to wherever the sims used to work.

Then let them all become unemployed, before reconnecting the routes,
but only a few at a time, so that all sims cannot get employed at once.

In such a case I'm pretty sure those living in the west would be employed first.

[SC4BOY]

I don't understand your conclusion; to me, the situation I described seems completely analogous to the tollbooth situation, but with a long looping route replacing the tollbooth.  Could you please explain what you're saying in a little more detail?

The tollbooth is an internal event and therefore is handled by the "destination/route" process totally. Once the "commuter" leaves the city it is never considered again. If by some circuitous route it is eventually re-entered into the city at another point after having "traveled through" another city, the given city is completely oblivious to the "delay" caused by the route. As we all know this is part of a state, not a "flow"... not to mention that of course a "commuter loop" can't even exist until you exit, and re-enter only after going through the affected cities and operated their individual simulations to establish the traffic pattern. The game is completely oblivious to (though heavily affected by) the commuter "loop" (by that I mean the game in no way attaches an identity to the "commuter" and "sees" him re-enter)

[xxdita]

Ahh but this would be two destination/path processes. As we've discussed before once the path exits the city tile it was "successful". The path to the 3rd city was a whole different destination/path process totally unrelated to the first.

Actually you just clarified what I was trying to write, but since it's already typed up anyway:
Once a Sim leaves one tile, the path ends at that neighbor connection, and he is deemed gainfully employed, since there is no true regional simulator or regional traffic simulator involved in this game. Upon entering the second tile, the sim now becomes a factor in a new traffic simulator.

And whether the Destination Finder runs West to East or furthest to closest, possibly even by Wealth level, the point is that the Destination Finder runs in cycles, just as the traffic simulator itself. Now. when the destination finder is actually ran I can't say yet; every cycle of the traffic simulator? Or maybe only as new growth is detected, ie new destinations. Or maybe as new paths are created, roads upgraded, mass transit added, etc. My instincts tell me it's ran before the traffic sim (pathfinder) every cycle, but I'm also wondering if they aren't simultaneous. At the very least, I think the destination finder has to take into account the Maximum Commute Time to some degree.

The tollbooth is an internal event and therefore is handled by the "destination/route" process totally. Once the "commuter" leaves the city it is never considered again. If by some circuitous route it is eventually re-entered into the city at another point after having "traveled through" another city, the given city is completely oblivious to the "delay" caused by the route. As we all know this is part of a state, not a "flow"... not to mention that of course a "commuter loop" can't even exist until you exit, and re-enter only after going through the affected cities and operated their individual simulations to establish the traffic pattern. The game is completely oblivious to (though heavily affected by) the commuter "loop" (by that I mean the game in no way attaches an identity to the "commuter" and "sees" him re-enter)

Absolutely. One tile couldn't care less about where a Sim travels to once it leaves it's borders. Which is why it can be dangerous to use a traffic sim that has excess speeds or commute times, allowing more commuters than there really should be. I don't think that the traffic sim's capacities have any impact on Neighbor Connections though, at least none that I've seen yet.
A tollbothh like we've discussed should effectively prevent Sims from even attempting to go back into the tile they've just come from though, even with another neighbor connection very close by, as they would be charged the commute time of having gone across the entire tile.

[sumwonyuno]

RippleJet, I have no idea what's the signficance of that name for a city tile (in post #19). 

z has answered your theory as it relates to East Capitalis.

Not to prejudge the testing, but wouldn't the traffic simulator start at (0,0)?  In the game, (0, #, 0) : (x, y, z) is at the northwest corner of the city tile.  Y doesn't matter, as it's the elevation of a particular tile.  In increasing value, the z coordinate is west to east, and the x coordinate is north to south.  So there could be some merit in RippleJet's observation.

As for z's observation in demolishing neighborhoods, it could be more of a desirabililty thing.  I have lots of experience in demolishing my neighborhoods.  They almost certainly do not rebuild in a strictly west to east, or north to south fashion.  I think desirability is more of an important factor.

[EDIT]:  I had thought that maybe in newly developed cities (not connected to any other city tiles), development patterns may give us a clue.  I just did a few tests, and development patterns seem to be randomized to a certain extent.  I can't draw any definite conclusions.

[RippleJet]

In increasing value, the z coordinate is west to east, and the x coordinate is north to south.

Almost... X increases from west to east, Z increases from north to south.

They almost certainly do not rebuild in a strictly west to east, or north to south fashion.  I think desirability is more of an important factor.

[EDIT]:  I had thought that maybe in newly developed cities (not connected to any other city tiles), development patterns may give us a clue.  I just did a few tests, and development patterns seem to be randomized to a certain extent.  I can't draw any definite conclusions.

It's not the development that is going west to east... it's the destination finder and path finder.


Regarding the development order, I pretty much agree with what the Prima guide states.
Demand and desirability are the two most important factors:

On any given day, the simulation follows a series of steps to determine where and what to develop.

1. Choose Developer Type
The simulation begins by choosing a developer type. The process is not random, as developer types with high demand are more likely to be chosen. To be eligible for selection, the developer type must have positive demand.

2. Rank by Desirability
The simulation ranks appropriately zoned tracts (R, C, or I) in order of desirability to the chosen developer type. If the chosen developer type was Cs§§, all C-zoned tracts would be ranked by their desirability to Cs§§. To qualify, a tract must have a desirability of at least 50. (My note: the size of a tract is 4×4 tiles).

3. Try to Build
When a tract is chosen, several issues arise, any of which could cause the simulator to give up on the chosen tract and try the next one on its list. These include:

Zone Compatibility
You can't build a Residential building on a Commercial lot, but a chosen tract could have among its 16 tiles more than one zone type. If nothing can be built on the tiles of the correct zone type, the tract is not developed.

Displacement of Current Residents
In SimCity 4, the development system is geared around maximizing usage of existing structures. This can mean looking to move the chosen developer type into already inhabited buildings on the selected tract before building new ones.
If a chosen tract contains an occupant of a given wealth level, the current occupants can be supplanted only if the chosen developer type is wealthier.

Road and Job Access
Every lot must have access to a Road or Street before it can be developed. Residential Sims have an additional requirement, they must be able to use those Roads to get to a job.

Reoccupy Vacated Buildings
The simulator tries to re-inhibit abandoned buildings rather than demolishing them and building something new or starting fresh in an empty lot.

Choose an Appropriately Sized Lot
Within a tract, the simulator chooses the best lot for the chosen developer type. If necessary, it will redraw the dimensions of the lot to be larger (aggregation) or smaller (subdivision). In some cases, a superceded house (or houses) will be demolished to make way for larger or smaller lots.

Choose the Building Size - Stage Limits
In this phase the stage limits come into play.
The current population dictates which building stage will be constructed. The simulator selects the largest size (ie. growth stage, my note) permitted under the stage limit. This choice is guided by the stage proportions, as the correct balance between sizes must be maintained. For example, if there are already the maximum percentage of Stage 3 houses and not enough Stage 2, a Stage 2 building will be developed.
In the case of redevelopment, an existing structure won't be demolished unless it can be replaced by a higher stage building. You cannot change a building to another building of the same stage. There is one exception, however: If the new building is to be a wealthier developer type, then demolition can occur.

Stage Caps
We have a location selected and we have a building. The only thing standing between us and development are the stage caps. If one of them trumps the selected building, a lower stage alternative must be found or the tract will be rejeceted.
Slope issues and the water and power supply are considered at this point. If the tract is permitted by the stage caps to build at the chosen stage, construction can begin.
If for example, the chosen building is a Stage 4 Residential building, the tract must have water service. If any of the applicable stage caps prevent development, the simulator moves on to the next tract on its list and we begin again.

[ldog]

To commute or not to commute, that is the question!
Wasn't that Shakespeare?

I guess I should have been keeping a closer eye on this thread.

Do want to clarify, I believe the tollbooths do have an effect on the route chosen by the freight; it is just the freight is always going to "commute" because there is no other destination for it.

I think once the choice is made then the pathfinder will route to the particular city according to normal rules; so high delay tollbooths make MT more attractive.
You would have to put some form of tollbooth on all the MT connections as well, but the problem is I don't think it will affect the choice to commute or not to commute.

I think it has been generally accepted that the destination chooser is part of the traffic simulator and runs as the first step. Although I suppose it is entirely possible that it is not.
At any rate, the destination must be chosen before the pathfinder can run, since to generate a path it requires a destination.

I'll do some tests after dinner.

[RippleJet]

I think it has been generally accepted that the destination chooser is part of the traffic simulator and runs as the first step. Although I suppose it is entirely possible that it is not.
At any rate, the destination must be chosen before the pathfinder can run, since to generate a path it requires a destination.

I would agree and even claim that the destination finder and path finder (if they are separate) are run at (or almost at) the same time.

I've checked Dublin's savegame file and looked for roughly half the lots (not commercials though, they do not have commute paths).

Let me first bring back the structure from the savegame on how the commute paths are saved:

For whatever it's worth... when we tried to cure the prop pox earlier this year, we decoded parts of the savegame format (SC4 files).
The commute path for each lot is saved in the end of the Lot Subfile (Type ID = 0x09BD5D4A), with the following structure:

DWORD	Count of Commute Blocks  (number of destinations commuted to from here)
DWORD	Count of Commute Paths  (usually 0x00000002 = morning and evening, 0x00000001 for freight)
DWORD	Count of Bytes in the Path
BYTES	Commute Path  (1
DWORD	Number of Commuters
BYTE	Unknown, 0x00 or 0x03
BYTE	Unknown, 0x00, 0x01 or 0x02
BYTE	Unknown, 0x08, 0x09, 0x0A or 0x0B  (0x00 if the commute path has disappeared)
BYTE	Unknown, 0x00 or 0x03  (0x04 if the commute path has disappeared)
SINT16	Commute Destination, X Tile  (2
SINT16	Commute Destination, Z Tile  (2
FLOAT32	Trip Length
DWORD	Unknown  (3

1)
Structure of Commute Paths:

BYTE	Starting Traffic Type  (see below)
BYTE	Path Start Tile X (network in front of the lot)
BYTE	Path Start Tile Z (network in front of the lot)
	Commute legs, repeated for each transit switch
BYTE	Transit Switch 0x4T  (T = Traffic type, see below)
BYTE	Length of Path (Count of quads)
QUAD	Path Direction  (0 = West, 1 = North, 2 = East, 3=South)
QUADS	00b  (repeated 0, 1, 2 or 3 times, in order to fill the last BYTE)

Traffic types are in the same order as in the Traffic Simulator:

• 0x00 = Walk
• 0x01 = Car
• 0x02 = Bus
• 0x03 = Passenger Train
• 0x04 = Freight Truck
• 0x05 = Freight Train
• 0x06 = Subway
• 0x07 = Light Rail
• 0x08 = Monorail

2)
Destination Tile

A job located in a neighbouring city has the XZ coordinate of the border crossing.

• A job located in the western neighbour has an X coordinate of -1 (0xFFFF)
• A job located in the northern neighbour has a Z coordinate of -1 (0xFFFF)
• A job located in the eastern neighbour has an X coordinate of 64 (0x0040), 128 (0x0080) or 256 (0x0100), depending on the size of the city
• A job located in the southern neighbour has a Z coordinate of 64 (0x0040), 128 (0x0080) or 256 (0x0100), depending on the size of the city

If the commute path has disappeared (e.g. work demolished or redeveloping), the X coordinate becomes 0xDFA8 (-8,280).


3)
Unknown

For residentials; often 2, but I've also seen e.g. 9 and 11. Always 16 for industrials.
If the commute path has disappeared (e.g. work demolished or redeveloping), this DWORD becomes 0x0012FC70.

Dublin was saved when the first industries had started to find the newly plopped seaport.
In addition to this, there were quite a lot of unemployed houses.

Thus, there were lots of residentials and industries not having a commute path.
Count of Commute Path was still = 2, but the Count of Bytes in Path was = 0.

However, I did not find a single lot that had a valid destination, but did not have a commute path.

If there would have been a significant time difference between the run of the destination finder and the path finder,
some of the lots should have been saved having a destination, but still no path.
At least that's my logic...

Whenever the commute path was missing:

• the Commute Destination's X Tile was always 0xDFA8
• the Commute Destination's Z Tile always had a valid number, probably remaining from before the path was lost
• the DWORD indicating Number of Commuters was not reset to 0, even if there was no path
• the FLOAT32 indicating Trip Length was always reset to 0.00
• the third unknown BYTE was always 0, and the fourth unknown BYTE was always 4
• the last DWORD was always 0x0012FC70 if the commute path was missing

This would also indicate that if the commute path is broken, the old destination it not saved.

Note that this is not the same as what happens when you bulldoze a road.
The commute path can still exist in the savegame, even if the road is gone.

It's only on the next round of the destination/path finder that the path either becomes invalid or is replaced by another one.

[z]

I would agree and even claim that the destination finder and path finder (if they are separate) are run at (or almost at) the same time.

Yes, this makes sense.  From a programming point of view, I would say that the destination finder is run first for all necessary destinations, and then the pathfinder.  But if you save the game in the middle of this process, you still won't see any destinations without paths, because essentially you have a finite state machine in between states at that point.  So the latest completed state is saved, and any progress toward the next state is thrown away.

You can actually see some evidence for this when the game is run.  I'm sure you're aware of the way the game slows down every few months when run on Cheetah speed; this is when the traffic simulator runs.  If you save the game at this point, and then restart it, it doesn't restart in the slowed state; instead, it restarts at maximum speed.  The reason for this is that the partially completed completed computations, which left the game between states, have been thrown away.  This ensures that the game is always saved in a consistent state.

[ldog]

  Really interesting stuff there.
I may have to start poking through savegame files myself (and I thought it wasn't possible I could spend less time in the actual game itself)

So...   ... oh yeah. Tollbooths. My current tollbooths actually have a TSEC of 0.32 so they are even worse than defaults. After removing them from the connections between Gridlock and East Gridlock truck use went up and train use went down significantly. Freight paths shifted themselves around accordingly.

I didn't notice a large difference in my sim commuters but then this was just a quick dirty check not a well-controlled test. My industry is much closer to the edges and/or seaports so it is easier to observe. The residential areas are a bit further in so there are more factors in play on their pathing; rail use for them was still very high, although the highway and ave congestion seemed to have darkened a few shades and the freight truck volume alone isn't enough to account for it. So I think we can influence which connection is used with transit switches once the decision to commute is made but not the decision itself.

[z]

One more point about the way destination finding and pathfinding are done:  If you observe the traffic volume view when the game is running at high speed, you'll notice that all the paths switch simultaneously during traffic simulator runs.  Clearly, they aren't all computed simultaneously.  Instead, this would seem to be the point at which all computations are finished, and the new state is declared complete.

[xxdita]

Or does it just mean that the traffic volume view is only updated so often?

[ldog]

Or does it just mean that the traffic volume view is only updated so often?

Well it wouldn't make sense to update it at any other time except after the end of a traffic simulator run.
So determine destinations, then find routes, then update data views and graphs.
If you watch your graphs constantly you can see exactly when it runs; at least if you made any kind of major change, then it is very clear as the line moves very sharply to the next point.

[z]

I agree completely with Lenny here.

[jplumbley]

Well... I've been hiding for a while.

This discussion has morphed from something relating to Extrapolation to something that relates to inter-city commuting and how the destination finder works.

I'm going to state that, we all know full well there is no regional simulator, for any of those outside of this discussion who are unaware.  And we all know there is a big problem when we get into an Eternal Commuter Circle.  I'm sure this has occurred to others as well, but maybe not every one.  You don't need an Eternal Commuter Circle for traffic commuting to effect Demand in your regions.

We all know the reason the "ECC"s cause your Residential Demand to tank since the jobs have all been taken from the "ECC"s.  But, by the same token if you have one Sim travelling from one city through another to a third that Sim is not taking up only 1 job, he is taking 2 jobs.  One for the city tile he is travelling through and one for the third tile where he finds his final destination.  It should be obvious, but for those unaware reading this thread it means that for all the Sims travelling multiple city tiles in your region they are effecting the demands in your region.  Effectively, it will diminish your Residential demands from what they truly should be.

I knew this was a problem back when I created Simulator A, and is a big reason I calculated the Max Commute Time for a large City tile and stuck to that value.  It restricts the distance so that a Sim will more likely choose a destination inside the City rather than a neighbor connection...  Of course that is also dependant on the design of your City and it's networks.  At the time, I knew that the Simulator somehow had to choose a destination before calculating the route but I didn't know much about it.  Nor does it matter all that much since I cannot effect it beyond possibly limiting how far away it will look for a destination.

Steve in his experiments seems to have shown that the PH value not only dictates how accurate the pathfinder is in finding the quickest path, but it also seems to have some relevance to how far away the Sim will look for a job.  I don't know if there truly is a relationship but I would assume that there is a relationship between the PH and the Max Commute Time that dictates to the "destination finder" how far away it can look.  In this situation, it would make sense that if the Max Commute Time being smaller and the PH being higher will at least act as some sort of limiter on how far the "destination finder" will look.

I don't know of any way we can limit neighboring cities from effecting the demands, maybe Tage knows more about that?

But we all know, and we should take into consideration the effect of multiple City travellers.  Not only the Eternal Commuter Circles.  If lowering Max Commute and raising PH a bit will help, then I think that is the right thing to do to prevent Sims from travelling multiple cities.  Maybe, modified "toll booths" will help, but I am not convinced the destination finder will not pick the neighbor connection and ignore the "toll booth" until after the Simulator runs the route.  In either case, we would then be relying on the end user to be knowledgable enough to (read these threads and remembered) place the "toll booth" at neighbor connections.  If we could limit or even prevent this using the Traffic Simulator in some way, I think it would be prudent of us to do so.  I know I tried with my work on Simulator A.

[ldog]

Well... I've been hiding for a while.

Welcome back to the discussions.

This discussion has morphed from something relating to Extrapolation to something that relates to inter-city commuting and how the destination finder works.

That is has. But then when can we ever stick to 1 topic in 1 thread?
Still, they all seem to be related to each other.

But we all know, and we should take into consideration the effect of multiple City travellers.  Not only the Eternal Commuter Circles.  If lowering Max Commute and raising PH a bit will help, then I think that is the right thing to do to prevent Sims from travelling multiple cities.  Maybe, modified "toll booths" will help, but I am not convinced the destination finder will not pick the neighbor connection and ignore the "toll booth" until after the Simulator runs the route.  In either case, we would then be relying on the end user to be knowledgable enough to (read these threads and remembered) place the "toll booth" at neighbor connections.  If we could limit or even prevent this using the Traffic Simulator in some way, I think it would be prudent of us to do so.  I know I tried with my work on Simulator A.

Not quoting all of your post since it is long, and I don't have much to add about external commuters since the rest of you have much more experience and knowledge about them than I do. It does sound logical and is definitly something to consider. Inter-city commuting is currently kicking my ass.

As far as the tollbooths idea; it doesn't look like it will work. Of course I haven't tried cranking the TSEC way up like Nate suggested. I'll give it a whirl tomorrow. Probably cause massive abandonment/redevelopment flapping  Wonder if it will make all my freight trips long too or if they will all start flooding the ports.
Good times! 

[xxdita]

You could always alter the truck speed to compensate, if necessary.

[jplumbley]

As far as the tollbooths idea; it doesn't look like it will work. Of course I haven't tried cranking the TSEC way up like Nate suggested. I'll give it a whirl tomorrow.

I really don't think it will work...  Simply because the destination has to be chosen first, and if the neighbor connection is the destination there is only one way there, through that toll booth.  But, I could be wrong hence the "maybe"... LOL.

Welcome back to the discussions.

Back to hiding now....

[SC4BOY]

A tollbooth like we've discussed should effectively prevent Sims from even attempting to go back into the tile they've just come from though, even with another neighbor connection very close by...

I don't believe under ANY circumstance will a sim re-enter the same city tile that he just left. I've never seen it happen anyways. They always must enter at least one more city before it will return to the "originating" city. I'm not sure what property prevents this other than some "entry test" that must be used before sending to another destination.. Perhaps it is even stopped by the "no reverse" element of the transit algorithm.