Jump to content


  • Content Count

  • Joined

  • Last Visited

About the7trumpets

  • Rank

Recent Profile Visitors

150,745 Profile Views
  1. NAM General Support Topic

    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.
  2. NAM General Support Topic

    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!
  3. 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.
  4. NAM: Development

    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.
  5. NAM: Development

    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
  6. NAM: Development

    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.
  7. NAM: Development

    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
  8. NAM: Development

    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
  9. NAM: Development

    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
  10. NAM General Discussion Thread

    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.
  11. 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'.

    Outstanding Job. If you want to expand these, I'd include diagonal versions. There is a set of sample diagonal MT lots in a thread somewhere, rotate your great looking props and they could look like a nice set. Thanks again!
  13. One Way Highway Puzzle Pieces

    Date: 5/10/2005 9:24:24 PM Author:kassarc16 Ok, it's gotta be possible, but is anyone willing and able? Pieces: Diagonals Overpass puzzles for Road, Avenue, One Way, Street, El Highway Underpass for Rail, GLR, other One-way highways I'd really like to help, but I've never been able to get myself into even the basics of modelling or modding. Questions? Critiques? Comments? quote> This is definately a notable and worthy idea. For starters, don't let the fact that you haven't modded anything yet scare you. The Interchange tutorial sticky thread in this forum links to an extremely good tutorial on modding the 3d network pieces. Concerning your idea, it is possible, but there is one notable limitation everyone should be aware of before people try using it. It's not major, but there is absolutely no way to overcome it: Since the default pathfinding engine looks only at tile entry and exit sides for the current traveltype the sim is using, maxis uses exe code to override pathfinding in specific 3d network tiles in order to ensure that cars do not 'jump' from a higher elevation to a lower elevation roadway with no ramp. The intersections affected are any diagonal/orthagonal, orthagonal/diagonal, or diagonal/diagonal intersection between any surface and any other elevated road network. Translation: Almost all diagonal interchanges between highways and road/oneway/avenue/street that we create WILL allow the cars to magically 'jump' from the highway to the road, the road to the highway, or both. With that said, it is a good idea. I just wanted to make everyone aware of this limitation which is impossible to overcome.
  14. NAM General Discussion Thread

    By all means! The more people working on these things the better. It's a sticky thread in this forum at the top titled Interchange Tutorial Thread
  15. NAM: Development

    Date: 2/8/2005 5:36:16 AM Author: smoncrie I have discovered a way to improve the appearance of some of the NAM puzzle pieces. The game does not render some S3D models very well at some zooms, particularly those with rail, like the rail overpass. For puzzle pieces one usually uses 1 FSH, one S3D and RESORCE KEY TYPE 0 in its exemplar. Instead, I suggest one use 5 FSH files (one for each zoom) to make 5 S3D models, and use RESOURCE KEY TYPE 3 to point to those five models. This technique is used fairly often by Maxis. smoncriequote> Good point. I should mention that this technique is probably also used to save on memory and improve responsiveness at zooms further away than zoom 5, since different textures and models are loaded which consume less memory. Curiously though, not all interchange tiles use this methodology. So it's a little unclear whether they deemed it unnecessary or whether they just got tired of doing it