Does this mod exist: Fill all jobs in current city before commuting to neighbour

[Ben1220 1]

I've been getting frustrated with having to structure my networks in unnatural ways in order to force sims traveling from city A to B to take jobs in B instead of heading express to C simply because the path to C is slightly quicker than taking a job in B.  I was wondering if anyone has ever edited / there is a way to edit the traffic sim in order to force sims to take a job in the city they're in if one is reachable, and THEN use neighbor connections for those sims who can't find jobs in the current city. 

Another idea that might be even better:  Would it be possible to add a constant to the distance for all sims using neighbour connections?  The constant could be customizable, chosen by the player (perhaps different for each map) or perhaps a reasonable "average" of what you'd expect the travel time in the next city from the border to a job.  This could be as simple as using different values of the constant for different map sizes and connection types (road, rail, pedestrian ect) This would make the simulation a lot more realistic and only requires a very small amount of extra computation from a theoretical CompSci point of view.  I know it's a very hacky solution and there would be heaps of situations where it doesn't fix the problem but I think it's a good compromise between what we have now where the border itself is considered an endpoint, and running shortest paths between the cities (which I know is probably impossible since the game doesn't know much about neighboring cities while they're not loaded) also given that the latter would be computationally very difficult. 

Both of these tweaks could also "fix" the eternal commuter bug, or at the very least they would minimize eternal commuters to only be "remainder" sims who can't find jobs in the current city.  The first idea of forcing sims to take jobs in their cities as a priority could cause some unnatural behavior though, with sims near a border doubling back and traveling to the other corner of the current tile map instead of stepping over the border, thats why I like the second solution better since, if a suitable constant was chosen, this problem could be minimized.    

I hope I explained my ideas clearly!  I assume that if this were possible to do someone would have already done it or maybe there's an issue with this I'm not thinking of that makes it worse than what we have now, but I thought I'd share the idea anyway just in case. 

[CorinaMarie 29,857]

I can't say that the Network Addon Mod for Windows INSTALLER Version 34 will solve this, but whether or not you have it installed will prolly be one of the first questions the experts will ask since it improves on the path finding of Maxis's traffic simulator. The reason I can't say if it'll help for your situation is that I'd just installed it and got it tweaked to my liking for a single city tile when the Vanilla Only Challenge came up. So, I'm running modless atm.

[rsc204 21,857]

I suspect that the problem here pretty much defines the eternal commuter bug. Bug is always a subjective word though, it suggests an error or fault.

When sims cross a border, the details that the simulator would usually know about them, is no longer available. It's little more than a total of the sims coming in from any given connection.

Now if you think of just the directly connected cities, in theory that could be a large tile, with 16 small tiles surrounding it. If the simulator had to calculate all the commute data from 17 cities at once, it would likely just fall over. Now that's before you take into account that for this to work, not only would a city need to know about every connected cities commuters. But also about every available job from the cities the commuters in that tile might want to travel to.

Then in order for a semblance of actual region play, i.e. for sims to work more than one tile away, it quickly becomes obvious every city would need to know about every other city for this to work. I.e. the traffic simulator would now become based on the entire region in one go, not just one city. Obviously this is not viable, I'm guessing a trade off was made.

Since the simulator is always looking for the quickest path to a job, exiting the city again is often the logical commute choice. If you didn't make sims look for the nearest job, well things would be chaos, likely it would break the game.

As soon as you start to add in code that takes the wider region into account, you'll break the simulator. You could say the programmers coded themselves into a hole, but I think pragmatically, there wasn't really a whole load of better solutions to the problem. On one side, the simulator can't make better decisions without knowing (crunching) more data. But on the other, computers simply didn't (and still don't) have the power to handle all the required data to simulate it.

7 hours ago, Ben1220 said:

Would it be possible to add a constant to the distance for all sims using neighbour connections?

The equivalent in the traffic simulator is probably the allowable commute time. But messing with this to reduce possible commute times would likely only result in no job zots. Sims don't suddenly rush for a job when the time is nearly up, either they find a job within this timeframe, or they are considered unemployed. Of course, since the simulator only knows sims have left your tile and there are jobs somewhere in the region. Once they've left a city, you may not get no job zots. Even if in reality those sims would never reach a job in time, or any job at all. Just as the incoming commuters are just a number, so is the data the city has about jobs outside of it's borders.

Even if you could make it work as you describe, how could you account for different size tiles? There are a lot of variables to fill in here. Once more though, the game would have no way of reading such a value (the remaining time) when sims hop over a border. So we're back again and having to make the simulator calculate at a region level, which simply isn't going to work.

[APSMS 1,893]

@Ben1220
Reading thoroughly the history of the development of simulator Z (the traffic simulator that comes in the NAM), there are two main side effects of having a low Max Trip Commute Time.

The first, most noticeable effect, is that your game will run significantly slower the lower the Max Commute Time is, especially if you are coming from using the NAM. This is because the Destination finder is only able to consider jobs that it thinks will be able to reach in time, and the Pathfinder must work harder to find routes which are valid given the time constraints, which means that the Pathfinder may have to run more loops in order to find a suitable path to work for a given Sim under shorter commute rules. A longer commute allows the Pathfinder to use the first route that works, meaning that each Sim's commute calculations take less time overall, and the Traffic Simulator runs significantly faster because the demands on it are lower (consider that people don't always take the most efficient route in real life).

The second effect you will notice is that Sims will be less likely to commute out of the city with lower Max Commutes, but will still do so if the jobs in the city are not sufficiently close. In a downtown city with lots of subways, Sims near the outer edge may be inclined to seek jobs at the city center, but road oriented cities may find more Sims commuting to the neighboring tile, because their Max Commute won't (according to the destination finder) allow them to travel across town in heavy traffic, but it will let them reach the next city without issue. In this case, you may be forced to have Sims commute to the city center before being allowed to travel out of the city, but this may still not solve your problems because the Destination finder works before, and independently of the Pathfinder (which chooses how Sims get to their jobs), meaning that the Destination finder doesn't know how the Sims will get to their jobs, just that the jobs in question are most likely to be reached under the time limit, so you may not get Sims being employed in the city center, but you might also get abandonment due to commute time, because the Pathfinder determines that the chosen job (outside the city) cannot be reached within the time constraints, and thus the Sim is left jobless.

If you really do want to go down that path, much testing will be needed, and may still not produce satisfactory results. You can try to make toll booths (or similar) to make routes out of your city less attractive, but as noted above, this may not factor into the Destination Finder (job finder) and you may get the same situation anyways.

See this page at SC4Devotion, for some more in-depth discussion, and some detailed tests and workings of the Traffic Simulator, and how this may all affect your game.

[Ben1220 1]

Thanks for the responses, 

Thanks for the link to the forum post I'm finding it very interesting, also thanks about pointing out the max commute time, I will try experimenting with this value and see what I can find out. 

I'm not sure if you guys 100 percent understand the solution I'm proposing though, since it hasn't really been directly addressed.  Sorry about that!
I'll try to explain it better but it might need me to use images to explain properly. 

I'm proposing adding a constant value to all (potential) journeys transferring from one city to another in order to discourage sims being overly keen to leave their current city, while still allowing them to do so when available jobs in their current city are sufficiently far away for it to make sense to commute to the neighboring tile.  Basically, it makes them "guess" how far they'll have to go in the next city to find a job, instead of assuming they'll find one the second they step over the boundary which is what they do now, causing a lot of the unnatural behavior we see.  From what I know about the traffic simulator, this fix would have to come in at the level of the destination finder, not the pathfinder since its the choice of jobs that we're trying to change (or more accurately, choice to leave the city for a job), not the actual shortest path once a job has been found.  See here for more details: http://www.wiki.sc4devotion.com/index.php?title=Tutorial:Understanding_the_Traffic_Simulator

Since this would be a global city wide constant (well, more precisely a different one for each neighbor connection, so a moderately low number of constants calculated per map, depending on how many connections you have) It does not require the destination finder to know anything additionally about neighboring tiles, it doesn't require the simulator to calculate shortest paths region wide or across neighbor connections, which, I agree, would not be viable.  All it requires is a simple addition to be done to all "potential jobs" leaving the city in order to make them less appealing / less likely to come up as an actual shortest path by the algorithm in the current city.  Once you load up the second city the same process would apply, meaning sims who DO still chose to go from city A to B will now be under the same constraints in city B that they were in city A, making ridiculously long commutes that cross multiple map tiles when there are plenty of local jobs available less and less likely 

As for what this constant could be?

As I said you could deal with this either by letting the player pick their own value in the traffic simulator like they can pick their own value for max commute time, maybe a good start default intuitively could be

constant = distance from connection to center of neighbour map as the crow flies x speed of network time. 
The former can be calculated easily using simple Pythagoras theorem / 2 dimensional vector distance , for a small map for example it would be sqrt((32-x)^2+32^2) where x is either the vertical offset of the connection location from the bottom left or right corner in the case of east-west connections or the horizontal offset from the top left or bottom left corner in the case of north/south connections.  The latter values are already known to us. 

This would naturally mean that you'd end up adding a larger constant to connections entering large tiles than to medium or small times, since the distance to the center is larger, and you'd have to experiment a bit to see if this is an appropriate thing to do.  It might turn out that you do want larger constants for larger map tiles but you don't want them to scale up so quickly like in this basic solution, which I'd hazard a guess based on my intuition would probably be the case, since you'd be less likely to need to go all the way to the center of a large map to find a job than you would in a small map.  
Of course this is a very very rough estimate / hacky way of dealing with the problem but I think it's a very good compromise since it doesn't require the simulator to deal with any information about neighboring regions (apart from their tile size, which I assume it already knows since it would need to to know which parts of the edge are boundaries of which city) 

One possible downside to my suggestion is that it might cause situations where a sim isn't willing to cross the border to a job just on the other side of the border, and instead doubles back to a job a lot further away in their current city.  This problem is the opposite of the problem we have now where sims do not take reasonable jobs in their own city when their origin is near the border, yet possible jobs in the next city might actually be a long way away, and it's just a side effect of the lack of knowledge the destination finder has of the location of jobs in the neighboring cities, and there isn't much we can do about it.  My first idea of forcing sims to take all jobs in the current city before commuting to the next city would obviously be more likely to cause this problem, my second solution of adding a constant hopefully is a better compromise that minimizes both problems.  What my solution does allow us to do though is chose which side we want our sims to be biased towards -- leaving the current city or staying in the current city, depending on our choice of constant, or if we want to use this "fix" at all (we have to pick one unfortunately, without regionwide shortest paths) and theoretically with a very good value of the constant chosen, you could make the commuting behavior very natural and minimize ridiculous situations. 

Whether or not the problem of sims taking neighbor connections too liberally is more of an issue to you than the flipside problem that would be introduced by my solution by them taking neighbor connections too conservatively will depend on the specifics of how your city is set up, my solution would actually make things worse in some situations.  

Also I don't think this makes the game any easier in a bad way really, since it's just about minimizing dodgy "unnatural behavior" cases that often come up when you use approximation algorithms, which I think is a good thing.   

Let me finish with an example of the problem in case you're not clear about what I'm talking about:

In this city I have low wealth sims in the city to the east and medium wealth sims in the city to the west.
The sims in the subway are traveling east to west from the low wealth city towards the medium wealth city, through the CBD.  Many of them do leave the subway in the CBD but as you can see, many of them are still taking the subway through to the medium wealth city to the west, despite there being nearby jobs for them in the current city, this can be seen by the building I queried only being half full by medium wealth sims, coming in from the west, with none of its low wealth jobs being taken.  As you'd expect, I am having this problem more in the west side of the city, where the allure of that nearby neighbour connection is way too strong for my low wealth sims to resist.  Weighting that subway neighbour connection to the west as higher would deal with this problem by making my sims willing to more fully explore this city for jobs before they moved onto the next.     
 

[APSMS 1,893]

So, how many jobs are in the western city? How often do you play the cities in the tile? Recall that the more often you play all the cities involved, the more accurate the job numbers will become, so that less Sims are sent onward to the next city instead of stopping in the current city to find work.

No one addressed your proposal, mostly because it's generally assumed to be a hardcoded problem with the game, designed to encourage regional play (with all of the previously encountered side effects). The best way to approximate this behavior is via the Max Trip Commute Time parameter, because the Traffic Simulator defines all trips to the region as long, and therefore the least desirable; a shorter commute time would mean that this undesirability is not only reached sooner, but is being forced to deal with more directly because longer routes may violate the time limit for the commute. The Destination finder, with a shorter MTCT, is forced to find appropriate jobs, and if it can't find them, then you will get abandonment due to commute time; this would be an indicator that sufficient jobs are not available, since the Destination finder does search for local jobs first before outsourcing to SimNation.

What does your zoning look like? Assuming that you have sufficient demand, you should download the Census Repository Building (and Cogeo's relot). It's a great tool to determine your demand, capacity, and what your job and population picture is (things like commuters, and demand, and vacant housing and unemployment, incl wealth levels).

Notice, in the link I posted before, that the primary cause of commuters was a lack of appropriate jobs. Sims commuting into the city, and Sims living in the city were constantly trading spots (between working in the city and commuting to the next town over) because there were not enough jobs to be had. I know the query shows that half of the jobs available in that building were open, but unfortunately the simulator isn't always that simple (even though it should be, appears to be, and is supposed to be). What happens, for instance, if you zone more commercial? If you get instant development, it may be SC4 is telling you that you don't have enough jobs to satisfy the incoming workers, even if it appears that you do. And it may be that the neighboring city isn't played often enough to properly update the available job totals, which is why the simulator is dumping the excess workers straight into the next tile.

None of this is necessarily your fault, but as the Traffic Simulator thread should show, nothing is ever as simple as it seems when it comes to the traffic simulation in SC4.

[rsc204 21,857]

The real point I was trying to make is that there is no point talking about this constant unless there is a way to make the game use it. In reality that means, unless the game is already coded to work that way, you probably won't be able to alter it as such. Whilst we can adjust properties to change values, we can't alter the behaviour directly. This is down to the proprietary nature of the code, which we have no access to or permission to modify. So if you can modify existing parameters to suit your goals, you may find it's possible. However, from what I understand the cost of altering sims likihood of crossing a border is breaking the very fixes of NAMs simulator Z. The net effects of which would probably be much worse overall than the effects of the eternal commuter loop problem being reduced.