NAM General Support

[GridL0cked 9]

Alright. I'm not entirely certain if this thread is appropriate for complex issues, but i'm posting about one anyways, because I can't be bothered to start a new thread when it might not be necessary. If someone points out that I should start a new topic for it, then I probably will.

Anyways. Theres a bizarre path-finding anomaly that occurs with the NAM traffic simulator, and the NAM traffic simulator only. What seems to happen at the core of the problem, is that most commuters will refuse to keep their routes for more then a few in-game months, resulting in an almost animated traffic query that constantly changes on the fastest simulator speed (cheetah). This seems to cause another problem, which is unemployment to/from neighbor connections. Another, possibly connected problem, is that when neighbor connections exist in a city, almost all commuter traffic out of said city will be pedestrians, seemingly regardless of distance.

Here's a video showcasing the effect, as measured by the route query tool. Take careful notice to the moving arrows:

It's not terribly obvious, but the effect becomes stronger in larger cities. Note that the city shown in the video has no neighbor connections.

  Edited April 16, 2017 by GridL0cked  

[Tarkus 6,932]

Regarding the seemingly "animated" commute query arrows, it doesn't actually look like there's anything wrong there.  The NAM does add some additional pedestrian paths to the sides of the various car-based networks, in order to allow direct connection to the Pedestrian Mall (PedMall) pieces, and I suspect the simulator is simply "exploring" them (there's a pair on each side).  The NAM simulator also gives the commute engine a much stronger drive to seek out less congested routes--actually a necessity for proper functionality with some of the wider override networks in the mod (i.e. in the Network Widening Mod and RealHighway plugins), and it's possible this might also be impacting that.

I've noticed the pedestrians going to the neighbor connections as well, and that's likely because of the fact that the NAM simulator increases the speed for walking from the default 3.5 to 15 for most networks, in order to make pedestrian and transit-based commutes more viable.  Provided there are jobs in the next city tile on the other side of the neighbor connection, the game sees the edge of the current tile as a "job" to which the sims can commute, and since the game can't run the simulation on the next city tile over, it has no way of knowing whether or not the pedestrian commute option continues to be viable on the other side.  This is simply an effect of the game's neighbor connection functionality not being finished to the extent Maxis really wanted--the "Eternal Commute Loop" is another similar issue.  Both issues exist in the base game without mods.

-Tarkus

[GridL0cked 9]

9 hours ago, Tarkus said:

Regarding the seemingly "animated" commute query arrows, it doesn't actually look like there's anything wrong there.  The NAM does add some additional pedestrian paths to the sides of the various car-based networks, in order to allow direct connection to the Pedestrian Mall (PedMall) pieces, and I suspect the simulator is simply "exploring" them (there's a pair on each side).  The NAM simulator also gives the commute engine a much stronger drive to seek out less congested routes--actually a necessity for proper functionality with some of the wider override networks in the mod (i.e. in the Network Widening Mod and RealHighway plugins), and it's possible this might also be impacting that.

I've noticed the pedestrians going to the neighbor connections as well, and that's likely because of the fact that the NAM simulator increases the speed for walking from the default 3.5 to 15 for most networks, in order to make pedestrian and transit-based commutes more viable.  Provided there are jobs in the next city tile on the other side of the neighbor connection, the game sees the edge of the current tile as a "job" to which the sims can commute, and since the game can't run the simulation on the next city tile over, it has no way of knowing whether or not the pedestrian commute option continues to be viable on the other side.  This is simply an effect of the game's neighbor connection functionality not being finished to the extent Maxis really wanted--the "Eternal Commute Loop" is another similar issue.  Both issues exist in the base game without mods.

-Tarkus

Interesting... It is true that there are no congested roads in the city, although despite having a neighbor connection, the test city has always been the only one in the region thus far. Still, I've noticed actual gameplay issues pop up during previous tests (like mass unemployment, which I covered in a thread I started late last year), that coincide with this oddity. You make a very strong case suggesting that it is not a problem, but I'm convinced it is a problem.

Problem or not, this glitch makes little sense, and theoretically shouldn't happen normally. If my understanding is correct, then in both simulators, sims will usually stick to their current route to work unless circumstances change. Whats actually happening with the route query suggests the sims are continuously changing their route to work every few in-game months (which, interestingly enough, is the time it takes for routes to change normally), hence the "animation" on "cheetah" speed. Based on that, and the various problems that coincide with this, one might be able to infer that something is constantly compromising these sims' commutes.

I've tested this before numerous times, and I can almost guarantee you that in a sufficiently large city, entire swaths of roads with thousands of commuters will have the route query arrows for almost every sim on that road jitter around all over the place. 

In the mean time, I guess I will do some more testing and experimenting. Someone once told me users experienced oddities like this with the NWM, and that I should test it. Perhaps I should do so now, seeing as I maybe should have tested that months ago.

[jeffryfisher 2,176]

22 hours ago, GridL0cked said:

If my understanding is correct, then in both simulators, sims will usually stick to their current route to work unless circumstances change.

Now that sounds like it would be a program weakness. Changing jobs and routes as new enterprises move in looks like an improvement. Other than piquing your curiosity, can you tell us how this new behavior hurt your game-play UX?

[rsc204 21,808]

On 16/04/2017 at 8:52 PM, GridL0cked said:

You make a very strong case suggesting that it is not a problem, but I'm convinced it is a problem.

Problem or not, this glitch makes little sense, and theoretically shouldn't happen normally.

Actually it makes total sense. Consider that the game is dynamic and things are constantly changing. So the simulator is continually looking to adapt to the changes that may be going on around it. If you try to bypass this behaviour, you will find that it negatively affects the working of the simulator. Because the more it looks to keep sims in certain jobs, the less efficient the majority of the pathing will be, leading to more No Job Zots and other problems. Think about it like this, say you zone some new houses which grow, the sims who move in will need jobs. Should the simulator only look for unoccupied jobs for these new residents? What if the only jobs not occupied were too far away for a successful commute? Now imagine by shuffling who works where around, more sims could ultimately get to jobs, in the least amount of time. That's in essence what these changes are trying to ensure. Continual optimisation of all commute routes every time the simulator is run. The net benefits are more sims employed and a more efficient set of routes overall.

Sure these updates do take a toll in terms of CPU runtime, but actually that's one of the key differences between the vanilla simulator and the Simulator Z from NAM. Maxis dumbed down the original pathfinder in order to reduce the CPU load, so the game would run on low end machines. Since the game was supposed to run on a PIII 500. However by the time of the Simulator Z, most people had computers that had no problems handling the extra load to give near-perfect pathfinding.

For an in-depth explanation for all this, see this Thread, specifically the section entitled "APPENDIX - Software Archeology:  Excavating Sim City":

[GridL0cked 9]

Alright, so I read some of the first section, which might be giving me a better idea of what's going on. It's a long (but fascinating) guide, so i'll hopefully remember to read more of it later, including the appendix part.

That being said, I have a few questions, which may provide insight into my cities' jittery route query arrows: How frequently does the NAM traffic simulator actually run, per in-game months? What exactly is the Z simulator? Is the NAM a direct successor to the Z simulator?

Thanks for all the help thus far. I appreciate it. 

[rsc204 21,808]

The simulator z is just the most current implementation of the simulator, which is included with the NAM mod. There have been many iterations over the years, but as things stand this one simply does the job better than any before it. Frankly, unless some huge break-through in our understanding occurs, I think it's here to stay. Having been around for some time already.

Typically the simulator/pathfinder is run every 3-6 months in-game.

[GridL0cked 9]

On 4/19/2017 at 10:57 AM, rsc204 said:

The simulator z is just the most current implementation of the simulator, which is included with the NAM mod. There have been many iterations over the years, but as things stand this one simply does the job better than any before it. Frankly, unless some huge break-through in our understanding occurs, I think it's here to stay. Having been around for some time already.

Typically the simulator/pathfinder is run every 3-6 months in-game.

Assuming it is opened once then left alone, the route query arrows should only update when the simulator/pathfinder runs, correct?

[rsc204 21,808]

11 hours ago, GridL0cked said:

Assuming it is opened once then left alone, the route query arrows should only update when the simulator/pathfinder runs, correct?

Not necessarily. The behaviour of things updating is completely normal.

[GridL0cked 9]

On 4/23/2017 at 6:18 AM, rsc204 said:

Not necessarily. The behaviour of things updating is completely normal.

Are you implying that the commute arrows in my game jumping around, dissapearing, and re-appearing is normal? Or are you just talking about things updating in general?

In any case, I recently decided to streamline everything: including (but not limited to) un-installling and re-installling the game along with all the patches and the NAM, partly because it was messy to browse for everything on my PC. I decided to look at my patchlogs (including the one from before I installed, I think?) to look for clues, and it all looks fine, except for one small (possibly important) detail at the bottom of both logs. Take a look: In the results, it says "File Patches Ignored: Old Files Missing....... (   1)" on both logs. Does that mean I might be missing an important file? For the record, I use the disc version.

I dunno if i'm maybe coming across as nitpicking at this point, but it seems all I can do right now is guess.

 

sc4_patchlog.txt

sc4_patchlog(old).txt

[rsc204 21,808]

1 minute ago, GridL0cked said:

Take a look: In the results, it says "File Patches Ignored: Old Files Missing....... (   1)" on both logs.

There is nothing wrong here. There are two editions of Rush Hour, the separate expansion for SC4, then the Deluxe Edition which includes it as standard. The patch is checking for both variants, but will only find one, so the other file is skipped (since it doesn't exist).

2 minutes ago, GridL0cked said:

I dunno if i'm maybe coming across as nitpicking at this point, but it seems all I can do right now is guess.

I don't see a problem. The video you uploaded looks exactly how my game does on high speed. Run the game without making new zones until all new development stops. When that happens and the game stops refreshing data on the fly, you'll find that things are a lot more settled. But whilst new buildings are popping up and upgrading, the game needs to alter pathing and other things to keep everything working. Although the actual pathfinder is run only every so often, the code can work in the background to prepare things in advance of this operation.

In short, the most CPU intensive part of the game is the pathfinder for linking sims and jobs. Maxis knew this had to be super efficient, otherwise as cities grow bigger, the game would fall apart. But at the same time, they also knew it couldn't be continually running all the time. That would be too taxing for most PCs (it still is today with a high end CPU and enough sims). So some parts are handled on the fly, but the main operation occurs 3-4 times a game year. Running on high speed also distorts what you are seeing somewhat. Since it makes the changes appear more frequent than they really are. That's because a lot of the on the fly stuff doesn't actually happen for real until the next time the pathfinder is run. It's just happening to reduce the workload of the pathfinder when it does.

In short, there is nothing wrong here. Unless your game isn't working, it's simply not worth spending you time thinking about further.

[GridL0cked 9]

2 minutes ago, rsc204 said:

There is nothing wrong here. There are two editions of Rush Hour, the separate expansion for SC4, then the Deluxe Edition which includes it as standard. The patch is checking for both variants, but will only find one, so the other file is skipped (since it doesn't exist).

I don't see a problem. The video you uploaded looks exactly how my game does on high speed. Run the game without making new zones until all new development stops. When that happens and the game stops refreshing data on the fly, you'll find that things are a lot more settled. But whilst new buildings are popping up and upgrading, the game needs to alter pathing and other things to keep everything working. Although the actual pathfinder is run only every so often, the code can work in the background to prepare things in advance of this operation.

In short, the most CPU intensive part of the game is the pathfinder for linking sims and jobs. Maxis knew this had to be super efficient, otherwise as cities grow bigger, the game would fall apart. But at the same time, they also knew it couldn't be continually running all the time. That would be too taxing for most PCs (it still is today with a high end CPU and enough sims). So some parts are handled on the fly, but the main operation occurs 3-4 times a game year. Running on high speed also distorts what you are seeing somewhat. Since it makes the changes appear more frequent than they really are. That's because a lot of the on the fly stuff doesn't actually happen for real until the next time the pathfinder is run. It's just happening to reduce the workload of the pathfinder when it does.

In short, there is nothing wrong here. Unless your game isn't working, it's simply not worth spending you time thinking about further.

Alright. The arrows still jitter about if I leave the game running on cheetah for long periods of time without doing anything, but if you insist it's not causing any legitimate problems then i'll take your word for it I suppose. I find it very bothersome to look at, but I guess it's something I'll have to live with.

Thanks for the help.

[Von F. 29]

Hello

Long time I haven't played this game - downloaded NAM 35 from moddb and installed it in an empty plugin folder to start things smooth...

Every component I tested seem to behave  fine however I noticed some problem with the NWM starter pieces, they do not trigger the texture override (pic)

So I uninstalled/reinstalled the NAM, rebooted my machine, tried and retried every NWM network starter to no avail. Anyone have a clue what may cause this?

Attached to this post the install log, if it can help the troubleshoot... I don't think I messed with the "decoupling network option" but hey, it's not 100% guaranteed - I remember having some fiddling in the past with previous NAM installations.

Game version is 1.1.641 (GOG), Win7, 8 Gb RAM, etc.

Thx

 

install.zip

[rsc204 21,808]

If the network overrides are missing, then some RUL code is not present required to make it work.

36 minutes ago, Von F. said:

"decoupling network option"

You need to be certain you have not selected this during installation. Doing so could certainly be the reason why you are missing the RUL code here.

The other reason would be that the controller compiler didn't generate the NWM option for some reason? In which case goto:

\Documents\SimCity 4\NAM Auxiliary Files\Tools\Controller Compiler

And try running it manually (NAMControllerCompiler.bat). Make sure you have NWM and all the options chosen during NAM installation selected.

[Von F. 29]

Nah I rechecked, haven't ticked that nasty box

However compiling the controller manually worked like a charm. Oddly it was disabled by default, perhaps because I don't use RHW?

Anyways problem solved, thank you Rsc!

[rsc204 21,808]

7 hours ago, Von F. said:

. Oddly it was disabled by default, perhaps because I don't use RHW?

That is odd, since selection of the NWM in the installer should make sure the relevant code is installed. It shouldn't have anything to do with RHW though, since the two sets of code are unique. Perhaps something needs tweaking in the installer though, I'll see if we can look into that.

[CT14 2,486]

Draggable Rural GLR curves are being weird.

[APSMS 1,892]

What mod are you using @CT14 ? It looks like perhaps some tiles were left out of the texture mod, because AFAIK normal GLR doesn't look like that, and neither do any of the default alternate draggable textures.

[CT14 2,486]

Thanks @APSMS ... here are some obvious candidates from my set:

• Paeng's Sandstone Mod(no obvious GLR components, haven't dug into dats)
• Sandstone Texture Mod for NAM by atmoguy (includes GLR components)
• Modular RR Props by jondor

As usual, removing 50% of plugins at a time should quickly isolate which one is doing it. I'll report back.

Edit: it was Sandstone Texture Mod for NAM. I'll look at patching it up if @AtmoGuy isn't around. I like that mod.

Thanks again for suggesting to look at GLR mods.

[APSMS 1,892]

It's possible, but unlikely, that @rsc204 missed some pieces when compiling his Sandstone NAM. I've not used his mod, nor have I experienced that glitch using draggable GLR. Of course, my draggable GLR doesn't look like that, either, so I'm unsure of the point of failure, though unfortunately that seems to be the case. Does this happen with all the flavors of GLR, or only the default?

[CT14 2,486]

It was the latest Rural Draggable version that wasn't working with atmoguy's Sandstone Texture Mod for NAM. Removing that mod makes GLR look different and the missing grass texture comes back.

[rsc204 21,808]

If you were using the mod by AtmosGuy, this will replace it entirely with a totally up to date and uniform GLR. It's based too on Paeng's Sandstone textures:

Currently it's just a preview version that's attached to that post, but it's in very good shape.

Being the Rural GLR, the piece you have problems with has the ID 7AB50E44-1ABE787D-5F884404. A quick check and indeed the Alpha channel is missing for this texture, which is contained within the file "Draggable.dat" inside the GLR folder. Fixing it would involve extracting the texture, adding an alpha channel and patching the file.

 

[PlutonianEmpire 2]

On 11/21/2016 at 5:39 PM, rsc204 said:

There are two patch files attached to this post for NAM Users:

• RRW-STRxBaseNetworks_Patch.zip
  This fix includes Models and Paths for STR crossings with Maxis Highway, El-Rail and Monorail.
  If you use one of the following overrides (but not all), MHO / ML Alternate El-Rail / ML BTM, install the file anyway.
  It will ensure all networks work with STR as intended. If you use all three overrides, installing will not cause any harm, but is simply unnecessary.
   
• NAM35_NewDiagonalCrossings Patch.zip
  This fix will allow the new Ortho Street/Ave by Diagonal Rail crossings to appear. Complete with pathing and T21s.

The files support RealRailway, PEG205 and Default Maxis rail styles. Only install the LHD or RHD file/(s) for the style you require.

 

NAM35_NewDiagonalCrossings Patch.zip

RRW-STRxBaseNetworks_Patch.zip

What are the differences between the LHD and RHD files? How do I know which one to put into the folders listed in the readme?  And how do I find out which folder goes where? I find the format of the readme to be a bit confusing, tbh.

[rsc204 21,808]

Well for one you can ignore the RRW-STR patch, after some testing the code is missing in NAM 35, so it's not useful afterall.

As for LHD/RHD, that simply means which side of the road your sims drive upon, i.e LHD = cars driving on the Left side of the road / RHD = cars driving on the right side of the road.

If you are using either the Maxis or PEG styles, the files need to go into the Network Addon Mod folder.
If you are using the standard RRW crossings, place them into the z___NAM\y_RealRailway folder.
Alternately, for RRW / TSR style crossings, you should place them into z___RVT Modds\RVT zRUM for RRW\BCD NAM, this assumes you are using Rivit's RUM for RRW mod also.

Sorry if the documentation isn't all that clear. But when patching things, it's rare people provide a full readme. Hence the patch readme does assume some knowledge of file/folder management. You have two choices as a user, either patch if you know how to apply it or wait for the next NAM version, where these fixes will be included.

[PlutonianEmpire 2]

That makes much more sense now, so I figured out where to put what file, which in my case was the RHD file into the y_RealRailWay folder. Thank you!

[Handyman 765]

Need help with NAM Controller Compiler

I was wondering if there is a way to auto fill the Input & Output directories?

I am trying to finish a bash script to run the compiler and I would like to complete these fields from my script.

Does the Compiler accept arguments?

  Edited June 25, 2017 by Handyman  

[Tarkus 6,932]

To my knowledge, the compiler can accept a few arguments, as there are different modes for it (regular, debug, and dev), but I'm not sure as to the full extent of what all it can take on that front.  Unfortunately, memo, who designed the compiler, hasn't been active for a couple years now, but the source code for the compiler is on GitHub, if that helps. 

-Tarkus

[Handyman 765]

Thanks Tarkus I'll check that out.

[Handyman 765]

I got a chance to take a look at source for the Compiler. While it does accept some arguments as is, I think I would have to rewrite some of the Java code to accept the Input/Output paths.

I did not want to get sidetracked from my current bash project, so I decided to find a different approach.

Actually I came up with two different procedures but settled on preseeding the settings file with the paths. This seems to be working as needed.

[dogabone 4]

Hello everyone. I am facing a strange problem with NAM installation on Linux. As shown in the attached image (and webm video), the installer gets stuck at some point and presents that graphical glitch.

The text in portuguese reads "Extract: 0100_CanNAM.txt"

I am using Arch Linux, fully up to date. My SC4 is the Steam Version, and I have checked that it is running correctly by creating a new region and playing 2 cities in it, averaging 6 hours without crashes or bugs. The NAM installer is the latest one, 35.

I am playing using WINE, latest version: 2.12. Arch Linux has two wine packages, the standard one and the staging version. Both are compiled with 64bit support. To troubleshoot my problem I have tried using 32bit and 64bit prefixes, with wine and wine-staging (at least 4 tests). After each failed test, I completely removed the wine prefix, thus removing the windows registry and all game installation files. I also cleaned the SC4 folder that goes into My Documents, where the plugins are installed. Before each test I checked that SC4 alone was running correctly. I also tried some variation of NAM options (first, second and complete install options, didn't try the custom one) with each wine prefix, before deleting them.

I also tested that same NAM package with Windows 8.1, and it installed perfectly.

The installer was able to run the cleanitool and the Large Address patch, before getting stuck in that condition.

I know that probably this isn't a NAM problem, but I would like some help or at least know if someone else encountered the same behavior for the installer.

Thanks in advance.

 

EDIT:

Forgot to add that I was also checking my operating system during the install. When it gets stuck, no disk operation is getting done, so it is not copying anything in the background. Also, that file 0100_CanAM.txt is created, but stays with 0 bytes. The installer task goes close to 95% CPU use. I tried to check the task with strace, but that proved to be too much for me, it seems to be looping at the same thing over and over, but I do not have the knowledge to interpret what is going on.

SC4.webm

  Edited July 16, 2017 by dogabone  
Add info