NAM for Mac Status Update (June 12, 2014)

Note as of July 28, 2014: NAM for Mac is now here.

As there have been a few questions of late as to the whole matter of NAM support for the re-released Aspyr port for Mac OS X, and it’s been a month since my previous “lowdown”, I thought I would give an update.  There is very little to report, and we are basically in a holding pattern at present.   While I mentioned that we had the encoding issue under control, there’s still two pesky complications the re-release presented us: (1) the “number of files” limit, and (2) the fact that the port is unpatched.  These issues still stand in the way.  (Note: Addendum here.  There’s also a third issue.)

With respect to #1, we do have a potential solution.  memo has developed a utility known as JDatPacker, which is designed to be a cross-platform alternative to the popular Windows-only SC4 Dat Packer program, that wouanagaine of New Horizon Productions (NHP) had released in 2007 on SC4 Devotion’s LEX.   For those not familiar with SC4 Dat Packer, the premise behind it is that it can combine and compress folders of SC4 plugin files into single .dat files, which, as the results of the BSC’s “Miramba Experiment” in 2006 showed, decreased game load times and increased performance.  Historically, the NAM Team has advised users to be very careful with using SC4 Dat Packer on their NAM installations, as it often led to installation issues when a user upgraded, though changes in the NAM since then have mitigated this issue substantially.  Since the Mac port issue is with the number of files, not their size, “Dat Packing” the NAM would increase the stability of the mod with the Aspyr port, especially when the game is played completely offline, which inexplicably lowers the threshold at which this issue occurs to an absurdly small number of files.

JDatPacker, however, is currently in an early beta state, and it requires further testing to ensure stability before we can go forward with NAM for Mac.  The latest version of the tool, Version 0.1.3, is available for testing on the aforementioned thread.

Now, for issue  #2, the matter of the game being unpatched, we have had some discussion with Aspyr about this topic.  Aspyr would apparently have to coordinate efforts with EA Maxis and dig back into the source code, in order to issue a patch to upgrade the game to the same state as Version 1.1.638, the minimum required Windows version required to run the NAM.  Per comments from their representatives, they have no plans to do so.  The biggest issue that 1.1.638 fixed with the NAM is the inclusion of several transit network path files that were either missing or broken in the original retail release.  Until we re-did the NAM installer for NAM 31.2, to force the user to have the 1.1.638 patch (known as EP1 Update 1) installed, we started getting inundated with users blaming us for path issues that were fixed by Maxis before the NAM even existed–the T-intersection where an Avenue ends at a One-Way Road is one such transit item with a broken path before the patch.  These exact issues occur with the Aspyr re-release at present, and we will be facing a recurrence of this if we release NAM for Mac.  The idea of the NAM Team releasing the fixed path files as part of the Mac version has been floated, effectively doing  of what Aspyr would not (at least in part), but there are legal questions involved.  The NAM Team has generally enjoyed a good relationship with the game’s developers (heck, our patch detection system in the installer has had the side-effect of preventing the NAM from being installed on cracked and pirated copies of the game) and we don’t want that to change.

In summary, in order for NAM for Mac to happen, (1) we need to know we have a solid Dat Packing utility to get around the number of files limit, and (2) we need to have some sort of method to ensure that at least the transit path file end of the port can be patched, within the bounds of legality.  Until both of these issues are solved satisfactorily, we won’t be able to properly support the Aspyr port.  In the meanwhile, we’re continuing development on the NAM’s 33rd full release.  It’s been slow going on that front, in large part due to many of us having bouts of “real-life syndrome”, but things are starting to pick up on that front.

-Tarkus

Advertisements

6 Responses to NAM for Mac Status Update (June 12, 2014)

  1. Pingback: The Lowdown on NAM 32 and the Mac Re-release of SimCity 4 (as of May 10, 2014) | SimTarkus - SimCity 4

  2. Wiimeiser says:

    It’s likely that the developers of the Mac port bypassed the need for a specific Documents folder or something by assigning the Plugins data to the part of the memory originally used by the online mode. Does the online mode have a file limit on Windows?

    Though, I haven’t used a Mac since 2001/2 (It was the standard in my primary school for some inexplicable reason, maybe the game with the detective and the robots where you have to save a school by finding spelling errors was Mac exclusive…)

    • tarkussc4 says:

      It sounds like you’ve partially confused it with the New SimCity release of 2013. SC4 never truly had an “online” mode, and there is definitely no limit like exists with the Aspyr port. Why Aspyr has set things up this way–almost reminiscent of pre-Patch 10 SC2013–is a mystery.

      I’ve gotten some additional information from our resident Mac user on the team as well, and will have an update/clarification/correction shortly.

  3. Michael says:

    Thank you for the update, it is really sad, on Windows I have a SC4 Version that not really has the best performance and dont run in native resolution on my 27″ Display. On the other side the Mac Version, with native resolution and good performance, but not up to date regard patches, so the Sim Night mod doesnt work.

    Unfortunately Aspyr is known for there “great” after release support for games. 😦

    Keep up the good work and thank you again!

  4. Pingback: Addendum on NAM Mac Port Situation – A Third Issue (June 15, 2014) | SimTarkus - SimCity 4

  5. ASE says:

    FYI, the default limit on the number of file descriptors a process can have open on OSX is 256:

    $ ulimit -n
    256

    I’d be interested if some of the crashes went away if this was increased by running:

    $ launchctl limit maxfiles 2048 2048

    from the Command Prompt then starting SC4

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: