There are currently several different versions of SimCity 4 Deluxe out in the wild, including the various digital editions (i.e., GOG, Steam, and the now-patched EA App version), the original disc version, and the Steam and App Store versions of Aspyr’s macOS port of the game.
As one may have noticed while scrolling the STEX in the past three months, a once uncommon, “Holy Grail” type of mod has begun to appear with some frequency: DLL mods. DLL mods are capable of modifying aspects of the game that have been previously off-limits to SC4 modders over the past 20 years. The two best-known DLL mods prior to this point are, of course, the SC4 Extra Cheats DLL, a file Buggi was authorized to release from the original developers at Maxis, and simmaster07’s revolutionary SC4Fix, which fixed two of the most notorious bugs with the game in a modded environment: the Puzzle Piece vs. Transit-Enabled Lot CTD, and the Prop Pox.
Thanks to the efforts of those continuing simmaster07’s line of work, namely Null 45 and memo, these sorts of revolutions are about to become more commonplace, bringing with them everything from improved game stability on modern systems, to long-requested new features and quality-of-life (QoL) improvements. Null 45 has already released over a dozen DLL mods on the STEX since November, one of the most recent of which allows more Building Styles. While I can’t reveal too much at this point in time, I will note that DLL files will become important components of major SC4 mods in the very near future. Suffice to say, we’re entering a very exciting time in the SC4 modding community.
There is, however, one caveat with this development: these new DLL mods will only work with Version 1.1.641 digital editions of the game on the Windows platform, while the older Windows disc versions and the Aspyr macOS port (in all its guises) will not be supported.
To those users who are running those versions, this almost certainly comes as a grave disappointment. There are, however, technical reasons that pose essentially insurmountable barriers toward bringing this new and exciting DLL-based functionality to those versions of the game, and effectively render them “legacy versions” of SC4:
Back in December 2017, simmaster07 had produced a mod known as SC4MacInjector, which provided a means for DLL-based mods to be converted into .so files and run in the macOS port via injection. Unfortunately, the changes that Apple made in macOS Catalina (10.15) effectively broke SC4MacInjector permanently, forcing simmaster07 to discontinue it in June 2020. With Apple moving to discontinue x86 architecture support in the near future, SC4MacInjector’s days were likely numbered either way.
With regards to the Windows disc-based versions of SC4, Microsoft’s removal of the secdrv.sys driver from Windows 10 effectively broke the SafeDisc copy protection system that EA used, thereby preventing the disc version from running (at least without complicated or legally questionable workarounds). The fact that the disc versions’ hardcoded aspects are also differently-structured (and encrypted) complicates the prospects of providing support for it to the point of practical impossibility.
For those of you running the Aspyr macOS port, unfortunately, Apple’s constant drastic changes to macOS and their entire hardware architecture have taken that version of the game out of the running. The only option to play on Mac with these new developments is some form of dual-booting and/or WINE with a digital copy of the Windows version of the game (which can readily be made to run on Linux). If you happen to be playing on the Steam version, you have access to the Windows version at no additional cost, since SC4 is a SteamPlay title. Unfortunately, with the App Store version, there is no such crossplay option available, and one will have to purchase a new copy.
In order for these developments to work directly with the Mac version, Aspyr would need to patch the game, preferably allow direct reading of .so files (the Mac equivalent of DLL files) without code injection or running afoul of Apple’s “Hardened Runtime” feature. Given that Aspyr, while updating their port to deal with Apple’s myriad drastic mandatory architecture changes over the years, has refrained from even issuing an equivalent of the 20-year-old 1.1.638/EP1 patch for the Mac port, or the almost-as-old 1.1.640/BAT nightlighting patch–the odds are even longer that they would do this.
For those on the disc on Windows, acquiring a legal Version 1.1.641 digital copy is the only way to get this functionality. Redeeming your CD Key with EA (via the EA App–EA Help can assist with this if one encounters difficulties) is one way to get one without having to buy the game again. The other option is to wait for the GOG edition to go on sale (typical sale price is US$4.99)–since GOG’s digital edition is DRM-free, it’ll be more “yours” than the disc version ever could be, as evidenced by the disc’s old DRM/copy protection scheme thwarting its use on newer versions of Windows. (And acquiring some sort of pirated/”cracked” version is, of course, a violation of community rules, including ST Guidelines, Section 5(a).)
Again, in short:
Version 1.1.641 Windows Digital Copies – Supported
Version 1.1.640 and earlier Windows Disc Copies – Not Supported (but CD Key may be redeemable for free Version 1.1.641 digital copy with EA)
macOS Port on Steam – Not Supported (but SteamPlay offers free Windows Version 1.1.641 digital copy with Steam for dual-boot/WINE use)
macOS Port on App Store – Not Supported (no option for compatible free replacement, purchase new copy)
All Other Versions – Not Supported (no option for compatible free replacement, purchase new copy)
In the past few weeks, I’ve fielded quite a few questions about whether such and such file from the former SC4 Devotion Lot Exchange (LEX) would be coming to SC4Evermore, the download-focused SC4 site I opened back in July 2023. The answer to pretty much 99% of any possible questions like that is “yes” (there are a few files–mostly things that are obsolete or too broken to fix, that won’t make the jump). SC4Evermore’s primary initial mission has been to become the new home of LEX content, albeit in a more modern, easy-to-use form–as evidenced by the LEX Legacy Packs (including the flagship BSC Common Dependencies set), and the fact that SC4E did away with SC4D’s often-confusing user account maze. There are also some efforts in the works to bring over some content that wasn’t previously available on the LEX over to SC4E.
The real question one should be asking is not “if” a given LEX file will be at SC4E, but rather, “when”. To date, we’ve managed to get the contents of about 1300 LEX files onto SC4E–though as one will notice, there’s only 158 actual files to download on the site, in large part because of the consolidation efforts we’ve made with the LEX Legacy Packs. We’ve managed to get many popular files restored in this format, but somewhere north of 60% of it is still pending, including the creations of popular BATers such as SimGoober, deadwoods, and many others.
As far as why this remaining 60+% hasn’t resurfaced at SC4E, the two main reasons are the discovery of a surprising number of serious issues with files in the process of preparing them for re-upload (including, in some cases, broken Lot Exemplars that have prevent growables from actually growing), and perhaps one of the heaviest outbreaks of Real Life (RL) Syndrome to hit the SC4 modding scene in many years. This outbreak has not only affected SC4E’s efforts, but also the NAM Team’s, compounded by the fact that SC4E’s content restoration efforts are pretty much entirely being undertaken by NAM Team members, who have the necessary expertise and commitment to carry out these tasks.
As a result, the climb beyond the first 1300 LEX files is going to be a slower and more arduous one, and it may still take us some time to get to the point of making all the remaining files available. We are much more concerned about doing things right than doing them fast (and wrong), and we thank the community for its patience in these times.
With regards to NAM 48, the LEX issues/SC4E efforts and the aforementioned heavy RL have derailed our Agile-like release engineering paradigm, and have basically put development on the new version on hiatus. To give some perspective as to just how heavy RL has been for individual members, in the roughly six months since NAM 47’s release, almost every one of the main active developers has changed jobs, started or finished grad school, and/or moved–in some cases, twice. The inconsistent pace of development has pretty much everyone of us unsure of the current state of this version, and we’re still evaluating how to proceed–once we actually find the time to do so.
If you’ve been over to SC4 Devotion’s temporary front page of late, you’ll notice there’s discussion of a new site, SC4Evermore. RL has been very brutal for me of late, so I’ve been a bit slower in terms of getting the official word out about what’s happening with SC4 Devotion and SC4Evermore (outside of the respective sites’ homepages).
What is SC4Evermore?
SC4Evermore (or SC4E, for short, https://www.sc4evermore.com) is a new, download-focused SC4 site that I’ve started. Its primary goal is to create a stable platform through which SC4 custom content can be preserved and shared in an easier-to-access modern form. The initial first goal with the SC4Evermore project is to make available the files that were previously hosted on the SC4 Devotion LEX, prior to the last-minute webhost-mandated PHP 8.1 upgrade that took SC4D (in its familiar form) offline on June 11th, 2023. All of the files that were previously hosted on the temporary SC4D frontpage have been made available at SC4Evermore, and more will be coming in the days and weeks ahead.
The name itself is a tribute to two community figures, Maxis’ Wren Weburg (of Wren Insurance fame), who formerly ran a site called SC4ever, and the “SC4, Forevermore!” catchphrase used by popular BATer DuskTrooper. Symbolically, SC4E also happens to come directly after SC4D in alphabetical order. The new name also emphasizes that the site is intended to be a true community effort, and we look forward to sharing more details on this end in the near future.
The SC4 Devotion Discord Server has also been rebranded to become the SC4Evermore Discord Server, and has recently been converted to a full Community Server, which brings with it new functionality, including Forum Channels–the first of which we’ve now launched with NAM development threads.
Rather than running on custom or commercial software, SC4E is running on Joomla, since it is an actively-maintained, open-source content management system (CMS) with the necessary features and plugins to run a viable file exchange.
Why aren’t all of the LEX‘s files available already? And why didn’t you just try to get the LEX back up and running?
The LEX had 4198 files in its database prior to being taken offline, and many of those files had descriptions with information about dependencies and the like. Recreating all of that is going to take a lot of time, and it’s been slower going of late due to the fact that, since the closure, heavy-duty RL has affected many of the key stakeholders involved.
The LEX’s custom software, while at least partially fixable, suffered from an onerous and ancient account system, which was a common source of complaints (see the frequent password/registration issues). Additionally, its key feature that helped make the dependency-heavy file ecosystem manageable, the Dependency Tracker, was very resource-intensive, and severely taxed our server (particularly in terms of RAM usage). Upgrading the server or changing webhosts is not an option at this time (and won’t be until 2025), so there was a real need for something less intensive.
To deal with the loss of the Dependency Tracker, offer a more streamlined and complaint-free distribution system, and curb server RAM usage, there has been an effort underway (spearheaded by Tyberius06, Ulisse Wolf, and myself) to repackage many key LEX files into a more convenient form that doesn’t require exotic infrastructure, as evidenced by the LEX Legacy packs we’ve been compiling since SC4D was knocked down by the PHP issues. This also takes time, but we hope it will lead to a much better experience for users of SC4 custom content in the long term. We’ve been prioritizing more frequently-used files, especially dependency packages that also get used by many files on the STEX.
What’s happening with the SC4D Forums and Wiki?
Both the SC4D Forums and wiki are back online (still operating on the sc4devotion.com domain, so the original links to them still work without issue).
However, we have, for the time being, placed the Forums into a semi-archived, read-only state for everyone, except staff and members of custom content teams with established private development forums on the site. As mentioned, we have added Forum Threads to the Discord Server. The decision on the read-only/semi-archived state of the Forums is not a final one, but we will only consider a full reopening if we know it’s going to attract enough activity to justify it.
The Wiki, operating on a fragile install of an older version of MediaWiki, has a number of issues, including certain articles being inaccessible or impossible to edit–something which cannot be fixed without doing a full reinstall of a newer version of MediaWiki that is fully compatible with PHP 8.1, and likely a manual reimport of all the articles and data currently on it (which was required previously with the 2019 migration).
Why have I been having issues with incomplete downloads on SC4Evermore?
One of the issues with running a file exchange which allows guest downloading without user accounts (which were a frequent source of complaints about SC4D and the LEX) is that it is a lot more susceptible to issues with bots. We had numerous cases in the first few days that SC4E was open with bots downloading the same file repeatedly (and often large ones, at that), sometimes as many as hundreds of times in a row in a short time span, which seems to have had the effect of a mild DDoS attack. We’ve started implementing solutions to curtail this bot activity without introducing roadblocks that hamper the experience for legitimate users in other ways, including getting CloudFlare protection working on the site.
Thank you for your support, and we hope you find SC4Evermore to be a useful resource to further your enjoyment of SimCity 4!
Those of you who have followed SimTarkus over the years have gotten a front row seat to the saga over the EA App (formerly Origin) and EA Play (formerly Origin Access) retail edition of SimCity 4–how it was originally locked to the unpatched Version 1.1.610, then fixed after my exposé blew up on Reddit and got covered by PC Gamer in 2014, then quietly and mysteriously reverted back to Version 1.1.610 sometime after the furor died down.
Well, it appears that sometime earlier today, not long after the EA Publisher Sale ended (which saw the game’s price temporarily drop down to a mere US$1.99 on Steam and directly through EA), EA finally did the thing that myself and pretty much the entire SC4 community have wanted them to do: re-patch their version of the game to Version 1.1.641, the same version that GOG.com and Steam have offered from the beginning.
The first report rolled in via /u/mate54 on the /r/simcity subreddit about 8 hours ago. My NAM Team colleague Ulisse Wolf and I both happen to own copies of the EA App version, and much to our pleasant surprise after so long, we were able to confirm the reports.
I’ve been able to install the new version (the EA App also did not try to sidle onto my Steam or GOG copies, as it had done during my previous investigations in September 2022), and sure enough, the executable is indeed Version 1.1.641. The size of the SimCity_1.dat file, one of the most critical files in the game, also matches that of the GOG version.
Updated EA App copy at Version 1.1.641.
Ulisse Wolf has done further testing in-game with the update to verify that it is operating up to spec with the other digital editions, and found that the Network Addon Mod (NAM), custom building nightlights, and critical DLL mods like SC4Fix.dll (which solves a number of major game issues) all work as intended. Like all other digital editions, while the game’s patches are applied, the 4GB/Large Address Aware patch is not already applied, and one will still need to apply it to the game prior to attempting to run the full version of the NAM. One should also make sure to add the -CPUCount:1 fix to the launch options for the game, either in the EA App or via any shortcuts it creates (or alternatively, use a separate launcher utility) to avoid the crash-to-desktop issues when running the game on systems with multi-core CPUs. To do so, simply click “Manage” on the game’s page in your EA App library, select “Properties”, and then type the command into the “Ulisse Wolf has done further testing in-game with the update to verify that it is operating up to spec with the other digital editions, and found that the NAM, custom building nightlights, and critical DLL mods like SC4Fix.dll (which solves a number of major game issues) all work as intended.
Like all other digital editions, while the game’s patches are applied, the 4GB/Large Address Aware patch is not already applied, and one will still need to apply it to the game prior to attempting to run the full version of the NAM. One should also make sure to add the -CPUCount:1 fix to the launch options for the game, either in the EA App or via any shortcuts it creates (or alternatively, use a separate launcher utility) to avoid the crash-to-desktop issues when running the game on systems with multi-core CPUs. To do so, simply click “Manage” on the game’s page in your EA App library, select “Properties”, type the command into the “Advanced launch options” box (as shown below–I’ve censored out my product key), and then click “Save”.
How to add the -CPUCount:1 fix in the EA App.
(Steam users should also do the same; GOG’s edition already includes this fix in the game shortcuts.)
We will be removing the warnings regarding the EA App/EA Play from the NAM documentation shortly, and we appreciate the team at EA and EA Play correcting this longstanding issue.
After a mere two-and-a-half months of development, NAM 47 has been released, with some pretty revolutionary features, on two completely different ends of the transportation spectrum: 12-lane highways with 3-lane ramps, and Draggable Classic PedMalls with RCI access.
For those looking for a more minimal NAM experience, we’ve also updated NAM Lite to Version 3, restoring the Maxis RUL2 code that went MIA, and adding the FLEX Road Overpasses to the optional Additional Network Features section.
The RHW-12S network was originally planned to be part of the notorious NAM 31 release, almost exactly 10 years ago, but was cut during that version’s final month of development, in large part because no ramps or width transitions had been developed for it at that point–which meant there was no way to get on or off the network, making it effectively useless. A decade later, however, it’s been revived, complete with support for the FLEX Width Transitions and an extensive array of supported ramp types. Among those ramp types are the mythical Type A3 and Type D3 ramps, which allow one to have 3-lane exits and entrances to and from not only the RHW-12S, but also its smaller brethren, the RHW-8S and RHW-10S. While the Type A3 and Type D3 ramps are ground-level only at present, many of the other orthogonal ramps for the RHW-12S do have L1 and L2 elevated forms, thanks to the model-making efforts of my colleague Flann.
On the complete opposite end of the spectrum, my colleagues Lucario Boricua and Ulisse Wolf have managed a “holy grail” modding effort, by not only adding the Draggable Classic PedMalls to the NAM’s transportation toolkit (with 8 different styles, no less–two more than the old puzzle pieces), but by also working out a solution to allow full access to RCI zones with them. The game normally operates with a hardcoded requirement for Car access to get most zones to develop–especially Residential zones–but some special pathing work resulted in a functional solution, without having to get into the wild world of DLL modding.
You can check out both in the “Secret Weapon” videos that Ulisse Wolf produced for this release cycle:
Here’s a full list of NAM 47’s features:
Pedestrian Revolution Mod Features:
The NAM Team is pleased to present the Classic Draggable Pedmalls, courtesy of Ulisse Wolf and Lucario Boricua. These come in 8 styles, 6 of which are equivalents to the Pedmall Puzzle Pieces, and introducing 2 new designs: the Retrowave Red Brick, inspired in the old brick texture used for the U-Rail in earlier NAM versions, and the Industrial Style, using the concrete surface typical of industrial lots. The initially supported features of these pedmalls include:
Multidirectional draggable starter pieces using the Street network, supporting all orthogonal, diagonal, intersection and roundabout configurations, with the exception of wide radius curves.
Intersection support (OXO T and 4-way) in the form of mid-block crosswalks. These support Road, Avenue, and all two-way Network Widening Mod override networks (TLA-3, AVE-2, ARD-3, NRD-4, TLA-5, RD-4, RD-6, TLA-7 and AVE-6). These draggable pedmalls are also compatible with the FLEX mid-block crosswalk pieces.
Special underground paths enable residential zone development, while crossings discourage car traffic through restricted car paths.
In addition, some enhancements to existing functionality have been implemented:
The override code for the size 3 mid-block crosswalks for TLA-7 and AVE-6 have been overhauled, enabling these to be overridden from one side.
RealHighway (RHW) Features:
RHW-12S A new, 12-lane quadruple-tile RHW network (separable into two dual-tile halves, carrying 6 lanes in each direction) has been added, with the following features:
Three height levels are supported: L0/Ground, L1/7.5-meter elevation, and L2/15-meter elevation. Transitioning between these height levels is supported by the ramp-style FLEX Height Transitions (FLEX-HT), as well as the FLEX OnSlope Transitions (FLEX-OSTs), by connecting them to the RHW-12S networks.
The RHW-12S features the same network crossings presently available to the other S-Type RHW networks, including crossings in all orientations for all Maxis base networks, all other RHW networks, Draggable Ground Light Rail, and Draggable Road Viaducts (L0-under-Viaduct-only), plus Orthogonal x Orthogonal (OxO)-only support for Network Widening Mod networks, Elevated RealRailway (ERRW) Viaducts, Tram-on-Street, Tram-in-Road, and Tram-in-Avenue. Limited Hybrid Railway (HRW) support also exists.
Extensive ramp interface support: supported ramps using FLEXRamps and Draggable Ramp Interfaces (when applicable) include Orthogonal Type A1 (all levels), Type B1 (all levels), Type D1 (all levels), Type E1 (all levels), Type A2 (all levels), Type B2 (L0 only), Type D2 (all levels), Type E2 (L0 only), Type A1-Inside (all levels), Type B1-Inside (all levels), Type D1-Inside (L0 only), Type E1-Inside (L0 only), the new Type A3 (L0 only) and Type D3 (L0 only), plus Diagonal Type A1 (L0 only), Type B1 (L0 only), Type D1 (L0 only), and Type E1 (L0 only).
FLEX Width Transition (FLEX-WT) has been added, to support width transitions between RHW-12S and RHW-10S at all applicable height levels.
FLEXFly over and undercrossings are supported with the RHW-12S (orthogonal-only, as diagonal undercrossings for FLEXFly do not presently exist for any network).
Several bridges have been added (see Bridge section).
Support for FlexSPUI is presently limited, and Three-Level Crossings are not yet supported.
RHW X3 Ramps: The first two FLEX 3-lane ramps, in A3 and D3 configurations, have been provided for RHW-8S, 10S and 12S. At present, only L0 support is available.
General Improvements:
Some enhancements, courtesy of memo, have been made to facilitate FLEXFly-over-FLEXFly functionality.
Some enhancements, courtesy of Flann, to elevated RHW network models have been added.
Various adjacencies involving RHW x RHW crossings next to the base orth-diag curve on the smaller networks (RHW-6S and smaller) have been addressed.
Bridges: A multitude of new bridges have been added, courtesy of IDS2 and Kitsune:
New viaduct bridges for L0 RHW-8S, L0 RHW-10S and L0-L2 RHW-12S.
A pair of new Steel Arch bridges for RHW-10S and RHW-12S.
Base Network Features: A new 5×5 90° Wide Radius Curve FLEX piece has been added to the Avenue network.
Miscellaneous: A huge number of bugfixes have been done for this release, including:
Various RHW situations involving “tile drops”, such as the RHW-8S-to-6S FLEX Width Transitions, the RHW-8S Type D1, E1, and B2 ramps, and the RHW-10S Type D2 and E2 ramps, have received considerable stability upgrades.
The orientation of the Road end-T on OWR-1 intersection has been corrected.
The orientations of certain NWM intersections involving the OWR-1 network with Euro textures have been corrected.
Stability improvements have been made to the Ground Light Rail crossings with various wider RHW networks.
The Dual Type 230 QCXs with L1 Dual Type 230-over-RHW-8C/6C and RHW-10S/8S have been improved.
Issues in which lane drop arrows appeared in the wrong places on the S-to-C FLEX Width Transitions have been corrected.
The ramp textures for the RHW-10S Type D2 and E2 ramps, as well as for the RHW-8S Type A2-Wide and B2 ramps have been improved.
Orientation and stability issues have been fixed with the Avenue-based AVE-6 and its Thru-T-intersections with Street, Road, and One-Way Road (both Short-T and Long-T).
Orthogonal x Diagonal slip lanes involving Road and One-way Road (OWR) have been re-implemented.
Several hundred path files across all areas of the NAM have been fixed by memo and Tarkus.
More SAM Street crossings with the Rail network have received crossing gates.
Euro wealth textures have been added to the Avenue-based AVE-6 network.
Once again, it’s worth noting that despite EA using pictures of the NAM on the EA App and on the game’s official page, the version sold on the EA App (and also offered up via EA Play and Xbox Game Pass) is the same as the infamous Origin retail edition (Version 1.1.610), and is not supported by the NAM (or NAM Lite). If you’re on Windows (or Linux) you’ll need at least Version 1.1.638 (and preferably Version 1.1.640 or 1.1.641) in order to run the mod.
We hope you enjoy the new version, and I look forward to seeing what everyone can do with these features. Rest assured, we have no plans of slowing down, and we’re already planning what kinds of transportation goodies we can bring to the table for NAM 48.
Just a few days ago, Aspyr released an update to their macOS port of SimCity 4 Deluxe to add native support for Apple Silicon processors–a move that will allow their port to continue to run on that platform even after Apple’s inevitable removal of the Rosetta 2 compatibility layer in the not-too-distant future.
For those who haven’t followed the saga of all the various digital editions of SimCity 4 that are available now, the Aspyr macOS port is distributed via two different platforms: Steam and Apple’s own App Store. And there are some very important differences between the editions offered via each platform, namely in terms of how they handle plugins and mods. The Steam version works very similarly to the Windows version, in that the Plugins folder is stashed within the user’s Documents folder.
However, due to Apple’s packaging requirements, the App Store does not use an external Plugins folder. Instead, the plugins are to be placed directly inside the .app container–specifically, per Aspyr, ~/Library/Containers/com.aspyr.simcity4.appstore/Data/Documents/SimCity 4. Since the .app file is what is being updated here, this means thatupdating one’s App Store version of the game will delete all one’s plugins. This sad fate happened to /u/SydneyEditor over on Reddit, as detailed here.
In order to avoid this, App Store users should backup the plugins within the .appbefore installing the update, by copying them to an external location.
Yesterday marked a significant milestone for SimCity 4: 20 years since it was released, back on January 14th, 2003. Now, right on the heels of this momentous occasion, the NAM Team is pleased to announce the release of not one, but two new packages: NAM 46 and NAM Lite 2.
NAM 46 is a full-blast transportation extravaganza, and includes among its new features the first phase of diagonal intersection and crossing support for the Network Widening Mod (NWM), over 20 new bridges by the team’s highly-prolific new bridge modder, IDS2, and much much more. Here’s the full list:
Network Widening Mod (NWM) Features:
Support for diagonal 4-way (+) intersections and crossings has been added for all six single-tile NWM networks (TLA-3, AVE-2, ARD-3, OWR-1, OWR-3, and NRD-4), including orthogonal X diagonal (OXD), diagonal X orthogonal (DXO) and diagonal X diagonal (DXD). These networks may cross one another, along with all base Maxis networks, Ground Light Rail (GLR), and Single-Track Rail (STR). Support for 3-way intersections, other NAM network families (i.e. RHW, SAM, etc.), and those involving multi-tile NWM networks will be added in a future phase.
A preliminary version of an Avenue-based form of the 6-lane Avenue (AVE-6) network has been added, which supports full wealthing. To build an AVE-6 with the Avenue tool, overlap two orthogonal Avenues, and they will convert (diagonals are not presently supported). Most intersections supported by the existing AVE-6 are supported with this new implementation, and it is also possible to transition to the traditional Road-based AVE-6 for any functionality not yet supported.
New Bridges: Over 20 new Bridges have been added, courtesy of IDS2, including the first Bridges for the OWR-4 and OWR-5 networks (which are Avenue-based Bridges, due to the side-by-side Bridge limitation). Further bridge support has been added for RD-4, RD-6, SAM-6 (Klinker Streets), SAM-11 (MGB Industial), Double-Track Rail (DTR) and Single Track Rail (STR).
Hybrid Railway (HRW) Features: L2 HRW support has been added, along with LHD improvements, and a reimplementation of the OnSlope Transitions to improve slope handling. Elevated support includes R2 elevated curves (at L1 and L2), orthogonal X orthogonal (OXO) crossings with the base road networks (Road, OWR, Avenue), the Network Widening Mod and the RealHighway, and diagonal X orthogonal (DXO) includes the base road networks and the RealHighway.
Rail Slope Settings: An improved set of Rail Slope Settings has been prepared, providing more user choice and greater usability with the smoother/more restrictive options.
Base Network Features:
Courtesy of the recently-returned Shadow Assassin, the diagonal transitions between the Avenue network and the Road and RHW-2 networks have been dramatically improved, and extended versions have been added. Direct connection transitions were re-designed for a smoother look, and the new extended versions use a stub-to-stub override.
In preparation for future phases of the NWM diagonal intersection expansion, the base T-intersections involving diagonal Road and/or One-Way Road have been revamped.
RealHighway (RHW) Features:
The long-awaited Dual Type 230 QuickChange Xpress Diamond Interchange setups are now available, which allow one to quickly build pre-fabricated interchanges between various RealHighway (RHW) networks and the triple-tile NWM networks, complete with turn lanes and all the bells and whistles.
The Diagonal Ramp-Style FLEX Height Transitions now support RHW-3 and RHW-6S.
The Double-Decker RHW-4 (DDRHW-4) models have been revamped, courtesy of Ulisse, coupled with some improvements to base functionality.
The Type E1-Inside ramps now have elevated forms, and various incremental improvements have been made to the elevated ramp interface models.
The Type A2 and B2 merging ramps have been re-designed to feature a lane drop prior to connecting with the mainline lanes.
A new FLEX Width Transition piece has been added, to better facilitate transitions involving multi-tile S-type networks (especially the previously unstable RHW-8S-to-6S transitions, with their tile drop).
The MIS 2-Lane FLEX Turn Lanes (including the FLEX Height Transition) can now connect smoothly to FlexSPUI and FlexDDI.
FLEX Turn Lane (FTL) Streetlights: The FLEX Turn Lane (FTL) setups (except the very limited Avenue Type 020) now support streetlights.
New NAM Website: An official Network Addon Mod website has been launched, https://www.sc4nam.com, featuring NAM documentation and feature guides.
In addition to the full edition of the NAM, the NAM Lite package, introduced as part of NAM 45, has been spun off to become a standalone download, with the release of NAM Lite 2.
A much more compact version of the flagship mod, NAM Lite features just the most essential of NAM features, including the renowned Traffic Simulator Plugins, refining SimCity 4’s pathfinding engine to work as it was originally intended, along with Automata Controller options, updated textures (including a Euro/International texture option), Roundabouts, Diagonal Streets, additional interchanges for the game’s base Highway system (the “Maxis Highways”), and (optional) Hole Diggers/Ground Raisers, allowing for precise terrain alteration.
Here’s the full list of what the NAM Lite update brings:
NAM Lite is now offered as a separate download.
Issues involving the Additional Maxis Highways feature have been addressed, including fixing functionality with Road and One-Way Road Perpendicular Interchanges with Elevated Highways, some of which affected users who did not install this option.
Some features from the full edition of the NAM that were unintentionally accessible through NAM Lite menu buttons (in very broken forms) have been removed from the Perpendicular Interchanges and Avenue Roundabouts buttons.
The Hole Digger and Ground Raiser items have been added to NAM Lite, as a strictly optional additional feature. They can be selected under “3 Additional Network Features”.
The SC4 anniversary has also started to attract the attention of some parts of the gaming press, including some very nice articles at Rock Paper Shotgun and the German GameForest. I shall be doing some further celebration of this anniversary (there may be some things afoot with Tarkusian Cities soon, even), and I can’t wait to see what all of you will do with these latest NAM features. Here’s to 20 years of SimCity 4, and many, many more.
Edit (as of 9 August 2023): EA has updated the EA App (formerly Origin) version to Version 1.1.641, such that it is now compatible with the NAM, as of June. However, EA is still using the images in question on the store pages for the game.
Recently, my good friend and colleague memo (who invented the first FLEX Piece back in 2006) returned to the SC4 community, and he happened to notice something very curious on the newly-revamped version of EA’s page for SimCity 4, in the screenshot gallery:
Screenshot of NAM Fractional Angle Roads in the screenshot gallery for EA’s official SimCity 4 page, taken August 21, 2022. Original SimCity 4 image by memo.
The image in question was actually made by memo himself, sometime in 2012-2013, showcasing the new Draggable Fractional Angle Roads feature he spearheaded during the development of Network Addon Mod (NAM) Version 31. In fact, six of the nine images included in EA’s promotional gallery clearly feature mods and custom content, and were almost certainly made by members of the online SimCity 4 community. Other prominent pieces of content shown in the gallery include one of cogeo‘s Semi-Transparent Train Stations, and KingOfSimCity‘s re-lot of SimGoober‘s Super Shopping Center #1. The NAM’s Diagonal Streets and Road Viaducts/Overpasses are featured in another featured image.
The bitter irony of these screenshots being used here are the advertisements just to the right, for the EA Play and Origin Store/EA App versions of the game–which, as many readers of this blog know, are perma-locked to Version 1.1.610, thereby not meeting the NAM’s minimum requirement of Version 1.1.638, which has been in place since the very first release of the mod in April 2004. Between June 2013 and July 2020, this requirement was actually enforced by a version check routine in the installer, which was instituted after users with unpatched games kept pointing blame at the NAM Team for issues that were fixed by EA/Maxis with Version 1.1.638. This version check ended up not only blocking users running unpatched disc copies and cracked copies from installing the NAM, but also those using the Origin Store’s perma-unpatched edition–which, as it has a different checksum than the original disc-based edition of Version 1.1.610, also isn’t recognized as a valid executable by EA/Maxis’ own official Version 1.1.638 patch (known more formally as “EP1 Update 1”).
As for the NAM Team’s perspective on this, we feel honored that EA would use screenshots with the NAM on their official promotional page for the game. On the other hand, however, we’re quite frustrated that EA/Origin is using it to promote sales and subscriptions for a version of the game that our mod doesn’t actually support, along with their silence in the face of community and customer complaints about its perma-unpatched state. Origin support agents, likely working off scripted responses, have generally tried to deny that EA/Origin possesses a patched copy of the game, which is absurd, given that:
Origin, the EA App, and EA Play are services of the very same company that made SimCity 4 and its subsequent patches.
Origin Customer Support has been giving free digital Version 1.1.641 copies (above the NAM’s requirements) to customers utilizing the CD Key Redemption program for many years. (There are some rumors this program has ended, but suffice to say, Version 1.1.641 is in EA/Origin’s possession.)
After my initial article on the issue here at SimTarkus in August 2014–which later ended up getting covered by PC Gamer–Origin did briefly switch out the perma-unpatched Version 1.1.610 for a pre-patched executable, which did meet the NAM’s requirements. However, they actually reverted back to a perma-unpatched edition without any fanfare–per the file dates, this was likely around November 2015. EA/Origin has not given a response as to why the reversion happened, which has led to considerable community speculation.
Steam and GOG have been selling digital Version 1.1.641 copies for many years. In Steam’s case, this has been since 2010 (prior to Origin’s launch in 2011).
In short, we’re glad to see EA promoting the NAM, and we’d be willing to discuss further efforts with them. But first things first–patch up the Origin Store/EA App/EA Play edition of the game so it meets the minimum requirements of the mod you’re using to promote it. You did it once, you can do it again, and you’re letting everyone down by continuing to trot out the perma-unpatched edition.
Those of you who have followed the developments of the Network Addon Mod (NAM) in recent times have likely noticed that the pace at which new versions have been released has increased dramatically in the past 18 months. Indeed, after NAM 37 took nearly 3 years, finally making it to an official public release in July 2020, in a little bit more than half that time, we’ve released 7 more versions, including the new NAM 44 release. We’ve also dramatically increased the size of the development team, which went from being a skeleton crew, with a mere three active developers, to one with over 30 members contributing in various capacities, approaching a size it hasn’t been since nearly a decade ago.
The fact that a computer game mod that has been continually developed since 2004–for a game released on 2003–has had this much going on nearly two decades later would likely be a surprise to many. Indeed, it’s a surprise to me, too, and as someone who has been involved for 15 years as of this past February, a very pleasant one. And I thought I would share my experiences as to what has changed in the past 2 years in order to make this sudden snowballing of activity with the NAM possible.
Those of you who have followed the NAM project over the past 5 years know at least some of the story of the infamous NAM 37, some of which I’ve shared here at SimTarkus. Long story short, that whole development cycle was cursed. Development on content intended for NAM 37 had already started before NAM 36 was released in September 2017. However, many of those projects we started encountered significant roadblocks (including the “Tidal Flow” issues that stymied the RealExpressway, the originally-intended flagship project for the cycle), causing them to get shelved and forcing us back to the drawing board constantly. And our very small development team, even with some slight expansion (including the key additions of our Bridge Department Lead, Kitsune, and SC4 Renaissance man Tyberius06), was often waylaid with heavy cases of Real Life (RL).
Once we finally did get things on track again, assembling the first complete internal build for the cycle, the aptly named NAM 37 Alpha Build 01 (NAM 37 A01 for short, also since referred to as “the nuclear artifact”), our installer system–which had already become a bit shaky with NAM 36–completely blew apart at the seams, the product of trying to corral the increasingly dense array of crosslinks between optional components, and the complexities of its interactions with the NAM Controller Compiler utility. It was routinely completely skipping the compilation of the NAM Controller, and also the failsafe of installing a full, pre-compiled one–and given that the NAM Controller contains all the RUL code required for the NAM’s network additions to be built in-game, this was a fatal issue.
Screenshot of NAM 37 Alpha Build 01 Installer – the infamous “Nuclear Artifact”
This situation resulted in a yearlong period of trying to completely re-engineer the mod’s file architecture, in order to reduce the internal complexity, and allow for it to be compatible with a different installer system. And given the fact that both eggman121 and myself worked in “essential” industries, the pandemic did not really slow RL down for us. The whole cycle was one, long struggle for survival for the NAM–and somehow, we did survive. But in order to keep surviving, it was clear we needed to do something different. The development hell of NAM 37 could not happen again.
On April 18th, less than a week before we finally issued a public release candidate for NAM 37 (prior to the official release in July 2020), I made a lengthy and rather frank post in our private development boards at SC4 Devotion, entitled “Guidance on NAM Development and Build Cycles – NAM 38 and Beyond”, or as it could be jokingly called, “the NAMifesto”. The NAMifesto basically addressed some of the long-standing elephants in the room (which had arguably been there since Tropod retired as team lead back in late 2005), and laid out a plan for how we could keep NAM 37 from happening again, which we’ve successfully implemented since then. My colleague Lucario Boricua put together this annotated version of our GitHub code commit graph, which illustrates how things have gone since the beginning of the “Monolithic Era” of the NAM (starting in 2013 with the release of the infamous NAM 31–our GitHub depository was started shortly before that version’s debut). As you can see, the “Agile Era” section, corresponding to our activities after the release of NAM 37, has a consistent flurry of activity, with much higher peaks than were seen at any point during the “Monolithic Era” that preceded it.
Graph of commits to Network-Addon-Mod GitHub depository, February 24, 2013 to March 22, 2022
One of the curious things with NAM development, which has been consistent throughout my 15 years on the team, is that it’s a largely freewheeling endeavor, and rather improvisatory in nature, especially during early phases of a release cycle. There’s no premeditated, centralized planning of releases or feature sets, and developers are generally not told what to do. Instead, they tend to work on what projects interest them, often in line with a sort of mutually-agreed-upon roadmap of where the NAM is headed, either solo or in collaboration with other developers, and there’s a sense of shared responsibility for seeing things through to a releasable state. Allowing developers with a mutual sense of purpose that level of autonomy is really the key to what has made our development processes and our working environment tick.
One of the structural issues we had often faced, however, was the fact that as the scale and difficulty of projects increased as the NAM evolved, and as RL had varying impact on developers throughout the release cycles, this could sometimes cause already-long cycles to be prolonged even further. We worked until we felt a given feature set was “complete enough”, however long that took, and that often spiraled into development hell, as developers got used to the long cycles and would give into the temptation to make more stuff. We’d pencil in rough target dates, and often consistently blow past them–NAM 28, for instance, was initially discussed among the team as a November 2009 release. It ended up being a May 2010 release–and despite also coming alongside the long-awaited debut of the Network Widening Mod (NWM, which was then a “separate-download plugin”), had a number of really ugly bugs that made it one of the worst releases the NAM Team ever made.
The early NAM releases were usually quick affairs–in fact, during the first two years of the NAM, 2004 and 2005, the average length of a release cycle was about 3 weeks. But after Tropod’s retirement from team lead duties, following the release of NAM 19 in late 2005, the average length ballooned to 9 months, and was trending toward cycles exceeding one year in length, beginning with NAM 30 in 2011, the last of the “Modular Era” releases. The length of the development cycles did not lead to a better product, either, as developers and testers became bored and frustrated (myself included), and lost focus. The thought among developers was “if I don’t get this into this next NAM, I’ll have to wait another year, maybe longer.”
The goal of the NAMifesto was to put a stop to this. The solution was to ultimately go back to something that more resembled the Tropod-Era NAM–back when the team was still called “Modd Squad Transport”. I proposed:
A hard cap on release cycle length, with enforcement of that cap.
Avoiding the sorts of major respecification projects that had become ubiquitous in NAM development during the 2010s, unless there was a very clear benefit to them.
Not being afraid to cut content that wasn’t going to be ready in time for meeting the hard cap.
Re-framing larger-scale projects as being things that could span over multiple releases (either by being broken into phases, or developed in the background), while drawing attention to the fact that being “three versions out” under this paradigm would still be sooner than “next version” under the old way.
The other members of the team, having some of the same frustrations I did after the joyless experience of NAM 37’s cycle, were willing to give it a shot, and entrusted me to help establish this plan as an official team lead (the first time we’ve really had one since smoncrie’s short post-Tropod tenure as team lead in 2005-2006, before RL forced him to take what ended up being a two-year hiatus). In many ways, what we ultimately built is an “Agile-like” development process. While some in the software community may bristle at “the a-word”, and conjure up mental images of rapid-but-buggy releases, and heavy-handed project managers demanding constant status updates, the NAM Team’s particular “Agile-like” approach has avoided establishing the bureaucracy of formal scrums, sprints, and the like. Instead, it has been about achieving results, doing so through a sustainable, repeatable process, and maintaining the “chaotic good” that characterizes NAM development at its best.
While the NAM Team policy has long been to avoid discussing release dates and timelines with the public (the one time we did was the disastrous NAM 31 cycle), it is worth noting that we have successfully met our “cap” with every release cycle since, with the average development cycle length for an Agile-Era NAM release being 3 months.
Cycle lengths for NAM Versions 1-44 (Version 1 cycle length technically unknown)
The increased focus has allowed us to more rapidly deal with bug reports and technical issues, and remain focused on our developmental tasks, resulting in more cohesive releases that have often ended up with larger feature sets than our previous marathon cycles, and, in contrast to the stereotypes about Agile development (and pre-Agile NAM releases with much longer cycles), fewer bugs. If a feature is not ready, we’ll simply cut it, and revisit it in a near future release cycle, thereby allowing it to reach a stable, mature state that’s ready for public consumption when it does finally debut. The shortened release cadence has helped tremendously in curbing the problematic, artificial sense of urgency that the old way of doing things pushed on our developers.
The way in which these changes have reinvigorated NAM development efforts has also gotten quite a number of new NAMites interested in learning some necessary skills to contribute. We’ve been readily upskilling the newer team members in various developmental tasks, thereby increasing our throughput that much more. Based on Lucario Boricua’s calculations from our GitHub activities, the NAM Team in this “Agile Era” is currently 4.4 times more productive than in the previous “Monolithic Era” (from NAM 31 in 2013, up to the eventual release of NAM 37 in 2020).
We’ve also been very careful with our efforts to grow the team, by bringing on those whose aptitudes, personalities, and maturity levels will be a good fit for the NAM ecosystem. Some past issues with personality conflicts have nearly derailed the entire NAM effort (we lost most our development team as the result of one that occurred during the NAM 33 cycle in 2015), so we’ve refined our recruitment methods (which are still invitation-only) with the goal of bringing in people who will be able to work respectfully with other NAMites. In fact, we’re more prone to focus on that aspect, as there’s many ways NAMites can contribute meaningfully to the overall effort.
The one other big difference that has come about during these more recent release cycles is the move toward using private Discord channels as a communication tool, rather than focusing on the forums (which we still utilize in some capacity). The live, active nature of Discord has helped create a more collaborative, responsive team environment, which has accelerated development and helped foster team unity. While we might not have the formalized scrums and stand-ups that a proper “Agile” development team might have, this does allow us regular, natural communication, without artifice.
There are still some areas where we are refining the process, but all in all, the changes brought about by the NAMifesto have probably produced the most productive and harmonious iteration of the NAM Team that I’ve seen in my 15 years involved with the project. Here’s to hoping we can continue it for many more.
NAM 44–the 44th version of the Network Addon Mod for SimCity 4–has just been released. (Just in time for Haljackey’s birthday, coincidentally enough.) It is presently up at ModDB, the SC4 Devotion LEX, and Simtropolis. What’s new in this version? Here’s a list of the feature set.
Hybrid Railway (HRW) Features: The Hybrid Railway system now features FA-2 Alt content, new textures to blend with the RealRailway (RRW) system, improvements to catenaries, and major improvements to Left-Hand Drive [LHD] support.
RealHighway (RHW) x Avenue Features:
The RealHighway (RHW) now has a FlexDDI system, allowing for FLEX-based Diverging Diamond interchanges with the Avenue network at ground level, and L1 and L2 elevations. Additionally, the FlexSPUI system now supports the L1 height level for the Type 120/Avenue configuration, along with stability improvements for all height levels. Both of these FLEX-based items can be found under a new button on the Roads menu.
The Avenue Type A1 and B1 MIS Ramp Interfaces have received draggable forms, following the same basic drag patterns as the RHW Type A1 and B1 Ramp Interfaces. (The still-puzzle-based C1 Ramp has been moved under the FARHW Ramp Interfaces button.)
RealHighway (RHW) Curves: New 90°draggable Mini-Curves have been added.
The new 3×3 R1 90°Curves support the ground-level RHW-2, RHW-3, RHW-4, and MIS Ramp networks.
The new 4×4 R1.5 90° Curves support the ground-level RHW-2, RHW-3, RHW-4, RHW-6S, and MIS Ramp networks.
The RHW-6S also now supports the 5×5 R2 90° Curve configuration.
MIS Ramp network support has been added to the FLEX S-Curve, and minor aesthetic improvements have been made to the L1 and above RHW-4 FLEX S-Curves.
RealHighway (RHW) Transitions:
45° Curved FLEX Height Transitions at the R3 radius have been added, covering the RHW-2 (L0-L1), RHW-4 (L0-L1, L1-L2, L2-L3, L3-L4), and MIS Ramp (L0-L1, L1-L2, L2-L3, L3-L4) networks.
Diagonal FLEX OnSlope (FLEX-OST) support has been added for the RHW-3 and RHW-6S networks.
Additionally, further adjacency stability has been added to the 4×4 90Ã,° Curved FLEX Height Transitions.
Bridges: New Viaduct Bridges have been added for Avenue (L0, L1, and L2), RHW-8S and RHW-10S (L1 and L2), and RealRailway (L0, L1, L2 for double track, L0 and L1 for single track).
Flexible Turn Lane (FTL) Features:
FLEX-based FTL Height Transitions have been added, including for the Type 120 Avenue (Ascending, L0-L1 and L0-L2–use the FLEX Pieces for ramp-style transitions, or drag the FTL setup into the ground end of the On-Slope Transitions to transition the turn lanes to elevation), and RealHighway MIS-2 Lane (Descending, L1-L0, with FLEX Pieces for ramp-style transitions) configurations.
Limited L1 and L2 Type 120 Avenue FTL support has been added (primarily for connecting to the L1 and L2 FlexSPUI).
The Type 230 configuration for the Triple-Tile Network Widening Mod (NWM) networks has received draggable support for rail-type crossings, including Rail (both Dual and Single-Track), L1 and L2 Rail Viaducts, Standard and Rural Ground Light Rail (GLR), Elevated (Light) Rail, and Monorail.
The MIS 2-Lane configuration has also received support for Avenue + and T-intersections (without FTLs), and One-Way Road intersections (with SITAP–Signalization and Turn Arrow Project–support, using the appropriate FLEX intersections).
Additionally, Avenues can now end at T-intersections with the Road/NWM Type 110 configuration, with turn arrows provided by the new Avenue Type 020 FTLs.
Streets and the Street Addon Mod (SAM): The draggable Diagonal S-Curves now work for SAM Sets 2 through 11.
Network Widening Mod (NWM) x Street Addon Mod (SAM): Adjacency support for the Network Widening Mod (NWM) networks’ intersections with the Street Addon Mod (SAM) sets has been vastly improved.
FLEX Overpasses: The Road, One-Way Road (OWR), and Avenue networks have now received FLEX Overpasses, which allow for prefabricated orthogonal viaduct overcrossings of 1-4 tiles to be built. The length can be selected by using Home and End to rotate the overpass. Simply drag any orthogonal network underneath the FLEX Overpasses to cross below them.
Road Viaduct Features: The L2 Road, One-Way Road, and Avenue Viaducts now support diagonal crossings with ground-level networks. The L1 version of this functionality has also received stability improvements.
RHW Disconnector/NAM Eraser: The RHW Disconnector Tool has been rechristened the NAM Eraser, reflecting its ability to erase 1×1 network tiles of any network or network crossing combination. Additionally, it is also now available on all network menus.
User Interface:
The NAM’s menu buttons have been reworked, providing a cleaner image and, to improve internationalization (i18n), the English text has been removed from the icons themselves.
The buttons have also been reordered, in an effort to improve the overall experience.
Additionally, the old puzzle piece-based overpasses have been related to legacy status.
Left-Hand Drive Support: Various improvements have been made across the board to LHD pathing.
Morifari Victorian Stations: The Morifari Victorian Stations for Elevated Light Rail and Rail Viaducts have been restored, with some associated bugs fixed.
Other Bugfixes:
Diagonal x Diagonal (DxD) crossings involving the MIS Ramp and RHW-8C network have been improved.
The RHW-10S will no longer flip improperly under Elevated RealRailway (ERRW) crossings
Pathing issues on the RHW-6C and RHW-8C FLEX Neighbor Connections have been addressed.
The Euro textures are fixed on the RHW-6S Type A2 Wide ramp.
The extraneous arrows on the RHW-2-to-4 and RHW-4-to-6C FLEX Width Transitions in LHD have been addressed.
Drag-through issues involving the Triple-Tile-Thru x Dual-Tile-End FLEX T-intersections in the Flexible Turn Lanes (FTLs) have been fixed.
It’s quite the list (and I’ll be making a post in the coming days discussing just how we’ve become so productive). The new version again uses our Java-based installer, so it’s cross-platform, and will work on Windows, macOS, Linux . . . anything that can run Java and SimCity 4. If you’re on Windows and intend to use the RealHighway features, make sure you have the 4GB Patch installed (to avoid the CTDs on city load from lack of memory bandwidth). The .bat file should do this process for you (run it as an administrator if you have difficulties). Also, again, note that if you purchased the game from Origin or are playing it through EA Play/Game Pass, that version is still unpatched/unpatchable, and unfortunately, not truly compatible with the NAM (or really all that stable).
Hope you all enjoy the new version! We’re already chomping at the bit to get going on NAM 45, which you’ll hear more about very soon.
SimTarkus - SimCity 4 
Recent Comments