Sabretooth78

At the risk of necromancing, I figured I would chime in that if you did install to a "non-standard" location, it does appear to be sufficient to "fake" a standard folder with symlinks in lieu of reinstalling or dealing with the SC4InstallDir.ini process (which I was not able to get to work). For example, with the GOG Galaxy install path of C:\Program Files (x86)\GOG Galaxy\Games\SimCity 4 Deluxe Edition\: Create folder C:\GOG Games\ Drop a symlink of the folder "SimCity 4 Deluxe Edition" in "C:\Program Files (x86)\GOG Galaxy\Games\" into the "C:\GOG Games\" folder you just created. Replace the "damnControl.dat" as instructed above. Profit.

Just did, and that seems to be a good work-around for the RRW wanting to slope-conform. It also seems to help in some of those situations where a road will draw fine but the rail just gives the dreaded "failed smoothing terrain". Still doesn't solve the CTD fussiness on that one city tile, but I'm just going to chalk that up to a unique file-specific situation and a lesson in being extra-vigilant about having wide enough platforms on either approach. I get this, on my full plugins (less terrain mods and the Ennedi slope mod). Unfortunately it's not pointing out any conflicts - that would make things too easy... This response eluded me until I just noticed it today. Fortunately, this was just a "sandbox" of sorts to acclimate to the new version NAM. That said these are good thoughts to take into consideration. My play style is a little more "organic" though, so in such a situation the avenue would have been a pre-existing thoroughfare and any bugs like this may well force the late-arriving RHW to accommodate it - though that's not to say that local roads are immune to re-routing. As for the neighbor connection itself, it is a valid connection. I use a mod that hides the arrows:

I was/am running on a fresh install of NAM, so in theory everything there should have been to spec. Same with DBE, copied straight from the original download ZIP, along with the RRW patch from the SC4D forums. All of this in an otherwise empty plugins folder. I typically have my plugins number-ordered, so ordering shouldn't be a problem anyway - NAM is in a "970" folder and DBE in "998". At last attempt, just to make sure, I prefaced DBE with 6 or 7 'z's just to be sure; no behaviors seemed to change. The only caveats I can think of: I didn't clear out the Program Files plugin folder, but that only contains various DLL fixes and DAMN. I am technically running on a Mac, but in a Windows 7 VM. I wouldn't think that would affect load ordering but I can see how it would be considered a "non-standard" setup. Something city tile-specific. Would seem odd to be a corruption as it's a mostly rural tile, prior to zoning farming on it yesterday, the only action it had ever seen was the initial rail laying/DBE about 6 years ago (which was RRW - I early-adopted it despite the warts). I'll run that tutorial when I get a chance - for now I want to get back to playing.

Yeah, these are all things I had figured out a few years ago and now that I'm getting back into things once again, I have to relearn. They are definitely finicky, but I never had this level of difficulty. Edit: A little bit of playing around revealed that by removing RRW Tunnel and Slope Parameters (as suggested) along with removing NetworkAddonMod_IndividualNetworkRULs.dat from 1 Core, the leveling aspect aspect of the RRW appears to work properly. As I'm blissfully ignorant of what makes the NAM tick, I'm not sure if that's at all helpful, or if it even makes any sense - but that's just what I found. With that said, it seems no measure of file removal seems to cure the "allergic reaction" to pre-existing RRW that seems to cause the CTDs. I saved a copy of that particular tile and deleted all the RRW from it to try again, and it still behaves exactly the same. Perhaps there are still relics of the old code in the save file? I'll also try re-drawing with NAM 42 and try it again. The RRW that was drawn in it is about 6 or so years old - I'm not sure exactly which version it was drawn under but it would be something in the low-30s. Edit 2: A little more playing around and it seems to be some effect of slope stability. I may have been following a red herring by blaming the CTDs on the existing RRW - I was able to complete the following bridge on the same tile pictured previously. This follows following the method prescribed by the DBE instructions, loading NAM fully except for the files mentioned above. The tile outlined in red is the closest non-level tile to the bridge. If I extend the track onto that tile (click on the tile and drag onto the existing track so as to extend the diagonal), it'll CTD. In the test city pictured in my last previous post (which consists of a perfectly flat plain with a deep chasm running down the middle), I can drag a diagonal track across the chasm with no problem. If I terraform a small hill in the way of the track, and then extend the track into it (in the same manner that causes the CTD above), it'll happily flatten the hill one tile at a time, not unlike placing road stubs. I can only conclude there must be some secondary slope effect caused by the nearby road which is causing a crash? Anyway, by being careful not to extend beyond the perfectly flat terrain, I was able to complete the bridge (ignore the flags; if I load my terrain mod, the water doesn't disappear): After all this, I did get a couple random crashes, once while opening this tile on the next load with DBE removed (so as to connect everything up) and another time exiting to the region. Not sure if they're related, or maybe I was just due for a random crash. Fingers crossed... I still have a pre-bridge copy of the tile saved in case it's of any use in testing a fix.

No, it's not that. For one, the RRW won't level like the roads, resulting in this work of art: I then tried it in the locations I was working last night. It initially seemed to be a bit more stable, but once again a CTD when releasing the cursor. I'll play around a little more with removing NAM components to try and isolate, if nothing else than for my own edification.

I'm not quite sure if this is the best place to post this, but I'm having a heck of a time trying to build some diagonal bridges using the NAM DBE enabler - this is also while using the "zDBE RRW Patch.dat". I'm getting frequent CTDs after using various tools (road, rail and mayor-mode level terrain). This is also while loading with only NAM and DBE in my plugins. I was having some trouble isolating some particular mods which were causing the water not to disappear (I believe it may have been terrain-mod related), while also getting these CTDs, as I suspected it may have been a conflict caused by some other random mod. Clearly one of those can't be the sole culprit when the CTDs still occur with the NAM being the only other thing loaded. In particular, I can get so far as to place a RRW bridge, but as soon as I hear the rail placement "ping" sound, the thing CTDs. If I load into a sandbox tile with no existing rail, it'll still CTD. If I strip down further and load only DBE (no NAM), then it seems to work OK. Subsequently loading into an active city tile (with RRW), it seems to want to work OK, provided I don't get too close to any existing RRW pieces. I can't prove definitively, but it seems that RRW and DBE are still not playing nicely together, even with the patched DBE. Has anyone else experienced this behavior? Example - it will work, but only if I remove the track back some substantial distance and then don't get too close while dragging new rail (not to mention, there was at least one instance where the rail being dragged wasn't flat). It seems my only chance of getting this to work without some kind of foul play is without the NAM loaded. NAM loaded - it reliably CTDs upon cursor release: So basically, the only procedure I could get to work: Load DBE w/o NAM Ensure RRW segments are deleted back far enough from the DBE site Drag the network Save; exit SC4 Reload SC4 w/ DBE and NAM Place DBE starter pieces (carefully) Save and exit, reload w/o DBE as per instructions. Many areas of road and RRW will need clicking/re-layout to restore NAM overrides It's been a few years since I last tried using the DBE but I never had any problems with it. I want to say it was under NAM 36, but it could have been earlier. Unfortunately, I no longer have the installer to test.

@Flann Very nice - I never expected to see it tackled so quickly! Just curious, are there any other networks that such a configuration will be added, such as road or one way?

Thanks! I don't seem to play often enough these days to remember all those little tricks...

Playing around with NAM42: Originally I just wanted to see if the NAM had become more flexible with ramp underpasses, and it just got more complex from there. In reality, we'd probably have a safer configuration (probably a diamond/parclo hybrid at the avenue), but it was a useful practice in learning limits. For instance, with my slope mod, I don't think there's 0.1m of elevation to spare between the AVE overpass, off-ramp and STR/MIS underpass. After all, the grade on the STR can't be flexible!

Playing around with NAM42, encountered a weird instance of pathfinding. If I delete the on-ramp, they use the bridge as you would generally expect: Close-up of the neighbor connection drawpaths. Assuming I set the thing up correctly - seems like it would be pretty difficult not to: I initially had a right-turn slip on the on-ramp, but evidently there is a "missing" texture for such a configuration. Otherwise works OK: Finally, two questions about OWRs: is it possible to bridge RHW with a diagonal avenue without resorting to OWR in place of RHW4 (as I did here) I didn't see an option in the installer to reduce the frequency of OWR arrow textures. In the past I believe I always used the "1/2" option. Has this been removed, or did I just not look deeply enough?

Got that to work myself as well. I guess the moral of the story is "if at first you don't succeed, try it the other way around." Now I just need a 7.5m ERD over Flex RHW puzzle piece!

Long time no see; getting back into this and playing around with NAM 39. A couple of questions I've encountered; forgive me if these have been addressed before. Regarding 7.5m (L1) structures, I was curious whether some things are possible as it relates to simulating some more rural/suburban configurations. It's quite possible I'm trying to build some things that either simply aren't supported, or I'm just going about it the wrong way. First would be the minimum length required for a RHW bridge. While theoretically possible to create a bridge of 1-tile length with the Flex Height Transition on-slope pieces, it's not possible to drag a road under the structure pictured below. Should it be possible? With that being said; it is a viable alternative for plop water stream crossings. It is possible to build a 2-tile length bridge and get it to work with a road underneath (with a fair amount of RHW2 clicking around to get the bridges to connect) or with a 2-tile network such as an Avenue straight "out of the box" (below, lower). The shortest configuration that seems to accommodate a road easily is the 3-tile length bridge (below, upper), which is OK but in most real-life situations you would never find the abutments that far away from the road being crossed: Going the other way around, and crossing the RHW with the road, there are a couple of options. The lower crossing pictured below can be achieved using the 7.5m ERD puzzle pieces, but for an RHW4 only with the crossing pieces being ERD over one-way and the minimum median width being 5 tiles or else the on-slopes don't work right. The upper crossing can be achieved for any median width provided the abutments are set back a tile (somewhat unrealistic as I noted above) so as not to cross the RHW at the end of the draggable ERD, which causes problems. Are there plans to add more support for short crossings of 7.5m ERD over/under RHW?

Seems it might be an issue with WinXP, because I'm noticing the same behavior. If I view the task manager processes list, SC4 appears but disappears very quickly. Doesn't make a difference whether I place it in the My Documents or Program Files plugin folders. I'm running a WinXP (fully updated) virtual machine in Parallels 14; macOS 10.13.6 High Sierra. The DLL works fine in my Win7 virtual machine. I suppose that's good enough for me - I didn't plan on creating disasters but if I have a nuclear incident I know I can clean the city up in the alternate OS - but that doesn't help the OP.

Keep it in there then.

Just to provide another data point regarding running SC4 on a MacBook - I have a mid-2012 MacBook Pro (9,1). Feel free to skip to the end if you just want to cut to the chase. *** To make an even longer story a little shorter (and to partially explain my relative disappearance from this site), back in early 2016 I got back into flight simulation and while that (MS FSX) ran surprisingly well, in the same basic Parallels VM as I had gotten SC4 to run well, Windows XP itself on the other hand was proving itself to be woefully inadequate for this use. This prompted me to purchase a Windows 7 key and try running in BootCamp; shortly after which I learned that Apple in their infinite thoughtfulness did not allow the BootCamp partition to "see" my discrete nVidia graphics chip. Windows 7 did run much better than XP in Parallels, however, so it was a move in the right direction. Figuring I now wanted to consolidate everything and didn't want to "maintain" 2 different VMs (as if that's such a hassle), I jettisoned XP for all of my Windows VM-based gaming (also includes the RCT-RCT2-RCT3 series along with Civ IV). I then soon learned that while SC4 seemed to run OK under Windows 7 (probably due to brute force of hardware), it didn't look as good. I tried a bit to get it to play a little nicer (see link at the end); gave up and accepted it and then just kind of drifted away anyway. Fast forward to a couple weeks ago when I got the itch to get SC4 and C:S running again. I have long since pushed the flight simulation (now in LM Prepar3d) onto its own dedicated custom build (running Windows 10 now, I was dragged into it somewhat grudgingly), and part of this new urge was because "hey, if I'm doing a long flight, I can play something else during cruise!" Call it simulation multi-tasking. There was a small catch, though. Back in 2017 I had a hard drive fail - and while I had backups and for the most part didn't lose a step, I never fully fixed the linkages between my VM and all my custom content (I symlink custom content for all my games into the VM from the Mac side, so the VM itself is essentially an easily replaceable wrapper). So in just a few hours' work I had everything back up and running again in the Windows 7 VM. Again, I ran into the issues of graphical appearance. I wasted a few hours fooling with the Graphics Rules and Video Cards files to no avail at getting "Fast Card" to appear in the config log. Finally it occurred to me that while I had long since deleted the Windows XP VM, I still had the installation materials. Little more than a few hours later (with a little cajoling to get Windows Update to run) I had a fully working setup, looking and running well, with "Fast Card" and minimal edits to the Graphics Rules and Video Cards. The only thing left now is to play. *** tl;dr - If you run Windows SC4 in a virtual machine on a Mac, you're much better off sticking with Windows XP, if you can. At least vs. Windows 7; I can't speak to Windows 10. Of course the disclaimer here is that I don't know how the newer MacBooks operate in this regard, maybe with newer models (and newer versions of macOS (or whatever it's called now), BootCamp allows the Windows partition to "see" the discrete graphics chip.