the7trumpets

This thread is ONLY for development of the NAM. If you are not actively creating or helping to create something for the NAM by posting models, paths, etc, please post in one of the applicable threads below. *Irrelevant posts that do not follow the scope of the thread, &/or do not add to the thread, will be deleted without warning & without notice.* While encouragement and comments are welcome and appreciated, it is easier to work when the development thread is clear of such comments. To make these comments, please make them in the following thread. If they are posted in the development thread, they will be deleted. General Discussion: NAM General Discussion Thread The development team will check the requests thread for projects to work on. If you have a request, go to the following thread, don't post them here. Thanks! Requests: NAM: Requests If you are looking for the NAM, it's not in this thread. Links for NAM and related addon items can be found in the NAM FAQ thread. Enjoy! Downloads: Network Addon Mod (NAM) and Real Highway Mod (RHW) FAQ and Download Links For all those who have read the interchange tutorial, and are actively creating something for the NAM, please use this area to develop those items, post completed and in-progress additions to the NAM, and ask questions of the fellow developers if you run into a snag which the interchange tutorial, reader thread, and other modding tutorials don't explain.

*Irrelevant posts that do not follow the scope of the thread, &/or do not add to the thread, will be deleted without warning & without notice.* The purpose of this thread is to allow for new requests to be made. If you are having a problem with the NAM, read the readme carefully, especially the Q&A section and the Installation Instructions section. If following all those instructions doesn't help you, delete the modd and re-download it, as it might have been corrupted somehow. Please don't post problems that you're having with the NAM in this thread, as they will be deleted. Any general discussion (non-development or new requests) should go to the old NAM thread: NAM General Discussion Thread Posts repeating requests or not specifically requesting a new option for the NAM will be deleted to facilitate those working on this project being able to easily find what has been requested. If you really want to see one of these requests get into the game, we invite you to read the Interchange Tutorial Thread and help us make these things a reality. We can always use some more help. Scope The scope of the NAM is limited to transit related network pieces, and things which require editing specific transit related files within the dat files which cannot be added to with another file. This modd will not include any transit enabled lots, as they never have a need to edit the specific transit files that this modd does. Things it will include are new interchanges, new intersections between ground based networks, and network puzzle pieces. If you are unsure whether your specific request fits the scope of this modd, please ask at the NAM General Discussion Thread used for general comments NAM General Discussion Thread before posting here. I appologize for the forceful tone of this, but the time those who are working to implement these requests spend answering questions which are answered in the readme, and weeding through repetative or mindless posts, means that the development of the NAM is slowed down and you don't get to see these things in the game. If you are looking for the NAM, it's not in this thread. It is, however, in the Mods section of this site, along with all the other downloadable mods. Under the heading Simcity 4 to your left, you will find a link which says Mods. Click on this and then scroll down the page until you find the Essentials section on the right hand pane of the page. Click on Netowork Addon Mod Beta and it will take you to the download page. Enjoy! Items requested prior to the start of this thread (do not repeat these, or your request will be deleted) 0) Tropod Monorail overpass over elevated highway Current Requests A3) FireSka Onramps for road and avenue over road/avenue overpasses. This way we can make 2 and 4 lane highways with entrances and exits. A5) woodb3kmaster Some highway interchanges with surface network types (avenues/roads/one-way roads) A10) Many requests Ploppable network-piece roundabouts (3x3 for roads/streets, 6x6 for avenues) A11) Many requests Improving the puzzle piece supports, the current ones look rather flat and have some weird shading would it be possible to make the supports under the puzzle pieces the same as the on/off pieces? A17) Birdin A suggestion for elev/elev stack interchanges: take the highest flyover ramps and move them below the main freeway lanes. If you can't drag roads/rails under there, you might as well use the space for the interchange. A18) Birdin Highway/highway interchanges (probably a Y, but maybe a trumpet) set up for even distribution of traffic: that is, upon entering the interchange, the center of the 3 lanes would split, producing 2 2-lane ramps, one to each freeway exiting the interchange. When 2 2-lane ramps converge to leave the interchange, the center lanes would merge. A22) Sim_Idiot a new ground highway elevated highway piece. When connecting the two highways together ingame you get an unrealistic slope for a highway, it would be nice to have a nice gradual slope across several tiles. A23) FireSka An elevated highway to elevated avenue puzzle piece A24) lakeyboy Road / One Way / Avenue / Elevated Hwy over => Pedestrian Mall puzzle pieces A31) hoonyr A traffic-light junction for ground highways. It's possible to use avenues to create a junction for highways but 1) its not very aesthetic 2) the congestion created by it is too big (due to transition to avenue + junction itslef) In Tel-Aviv, were i live, we have 'big-high-speed-avenues' that are practically ground highways but they have junctions about 1 KM apart and usualy the junctions have a ground-level-ramp-like right turn, to help make the junction less time costly. The junctions could then be later replaced with full overpasses when money permits. A33) qurlix Are you interested in including the cul-de-sac mod as an extra option in the NAM? I don't remember who suggested it, but you have my permission. A36) ScLu Corner puzzle pieces Related request by theyeti2001: Elevated intersection puzzle pieces A37) Many requests New textures/props for the pedestrian malls A38) BrandonTheGreat Road over C/D highways (multi-highways) A39) BrandonTheGreat transfer lanes from one set of lanes to the other in a C/D highway A40) Aures Puzzle pieces that cross over diagonal networks Note: the rest of this request is in the thread below A41) Puddlemonkey If 'raised ground rail' puzzle pieces are implemented, could the start and end pieces be made much longer, say 6 x 1 so the gradient the trains climb is less steep. The 3 x 1 climbs are unrealistically steep! Most realistic of all would be if a piece could be made that joins the puzzle pieces to terraformed ground at the same (raised) level, rather like the rail over road bridge illistrated in request #B4. A42) theyeti2001 Ground rail puzzle pieces with different base textures (eg. concrete, cobbles, grass etc.) and rail intersections (made as per interchanges) that use the same base textures as above. A43) Cactaur55 A way to lay down the half ground highways, aka multi-highways, directly? This could probably be done through a simple set of highway puzzle pieces. B1) joexcooldude I request a 6 ramp parclo and a Volleyball interchange Related request by woodb3kmaster: I, for one, would also like to see these included -- perhaps as single-sided ramp combinations (i.e. the ramps for only one side of the highway); then we could combine them with diamond ramps, if we wanted to: B2) sargeantcm Something I posted back in the old Intersection and Interchange Mods (post-RH) thread was a request for an interchange between a road and another road (or avenue to road). These generally exist on super-two 2-lane limited access highways that have intentions of being upgraded to 4 lanes some day when the traffic volumes justify it. Here's the pic I posted in that thread. Obviously this is Photoshopped!! B4) Thalassicus Would it be possible to make overpasses for this style? They could be designed for the default height and slope angle available through the Hole Digger/Raiser lots: Later request by smoncrie: I think that intersections involving sunken highways (or rail, etc.), raised ramps, and underpasses could all be done if there was an additional kind of end puzzle piece. The piece should one tile long, flat topped, and designed to rest on the sloped side of the trench, ramp, etc. (many later requests in various forms) B6) Many requesters TGC's Stack Interchanges that were modelled four months ago... The finished stacks for ground/ground, ground/elev, and elev/elev on page 23: www.simtropolis.com/idealbb/view.asp?mode=v iewtopic&topicID=49685&num=30&pageNo=23 B7) sargeantcm Single-point urban intersection (spui)'s for Avenues, which would take up less space than a standard diamond intersection. Later elevated highway/road spui model posted by ardecila: B8) Many requests A trumpet interchange: Related request by Feer: A road/highway trumpet interchange: B9) BigRedFish One-sided versions of single highway ramps, which continue straight onto a one-way road, like so: (many later requests) B12) Many requests The train viaduct puzzle pieces created by mikeyb66 and/or ardecila: B13) wicher Partial diagonal-orthogonal interchange: B14) joexcooldude 2 variations of Y-Interchanges that are very common: Later request by wicher: Orthogonal/Diagonal Y highway interchanges. A full connection is unecessary, there would be more direct routes between the southbound and eastbound highways somewhere off to the right. Related request: A fully connected version: B15) momo Something like this for the ground/elevated or elevated/elevated diagonal stacks? B16) joexcooldude a semi-stack/cloverleaf: Redlotus: Interesting stack. I tried to recreate it using GMAX and this is what I've got: B19) Many requests Would it be possible to create narrow ground highway access ramps in addition to the standard 3-tile ones? B20) Many requests A Diagonal/orthogonal (can be flipped or rotated as necessary) highway/road interchange. Also requests for an highway/avenue version. B21) lord titan One-way road puzzle pieces (or other network types) modelled to fit on a slope with a retaining wall, for sunken highway service roads directly on the embankment. Two angles would be useful, one at the angle of the Road Hole Digger lot (the height of standard ground highway overpasses), the other for the Rail Hole Digger angle (the height of ground highway overpasses with onramps). In addition to puzzle pieces to transition the access road off the embankment. B25) dominohobbes How about something like this : Related requests: Related request by davidhogan: If you're already modeling this, how about a version that allows access to/from the other side of the freeway also? Just 2 flyover ramps is all it'd need. B26) Many requests TGC's highway Y-interchange modelled some months ago: B27) FireSka a partial T-interchange stack: The modified cloverleaf in the custom interchanges menu does not do this correctly this because it does not allow southbound traffic to exit to travel east on the adjacent highway nor does it allow eastbound traffic to travel north on the adjacent highway. If you look closely at the partial cloverleafs already provided in the NAM, you will notice they have really, really weird access patterns. Similar request by LakeTrash311: 2 ramps 4... (the T interchange mentioned earlier) 6 B28) Dexter Different textures available for under the puzzle pieces B29) iamthouth Roundabout stack-interchanges. Basically, it's a 3 tier intersection, with highways crossing in tier 1 and 3, but with tier 2 as a roundabout. This is a map from where I've seen it, the Sinsen intersection in Oslo, Norway. The grey lines feeds into the second tier roundabout, while the orange highways cross above and below the roundabout. B30) wicher An avenue/road partial overpass: Especially useful for busy and/or important avenues, with little space. The idea is that it works the same as a normal avenue-road-crossing, but the North-South-direction (in this particular case) can drive trough at full speed. B32) qurlix In regards to the proposed cutting up of ped overpasses into puzzle pieces, I dont think it is necessary. I do think that it would be cool to pick the best one for each style (road, rail, avenue...), enable it to work correctly (see below), and add it to the NAM. Pedestrian malls aren't really fully functional without connections like these. B34) WJ_Webhog I'd like to see a road to one way road transition, and maybe a one way road to road transition... what it would look like (rough sketch): B35) r7d9 ...intersections with between an Avenue and a one way street with out having stop lights or an actual intersection (the oneway branches directly off the avenue) Picture by T7T: B36) Dusktrooper How about a highway overpass bridge in a different design? B37) rubberring I think that would me a useful modification for the ant network. this 3 lane road is a cheap alternative to the avenue out of town and has a much higher capacity than a road. it also can be used as temporary road for later expansion. thus on intersections or interchanges it's able to be converted into 4-lane-avenues, so you don't have to create new intersections. B38) LakeTrash311 El-highways with retaining walls, or even turnarounds/crossovers at avenue overpasses: B39) Thalassicus Could someone take this overpass: and when used in this situation: make one which looks like this: The proper depth for avenue overpasses is achieved through the rail hole digger lot. Not possible in the game: C1) thpwrthtbe ONE WAY neighbor connections Neighbor connection logic is hardcoded into the game, we can't change this C2) dominohobbes Being a realism freak, I think it would be cool to get to choose different pavement types, like choosing whether a network is asphault or concrete. The surface/texture for a network can only be entirely replaced or not at all, and doing it either that way or with puzzle pieces would require making hundreds and thousands of textures. C2) Tunafish Sunken puzzle pieces As far as I know it is not possible to do this and have it work with UDI and emergency vehicles (although it was done with the NDEX sub rail conversion, so...?) Can al

First, let me give huge thanks Rybolton, for creating the original instructions on how to use the USGS data, without which I would have never even thought this project to be possible. Many of the instructions here are taken from his excellent omnibus article. Also, a big thanks goes out to Odd8ball for helping me so diligently with the calculations and DarkMatter and ExtinctSKB for finally getting through to my thick skull on how SC4 does its 3D projection. I apologize for the length and complexity, but it should be fairly easy to follow. Part 1 - Getting the USGS data First you will need to get a program called MICRODEM. Get it here. Follow the link ’Complete Install’. Now install MICRODEM. Now that you’ve installed MICRODEM you will need to get a DEM (Digital Elevation Model). You can download them from this site. When the page loads, click on one of the two buttons entitled ’View and Order Data Sets’, corresponding to whether you want to download maps of the US or of the World (currently only North and South America are available). That will take you to this page: you should see this map once the applet loads In the "Download Layers" section at the top right corner (boxed in blue in this screenshot), select only NED and 1/3" NED for US maps. If you are downloading Canadian, Central American, or South American terrain, you will need SRTM 30m and SRTM 90m selected. The toolbar on the left hand side of the screen allows you to move around the map, zoom in and out, and select area to download. The zoom in tool is default. After you’ve found the location that you want to download, select an area to download using the download by rectangle tool in the lower left hand of the toolbar. To get an idea of the size of your selection, you can click on the ruler icon above the download section and change the scale to kilometers. Using the download by rectangle tool, select an area a little bigger than how big you want your region to be. your download selection is shown by this green box Once the new window has finished loading, you will see the following page. Click on the "Modify Data Request" Button at the right. summary page This will load the next page, where we will select our preferred format. Select TIFF in the data format column of all available resolutions: NED, 1/3" NED, etc. request options page Now click on "Save Changes and Return To Summary" button on the bottom right. It will now take you back to the previous page. In order of most preferred (highest detail) to least preferred (lowest detail), the possible download choices you may have are: 1/3" NED - ArcGrid Format; NED - ArcGrid Format; SRTM 30m; SRTM 90m. You only need one of these. Simply download the most preferred (highest resolution) option available. Note: When trying to download large areas, the 1/3" NED may be broken up into several files because the system cannot generate any files over 100MB. If this occurs, and you really want to download this large of an area (which will be larger than a 16km by 16km standard sized region), simply download all the 1/3" DEM's that are listed, and you can piece them together later.Once you click the download link, a new window will pop up that shows the status. The server has to compile the information in the format you requested, and then compress it in a zip, so it might take a minute or two for larger files. Remember where you download this file, and unzip it. Part 2 - Working in the MICRODEM program Start MICRODEM and select File-> Open DEM. Find where you unzipped the DEM you just downloaded and open the tiff file, which will be named some eight digit number. right click sub-menu Once the DEM is opened, right click on the picture and click on "Display Parameter". Then on the next menu that pops up, click on "Reflectance". The following dialog box will open: reflectance options dialog box Here, you need to ensure two things. First, make sure ocean check is on. Then click on the button that says "Water" with the color block next to it. Change the color to RGB=65, and click OK in both dialog boxes. Next, right click on the image again, select "Display Parameter" and then "Elevation" The map should now look something like this: elevation view Now right click on the image, select "Elevation colors" and then "Colors". The following dialog box will appear: elevation map options Make sure to select "Grey scale" as well as checking "Ocean check". Then click on the button named "Missing" and change its color to RGB=65. Now click OK in both dialog boxes. The map should now look like this: map after greyscale is selected Next we need to set the altitude scale. When importing greyscale images to terraform regions, the SC4 map has a total altitude change of 933 meters. Sea level is at RGB=83. However, when the land level is RGB=84, SC4 seems to slope the land down slightly at the edge of the map which causes weird behavior (sand or water) at the border of your cities. Also, when the lowest land value is set to RGB=85, about 100 meters of coastline is eaten away by the interpolation of the greyscale image. At RGB=86, only about 30m (two tiles) of coastline is eaten away, which is a good compromise. This means 0m elevation needs to equal RGB=86. To accomplish this, right click on the image and select "Elevation colors" and then "Specify". This will bring up the following dialog boxes (one first and then the other): the altitude where RGB=0 the altitude where RGB=255 If this is an ocean region, use the shown numbers (-314 and 619) to set land at RGB=86. However, if this is a map with a lake instead of an ocean, place your cursor over the surface of the water. In the lower middle of the DEM window on the status bar, it will give you the elevation in "z= 385m" format. Add that value to both -314 and 619. So, if the lake had an elevation of 385 meters, you would type in 71 for min Z and 1004 for max Z. If it is a map with no lakes or ocean in it, you need to get the whole map above sea level. To do this, select "Elevation Colors" --> "Specify", but do not change the values that are there yet. Take whatever is shown in the first dialog box (min Z) and add it to both -311 and 622 to get the values to use. Remember, very mountainous maps may be difficult or impossible since they may have more elevation change than we can import from greyscale images. Now your map should looks something like this: map after altitude scale is adjusted Next, we need to turn the grid on so that we have something to set the North/South and East/West scale to. Right click on the map and select "Grid" which will bring up the following dialog box: grid dialog box Make the window look like the one above. Ensure that "Grid" is set to UTM, and "Label Grid" has neither UTM or Lat/Long selected. Under "UTM grid interval (m)", enter either 1024, 2048, or 4096. These correspond to the widths of a small, medium, and large city, but this does not mean your cities must be that size, it will simply be used for measuring the scale. Click "OK". Next, in order to save the file with its full resolution, you need to zoom in full. To do this, simply click on the magnifying glass with a 1 inside it on the toolbar of the DEM: A confirmation message will likely pop up that asks you if you want to do this. Click OK, and you should see something that is obviously zoomed in: Note: If you are working with the standard DEM instead of the higher resolution 1/3" DEM, this message may not come up and your window may not zoom in as much simply because there is not that much resolution to the image. fully zoomed in 1/3" DEM Now select "File" --> "Save map as GEOTIFF". Save it as something like "region name with grid", because we will now turn the grid off to save the real image we are going to use. Right click on the DEM again and select "Grid". In the dialog box, under "Grid", select "neither". Now save it again via "Save map as GEOTIFF" giving it a different name like "region name without grid". You are now done with the MICRODEM program. Part 3 - Image Editing Close Microdem and open up your image editing program. The first thing you need to do is measure the North/South and East/West scale. To do this, open up the tiff file with the grid that you saved from Microdem. Zoom in close enough to see the pixel which is at the intersection between grid points. Either by writing down coordinate points, which should be shown in a status bar somewhere, or by using a pixel ruler, measure how many pixels in the direction of measure it takes to go 4096 meters in both the North/South direction and the East/West direction. Depending on what the latitude is of the area you are terraforming, these numbers will probably not be the same. Divide 257 by both the EW distance and the NS distance to get the ratio you need to multiply the image size by, in each direction, to get the desired size for your image.For example: Measuring the East/West distance, point number one is at (285, 346) and the point 4km east of that is at (807, 349). Subtract X1 from X2 and you get an East/West distance of (807-285) = 522 pixels. To measure the North/South distance, return to Point one (285, 346), and move up to the grid intersection 4km north of the first point. You find this point to be at (281, 858). Now subtract Y1 from Y2 to get the North/South distance of (858-346) = 512 pixels. Now divide 257 by the East/West distance to get the East/West coefficient (257/522 = 0.4923), and divide 257 by the North/South distance to get the North/South coefficient (257/512 = 0.5020). These are the coefficients you need to multiply the current image size by to make it scale accurate in the North/South and East/West direction. If the image size were 3450(width) x 3844(height), you would multiply 3450 (current East/West distance) by 0.4923 (East/West coefficient) which is 1699 and multiply 3844 (current North/South Distance) by 0.5020 (North/South coefficient), which is 1930. So, you need to resize your image to 1699 by 1930. Open up the tiff file you saved from Microdem without the grid, and resize it to the needed size (1699x1930 in this example). Note: I suggest measuring a minimum of 4096m distance to get descent accuracy. You may measure a larger distance than this, just take the number of meters you measured according to your grid divided by 16 and add one to the result. Then divide that by your pixel distance. So, if you measured 16,384 meters, you would divide (16384/16) + 1, which is 1025 by your pixel distance to get the desired image width in that direction. Do the same for the other direction. Since these DEMs are derived from satellite photos, docks, shipyards, and ports appear as coastline instead of seaports. I typically go in and simply "paint" water (RGB=65) over these obvious rectangular protrusions from the coast. before after Also, small rivers are not accurately interpreted. The smallest river that I have been able to make by importing from a greyscale image is about 100 meters from shore to shore. For this reason, any rivers that are not necessary for the look and function of the region and are narrower than 4 or 5 pixels I usually paint in with the surrounding elevation level (almost always RGB=86). Here is a screenshot of the creeks that I deleted: before after However, some rivers or areas of ocean are necessary for the look of the region even if their final width will be slightly larger than in reality. Here is an example from our Manhattan region: The area highlighted by the green rectangle is the small stream of ocean that I did not fill in with RGB=86 because it would have connected this island to the mainland. The next step is quite possibly the trickiest and the most subjective. Unfortunately, the DEM data does not have underwater depths. Because of this, we were forced to choose an arbitrary depth for all of the water (RGB=65). However, the way SC4 interprets these greyscale images when it imports them is not absolute, it interpolates them. Depending on the RGB difference between the coast and the sea floor it is ajacent to, it either causes an extremely sharp dropoff cliff, or it creates a more gradual elevation change by eating away at the shoreline, making your land masses smaller. The steep cliff looks really bad on a coastline, and that's why we chose RGB=65 for the ocean floor instead of something deeper. The end result is that if you import the map as it is now, the shorelines will be receded from where it appears they should be on the jpeg you imported. If you don't care about preserving these last 50 meters of shoreline, don't worry about it. However, if you want it to be as accurate as possible, or you have small islands (less than 250m across, or less about 16 pixels) that could turn into stumps or completely disappear, this is what I recommend doing: You basically need to extend the shoreline gradually into the water so that when it is interpolated, the resulting shoreline will be in the right place. The best way I've found to do this is to select the water with the magic wand tool and do an edge-->dilate effect enough so that it adds about 3 pixels to your shorelines. This can still fill up some small water channels though, so after I do that, I simply go in and redraw the small waterways that need to be there with a very small Width = 1 pixel paintbrush painting RGB=65. Now is the easy part. Simply decide how big you want your region to be (16km by 16km is standard) and crop an area out of your tiff that corresponds to that much area. For each direction, you multiply the number of kilometers you want the region to be in that direction by 64 and then add one. The region sizes must be in multiples of 4 kilometers, so you cannot have a 15km by 13km region. Each dimension must be evenly divisible by 4km. I chose to use a 16km by 24km area to fit all of Manhattan island into my region. So, my image size was 1025 by 1537: crop the selection out of your tiff file Now you convert it to a greyscale image (gif, bmp, or jpg). I usually use bmp because I'm terrified of jpeg or gif compression messing up my hours of work. You will probably want to create a custom config.bmp file to control where different sized cities in your region are. Ordio has created an amazing program that allows you to overlay city sizes on top of your greyscale image so you can easily plan where to put your small, medium, and large sized cities. Find the program here. First open up Simcity 4 and create a new region, name it what you want, and exit Simcity. There is not much documentation on the program, but it is fairly straight forward. Once you start the program, select Map-->Open. Find your greyscale image and select it. Now click on the "Overlay Config Over Region" button on the top (highlighted green in the screenshot below). The map should look something like this: create your config.bmp file Use the controls in the program to customize where which sized city goes. Blue is large cities, green is medium cities, and red is small cities. When you are happy with the way it looks, select "Config-->Save". Navigate to your "My DocumentsSimcity 4Regions{YOUR NEW REGION NAME}" directory and save the config as "config.bmp" in that directory. Start up SimCity 4 and load the region that you just created. At the main region view (not inside a city), press Ctrl+Shift+Alt+R and it will bring up this screen: import your greyscale image Find the greyscale image you are using, select it, and click 'ok'. While it is working, it will show you flat city squares for the size city it is currently working on, as if you are opening a city of that size. If this does not happen, most likely the image is not converted to greyscale, or it is the wrong size. Also, sometimes I have to physically type the name of the image into the dialog box instead of double clicking on it. It will take quite some time to calculate the region's terrain. In my experience, it takes roughly 3-5 minutes per 4km squared block, or 12-20 minutes for a standard 16km by 16km region. However, the speed of this is dependent on the speed of your computer. Once it is done, you will have a brand new scale accurate region!!! You will probably notice that most of the coastlines will look sort of rough. Unfortunately there is no good remedy for that. It is another disadvantage of the satellite data not having ocean and lake depths. If you want it to look more like the "smooth" tool instead of the "erode" tool in god mode, simply use the smooth tool on each city before you start building on it.

I think car paths were coded to avoid this because of highway overpasses. Think about that for a second. Since the RULes do not differentiate on height, there are several situations where they do not prevent level jumping because of 'odd' tiles. Many, but not all of these are highway overpasses. These 'special' situations have override code in the executable which we cannot change. Many years ago, we worked to find quite a few of these, and Maxis did an amazing job of going through and finding and fixing almost all of these situations for the RH patch. Some may have been missed, and certain desired puzzle pieces would require additional overrides in the executable, which can only be done by Maxis.

A brief note to everyone who has worked on the NAM: HOLY SHMOLIES, BATMAN! I step away for a few years, and you have created a veritable cornucopia of new network possibilities. What you have created is nothing short of incredible. Over the past few years, I have gotten ever more busy with going back to school (while working full time) etc. So even if I did remember anything from the early transit modding days, I wouldn't really have much time to help out. In the mean time though, I'm hoping to spend a couple hours a week actually ENJOYING the fruits of all of your labor. It is... simply incredible. Believe it or not, I never really spent much time playing SC4 even back in the day. I spent all my time looking in RUL files Three cheers to everyone!

Please forgive me, Larsz, for re-doing your topic. I just wanted to make it easy to read and follow, with a full checklist and other information in the beginning. Welcome to the home of Rush Hour commute testing. I will be maintaining and updating a report including all discoveries we have made once they are understood and corroborated. Please click here to access this report. Please have a realistic expectation for the 'new' pathfinding engine in Rush Hour. It is obvious that they had to rewrite it, since it now includes morning and evening commutes. However, it is unclear how many under the hood changes they made to the actual code. MaxisFrank and MaxisKevin (producers of SimCity4) have both stated that the heuristic for the pathfinding engine was set where it is for performance reasons. So don't expect perfect pathfinding. I am thrilled that so many people are excited about exploring the commute engine in Rush Hour. However, in order to keep this thread easily understandable and productive, I ask a few things from all valuable contributors to this project: Read the entire commute time and pathfinding report to familiarize yourself with some things we found about the original game, and enough of the travel time testing... thread to familiarize yourself with some of the testing methodology we found helpful. Review the current version of the Rush Hour Commute Report so that we don't have to keep going back over issues that have been covered. We will happily answer questions, but the reason for me keeping this report is so that most questions can be answered before they are asked . Post as clearly as possible, using cropped screenshots labeling what you are reffering to, text formatting, colors, and being as analytical as necissary to explain your findings. Be respectful to maxis. They wrote the pathfinding engine and all the things about this game in the first place. We are doing this in order to better understand what the mechanics of the game are, so that our community can in turn, create better cities. Excess unfounded complaining will not get us anywhere closer to our goal. Our Tasks: These are the tasks we need to do, roughly in this order, since some of them are dependant on previous findings. This list will be updated as we accomplish tasks and find new ones that we need to do. Verify travel speeds Verify the route querry tool's authenticity and accuracy Study the effectiveness of the new pathfinding engine as compared to the old one Test interchanges for correct traffic flow Test inter-city commuting Test Mass Transit usage requirements Verify Tile dimensions I think that just about does it. If there are any new ideas, let me know and I'll add them to the list. Right now I'm off to my neighborhood 24 hour wal-mart to hopefully pick up a copy of Rush Hour!

Welcome to the new home of all things pathfinding related. This thread will cover the following: 1 - Experiments, hypothesis, and discoveries about the current pathfinding engine for sims walking and driving to work. 2 - Presentation of ideas and testing on alternate algorithms the pathfinding engine could use. It will NOT include anything about pathfinding for mass transit. For now, keep that in the "Mass transit testing..." thread. Thats all folks. Have fun, and good luck!!!

I've done some extensive testing recently on this subject, and I think I've narrowed down the two main issues or bugs which currently exist that you have to watch out for to keep from seeing the 'dissapearing' simms phenomenon. The first is more of a limitation of the programing. For some reason, the number of sims commuting through a neighbor connection was stored as a UNIT16 number in the dat file, which basically means that you can't have more than 65535 sims going out or coming into a city at a single neighbor connection tile. The second is far more complex. Somehow, the building development engine, which decides where and when to build new buildings to satisfy demand is feeding the pathfinding engine strange and bogus data for short spurts of time right after buildings begin to develop or fill (I'm not sure which). The result is that upon entering a working city, and seeing a bunch of C or I buildings develop, route querrying the connection point will reveal intermittent jumps (and very occasional dips) in the number of sims using the connection point. It doesn't seem to settle down and go back to the actual number of sims coming into the city until all development ceases, which usually means that all demand is satisfied. The problem with this is that if you happen to pause the game during one these spurts, the commute data never gets rectified again. Once you have many sims commuting into a city, it is also quite disconcerting to see your traffic congestion graph go from green and yellow to mostly red for an instant, and then back down. When I had about 150,000 sims coming into a region, it would regularly spike up to about 280,000 sims, and then go back down. If you pause and save it when it's spurted, your a gonner. It doesn't stick at the high number, usually it goes way low as a result. I'm not really sure why or how yet, but hopefully soon I'll post up some pictures and have some plausable explinations. For now, make sure development is not going on, and that your incoming neighbor connections are completely static before pausing and saving a city. Otherwise, your regional commute data will be incorrect, which contributes to nasty things, like sims assuming thier commute is 120 minutes because they can't actually get to the city to see how long it is. In theory, this 'could' be a cause for some zones showing long commute times when others do not, but only if those sims are commuting to another city to work. Happy playing!

Could I interest any seasoned BATters to edit a transit s3d tile, to allow for uber-wide freeways? The concept is this: If you placed two freeways of the same type (elevated or ground level) directly next to each other, they would magically turn into a single 6 lane per side freeway. For the full project, we'd need about 20-30 s3d tiles, as well as gluing some together for preview models for the interchanges. However, to start, I ask that someone who finds this interesting simply does the first piece, so that I can make sure there are no weird side effects: What we need is someone to take highway piece 0x02001500, which includes the s3ds at the following Instance IDs: 0x02001500 0x02001501 0x02001502 0x02001503 0x02001504 Take the center barrier, which is on the south side of the tile, and replace it with one half of a lane stripe, such that if you take two of these tiles, one of them flipped along the horizontal axis, the lane stripe is complete and looks correct. To make it look right, you might have to widen the other two lanes slightly, to make all the lanes even widths. In any case, if someone wants to do this, I'd be more than happy to show you what it can look like in the game . If we get this tile done and there's more interest, we could go ahead and do it as a complete upgrade to the SC4 freeway network.

Date: 1/24/2006 10:02:08 PM Author: ardecila t7t: using Method B, how would a GLR drag be initiated? If you freed up the second ElRail RUL, would that enable you to add a new drag tool/icon? I understand that you have two solutions to continue a drag, and then prevents are in place to make it choose a GLR 02000200, but how does it get onto GLR in the first place? Do you simply start the drag from a ramp puzzle piece, like Method A uses?quote> Yes...unfortunately. As smoncrie said earlier, initiating glr with a network tool from a different network requires a unique piece to begin the domino effect. Essentially you would plop a puzzle piece and then drag from that to the rest of the network. There are a number of interesting ways to accomplish this though where it might appear completely transparent to the end user. The el glr ramp could be one of these 'starter' puzzle pieces, but we might be able to wrangle glr stations into spawning a starter piece, in which case the user just plops a station and starts drawing glr from it. No guarantees on that method though, I'll have to refresh the little knowledge I once had about the transit enabled lotconfig property (rep 13?) and do some experimenting. I'm all ears to any ideas you guys have . Ultimately glr will have to have some sort of 'starter' puzzle piece before any glr can be drawn from it, regaurdless of which approach is taken.

Date: 1/23/2006 8:07:24 PM Author: qurlix the7trumpets/smoncrie: (@t7t) If we are going to keep system A, we also must explain the flag bouncing routine to you (for dealing with multiple successive intersections).quote> Yes, this would help a lot. I have read little snippits of this so called 'flag bouncing' but I haven't seen it layed out and can't really imagine it from scratch without a few more clues I can't see any problems with the prevent method, except for GLR-El intersections...I'm not quite sure how that will work out. Then again, we aren't quite sure how they'll work out the other way.quote> Ah, I knew there was something I forgot. Glr-el intersections (and glr-glr) would be treated just like any other glr piece, with prevents for each exiting glr side attaching to an el piece. Seems simple to me, but maybe I'm not considering something important. However, before I grasp this flag bouncing sceme I can't really compare the two methods on these glr-glr el-el and glr-el intersections. PPS: We also need to set out a specific way to make draggable pedmall. We could use your prevent method for this too. Then, again, because there are no tile-differences from pedmall to pedmall piece, there would be very little override code, so that may be easier. -qurlixquote> ...7puts his thinking cap on...time to dream in RULes

smoncri:e Thank you very much for your explination, it's all starting to make sense now The basic idea (using overrides to domino-effect {glr}{el} -> {glr}{glr} replacement) is what I was thought you were doing, but the added information on glr specific tiles (90 degree turn and T intersection, for instance) is very helpful. Don't let me slow you down, but the way I see it there are two possibilities. I really don't know which would have better performance, or if both are even 100% possible, but I'll try to lay them out below to at least help myself to think through them 1. Convert {GLR}{EL} to {GLR}{GLR} with override rules. This is the way you have described. It does require quite a bit of complex RUL override coding though. As you mentioned, the endpiece (RUL code 02000000) does not get converted with the first RUL override line. To do that, an additional override line is necessary. This theory extends to all curves, intersections within lightrail, and intersections with other networks. If the domino effect is to continue through those places, RUL overrides have to be made in the following manner: {GLRa}{ELb} -> {GLRa}{GLRb} Where 'a' indicates all tiles with an eastward RUL code matching the westward RUL code of 'b', and where each GLR tile 'b' is a symilar looking GLR replica of the 'b' elrail piece. For example, the following GLR tiles would need override replacement lines with each EL piece listed. So, there would be an override line for the first GLR tile next to each one of the EL tiles listed and so on. And this list is only for the 02 connection type. {GLR 00000200} {GLR 02000200} {GLR 02020200} {GLR 02000202} {GLR 02020202} {GLR 00130200} {GLR 02130200} {GLR 00000211] {GLR 02000211} {GLR 00130211} {GLR 02130211} {EL 02000000} {EL 02000200} {EL 02020202} {EL 02110000} {EL 02110200} {EL 02000013} {EL 02000213} {EL 02110013} {EL 02110213} 11*9 = 99 RUL override lines just for the 02 connection type. And this doesn't include intersections, meaning it would be several hundred lines of code. Using this method would also require some creative solutions for the 90 degree pieces, T, and X interchanges for GLR (as you already mentioned). Drawing up to, but not into existing glr seems plausible but confusing to the end user, and there may be instances (although I cannot think of any) where the user does NOT want that to result in a GLR intersection or curve. This method would work though. Another solution for the 90 degree issue is to actually create eltrain pieces symilar to the 90 degree turn pieces, and then use override rules to prevent them from appearing next to any other eltrain pieces. This should ensure that they are only used as placeholders when they are about to be converted to glr (next to a glr track). There is a chance that red draws would occur because of things being prevented or overriden in the wrong order. This can be corrected by reordering the overrides RUL, but it is extremely difficult to track down these bugs. The final solution would be to abandon the idea of 90 degree turn pieces on GLR. This is my personal favorite, but I suspect the users of GLR would balk because they have gotten used to 90 degree turns and planned thier cities accordingly. So I suppose this isn't really an option. 2. Add railRULes for glr pieces, and use overrides to prevent GLR pieces from being continued as an eltrain piece. I think this method would be easier in the long run, but if you're more comfortable with the first method, don't let me slow you down too much. Let me explain how this would work though: You would combine the two existing simple railRULes files into one, and then use the now empty RUL file to create simple RUL entries for all GLR tiles. In the first method, you use the eltrain tool to draw {EL 02000200} and then using the following override: {GLR 02000200} {EL 02000200} -> {GLR 02000200} {GLR 02000200} In this method, there are actually two solutions to the network drawing provided in the simple railRULes files, {EL 02000200} and {GLR 02000200}. Then you use a prevent RUL to prevent EL from being built as a continuation of GLR: {GLR 02000200} {EL 02000200} -> PREVENT (0x00000000 IID) It would then choose the GLR piece instead of the EL piece. To me, this seems like it has a number of advantages: 1. 90 degree problem is mostly solved. Simply draw it the way you do normally, into or from the 02000000 piece to create a 02020000 piece. Since the GLR piece is the only tile with RULes that satisfy 02020000, GLR is drawn. Prevents would still be necessary though, to ensure that GLR 90 degree turns don't get drawn in the middle of your EL network. 2. Less likelyhood of bugs. Since all the overrides are Prevents instead of replacements, each RUL line only has one pair of instanceIDs instead of two, which means bugs are easier to track down and less likely to occur in the first place. 3. Easier maintenance of code. While it does require more lines of code (simple rail RULes have to be added for all GLR pieces), it is easier to add GLR pieces as textures get drawn by inserting an additional RUL entry into the simple railRULes file and then Putting in the prevents necessary in the overrides file. This method would still require a large number of RUL override lines, but they would be much easier to write and bugfix since they are prevents instead of actual replacements. 4. 3d Network Interchanges. GLR running under an elevated highway is inherently different from eltrain ramping over an elevated highway. An oirthagonal eltrain ramp over orthagonal elhighway takes up 8 or 10 tiles, while orthagonal GLR running underneath orthagonal elhighway takes up 2. With this method, you simply enter simple RULes for glr going underneath elhighway in the simple single tile multinetwork intersections RUL (sorry, I can't remember the real name of the RUL file). Then you find the first tile in the eltrain ramp over elhighway and prevent it from drawing next to GLR, and prevent the GLR under elhighway piece from drawing next to elrail. While it may be possible when using the first method to use overrides to convert all 8 or 10 eltrain tiles to straight glr tiles, it makes it more difficult to draw glr over/under 3d network intersections since you have to first drag GLR 10 tiles across the el highway and then buldoze most of it until you have the shape you want. ---------------------------------------------------------------- In general, the second method seems to me like the slightly longer bug slow and steady way to win the race. I may very well be overlooking some show-stopping problem with it though, so please attempt to shoot holes in it before you decide to use it Like I said, the method you laid out will work, but it may have usability issues and a higher chance of bugs cropping up or being more difficult to solve. In the end though, since it will only be done one way we won't know how difficult the other method is, and the grass will probably seem greener on the other side of the fence so we'll wish we chose the other method...oh well. Good luck, and thanks for having patience with me as I re-orient myself with what's goin on.

smoncrie: I have to appologize if I have confused everyone more, so I'll give a breif synopsis of the relevant information that I've heard from Kevin back in the bugfix era or tested on my own. Then I'll provide some thoughts which should be ignored if my understanding of your methodology is incorrect. How does network dragging work? The process is a fairly straightforward, but can become confusing if it's not kept in context. When a draw is initiated, RUL data of the appropriate flags is entered into the tiles you are drawing. For instance, if you use the road tool to draw a five segment orthagonal road, road RULes symilar to the following are added on their respective tiles: 02000000, 02000200, 02000200, 02000200, 00000200. Once those RULes are entered into memory, the fun begins. The game has to decide which transit tiles to display (and build when you let go of the mouse button). For each tile which contains RUL data (is a transit tile) within 2 tiles of the current network draw, the following flow is initiated to find the right transit tile IID and flip/rotation value. I should add that it may extend to 3 tiles from the network draw, but I'm pretty sure it's 2, I just haven't checked in a long time Case: tile contains network data for only one network 1. Look in the first 'simple RUL' file for the applicable network, these are the RUL files with low IIDs 2. Look in the second 'simple RUL' file for the applicable network. 3. Check the complex interchange RUL file (the one with the checktype and rotation ring lines) and search for a solution. Only use a found solution if it's the only one found, or autopromt is enabled (in which case a prompt is displayed). 4. Look in the Overrides RUL file for a line which contains the IID of the tile it has decided to use in the first pair in the declaration. When it finds an applicable line, it checks that line against all 4 bordering tiles. If a match is found, it replaces it with the second pair of tiles, and then looks in the overrides RUL again for each one of those new tiles. This continues until no applicable overrides are found. If there is no solution found after step 3 for any tile, it results in a red draw. In EVERY step a solution does not kick it out of search mode, but it continues to go through the whole file, using the last found solution. This can sometimes be used to our advantage, especially in the Overrides file. Case: tile contains network data for two networks 1. Look in the simple intersection RUL file and search for a solution. 2. Check the complex interchange RUL file and search for a solution. Only use a found solution if it's the only one found, or autopromt is enabled, and then display a prompt. 3. Look in the Overrides RUL, same process as the single network tiles. Likewise, if no solution is found after step 2 for any two-network tile, a red draw results. Concerning 'custom' RUL codes, I really don't get exactly why karybdis was suggesting them since you can't really draw custom RUL codes. My understanding is that the network drawing exe code creates the RUL codes, which the engine then tries to find a matching tile. It is surprising that using the intersection ordering RUL like you did didn't work though, since you weren't really drawing anything. My guess is that the orientation you were trying to plop it in was a flip/rotate that you didn't put into the rail RUL file. The hard way is to manually create all 8 possible flip/rotations in the rail RUL file. The easy way is to copy all the rail RULes into the first file and then put a #Transmogrify header in the second file, with one declaration. For some reason, the game seems to want to use flipped tiles when un-flipped will work...but I never tracked down why, I just gave up and put in all the flips and rotations when it became a problem. ------------------------------- Now, here is my current understanding of your ideas for dragable GLR. If I'm wrong or confused, please correct me and give me a little one of these: I think you're using a custom interchange piece defined in the interchange RUL (glr to el ramp) which is then checked in the overrides RUL to see if the glr side is connected to an el network piece. If it is, the override RUL changes it into a glr piece. From then on, if a glr piece is connected to an elrail piece, the el piece is changed to glr. In this method, the glr really is part of the elrail network (and will be reported as such in transit maps, etc) which is probably a positive thing, but it does bring up its own challenges: It would require override RULes for every 01, 02, and 03 RUL side eltrain tile next to every respectively matching 01, 02, and 03 glr piece. Whether this would create unacceptable slowdowns, delays, or crashes when drawing simply won't be known until it's tried. One unknown possibility is the 90 degree within one tile turn issue you have brought up previously. There is no 00000202 eltrain piece, so we would need to verify whether the eltrain drawing tool will create those RUL codes for the tiles in question. I presume the answer is yes, but I haven't tested it (maybe you have). glr crossings of 3d networks (like ground highway) are a potential challenge since they can take place over many tiles to ramp up and down over the obstruction. The easiest way to solve this (if it works) is to put RULes in for glr crossings and then prevent the eltrain solutions if it buts up against a glr track. Finally, although this is a step that could be put off until much later, some surveying needs to be done on whether it is intuitive for the user to build a ramp and then draw eltrain to make glr, and then buldoze the ramp if they want a glr only network. It seems wacky to me, but I suppose we don't have many options here. Okay, I think I've succeeded in confusing myself. I have to train myself how to dream in RUL codes again...I'm still waking out of simcity hibernation

Date: 1/21/2006 11:08:10 AM Author: qurlix t7t: All of the orthogonal el-glr intersections have been successfully automatized. Diagonal, that's another story. I'm not sure how much smoncrie has worked on the draggables recently, but we layed out an official system a while back. I've revised it several times since then, to accomodate for turns and intersections. The easiest way to describe it would be bouncing marker tiles back and forth. Yeah, that probably wasn't real clear. I'll send you a copy of the specs when I get a free minute. -qurlixquote> I'll be awaiting it, sounds like fun light reading I was more concerned with how el-el intersections would be differentiated from el-glr intersections if you use the el network tool to draw glr instead of using puzzle pieces. It would be doable with overrides, but because there are no wildcards in the overrides (ggrrrr!!!!!) it makes it quite a bit of extra override coding, which can actually effect game performance when drawing. I ran into this when using overrides to do most of the turning lanes RUL codes (think 200 extra lines of recursive RUL codes), which resulted in a 2-6 second freeze when releasing the mouse button while drawing an avenue. But alas, I will await the 'light reading'. In any case, I'm very impressed with what has been accomplished. I just hope I don't slow you guys down

Date: 12/14/2005 3:20:34 PM Author: smoncrie Inspired by the Rural Highway project, I have found a new way to do GLR tracks. A disadvantage of doing it this way is that the GLR tracks cost the same to build as elevated rail tracks. Another problem is that current GLR stations do not work on the new tracks. I tried doing the same thing in reverse for road to viaducts, but if it is possible, it is harder. quote> Okay, I finally found your post and it makes more sense to me now One thought: Doing this might make it difficult to do intersections of elrail-elrail, glr-glr, and elrail-glr. You might have to choose one for normal operation (probably elrail-elrail) and use puzzle pieces for the rest. I still have to do some thinking about this though. In the mean time, I am trolling around simtropolis a bit more so if you have some ideas or questions on RULs that you want to bounce off me, just let me know. Since I've switched over to Mac though, my actual modding ability is severely limited Great advances on the bridges though, I was always scared by the bridge ini files

Date: 1/11/2006 5:46:11 PM Author: qurlix My rundown: Draggable GLR, Dirt Street, PedMall - Same as what smoncrie said. Draggable El-Rail Over Road - Works perfectly fine. Can someone explain to me why these currently don't use the IntersectionSolutions? Why weren't they made draggable by default? quote> Disclaimer: I've been away for quite some time, and switched to a mac for my main platform (aaaahh, I finally enjoy using my computer I have been away for some time, so please forgive a little of my ignorance. With that said, the very idea of dragable GLR is awesome! Are you using the 'dirtroads' network to do this? I attempted this a long time ago, but got weird results and could only get sims to use the network if trains had a non-zero speed set for roads (not dirtroads). In addition, the traffic density went from zero to completely red as soon as one sim started using the transit tile. I'm certainly eager to hear your progress on this though Concerning draggable el-rail over road, it is possible and really easy, unless you want to have elrail cross over an intersection of two different networks. Each transit tile can only really 'hold' RUL data from two different networks (unless you've found a workaround). I always figured these pieces were done as puzzle pieces as a design decision to reduce confusion of not being able to draw el-rail over other networks in lots of situations. Finally, I'm still trolling, but being on a mac limits what actual modding work I can do now Maybe I should look into xcode and do something about that..... (mac's development platform). Amazing work on the NAM though, it's really a remarkable piece of work.

Date: 1/19/2006 9:34:18 PM Author: drdru7029 my problem is when I want to have a dynamic (one that is not a 'museum' and has the ability to change over time) neighborhood that is still roughly confined to a certain wealth level such as R$ or R$$.quote> One trick I have used in low density areas (stage 3 and below) that I only want low and medium wealth residents is to simply not give them any water. They complain, but zero high wealth folks will move in guaranteed. This doesn't work if you want medium or high density buildings though, since those require water to develop at all wealth levels. Not a perfect solution, but it does help for the middle class 'burbs'.

Date: 11/19/2005 9:21:41 AM Author:Bones1 I noticed something interesting in my region, and thought I'd throw a question out here. What is the longest walk you have seen in a route query, without using any cheats (such as the NAM commute mod). From my analysis of the traffic simulator in https://www.simtropolis.com/idealbb/view.asp?topicID=65161 , I concluded that pedestrians will walk a maximum distance of 21 tiles, which takes them 150 minutes of commute time. However, I've often seen mentioned in threads about mass-transit, that pedestrains will only walk 6-8 tiles.quote> You are correct as evidenced by your thoughtful experimenting. The reason that sims in practice will only walk 6-10 tiles is that the simulator gives a small advantage to walking so that if the job is 7 tiles away the sim will walk instead of driving across the street. At more than 10 tiles though, it becomes much quicker to drive, so the sim drives. If driving is made impossible, and mass transit is forced, the total commute time has to be lower than 120 minutes (slightly longer for intercity commuting) or else the sim won't go to work. Once you add the time to take the bus/train and time to walk from the destination station to the workplace, you usually only have 6-8 tiles to spare to get from home to the first mass transit station. The odd thing is that the starting city shows 21 pedestrians leaving, but only 1 shows up in the arrival city. I'm not quite sure what to make of that. Perhaps they get dropped because their paths would be longer than 21 tiles? quote> This is odd indeed, and it is one of the most anoying things I have found about the game. It's been a while since I tested it, but there is basically a short moment during the pathfinding simulator cycle where if you save it during that time, some sims are lost forever. They never appear in the next city, but they think they have a job with a commute time of 120 minutes + travel time from home to the city border. This can also happen if more than 65535 sims commute through a single neighbor connection tile.

err..I hope that topic makes sense. Lately, I have been trying to get eltrains to drive on the rail network. Nothing I have tried has worked. While I did make some silly errors along the way, I did change all the necissary paths and the speeds for the eltrain in the traffic simulator exemplar. As I continued testing to see why it wasn't working, I discovered that I could not get eltrain to go on any network other than elevated rail, I could not get monorail to go on any network other than monorail, I could not get trains to go on anything but heavy rail (ground rail), and I couldn't get cars to go on ground rail, elevated rail, or monorail tracks. Has anyone ever achieved something like this? Getting a MT vehicle to drive on a road or rail not designed for them, or getting cars to drive on any type of rail? I ask because I have lost all hope, and almost admitted my defeat, but I have a glimmer of a hope that the more experienced and insightful modders have already done something like this. I have concluded that there must be some switch other than the speeds in the traffic exemplar which allow a certain vehicle type to travel on a certain network. It may be in the exe (hopefully not), but I hope that if such a switch does exist, it's accessable in some exemplar somewhere. Thanks for hearing my ramblings. If you have done anything like this successfully, please let me know the setup. Thanks, fellow modders!!!

Date: 8/25/2005 8:22:49 AM Author: edcase2k4-thugangel1983 first, can i just check something? the NAM, ground light rail, and diagonal streets: they all use the ANT, right? and they also all use puzzle-pieces yeah? see i'm under the impression puzzle-pieces and the ANT are the same thing... quote> I have to qualify this by saying I've been away a bit, so something may have changed in the glr project, but as of a few months ago diagonal streets and glr did NOT use the ANT. There were plenty of attempts to use the ANT instead since it would make drawing the networks much easier instead of tabbing through a bunch of puzzle pieces in a long menu, but to my knowledge none of them were a success. No, the ANT and puzzle pieces are not the same thing. The ANT is an unused network, while 'puzzle pieces' are our little nickname for creating small interchanges which are used as sections of a custom network-looking thing (like the glr). Diagonal streets are simply normal streets with the rules recoded so that zigzag drawn streets will look diagonal. as far as my understanding goes the ANT is like a 'spare' transport network which Maxis decided not to use but still included for some reason; and this is used as the network type for puzzle-pieces created... well, that's what i thought anyway quote> It's a spare network, but not everything associated with the ANT behaves like the other networks. Case in point: when doing research to attempt to migrate the glr project to the ANT, I found that the speed of eltrains on the ANT was NOT determined by the eltrain speed for the ANT in the speed matrix in the exemplar, but by the car speed on the ANT. There were several other limitations and confusing things which seemed to suggest that not all the 'wiring' in the exe was complete for the ANT. so basically my intention is to create 'puzzle-pieces' similar to those in the NAM which are used to create custom overpasses, but are ground-road pieces with their own paths, props, and change sidewalk textures with the wealth of surrounding buildings (like normal road networks) the puzzle pieces would come is a variety of shapes and sizes (just like the NAM overpass puzzle-pieces) - mostly 1x2 and 2x2 for straight pieces; but a bit different shape for curves and diagonals quote> This is fine, but one word of caution: First of all, the 'lane changing' paths which you have put in are unnecessary, and in fact will cause the cars to change lanes very frequently instead of once in a while. The caution comes in because the game will automatically change lanes if one lane is full even if there isn't a connecting path. That means if a car is driving in the car lane and there are no busses in the bus lane, it may change lanes into the bus lane. To my knowledge, there is no way to prevent this within a single tile. the way to block cars from using the bus lane tiles is by plopping a 'BUS LANE' road marking 1x1 Lot over any plopped straight or diagonal bus-lane tile, with car traffic set to speed 0. these Lots will need to be placed at the start of any bus-lane and after any junction or series of junctions if the user wishes for the cars to not use the bus-lane quote> I'm sorry if what I said earlier was confusing, but you CANNOT set car and bus speeds separate for each lane, they are equal for the entire tile. The only way I can concieve of this working is having two transit lots for the entrance of a bus lane. It would be a 1x1 bus lane entrance tile, plopped on the roadway which would allow busses to exit the tile on the 'sidewalk' side of the tile, while only allowing cars to continue straight. Placed just outside of that on the sidewalk side would be a puzzle piece or bus station (depending on whether you wanted pedestrians to be able to board or get off the bus at that tile). This lot or puzzle piece would be 1x2 tiles, with the 2 tile length along the roadway. the first tile allows busses to come away from the roadway, and they merge back onto the road in the second tile. Then you just make the rest with puzzle pieces. Functionally this would probably give you most of what you're looking for, but there is nothing that can keep the cars or busses from switching lanes as I stated earlier. The challenge of this method is that this only takes care of orthagonal situations. An different implementation is required if you wish to use this with diagonal roads. Now, to answer the questions you PM'ed me: i> there should not be any problem with plopping a lone-standing Lot ontop of an ANT puzzle piece -- should there?? quote> There shouldn't be any problem, but you may run into challenges because of the 'buggy' incomplete status of the ANT network as a whole. I would stick to using puzzle pieces of whatever network you are extending, and then a transit enabled lot to separate the traffic by diverting busses outside the roadway and then merging them back in. ii> can you set vehicle speeds different for the two tiles within a 2x1 ANY ploppable puzzlie piece?? (i'm thinking it would be a good idea to put the speed of the bus lane tile a fraction higher than the car lane - so that buses travelling along that particular road will stick to the bus lane -- until they approach where they need to turn at a junction) quote> Absolutely NOT. speeds are soley determined by the network exemplar on a per-network basis, not on a per-tile basis and definately not on a per-lane basis. Each network enabled transit lot can have a different transitswitchcost (the time it takes to traverse the entire lot), but that must be the same for all modes of travel (car, bus, pedestrian, train, etc). However, transit lots can enable some modes to enter/exit a certain tile side of the lot while others cannot. The only foolproof way to keep the busses and cars from changing lanes is to put them on separate tiles, which basically means you're drawing an additional road next to this one and only allowing busses into it with a transit enabled lot.

Date: 8/18/2005 1:01:17 PM Author: edcase2k4-thugangel1983 out of personal interest and i suppose unrelated to this project: i would like to know how the NAM actually works regarding a particular situation -- in the case of road-type networks that cross over eachother; how are the paths kept seperate where they cross, if they have to be together in one path file? quote> Well, about 80% of the time there is no problem because the tile entrance sides are different for the two paths. For instance, when all the road paths underneath a highway enter on side 1, and all the highway paths enter on side 2 or side 0, there is no possibility of cars 'jumping' from a road to a higher level. Every once in a while though, there is a problem when two paths which exit different tile sides enter on the same tile side. Maxis' solution has been to code custom exception rules into the exe, so we have no way of solving such errors in custom created content if they exist, or fixing existing bugs (almost all of which were fixed in rush hour update 1).

First let me reiterate something: The main stumbling block I see in any approach to this is that separating bus from car/truck traffic is nearly impossibe if not impossible. Date: 8/17/2005 2:33:40 PM Author: edcase2k4-thugangel1983 if we cannot place lots side-by-side when they are plopped over networks, and we cannot lay a network over lots that are already plopped side-by-side, then how about laying network over network?! surely this must be possible because we can already do this with existing networks; and isn't there a mod which allows EL rail to be placed running along the top of road..? is that infact only a single network, combining road texture and EL structure, and combining road and EL paths? or is it actually two seperate networks running on the same tiles? my single question i guess would be is it possible to place ANT network tiles side-by-side then run a road-type network over it (or the reverse, place the ANT tiles after the road network)? quote> When two networks are drawn intersecting each other, there is a RUL file which tells the game which network tile to use in each situation. It looks at the RUL tile side definitions of the first network and the RUL tile side definitions of the second network, runs through this long text file of 'intersection solutions' and spits out an answer if there is one defined. Otherwise, you see the infamous red line and you are unable to draw the second network. Once the game determines which tile to use as the intersection it does not combine, change, modify, or have anything to do with the path files from the two individual tiles. The new intersection tile has its very own path file. This design is in fact what caused many of the transit bugs post-rush hour release. Since there are literally thousands of possible intersection tiles, there is one path file for all of those, and it's easy to write a '2' instead of a '1' somewhere creating a bug. For your application, this means that allowing busses to drive on the ANT but not cars and then defining a right lane only path file for ANT pieces and a left lane only path file for roads won't work when they are placed on top of each other since a new custom path file will be used for that transit tile. The only feasible way I can see to separate bus and car traffic is to design the system some way so that the bus lane goes through a transit enabled lot tile which the car/truck lane does not. That way you can define that only busses can enter/exit that lane. The advantage of using lots instead of network tiles is that you can define which vehicle type is allowed to enter/exit each tile side in addition to defining the paths. If you were to try to create a drive through bus station that was a network tile, there would be no way to allow busses through and block cars/trucks. With a lot however, this is possible. If what cjmarshal said is true, doing that gets a bit more complex. You would have to get really creative and create transit enabled lots which have that strange 'overlay other adjacent tiles with an overlay texture' feature, which may or may not be buggy, I've never tried it, just heard about it. Then you would create transit enabled lots which you place every other tile and draw the network through them. Visually, a oneway or road would HAVE to be two tiles wide, because you need one tile to allow cars/trucks through and one lane to allow only busses through. The diagonal versions would have to be one more tile wide as well. Likewise, avenues would have to be three tiles wide. I just hope I have answered more questions than I have caused confusion.

Believe it or not, I have considered this very idea in the past. To make a long story short, the transit and especially the automata system are simply not designed for this, so most of my attempts at designing a system like this have ended in headaches First to answer a few questions: Are paths defined in the path files by vehicle type? Can we use this to separate the paths of busses from cars? Answer: Paths are defined by 'transit' type. The valid transit types are (in no apparent order) walk, drive, heavy rail, subway, lightrail, and monorail. Freight train and commuter rail are copied from heavy rail paths. Truck, Bus, and Car paths are copied from drive paths. Therefore there is no way to define one path for busses and anothe for cars. Is it possible to use speed=0 settings to limit which vehicles can travel on a particular lane of a particular transit tile? Answer: No and No. Setting transit speed to zero in the tranit exemplar means that vehicle cannot pass through any tile of that network. Can a transit enabled lot have a base or overlay texture base on which network tile it is placed upon? Answer: Not exactly, I'll elaborate on how transit enabled lots decide where they can be placed: A transit enabled lot can be placed when any network tiles which occupies the land which the lot is being placed on conform to the RUL codes defined in a particular rep of the lotconfig property for that lot. In practice this means it's relatively easy to create a lot that requires a particular situation of network tiles, but it's not possible to create a single lot that will 'conform' to the network tiles underneath it. (Assumed) Transit lots cannot be inline directly next to each other. This is actually not entirely true. A few moths ago someone (smoncrie? can't remember now) posted a post in the R&D forum describing how create transit lots which could be plopped end to end. It basically has to do with how you code the RUL code lotconfig lines in the transit lot lot exemplar.So what does this all mean? The best idea I could offer is to make transit enabled lots for straight and diagonal versions of each network and code the RUL lines in the lotconfig properties so they can be plopped adjacent to each other. I suppose it would also require a start/end peice for each orthagonal and diagonal network you want. As you can see, the required number of textures/lots quickly baloons, but it seems like it would be feasible to tackle. Unfortunately I cannot think of a solution to separate bus and car/truck automata. Anything you define in the path file will apply to all three (bus, car, truck). The only thing I can think of is extending the bus lane into a bus stop tile to the side of the network and coding the paths so that only busses can enter and exit that tile. The automata engine will only draw cars/trucks in the right lane if it can continue for the next 3 tiles. Since within three tiles it enters a bus only 'bus stop' tile, car/truck traffic simply won't draw in the right lane, but will in the left. Unfortunately this is a sub-par solution since a bus stop every 150 feet taking up a tile of your city isn't exactly what the doctor ordered, it's just the only solution I can think of at the moment. The 3 tile look-ahead number is configurable, but it has quite a bit of impact on game performance. Once you get above 5, everything crawls even with low or medium automata settings. Understand that I am almost always a staunch supporter of using transit network solutions rather than transit lot solutions for things like this, I just cannot think of a way to do it without a lot. It is true that you could block non-bus traffic with the ANT, or an ant/road intersection piece, but this would block car and truck traffic through all lanes, not just the bus lane. Feel free to PM me if you have additional questions, I'm just away more than usual with RLS right now. Good luck to you!