May 10, 2014 8 Comments
Since Aspyr made the surprise announcement that they had just re-released their port of SimCity 4 Deluxe for Mac OS X on the App Store and Steam, with Universal Binary support, the NAM Team has been inundated with questions from Mac users about running NAM 32 on the port. This post is designed to clear up the current status of the usability of the NAM on the re-released port, as of May 10, 2014. I plan to update this as new developments arise.
Note as of July 28, 2014: NAM for Mac is now here.
Is it possible to run the NAM on the new Mac port released on the App Store and Steam?
Yes, but there are some severe issues at present with doing so, which are described below.
Is the NAM Team offering official support to Mac port users?
No, not at present. While we are providing some guidance to Mac port users out of courtesy, running the NAM on the port is presently at your own risk.
Does the NAM Team have plans to fix the issues and bring back a Mac version?
Yes, we are currently working on addressing the issues.
Until the re-release, we had absolutely no idea what was causing the crash-to-desktop (CTD) errors that occurred when certain NAM plugins (some quite critical) were included in the Plugins folder. Our development team has worked almost exclusively in a Windows environment, and until the re-release, even our lone active Mac user on the team used a dual-boot to run the Windows version. With the lack of Mac-compatible modding tools, and thus, the resultant lack of knowledge about the internal workings of the NAM among Mac users running the port, there was no way to feasibly investigate the situation until we were finally able to look at it ourselves, thanks to the re-release. It was because of this inability to address the situation in any meaningful way that we dropped NAM for Mac with the Version 31.0 release.
What issues currently exist with using the NAM on the port?
Most of the same issues that existed when using the NAM on the original version of the port, after Mac OS X Lion was released, still exist with the re-release, along with a few brand new complications:
- A file encoding issue, affecting most of the additional bridges, a number of transit stations, and the High-Elevated Elevated Rail and Monorail plugins, causes the game to CTD.
- The re-release has a limit on the number of individual files/folders that can be installed to the Plugins directory, above which the game will CTD. For some reason, this limit is significantly lower if the computer is not connected to the internet while running the port. There have been reports that the game begins to become very glitchy when the Plugins folder has as few as 80 files or subfolders, without the connection, and will almost certainly crash at 200. The limit manifests itself as memory corruption, and can occur even with 200 empty subfolders in the Plugins directory.
- The port re-release is unpatched, making it essentially equivalent to the original Windows retail disc version of SC4 Deluxe, Version 1.1.610. The first patch for the game, the EP1 Update (Version 1.1.638), is a requirement for the NAM, and contains a number of pre-NAM first-party transportation fixes. The NAM Team became stricter with this requirement beginning with NAM 31.x releases, after several users attempted to file NAM bug reports, citing issues fixed by the EP1 Update. (Note: some users, upon seeing the presence of the file “EP1.dat” in the installation folder, have assumed that this meant the game was patched. This file, however, was introduced in the retail disc Windows copy of SC4 Deluxe/Rush Hour, and exists in Version 1.1.610, pre-patch. The EP1 Update does not add EP1.dat, or even patch it in any way.)
- Aspyr themselves have stated that they cannot guarantee the proper functionality of any plugin–including Maxis-published official updates–with the re-released port. Mod functionality was apparently an afterthought for the re-release, though they are considering revisiting the topic. (source)
A note about NetworkAddonMod_Bridges_Plugin_Controller.dat: This file has been cited by many Mac users as the root cause of the CTDs, but the subsequent investigation of the issue after the port re-release determined that this file causes an issue only if the Additional Bridges are also installed. Despite the presence of “bridges” in the title of the file, it controls a number of other important functions, including pathing adjustments for copies of the game that are running in left-hand traffic mode (i.e. the UK version of the game). Running the NAM on a Mac in left-hand traffic mode would presently restrict the user from using any of the additional bridges.
Will old NAM releases work with the Mac re-release?
No. The first CTD reports rolled in July 2011, with NAM 29.
Mac OS X Lion (10.7) was released that same month, which removed the Rosetta translator that allowed PowerPC apps like the original Aspyr port of SC4 to run on Intel Macs. At that time, this forced users with newer versions of OS X to install Aspyr’s unfinished Universal Binary patch, which is where the trouble started. The files that have been discovered to play a role in the CTD issue have been a part of the NAM for at least the past 8 years, and would have almost certainly caused the CTD had OS X Lion been around. However, because users either had Rosetta or were still running PowerPC systems before Lion, the issue did not arise.
The NAM Team does not provide support for users running old versions, and does not condone the redistribution of any outdated or unofficially repackaged versions of the NAM.
When does the NAM Team plan to issue a fix for this issue?
There is no release date or timeline for release for a Mac-compatible NAM. We have gotten to the bottom of the encoding issue, but the fact that the re-release is unpatched and has the additional roadblock of the plugin limit has greatly complicated matters. As the NAM package has grown substantially since we switched to the Monolithic NAM approach in NAM 31, we also need to determine the best way to package and distribute a proper Mac version, once we get to that point. The old .zip package has been eliminated from consideration. We have also have been in talks with Aspyr behind the scenes regarding matters of plugin support. Depending on the results of all of these efforts, we may still be unable to provide full support to users of the new port, but some of the critical CTD-causing issues will have at least been resolved on our end. We are striving for the best possible outcome for the port’s users, however.
What if I’m running Mac OS X 10.6 or earlier, with the original version of the Aspyr port?
As long as you didn’t install the old Universal Binary patch, you should not encounter the CTD issues with the aforementioned files, and even the latest NAM release will work. The biggest issue you will encounter in that case is the process of installing the package. Due to the complexity of a manual install, the easiest way to accomplish this is to go to a Windows computer (or partition, if you have a dual-boot setup–some users have also reported success with Wineskin), run the installer, and then copy over the installed files (both the Network Addon Mod and z___NAM folders) over to your Mac (or OS X partition). The Windows installer can be opened like an archive using Keka, but with the size of the mod, a manual install is only the domain of an advanced user–it is strictly at your own risk.
What other options are out there?
A number of Mac users are running the Windows version of the game, either using a dual-boot or Wineskin. A tutorial on Wineskin can be found here (thanks to sargeantcm). The behavior is the same as it would be on the Windows, and thus, we can provide full support to Wineskin or dual-boot Mac users running the Windows version. Similarly, we are generally able to provide full support to Linux users running the Windows version with WINE. Additionally, useful plugins like the Extra Cheats DLL (unusable on the Mac port as OS X can’t read DLL files–and moot anyway, as Aspyr has disabled cheat functionality on the Mac re-release) and many SC4 modding tools can also be run using this approach.
As more information is available, I will update the situation.