Started by Fabio, June 21, 2013, 02:18:50 PM
0 Members and 1 Guest are viewing this topic.
Quote from: neroden on May 02, 2013, 12:43:15 AMIt was irritating me that terraces were not constructing the way we wanted them to look (long rows of identical houses). So I programmed what I think is an elegant solution. Tested, compiled, runs, works. It's on my pretty-cities branch in git. A test run for modifications needed to the pakfiles is on the pretty-cities branch of the pak128.britain git repository. There is a new line available in the .dat files for city buildings (and only city buildings, and only residential/commercial/industrial). This is "clusters". There are 32 possible clusters (numbered 1 through 32) available for a pakset. Buildings do not have to be part of any cluster, and are not part of any cluster by default. A building may be part of two or more different clusters. (It's a bitfield. I had to use a bitfield for internal reasons, so I figured I might as well allow pakset makers to use it.) I would suggest putting rowhouses and other buildings which fill from side-property-line to side-property-line into clusters. I would put everything with the same setback from the front-property-line in a single cluster. I would leave detached houses without clusters. For example, I put the grey stone terraces (both houses and shops) into cluster #4. Code Select Expandclusters=4 I put the wall-to-wall 1750s warehouses into cluster #6. Code Select Expandclusters=6 If I wanted a building to cluster with both of those, I would write Code Select Expandclusters=4,6 If a building is a part of a cluster, then when the city growth routine tries to build a building next to that building, it will preferentially (but not always) build one of the buildings of the correct cluster type. This means more grey terraces next to existing grey terraces. This does not override the level checks, so if there are no grey terraces in the next level of buildings, down come the terraces. (The way this works, specifically, is that the four orthogonally adjacent tiles are checked. A building which matches any one of the clusters for any of the buildings on any of those 4 adjacent tiles will get a bonus to its chance of being built -- currently a factor of 10. A building which matches none of the clusters will get a penalty -- currently also a factor of 10. If something is being built with a grey terrace on one side and a brownstone on the other side, brownstones and grey terraces will both get the bonus.)(Further technical note: I used extra_data, which isn't used yet for res/ind/com buildings, so I didn't have to alter the data structures. Save game compatibility is preserved, and you can even use old compiled paksets with the new executable.) A building which is not part of any cluster will continue to follow the existing rule -- it will not be placed next to an identical building (to "avoid boring cities" as the code says). However, a building which is part of any cluster will ignore this rule (obviously, as the clustering rules wouldn't work otherwise). I am open to the question of whether this rule should be removed entirely in favor of a truly random building distribution. On the whole I like the results. I get blocks of matching rowhouses, while the blocks of detached houses remain a mix of different buildings. See the following screenshot for something which you could not have generated randomly with the prior code. http://simutrans-germany.com/files/upload/simscr03.zip (This code could probably go into standard, since I think experimental has barely touched any of this code. It's proven to be extremely painful and difficult to get patches into standard, however. If someone else is willing to extract the diff between my branch and the existing experimental branch as a patch for standard, it would be appreciated. Be warned: while I was fixing and deciphering the code, I translated great hunks of it from German to English, which is what is supposed to be done. If the developers for standard want this kind of nice little uninvasive improvement to go into standard... they should switch to using git, and review requested patches promptly.) I have a couple of other "pretty city" projects in mind, to fix the last couple of annoyances: (1) Buildings built next to the beginning of a bridge frequently face the wrong way. I haven't figured out why the start of road bridges isn't triggering the street detection algorithm correctly, or how to fix that. (2) For buildings in small blocks (2x2) it is somewhat random which direction they face, so that even though I can get four rowhouses, they may all be facing in four different directions. I have some ideas about how to fix this but I think I want to fix the bridge issue first. (3) Factories aren't facing the right direction (they're frequently facing away from the road) This is mostly an issue with "final destination" factories like the Bakery and so forth. (4) When a building has a choice of facing two roads, one of which is flat, and the other of which is on a slope, it should prefer to face the flat one. It often doesn't. (5) I'd like to improve my clustering algorithm, so that it only looks "along the road" for buildings to cluster with, not "across the back lot". I think this needs to be done after fixing (1), (2), and (4), as it's going to require the same sort of information. But anyway, I think this is an improvement even as it is. And if you don't like it, well, you don't have to put "clusters" in your dat files. :-)