PSA: Updating Your NAM Version? Don’t Uninstall The Old One (and Other Advice)

The NAM Team has encountered quite a few tech support cases recently, with users who have recently gotten around to picking up the latest version, and subsequently finding that some transit item in their city has gone missing.  In every case, this has been the result of users heeding long-outdated advice from 5+ years ago, that suggested uninstalling the old version before installing the new one.  This, however, is no longer the case, and since the NAM 31.x series of releases in 2013, it has been the official advice of the team that users should NOT uninstall their previous NAM version while upgrading to a new version.

The NAM installer was completely overhauled for the move to the “Monolithic” package that has been the norm since NAM 31.0 in March 2013 (thanks to z1), and it is a lot smarter than the NAM installers of yore.  Namely, just as it can read whether or not the game has been patched, it can locate a user’s NAM installation, and is able to determine which options were installed.  With the old installation in place, the installer can then read the files, and will automatically select the same components that the user had previously for the new installation.  Additionally, many of the old issues with outdated controllers and the once-dreaded “red arrow bug” have been solved by the current package as well.

If one instead follows the outdated advice of uninstalling the old version, the old NAM installation is no longer there for the installer to reference, and it is then entirely on the user to ensure that they select the same options they were previously using.  With as many options as there are now in the NAM, that is no small task, and the possibility for installation error increases exponentially.

If you happen to be concerned about outdated/conflicting files, there are mechanisms in the installer to handle this now, including running the built-in version of BSC Cleanitol.

A few other related pieces of advice, to help streamline your NAM installation and upgrade experience:


The Version Check and Switching from Disc to Digital 

This one has come up a lot lately as well, and quite understandably so.  Microsoft has been doing everything in its power to try to eradicate the secdrv.sys driver file, which disc copies of SC4 require, including the infamous KB3086255 update for Windows Vista, 7, 8, and 8.1, and the complete omission of the driver in Windows 10.  As a by-product of this, many users have been switching over to digital copies of the game, from Steam, Amazon,, Origin, GamersGate, and other sources.  The NAM requires the game’s executable to be at least Version 1.1.638 (the version number of the disc copy with the EP1 Update 1 patch), and all of these digital copies are updated to Version 1.1.641, and do not need to be patched.  However, if a user happens to have an unpatched disc copy (Version 1.1.610 or 1.1.613) still installed after installing the digital copy (or has a $%&^! installed in the folder for the original disc copy), the Windows Registry will still point the installer toward the old SC4 installation, not the new digital copy, and the installer will fail.

There are two ways to get around this.  Probably the cleanest in the long run would be to uninstall both the disc and digital copies, and then reinstall only the digital copy, at which point the Windows Registry will then point to the digital copy, and the NAM installer will be happy.  The one case where you might want to preserve the disc install is if you’re planning on also installing the game’s official Building Architect Tool, which, reportedly, at least some digital versions with DRM (i.e. Origin) apparently prevent.  In that case, the best solution would be to patch the disc copy, at which point the NAM installer and the BAT installer would see it as valid.  The disc copy may subsequently be removed once the BAT has installed.  For more on the BAT installation matter, see rsc204‘s post here.


DatPacking and the NAM

Another piece of advice that is of the same vintage as that uninstallation advice, that the NAM should not be “DatPacked”, using a tool like wouanagaine’s SC4DatPacker, or memo’s JDatPacker, because of its negative impact on NAM upgrade installations.

In the case of Mac users, however, the number-of-files limit present on the newer digital versions of the Aspyr port requires DatPacking (using JDatPacker, which is cross-platform) in order for the game to run properly with a larger NAM installation.  This limit on the Mac port is not impacted by the size of the files, but merely on their number–enough empty subfolders will trigger it.  With respect to the Windows version, the improvements to the installer prevent a DatPacked NAM installation from causing a “red arrow bug” in doing an upgrade (this was the main reason it was discouraged in the past), but because some users have exhibited a tendency to discard the pre-DatPacked files, leaving just the massive “Network Addon Mod.dat” file created by the DatPacker tool, the same issues caused by uninstalling occur, namely that the installer will not be able to discern the contents of the massive single .dat in the way that it could with the original file architecture, making installation error far more likely.

Thus, for Mac users, DatPacking is recommended, but for Windows users DatPacking is still not recommended (unless you really know what you’re doing).


Keep the Installer Handy If You Change Your Mind on Features

Particularly if you’re on the fence on installing a feature, or if you’re a new user who doesn’t know what most of the options do yet, it can be to your benefit to keep the installer for the current version handy.  If you decide you want to change options, leave your existing installation in place, and run the installer again.  Just as with upgrades, the installer will be able to read your installation and the current set of options installed, which will help out immensely in determining which boxes to check and uncheck.  And again, as with upgrading, it is not at all recommended to uninstall before running the installer again, as this makes re-installation a far, far more daunting task.


Hopefully, this proves to be a useful reference for those of you installing, re-installing, or upgrading your NAM version.  Happy NAMing!


Introducing QuickChange Xpress (QCX) – The “Scandalous” RHW Feature So Many Have Wanted

Yesterday (July 12th), I posted a video on YouTube showing something that, up to this point, has been deemed completely off-limits for RealHighway (RHW) development (hence the quotation from Earthbound/Mother 2’s infamous final boss in the title).  For those who haven’t seen it yet, here it is:

Yes, that is basically what it looks like–a full-on pre-fabricated diamond interchange for the RHW, placed in one click.  It’s something we’ve been adamant about not including in the past, as evidenced by question #17 on the FAQ in the first post of the RHW development thread at SC4 Devotion:


17.  Will “Maxis-styled” prefab/plop interchanges ever be produced for the RHW?

No.  The massive amount of time required in making one, the size limits imposed on them, the fact that they would duplicate already existing functionality, along with the rigid inflexibility of such setups and the massive number that would have to be made in order to account for all the networks included in the RHW renders the notion of plop interchanges impractical and unworkable.  The QuickChange system is the closest we will come to making full prefabs.


This of course, begs the question–what changed?  Believe it or not, the biggest game-changer in this situation was the steady march away from the traditional “static” puzzle pieces, toward FLEX setups, which already permitted the QuickChange system, introduced in NAM 32.  The “official” term I’ve devised for this new full interchange setup is QuickChange Xpress, or QCX–a rather unique acronym, as it includes both a Q and an X (and indirectly pays tribute to Q and X enthusiast and RHW project founder qurlix).  The name represents the fact that it takes what QuickChange brought to the RHW system, and has sped the interchange creation process as fast as it can go.

The traditional pre-fab interchanges for the Maxis Highways are massive static puzzle pieces, which require a lot of Instance IDs (IIDs) in order to function, and as a result, are very tedious, painstaking items to develop.  Had this interchange been developed the conventional “static” way, as this piece is 15×4 with a bumpout on either side in the middle for the Road crossing, we’d be potentially looking at 62 IIDs, plus a lot of tedious exemplar editing, model shifting, and pathing.  Plus, in order to fill demand, we’d need to make versions for several different RHW networks, multiplying development time considerably.  It becomes abundantly clear why RHW pre-fabs requests were vehemently shot down in the past.

However, the QCX is built entirely from existing FLEX pieces, plus the L1 Road Viaduct starters on either side.  The original FLEX pieces themselves are being dropped in place here, just by virtue of using RUL0 to reference their anchor points and filling in the gaps with base network tiles, which RUL2 overrides then handle as needed to form the full interchange.  And as with other, smaller FLEX pieces, we can use the same placeholder dummy IID that’s been around for a decade with the original FLEX piece (the Diagonal Streets from NAM 20 in 2006).  There’s exactly zero new IIDs required.

Nil.  Zilch.  Donut.

No pathing, no exemplars, no model manipulation outside of the preview model (which is by far the most difficult part of making a QCX).

For those of you out there who are RHW power users, this doesn’t mean we’re going to abandon the advanced, modular side of the RHW.  Far from it.  It does, however, open what has long been considered (even by many advanced users) a maddeningly complex system to a much wider audience.  We’ll continue to develop new RHW content, focusing on the traditional, smaller modular pieces, in FLEX form, but now, we’ll also look at ways to assemble these FLEX items into larger QCX setups, that can get anyone up and running with the RHW, which takes surprisingly little time.  About 30 minutes elapsed between when I started making that first functioning QCX prototype and recording that video.

The QCX in the video is by no means the final design, and we are looking at some potential improvements to it, trying to find the right balance of ease-of-use, realism, and in-game efficiency.  Some of the improvements being considered may necessitate pushing the rollout of QCX out until NAM 36 (NAM 35 is the version currently in development), but rest assured, the RHW will soon be a far more approachable component of the NAM.