Birdin

Making a basic config.bmp that works is really simple, and probably not even worthy of an article in the Omnibus. In fact it's easier than I make it sound just below, but I wanted to be thorough for the engineering types who want to understand every detail. But I figure it's a good place to start before I get to the more fun part of the article. First, there's really only one rule regarding how a region is divided into cities: that each city is a square of 1km, 2km, or 4km on a side (aligning to a 1km grid) and the cities can't overlap. For simplicity, most people make their regions so that the cities fill a rectangle (often 16km x 16km) but this isn't completely necessary, as we'll see later. Anyway, the config.bmp file is a standard Windows (or OS/2) Bitmap file. The color depth should always be 24 bits (true color) and the width and height in pixels should equal the east-west extent and north-south extent of the region in kilometers, respectively. Each pixel represents one square kilometer in the region, and the color of the pixel is determined by the size of the city covering that square. Red (RGB=255,0,0) is for small (1km) cities, green (RGB=0,255,0) for medium (2km), and blue (RGB=0,0,255) for large (4km) cities. For example, a 9x7km region might be divided like this: And the config.bmp (enlarged 4x here for clarity) would look like this: While I'm at it, I'll note that the dimensions of the greyscale heightmap image can be obtained by multiplying the dimensions of config.bmp by 64 and adding 1. So a 9 by 7 kilometer region would need a greyscale heightmap image of size 577 by 449 pixels. All of this so far is just about common knowledge. So far. The first "secret" I'm going to tell is how SimCity interprets the colors in config.bmp. Each pixel doesn't have to be one of pure red, green, or blue. In fact, *any* color can theoretically be used in a config.bmp file. When SimCity looks at a pixel in config.bmp, all it really cares about is whether or not each channel of the color is 255. Any other value from 0 to 254 might as well be zero. Now any pixel where the red value is 255 and the other two values are not 255, the pixel is considered to be red. Similarly, any color where the red and blue values are 254 or less and the green value is 255 is considered to be green, and any pixel with a blue value of 255 while the red and green values are both not 255, is considered blue. On top of that, any pixel where *no* channel has a value of 255, or if more than one channel has a value of 255, the pixel is considered "other." What does SimCity do with "other" pixels? It leaves that part of the region empty. In this way, one can create a region with an irregular shape, even holes or "islands" that aren't connected (even by ocean) to other parts of the region. This can actually be useful in reducing import times for custom regions, as SimCity won't take the time to process parts of the region that aren't covered by cities. If a large section of a region is ocean, those parts of the region can be left not covered by cities, and only the playable cities will need time to import. One last secret. If possible, SimCity will reduce config.bmp to the smallest possible rectangle containing its red, green, and blue pixels, eliminating "other" pixels on the bottom (south) and right (east) edges. Note, SimCity will not crop out pixels that actually represent cities, only empty areas. It will then look for a greyscale heightmap in the *new* dimensions calculated based on the cropped config.bmp. This means that theoretically, one can take a 640x480 (or larger) digital photograph, make sure none of the pixels are lighter than (254,254,254) and then place a proper config.bmp in or near the upper-left corner. I wouldn't suggest doing this on Simtropolis's Map Exchange, however, because a .bmp file at that size would be ridiculously large to download, and your map will probably be deleted from the STEX. It can be fun, though, to put a nice frame around your config.bmp (leaving extra space in your greyscale image on the top and left sides for the frame, since SimCity won't crop on those sides) or play around with the colors inside the map itself as long as care is taken to make sure you don't change how a pixel will be interpreted by SimCity. Here's an example. A simple application of this is Fertile Coast in the STEX There, the colors between the cities are varied a little bit so different cities can be distinguished by a human viewer. Phil's Country and Columbus* show some more advanced techniques. There are endless ways in which people can personalize their config.bmp files. Please use good taste. * Columbus was not yet uploaded at the time of this writing, but an enlargement of its config.bmp can be found in the City Journals forum.

Yeah, in all previous versions of SimCity, you could plop down roads or pipes or whatever one tile at a time and if they were right next to each other, they'd connect automatically. In SimCity 4000, you actually have to drag with the mouse to lay down a continuous network.

Both highways have to be perfectly straight for at least six tiles in either direction, not counting the intersection itself -- that is, a total of 14 straight tiles of highway, intersecting another highway with at least 14 straight tiles. No on-ramps or intersecting roads can get in the way. And a tile where the highway dead-ends doesn't count as straight for the purposes of this description.

Update: I kept working in Maple Pont, adding commercial jobs. Then I noticed that all of the commercial lots that were previously residential were *still* generating trips to Sandville. The only way to eliminate these trips was to de-zone the lots and re-zone them again, which had to be done gradually because typically that meant temporarily eliminating jobs of the very kind that I was trying to create. Anyway, after quite a bit of work, I managed to get the number of Maple Pont to Sandville commuters down to about 1,600, all of which happily routed to industrial and commercial jobs on the near side of Sandville.

Originally posted by: mistershnerplesbut how do you deal with your mass transit? i always put a bus stop and subway at every NE or whatever corner of the 6x6. it's fascinating what people do with their gridding.quote> Well, when it starts to get dense enough to overrun the grid with traffic, I start building highways, either by converting existing avenues, or running the highways down the middle of blocks. At this stage of development, I can usually find a path for a highway that doesn't require the bulldozing of tons of high-rises. Buses are also a common tactic in my cities. Here's where the Roadtop Mass Transit mod helps a lot. Placement of stops varies. Finally, if the need exists and I have the budget for it, subways. Sometimes I use el-rail in less-dense cities adjoining cities that use subways. That of course usually requires some demolition. In case you're wondering about the life experiences that led to this style, I grew up (and still live) in central Ohio, where for decades, development was allowed with little resistance, and little responsibility to help upgrade the transportation network. Then in 2001 I went through DFW on the way to and from Mexico, and I saw developments being built that included 4-lane divided avenues, some of which just ended in empty fields, surely to be extended by the developer of the next land tract. So when Rush Hour arrived and avenues were an option, I quickly learned that it's easier and cheaper to build avenues into the grid from the beginning, rather than expand roads when they go over capacity. Because they do go over capacity quickly.

In case anyone else with the same problem finds this thread, I'll note here that I also posted it at https://www.simtropolis.com/forum/messageview.cfm?catid=124&threadid=91397&startpage=1 and received an answer. It's not a satisfying solution, but it's an answer nonetheless.

Well, Carson Pass *does* have jobs, but not many. (I rarely create cities that purely stick to one zone type...) Each city along the line has a few jobs, and there are a lot of jobs at the other end -- but a lot of residents occupying those jobs. If the game is in fact keeping track of what type of job the commuters are seeking, I wouldn't expect this to happen. Maple Pont (the "origin" city of the problematic commuters) has a lot of the high-end commercial jobs. Sandville has a variety of Industrial jobs. So I'd imagine, if a sim from Maple Pont has to go to Sandville for work, they're probably looking for industrial jobs. (It would appear that it's mostly low-wealth sims heading for Sandville by casual observation...) I suppose it's possible that there just aren't enough of the "correct" jobs in Maple Pont. I've been trying to correct this, by re-zoning low-density, low-wealth residential areas to commercal zones. While the number of commercial jobs has increased (mostly Co) and the overall residential population has decreased slightly, the number of commuters "exported" to Sandville has increased! On the other hand, R$$ has been increasing compared to R$, so I guess it's rather likely that growth in the proper C sectors hasn't been fast enough. Plus, it would seem that the concept of stage limits (which I have come to better understand very recently) is preventing commercial areas from developing as dense as I would hope in Maple Pont... Well, thanks. At least now I think I know a little more about what to avoid.

Originally posted by: N_O_Body Originally posted by: Birdin The only traffic that's seriously simulated in SimCity 4 is commuter traffic. People don't take taxis to work. They're too expensive.quote> Have any evidence for this? What about people who arrive at an airport and need to get downtown to attend meetings?quote> Evidence of the cost of a taxi? Call any taxi company, you'll find it's like two bucks a mile, which is well over ten times the cost of fuel to drive yourself. People arriving at an airport who need to get to a meeting, while they are traveling within the city for work purposes, they aren't en route from their home to their primary place of employment, and aren't considered commuters; such trips are not simulated in SimCity anyway. Now, if SimCity were to actually include trips for business meetings (Co to Co) personal meetings (R to R) or shopping (R to Cs), then the argument might be a little different. And I suppose there are probably a few high-powered execs that travel by air (or, unlikely, by some kind of mass transit) daily to some point near their office, and then take a taxi the rest of the way, but I think they're much more likely to hire a limousine. And air travel isn't a commuter transit method in SC4. All in all, I wouldn't think more than a few rich oddballs would utilize a taxi every day to get to work. So until SimCity begins simulating trips *other* than commuters, I don't think taxis figure into actual gameplay. (OK, so they also simulate freight, but just barely; don't get me started on that...) On the other hand, I have no quarrel with someone who wants to have more taxi automata on the screen, or even add a taxi-service building to the game. But it shouldn't influence traffic simulation, because the game simply doesn't simulate the kind of trips that taxis typically serve. Limos would be interesting. But that's just another "car" trip, so it doesn't affect the game numbers. Still, I wonder if it would be possible to introduce limousines on the roads, based on what proportion of that traffic is high-wealth...

In my cities, I try to maintain a universal grid system. The basic, repeatable unit is 16x16 tiles. (So 4x4 of these units fit in a small city, 8x8 in a medium, and 16x16 in a large; also, the units line up across borders.) An avenue runs across the exact middle of the unit in both directions; that is, the 8th and 9th row and 8th and 9th column are occupied by avenues. Streets/roads occupy the 3rd and 14th rows and columns, so there's a 4-tile space between them and the avenue, and a 4-tile space between parallel streets in adjacent units. Pairs of one-way roads are often made. Graphically, 4 units: ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v > > + > > > > + + > > > > + > > > > + > > > > + + > > > > + > > ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v < < + < < < < + + < < < < + < < < < + < < < < + + < < < < + < < > > + > > > > + + > > > > + > > > > + > > > > + + > > > > + > > ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v < < + < < < < + + < < < < + < < < < + < < < < + + < < < < + < < ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v > > + > > > > + + > > > > + > > > > + > > > > + + > > > > + > > ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v < < + < < < < + + < < < < + < < < < + < < < < + + < < < < + < < > > + > > > > + + > > > > + > > > > + > > > > + + > > > > + > > ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v < < + < < < < + + < < < < + < < < < + < < < < + + < < < < + < < ^ v ^ v ^ v ^ v ^ v ^ v ^ v ^ v Of course, allowances must be made for buildings larger than 4x4 tiles. I generally improvise, though there are a few techniques I've come to prefer for specific buildings. I'll share those if anyone asks. Once this pattern is repeated, I tend to think of the avenues as the boundaries of block groups, which are more prominent than the invisible "unit" boundaries as defined above. There are nine 4x4-tile blocks in a block group. Sometimes, however, I consolidate a one-way pair into another avenue, making six 6x4-tile blocks in a block group, or doing that in both dimensions, four 6x6-tile blocks in the block group. And sometimes, in dense industrial areas, I only build the main grid avenues, making large 14x14 blocks of zoned land. The primary benefits of this system are as follows: 1) There is no need to adjust the grid to "fit" the edge of a city, as you always have just enough room for 2-tile-deep zoning along all edges; 2) The grid always lines up across city boundaries; 3) It's easy and not too expensive to build in a small city (use streets instead of roads, and just leave space to build the avenues later if you're really broke); 4) When fully built out with one-way roads, it has the capacity to handle reasonably dense development; though highways and mass transit should definitely be implemented when you've got multiple thousands of residents or jobs on each block.

It's not entirely clear from what you posted, but I'm guessing you're referring to the left turn lanes. When you install the NAM, you want to make sure you have the left turn lanes option(s) selected.

(Also posted at https://www.simtropolis.com/forum/messageview.cfm?catid=22&threadid=91390&enterthread=y ; sorry for double-post, but I want to be sure the experts will see this...) I've recently started a brand-new region, and currently have six cities basically strung out in a line. The total population of the region right now is about 150K. On one end is Maple Pont, then Sandville, then Carson Pass. Sandville is supposed to be a big job city (mostly industrial: I+C total is nearly twice the R total) and Maple Pont is mostly residential and commercial, with emphasis on education. So there are about 7,500 commuters travelling across the border from Maple Pont to Sandville, mostly by car, but some by bus. Besides the clogged neighbor connections, all is well in Maple Pont. In Sandville, however, it's utter lunacy. Despite plentiful bus stops in the industrial areas, the bus commuters just roll right through to Carson Pass. As for the car commuters, only about 10% actually stop at jobs in Sandville. Jobs in Sandville are more than plentiful. Most of the industrial buildings query with 60 to 100 jobs occupied, but the route query reveals only one or two cars actually being routed there. (Is this an "occupant leak" issue of some kind?) With 5,000 or so cars just dumped into the next city (which really doesn't have a lot of jobs at all -- not that they'd stop there anyway) you can see where this can become a major traffic problem for a region. This problem has been present for quite some time for me. Nearly all commuter traffic which enters a city just drives directly to the very nearest connection to another neighbor city. If there are jobs closer than that, there's a chance that a few will actually stop there, but this doesn't account for much, as can be seen in Sandville. Most of the time, this leads to unrealistic traffic flows across the corners of cities, often curling back towards their origin after crossing two or three city borders. I'm currently using the NAM Beta version 09.04B.04 with "Better Pathfinding" and "10x Commute" along with the various turning lanes and roundabouts, diagonal streets, the custom highway menu option, and radical automata. I'm using a few other mods which don't relate to transportation, except the roadtop MT, and marginally, the bridge height mod. My EXE version is 1.1.638.0. Could someone with knowledge of how pathfinding works explain how the game decides where a commuter entering a city attempts to go? Is there any data about the commuters regarding their wealth level, or what type of job they are seeking? Most importantly, how can I get commuters entering Sandville to actually stop and work *in* Sandville besides cutting off access to all other neighbors?

One thing that would be very helpful: Orthogonal single ramps to and from diagonal highways. Only one tile would actually be needed for the connection to the highway, and this would allow interchanges without requiring a highway to run in a straight line for several tiles. Ideally, this would be available for both elevated and ground highways. And maybe even a version where the ramp connects to a curve.

What T Wrecks meant is that the "average commute time" number doesn't actually cause abandonment (unless it's at the max, which is very high) and therefore a 20-minute-commute city could have problems just as easily as an 80-minute-commute city. Your problem is likely that there just aren't enough jobs for rich people. Try developing high-tech industrial or high-wealth commercial areas.