NAM General Support

[Tarkus 6,932]

25 minutes ago, rogerpowell said:

I see no vehicles in my game. I have installed the latest NAM. I have not had this problem before.

If you've by chance installed a "24-hour" version of the Automata Controller, traffic (particularly on lighter-traveled transport networks) will tend to not show up so much during non-commute hours.  The automata (the technical term in the game for the vehicles) are also generated based on the traffic volumes and congestion levels as well.  If you're running a higher-capacity version of the NAM Traffic Simulator, that can also mean fewer vehicles appearing, since the congestion levels will be lower.

The "Radical Persistent" option (not the 24-hour version of it) is going to give you the most visible traffic, generally speaking.

-Tarkus

[Haljackey 17,302]

11 hours ago, Sabretooth78 said:

 

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:

 

 

Just a note this config is not supported. If you want a slip lane like that, drag one way road out of the curve (that is supported) and then drag MIS into that. It should override to a much better looking connection.

[Sabretooth78 808]

43 minutes ago, Haljackey said:

Just a note this config is not supported. If you want a slip lane like that, drag one way road out of the curve (that is supported) and then drag MIS into that. It should override to a much better looking connection.

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

[matias93 7,535]

17 hours ago, Sabretooth78 said:

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:

This is certainly an issue with network capacities making the routing go haywire. RHW is obviously faster than avenues, but it shouldn't be that much as to justify this route. I guess @Lucario Boricua should see it.

[Lucario Boricua 7,028]

57 minutes ago, matias93 said:

This is certainly an issue with network capacities making the routing go haywire. RHW is obviously faster than avenues, but it shouldn't be that much as to justify this route. I guess @Lucario Boricua should see it.

I'm looking at the corresponding screenshot (quoted below):

 

Quote

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:

 

My thoughts so far:

• Simulator Z uses a really strong intersection approach congestion effect. Using the direct trajectory here (diagonal avenue) involves 4 sites where this congestion manifests (MIS diagonal intersection, overpass over each of the RHW-4 directions, 2nd diagonal MIS intersection). The odd path seen here, surprisingly enough, has 6 such instances (1st diagonal MIS intersection, MIS on-ramp, RHW-4 just before the neighbor connection loop, RHW-4 under AVE-4, MIS off-ramp, 2nd diagonal MIS crossing with avenue).
   
• However, the base speed of RHW networks is much higher than that of cars along the avenue, 3 times greater. Even with this convoluted path, the RHW-4 + MIS routing is actually faster than going straight along the diagonal AVE-4 overpass. This actually more than compensates for the 6 intersection effect sites along the RHW-based route, as you'd effectively need 12 intersection effect sites to have an equivalent slow-down, before accounting for overall route length.
   
• The neighbor connection system we use is called the Neighbor Connector Loop, which we use to do connections for multi-cell override networks derived from single-tile base networks (wider NWM and RHW other than RHW-2 and RHW-3). The game needs to detect that it can send bi-directional traffic across each cell of the connecting network, and the paths here are designed to do just that while still looking 'normal' at the surface.
   
• One suggestion I have for this situation is using a Maxis Ground Highway neighbor connection and using the RHW-4 S-curves to transition the RHW-4. You'll definitely need to re-work the MIS ramp closest to the neighbor connection to make this option work. It's not pretty, but it works.
   
• Another suggestion would be to try and shift the crossing avenue to be more distant from the neighbor connection. From what I can see in this screenshot, there is some available space to the left of the suburbs along the bottom edge of this view. I don't know how routing of the avenue works beyond this area, and as such, this re-design would likely involve more changes elsewhere.
   
• I also notice the neighbor connection lacks the arrows, make sure to drag the RHW-4 towards the city boundary. It's possible that you could get a better commute behavior this way, especially if there's available jobs in the neighboring city.

[Wiimeiser 444]

4 hours ago, Lucario Boricua said:

I also notice the neighbor connection lacks the arrows

There's actually a mod that disables the arrows; I use it myself.

[Tarkus 6,932]

On 10/5/2021 at 11:28 PM, Peter N N said:

hello guys

I installed NAM 42 to my SimCity 4 delux edition after installing the game carshes out to the desktop during loading my own city and 4GB Patch changes the date of the EXE file of the game which make it not working after using the patch . My PC is HP laptop G62 notebook OS is Windows 10 (64-bit)

The 4GB Patch should be fixing your crash-to-desktop issues upon loading your cities.  It sounds like the patch wasn't properly applied for some reason (the date on the .exe can still change even if the patching is unsuccessful).  I'd recommend either reinstalling the game and then the NAM, or going for a lighter install (no RHW) and choosing the "LowRAM/NoRHW" Controller option in NAM installation (which doesn't require the 4GB Patch to run).

-Tarkus

[Haljackey 17,302]

I've made a vid going through all the networks in the road tab-

 

[Flann 1,709]

On 10/5/2021 at 8:24 PM, Sabretooth78 said:

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:

 

Working on it :

[AsimPika3172 1,136]

@Flann Awesome!!!!👍

[Sabretooth78 808]

@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?

[rsc204 21,808]

One way road is already supported, given that it's a single-direction exit, it wouldn't make a lot of sense to add Road support for this setup.

[Flann 1,709]

23 hours ago, Sabretooth78 said:

@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?

I looked into it just now for road and it presents some challenge.  The way this is done on the network coding side is through RUL1 or intersections solution rules.

Essentially, an RHW stub tile needs to intersect with a road curve, which is problematic.  The network flags for the road piece in question involve what's known as 'blend flags' which are basically intermediate flags between ortho and diagonal, in this case blend flag 11.

However, RUL1 only accepts pure ortho and diagonal flags ( 0, 1, 2, 3, and 4 ).  What this means in practice is that you will not be able to drag an RHW into or out of an already drawn curve.

It would be possible to draw it like this, but its not intuitive at all and I'm not sure it would be a good idea given that.

[Wiimeiser 444]

A situation like this is where a FLEX piece would come in handy. There's already a REW version of that piece, albeit rotated 45 degrees and in desperate need of the orthogonal configuration...

[Sabretooth78 808]

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.

[rsc204 21,808]

6 hours ago, Sabretooth78 said:

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?

I'd put money on it being the Rail Slope Mod included with RRW these days, it's part of the NAM itself so would be present when it's folder is. Temporarily remove the RRW Tunnel and Slope Parameters folder from 2 Additional Network Features\

I've long since noted, that having more than one copy of the Network Properties exemplars - those that determine slope, tunnel placement and many other settings, for a given network is a cause of instability. I have seen this problem due to the equivalent MHIO Exemplar which exists for the same reason as the RRW one, to ensure the altered tunnels work right. Every time I install the NAM and forget to edit the containing DAT file, sure enough my game becomes unstable again.

So far as I can tell, this happens when there are conflicting Properties between competing overrides. In the case of the DBE, I suspect as the bridge finishes, it needs to (auto)terraform the embankment which CTDs when these conflicting values for want of a better term, causes the code to fail. But more generally if terraforming land, including instances triggered by zoning/building networks etc, trigger CTDs, you want to be looking for such conflicting files and consolidating them all. 

[Sabretooth78 808]

1 hour ago, rsc204 said:

I'd put money on it being the Rail Slope Mod included with RRW these days, it's part of the NAM itself so would be present when it's folder is. Temporarily remove the RRW Tunnel and Slope Parameters folder from 2 Additional Network Features\

I've long since noted, that having more than one copy of the Network Properties exemplars - those that determine slope, tunnel placement and many other settings, for a given network is a cause of instability. I have seen this problem due to the equivalent MHIO Exemplar which exists for the same reason as the RRW one, to ensure the altered tunnels work right. Every time I install the NAM and forget to edit the containing DAT file, sure enough my game becomes unstable again.

So far as I can tell, this happens when there are conflicting Properties between competing overrides. In the case of the DBE, I suspect as the bridge finishes, it needs to (auto)terraform the embankment which CTDs when these conflicting values for want of a better term, causes the code to fail. But more generally if terraforming land, including instances triggered by zoning/building networks etc, trigger CTDs, you want to be looking for such conflicting files and consolidating them all. 

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.

[rsc204 21,808]

I made this with NAM 38/39, yeah diagonal bridges are tricky and it is beneficial to do some terraforming beforehand to setup the right conditions for one. Specifically I recommend ensuring both sides will be of identical height, the new NAM tiny raisers/diggers should make this much easier. Also to have a transition from the edge of the water be well defined, for example a sharp drop on the very next tile typically works better than a hill with gentle slopes (going underwater).

A brief test on my Mac is giving me much the same problem as you, it doesn't keep at a specific level. I do notice my Mac cursor doing it's spinning colour-wheel thing (sand-timer in Windows) and holding for a very long time if I go beyond a certain length before the game returns to responsiveness. I'll note this test is with the RRW Slope settings, which may explain both these things, but everything needs to be DATPacked on a Mac, so it's a PITA for me to remove it. Whilst I've not seen such behaviour before under Windows, it wonder if something so clearly computationally intensive might be related to the CTD?

I need to investigate a little in a Windows environment, the Mac doesn't do that stuff well, I'll try to find some time tonight because at first glance it does appear something might have changed..

[Sabretooth78 808]

3 hours ago, rsc204 said:

I made this with NAM 38/39, yeah diagonal bridges are tricky and it is beneficial to do some terraforming beforehand to setup the right conditions for one. Specifically I recommend ensuring both sides will be of identical height, the new NAM tiny raisers/diggers should make this much easier. Also to have a transition from the edge of the water be well defined, for example a sharp drop on the very next tile typically works better than a hill with gentle slopes (going underwater).

A brief test on my Mac is giving me much the same problem as you, it doesn't keep at a specific level. I do notice my Mac cursor doing it's spinning colour-wheel thing (sand-timer in Windows) and holding for a very long time if I go beyond a certain length before the game returns to responsiveness. I'll note this test is with the RRW Slope settings, which may explain both these things, but everything needs to be DATPacked on a Mac, so it's a PITA for me to remove it. Whilst I've not seen such behaviour before under Windows, it wonder if something so clearly computationally intensive might be related to the CTD?

I need to investigate a little in a Windows environment, the Mac doesn't do that stuff well, I'll try to find some time tonight because at first glance it does appear something might have changed..

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.

 

[rsc204 21,808]

So I tried this out under Windows and I'm no longer able to replicate any of the problems.

I mentioned testing certain things for Macs aren't fun, this highlights a good example, the load order on the Mac is... let's say not well documented and certainly not identical to Windows. What I'm guessing happened for the Mac, is that the RRW SlopeParameters file ended up loading after the DBE, which explains why it wasn't building level rail over the riverbeds. So first I wonder if you are failing to load the DBE last, using it's default ~Diagonal Bridge Enabler (Temporary Files) folder name and keeping that in the root of Plugins, should prevent this occurring.

I've tested the DBE both without and with all three variants of the RRW SlopeParameters installed, it works and no CTDs. I used the exact same city as when I made the DBE video to run these tests, but since it was no harder than loading a different save, I also checked it in an older city too. This is from a region entitled NAM 33 Alpha, so I know I would have made an existing diagonal bridge in it using NAM 33 or at the very latest NAM 34. Since NAM 32 was the first RRW release, you can't go much older. Again making a diagonal bridge didn't present any unusual problems.

In each case I never once had to remove the NetworkAddonMod_IndividualNetworkRULs.dat file either, likewise this would have been present when testing on the Mac. I can't explain what could be inside that might cause problems, it's ultimately just full of RUL code. Either way if the release file was somehow behind your troubles, then on both my systems I should be seeing the same issue. Is there any chance you've either an older or duplicate copy of this file hanging about? Even so, that doesn't really explain anything.

Whatever is behind your CTDs though, I think it must be something unique to your setup, rather than a general problem. If your work-around works, great, I'd just make use of that. But I am still convinced the CTDs may be related to Slope Mods and the like, which if removed temporarily should prevent problems. Using the attached .dat file:

~Placement Tuning Parameters.dat

Run the process from this tutorial with iLives Reader using the downloaded file, the output data will show you every other file containing the Network Properties Exemplars in question. See what happens when you remove all of those and run the DBE with the rest of the NAM files present.

[Sabretooth78 808]

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.

[Eggman121 1,035]

I,m going to chime in here.

The RRW re-basing has caused alot of issues with the DBE.

One thing I did a couple of cycles ago to help with the DBE X RRW is the ability to draw a road than with a RUL1 edit draw over that road land bridge with rail.

Try drawing a diag road bridge and than draw over that with rail and see if that helps.

-eggman121 (NAM Team Member)

[Sabretooth78 808]

20 minutes ago, Eggman121 said:

Try drawing a diag road bridge and than draw over that with rail and see if that helps.

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.

 

2 hours ago, rsc204 said:

Whatever is behind your CTDs though, I think it must be something unique to your setup, rather than a general problem. If your work-around works, great, I'd just make use of that. But I am still convinced the CTDs may be related to Slope Mods and the like, which if removed temporarily should prevent problems. Using the attached .dat file:

~Placement Tuning Parameters.dat

Run the process from this tutorial with iLives Reader using the downloaded file, the output data will show you every other file containing the Network Properties Exemplars in question. See what happens when you remove all of those and run the DBE with the rest of the NAM files present.

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

 

On 10/6/2021 at 3:50 PM, Lucario Boricua said:

My thoughts so far:

<snip>

• Another suggestion would be to try and shift the crossing avenue to be more distant from the neighbor connection. From what I can see in this screenshot, there is some available space to the left of the suburbs along the bottom edge of this view. I don't know how routing of the avenue works beyond this area, and as such, this re-design would likely involve more changes elsewhere.
   
• I also notice the neighbor connection lacks the arrows, make sure to drag the RHW-4 towards the city boundary. It's possible that you could get a better commute behavior this way, especially if there's available jobs in the neighboring city.

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: 

 

 

[SIM-ple Jack 17,444]

Not sure if this belongs in this thread or not, but the self-destructing hole diggers that come bundled with NAM, keep ctd'ing at certain zoom levels. Anyone know why?

[Lucario Boricua 7,028]

2 hours ago, SIM-ple Jack said:

Not sure if this belongs in this thread or not, but the self-destructing hole diggers that come bundled with NAM, keep ctd'ing at certain zoom levels. Anyone know why?

Can you be more specific about the circumstances in which this CTD problem arises? We'll need to know the following:

• Which zoom levels are affected?
   
• Which particular digger/raiser option(s) you're using (height change and whether it digs or raises the terrain)?
   
• Did you use these over open terrain, buildings, other lots, transit lots (rail stations, bus stops, parking garages, etc.) or transportation networks?

Let us know these and any other details about the circumstances immediately preceding the crashes, that way we can recreate and resolve the bugs.

 

[SIM-ple Jack 17,444]

On 11/20/2021 at 2:23 PM, Lucario Boricua said:

Can you be more specific about the circumstances in which this CTD problem arises? We'll need to know the following:

• Which zoom levels are affected?
   
• Which particular digger/raiser option(s) you're using (height change and whether it digs or raises the terrain)?
   
• Did you use these over open terrain, buildings, other lots, transit lots (rail stations, bus stops, parking garages, etc.) or transportation networks?

Let us know these and any other details about the circumstances immediately preceding the crashes, that way we can recreate and resolve the bugs.

 

The 2 closest zooms, and not right away either. Sometimes I get half the task done before the crash. Digging canals in water in water pollution view. The reason, so I can count the tile spans. Usually in 30m digger setting. Seems not to happen on land, just in water. Most of the time, nothing much has been built in the tile except a highway section.

For instance, twice in this tile, before any buildings were in-

[Lucario Boricua 7,028]

@SIM-ple Jack That's actually an unexplored aspect of the self-destructing terrain diggers and raisers. I've used them overland and digging into the water, but only from the regular surface view of the game. My strategy consists of forming a flat area close to sea level, IIRC, the grid lines stop showing for elevations below 255m (5m above sea level). A canal formed with the 30m diggers should actually be enough for a vast majority of situations, very few ships worldwide require drafts greater than 20m, and a handful might require as much as 25m. If using these depths is compatible with the ship sizes you're using, I suggest using this method instead.

Now, I don't think using the diggers/raisers in the water pollution view was ever intended, so I doubt it'd be a priority to fix. If you do have more questions about 'em, the person to ask is @rivit, the creator of these special lots.

[rivit 3,391]

Actually I didn't make them first - I only cloned and extended them to the small heights and depths.  And the niceties of them is something I dont understand at all.  Jack you're taking us to where no-one has gone before... Captain I dont think she can take it!

More seriously though, I've actually tried to replicate the problem in a random existing tile and I can't get mine to crash when using either the 30m digger or 30m raiser underwater in water pollution view. I do have the SC4Fix installed. As far as I can tell they are stable and that's why they're so useful - I can see why you've applied them this way - rather clever I think.

Q. Is it intermittent or all the time you use it this way?  Do you get it in all maps or just the one you've described?

Q. Is it possible that you've dug through the bottom of the map  i.e. to depth 0 ?  seems unlikely; or that there are pipes or subways accidentally involved?

So I dont have an explanation at this time.

[rsc204 21,808]

Have you tried lowering the terrain in a spot which CTDs using the in-game tools rather than the raisers/diggers? If that too CTDs it pretty much completely rules out the lots themselves as the problem. Although if we can’t replicate the issue our end, that’s almost a given already. Likewise at this juncture you need to rule out your other mods, does it still happen when the NAM is the only mod in use with a blank/new tile?

I suspect it’s conflicting slope mod (or similar) properties causing issues when altering terrain. 

[SIM-ple Jack 17,444]

2 hours ago, rsc204 said:

Have you tried lowering the terrain in a spot which CTDs using the in-game tools rather than the raisers/diggers? If that too CTDs it pretty much completely rules out the lots themselves as the problem. Although if we can’t replicate the issue our end, that’s almost a given already. Likewise at this juncture you need to rule out your other mods, does it still happen when the NAM is the only mod in use with a blank/new tile?

I suspect it’s conflicting slope mod (or similar) properties causing issues when altering terrain. 

All my maps are set at exactly sea level to prevent denting when placing ports. Raising or lowering terrain will destroy that height. Not an option.

16 hours ago, Lucario Boricua said:

@SIM-ple Jack That's actually an unexplored aspect of the self-destructing terrain diggers and raisers. I've used them overland and digging into the water, but only from the regular surface view of the game. My strategy consists of forming a flat area close to sea level, IIRC, the grid lines stop showing for elevations below 255m (5m above sea level). A canal formed with the 30m diggers should actually be enough for a vast majority of situations, very few ships worldwide require drafts greater than 20m, and a handful might require as much as 25m. If using these depths is compatible with the ship sizes you're using, I suggest using this method instead.

Now, I don't think using the diggers/raisers in the water pollution view was ever intended, so I doubt it'd be a priority to fix. If you do have more questions about 'em, the person to ask is @rivit, the creator of these special lots.

I usually pre-determine how ports look and lay out when making my grayscale in fantasy maps, anyway. I don't have that luxury when using real maps and want to remain faithful to the landscape as much as possible. The water in my maps is usually, at the deepest, about 30mil or less. When adding something in the water that I want to bridge to, I terrain a 1 tile land bridge, so the bridge comes out perfect. As I said, usually I run out my highway and railway before starting my city, so I don't have to retro-fit it later. Before, when I wanted to do something in the water, I'd use the setsealevel0 cheat which would usually destroy some of that road/rail. So I started using that pollution view instead.

15 hours ago, rivit said:

Actually I didn't make them first - I only cloned and extended them to the small heights and depths.  And the niceties of them is something I dont understand at all.  Jack you're taking us to where no-one has gone before... Captain I dont think she can take it!

More seriously though, I've actually tried to replicate the problem in a random existing tile and I can't get mine to crash when using either the 30m digger or 30m raiser underwater in water pollution view. I do have the SC4Fix installed. As far as I can tell they are stable and that's why they're so useful - I can see why you've applied them this way - rather clever I think.

Q. Is it intermittent or all the time you use it this way?  Do you get it in all maps or just the one you've described?

Q. Is it possible that you've dug through the bottom of the map  i.e. to depth 0 ?  seems unlikely; or that there are pipes or subways accidentally involved?

So I dont have an explanation at this time.

Currently, I'm working on water-less tiles, but will be back into coastal tiles in about a week. Captain, i'm making 2 to 3 cities a day and am low on dilithium crystals. Dammit Jim! I'm an engineer, not a doctor!

A. I think this happened in a region, earlier this year...on dry land, but with the 30mil.

A. Like, what are you saying? We can dig right through to the other side of Planet Sim? lol I use a cheat for pipes, so running plumbing isn't necessary, and I never use subways.