Tile loop vs tile hub?

[MarkShot 631]

I have been building central transit hubs for large tiles containing major arteries as the switching point for intra-tile to inter-tile transit.

It just dawned on me that this has been based on a fallacy of basic math/analysis.

Given:

(1)  Most tiles will due to the infinite commuter problem often enter one end and exit the opposite.

(2)  The tiles are squares.  In most cases, the transit off a perpendicular side is the length of 1 side whether traveled by hub or loop.

(3)  In case #1, a hub yields 1X side distance and a loop 2X side distance.  As there can only be one opposite exit, a simple direct shortcut suffices to resolve this case without a generalized hub.

Conclusion:

(1)  The loop is far simpler to construct than the hub.

(2a)  All above ground building can happen within the loop without the loop becoming a consideration.

(2b)  The loop greatly reduces clutter.

(3)  Transit inside the loop is mainly local to bring transit to the loop.

---

I think loops are to become a major feature of all infrastructure.  Comments?

Thanks.

[CorinaMarie 29,857]

I sort of almost kinda believe I understand that, but I'm not certain. Are you saying like a large beltway around the outer edge of the region will work better than a star/tree pattern radiating from a central tile?

How about a couple pictures to illustrate?

[MarkShot 631]

I am saying the beltway adds no more distance to transit given one bisection only due to the eternal commuter problem.  All the tunneling, over-passing, under-passing is largely negated by having city live inside the loop.

Now, the star could have anywhere from 8-16 spokes given a large central tile and all small exterior tiles.  That's a lot of simplification.

Now, of course, lost of sophisticated road work is SC4 art ... my comment was mainly about design and operations performance.  Art is art and cannot be quantified.

[jeffryfisher 2,176]

12 hours ago, MarkShot said:

The tiles are squares.  In most cases, the transit off a perpendicular side is the length of 1 side whether traveled by hub or loop.

The way I see it, spokes from a hub radiate at about 1 side-length per sector, but a beltway goes sideways to go around sectors it avoids crossing, making it as much as double the distance to get to a sector on the far side. The risk in a hub & spoke layout is that traffic jams in the center.

As for mode switching, I think that all commutes using neighbor connections are considered "long", so distance doesn't matter as much as economy, avoiding bottlenecks, and forcing sims to find local work before jumping off the edge of the world.

If you were thinking of something else, then please show a picture.

[NCGAIO 562]

2 hours ago, jeffryfisher said:

As for mode switching, I think that all commutes using neighbor connections are considered "long",.....

In fact, this is not very correct.

 

The idea that the distance to complete work trip on the other tile (neighbor or not) makes no difference is also incorrect.

If it were to consider only actual performance it would be evident that many of the mods would lose meaning so I also agree ... if it is by art then not have discussion.

 

[jeffryfisher 2,176]

In that case, I either misunderstood what was written in other threads or else a mod like NAM has changed what was vanilla Maxis behavior.

[NCGAIO 562]

7 hours ago, jeffryfisher said:

In that case, I either misunderstood what was written in other threads or else a mod like NAM has changed what was vanilla Maxis behavior.

Well ... also always read that aim of modifying the exemplar of traffic tuning by NAM was to reduce cases of comute long.

Or maybe this are referring to unknown  " time commute penalty for Neighbor Connections"  that no matter how hard  look, still can not find it except for an erroneous interpretation of the text below.

Quote

WORKING IN NEIGHBOR CITIES

As mentioned in Chapter 19, Residential Sims use Neighbor Connections to real cities to complete job trips. If the connected city hasn’t been visited since the connection was established or the connection isn’t linked to any jobs, the active city must estimate how far the job is from the connection on the inactive city side. This estimate is always punitively high. You must enter the other city after you establish the connection. Link the connection to the main Road network. When you exit this city, the simulator remembers the average commute time and adds it to trips exiting from the first city.

As has been said before .... it's all by the beatiful visual then  is no discussion about it but the concept is incorrect

[jeffryfisher 2,176]

I'm not an expert, so I'll leave it to others like @z1 to reconcile your route query and quote from the manual against earlier discussions stating that all neighbor-commutes are treated as "long".

[CorinaMarie 29,857]

Ok, so let's just gather some empirical data. I started in an empty tile which has shared demand because of the water connection bug.

 

Then I built this in the adjacent tile:

 

And inquiring about a single home:

 

So, having built the industrial buildings first and then saved I believe this tile already knows how far away the average job is. And as we see here it's a Short Commute.

I also did a test where a small town was built up on the far side from a new neighborhood connection and then did this same test. Allowing each tile to run long enough to stabilize the commute was deemed medium. The jobs they could actually get to are the same short distance, but the overall jobs of the tile are spread out. (Note: All tiles in these tests are medium sized.)

[NCGAIO 562]

8 hours ago, jeffryfisher said:

I'm not an expert, so I'll leave it to others like @z1 to reconcile your route query and quote from the manual against earlier discussions stating that all neighbor-commutes are treated as "long".

Well ... it is not my route query but the query presented by the game and hardly a mod plugin can modify this without changing the behavior encoded in it.

I just quoted what was said (neighbor commute always long) because many myths in SC4 are born precisely by repeating concepts in past experiences that may or may not cover all the variables that lead to a conclusion.

In this case the said penalty to cross borders seems to have really become a myth.

 

6 hours ago, CorinaMarie said:

.......... And as we see here it's a Short Commute.

NAM? ...commute for pedestrians or cars?

[MarkShot 631]

CorinaMarie,

Things are getting to the point where it is time to propose your PhD thesis and publish! 

"SC4 - Spooky interactions of sims across tile boundaries and other weak forces"

[CorinaMarie 29,857]

On 3/28/2017 at 0:15 PM, NCGAIO said:

NAM?

NAMless. This test was conducted in plain vanilla.

 

On 3/28/2017 at 0:15 PM, NCGAIO said:

...commute for pedestrians or cars?

Ah. The random house I clicked on was a car. All homes with pedestrians show Medium, 3 lots with cars show Short, and one lot with a car shows Long. Here's the breakdown labeled in this pic:

It seems a wee bit odd that the Long commute for that one house happens to be closer to the neighborhood connection than the Short one in the lower right. Maybe that has something to do with those Tract pics you've shown us before.

Anyhow, this still provides support that neighbor commutes are always long is truly a myth.

 

@MarkShot That is an idea I could consider, but even tho I seem to know their exact speed, I'm quite uncertain where they are.

[Prophet42 1,503]

3 hours ago, CorinaMarie said:

It seems a wee bit odd that the Long commute for that one house happens to be closer to the neighborhood connection than the Short one in the lower right. Maybe that has something to do with those Tract pics you've shown us before. 

Maybe this sim leaves his house late and has to drive his car behind all the slow moving pedestrians.

[jeffryfisher 2,176]

10 hours ago, CorinaMarie said:

this still provides support that neighbor commutes are always long is truly a myth.

"Myth" might be a bit strong. It's my understanding that @z1 worked on NAM's Z simulator (which name might not be a coincidence), so he might have been referring to that rather than vanilla. My thought now is that NAM might treat neighbor commutes as long in order to discourage them when there are yet jobs to be found locally.

Then again, he might have meant something else. Perhaps what we're seeing in housing queries is not the same data as any traffic simulator uses to plan routes.

These revelations are interesting, but I'm not yet ready to completely dismiss what we've been told by someone who's had his head under the hood. There may yet be a good explanation for how these apparent contradictions can coexist.

[MarkShot 631]

I just reread the Prima Guide and it spoke about an average commute being computed during execution to be used as the defacto constant across a particular tile boundary.

 

But who knows.  You either run lots of test cases or reverse engineer the code.

 

Is the NAM engine in JAVA or just the front end of it?

[CorinaMarie 29,857]

1 hour ago, jeffryfisher said:

These revelations are interesting, but I'm not yet ready to completely dismiss what we've been told by someone who's had his head under the hood. There may yet be a good explanation for how these apparent contradictions can coexist.

I may have missed it up above. Do you have a linky to a direct quote of @z1 stating that neighborhood commutes are always long? If it is that quote about  WORKING IN NEIGHBOR CITIES posted by @NCGAIO above, then the reconciliation has already been explained. If that's not what you are referring to, how about a linky?

[rsc204 21,859]

How does the game calculate if a commute is long or short over a border, when it has no data about the jobs on a tile over the border? Yes in NAM using Simulator Z all commutes across the border are considered long. I'm not sure how it could work otherwise even without the NAM, but I couldn't state categorically that's the case.

[CorinaMarie 29,857]

8 minutes ago, rsc204 said:

I'm not sure how it could work otherwise even without the NAM, but I couldn't state categorically that's the case.

Are you suggesting my test above is a fluke? If that quote above is true then an average commute time is calculated and saved with a city tile which is then added to the commute time in the current neighboring tile. Seems like a single variable is stored and that is used by the game.

 

11 minutes ago, rsc204 said:

Yes in NAM using Simulator Z all commutes across the border are considered long.

So, NAM does not utilize the above average commute time variable for travel to a neighbor tile?

[rsc204 21,859]

1 minute ago, CorinaMarie said:

Are you suggesting my test above is a fluke? If that quote above is true then an average commute time is calculated and saved with a city tile which is then added to the commute time in the current neighboring tile. Seems like a single variable is stored and that is used by the game.

No, simply that since the actual data on where the jobs are doesn't exist, that it would be impossible to calculate it with any accuracy. The sims could literally go many tiles for their commute, there is no way for the game to know. So if it shows as short, then yes some sort of guesswork must be involved.

3 minutes ago, CorinaMarie said:

So, NAM does not utilize the above average commute time variable for travel to a neighbor tile?

Seemingly. But I do know that commutes across borders should always show as long. However other changes in the simulator Z in terms of the allowable commute times should prevent major issues with NJZs appearing, even if commutes are long.

[MarkShot 631]

Forgive me, I am somewhat new.

NJZ?  (Zombies from New Jersey?)

Thanks.

[twalsh102 1,601]

Good guess anyway! No Job Zot

[Prophet42 1,503]

@CorinaMarie From your little experiment above, could you post a picture of the route taken by the commuters across the border to the factories.  It would be interesting to see if the numbers across the border line up and if the simulator actually routes the sims to the specific factories.  If it does, then wouldn't this seem to indicate that the SC4 simulator actually does know were the jobs exist across the border and how long it takes the sim to get their.

Another part of the experiment could be to create a job on the other side of the tile and get a sim to 'change jobs' and start commuting there and see if their commute time increases.  I admit this may be tricky to do.

Edit:  I did a small experiment to see how the game updates cities.  I have three cities of En Rogel, Tamar and Boonville.  En Rogel is neighbor to Tamar and Boonville.  Boonville and Tamar are not neighbors.  Each city has a 'Last Modified' date of 6/23/2016.  I played En Rogel for 5 sim years, but did not play Tamar or Boonville.  When I went back to see the Last Modified date, all three cities had a date of 3/29/2017, even though I did not open or play Tamar or Boonville (the neighbors of the neighbors did not change dates).  To me this indicates that the simulator is passing on information to the neighbor cities.  I'm not sure what that 'information is, but possibly it is infomation of commuters, commute time, job locations (as far as distance), etc...

[CorinaMarie 29,857]

On 3/29/2017 at 5:25 PM, Prophet42 said:

could you post a picture

I first went into the factory tile and let it run a bit over a year, saved, opened the residential tile and let it run awhile, took a pic, saved, then back to the other tile and let it run more before the pic. Here are both of them:

 

As we can see the factory side only sees the cars and none of the pedestrians. I also checked the trip length for each house after having let it run. They were all the same except the one which had been Long is now Short.

Keep in mind this is plain vanilla and since @rsc204 says Simulator Z of NAM behaves differently my tests are pretty much a moot point cause nearly everyone has NAM installed.

[jeffryfisher 2,176]

12 hours ago, CorinaMarie said:

Do you have a linky to a direct quote of @z1 stating that neighborhood commutes are always long?

An acknowledgement from 2012

It could be that he was only aware of what happens when a neighbor hasn't been analyzed (when a connection is new and has not yet been plugged into the net on the other side). If this is the case, then neighbor connections could be much more intelligent than we've thought all these years. Color me hopeful.

PS: Is there a distinction between "link" and "linky"? The latter term is new to me.

  Edited March 29, 2017 by jeffryfisher  
Linky?

[CorinaMarie 29,857]

On 3/29/2017 at 5:25 PM, Prophet42 said:

Another part of the experiment could be to create a job on the other side of the tile and get a sim to 'change jobs' and start commuting there and see if their commute time increases.  I admit this may be tricky to do.

How about if I do it like this:

 

And on the other side the road goes to a far off factory:

 

Again, I let each run for a while. So, the new residential using a car for the drive across the river is listed as a short commute. My guess is the average distance is still not too bad considering there are more available jobs right near the border.

 

Edit:

On 3/29/2017 at 6:02 PM, jeffryfisher said:

PS: Is there a distinction between "link" and "linky"? The latter term is new to me.

Nope. No difference. Linky is silly girl speak meaning link.

[rsc204 21,859]

@CorinaMarie: A bit OT, but just being curious... The picture you posted just under an hour ago with the industrial buildings. It looks super-duper crisp graphically-speaking. I know you got a new PC sort-of recently, but just wondering what Graphics Card / Resolution you are using?

[CorinaMarie 29,857]

@rsc204: It's that same NVidia GeForce FX 5500 you helped me tweak in my That Fast Video Card Setting (or whatever I called it) topic. Yes, I did buy a couple new comps, but I haven't yet moved SC4 over to them. I've still got the game on an antique Dell Optiplex GX270 which is sitting adjacent to this comp. I did get a better screen for it which is a Gateway FPD2020 and I'm running my desktop at 1600 x 1200. For those pics, however, I ran the game full screen at 1024 x 768. I pick whichever game resolution lets me fill the screen at the in game zoom level I want. (I made separate icons for 1024x768, 1280x1024, and 1600x1200 so I can just pick which I want.)

[MarkShot 631]

Speaking of resolution, I am running full screen at 1080p (32" TV).  I have don't this for a lot of games, since a big computer monitor just makes games/text look even smaller and I am pretty much 60; which includes my eyes.  But 1080p is the same number of pixels on a 27" display as a 63" display ... just larger text. 

The max zoom for the game looks really crappy and pixelated, but I understand that this is limitation of SC4.  That the internal rendering is at a lower resolution than my display, and then the game is upscaling.  Is this correct?  No way to get a sharp max zoom in at 1080p (Full HD)?

Thanks.

PS:  I actually have two displays:  21" 1600x1200 and 32" 1080x1920.  There are a few games I run on the 21" such as shooting pool or DOSBOX games.  And only about two I run across both displays, because few games are designed to use floating windows which are not subordinated to the main window.

[rsc204 21,859]

9 hours ago, MarkShot said:

That the internal rendering is at a lower resolution than my display, and then the game is upscaling.  Is this correct?  No way to get a sharp max zoom in at 1080p (Full HD)?

Yup, zoom 6 was tacked on late in the development process, I think for the Rush Hour release too, to support the My Sim feature. As such, the way items in the game are displayed is based on just 5 zooms and 4 rotations, textures don't exist for the 6th zoom level and there is no way to make the game see/use them. This same problem is what gives us the option of so called HD textures. Either zoom 5 can be the default resolution, with zoom 6 upscaled or where twice the resolution textures as used for z6, the z5 texture is down scaled. Either upscaling or downscaling in this sense leads to a poor quality image.