SC4 for Mac 64-bit

[xxdita 1,097]

36 minutes ago, rsc204 said:

Right so perhaps this being the case, you might consider adjusting your tone in future to be less accusative? This has always been one of things I dislike about stuff going on on Discord, if you're not there, many important things don't get communicated to the wider community. If we aren't open about detailing problems and gathering data, how can anyone else be expected to know about it? Or is there some elite club I'm not a member of that's handing all this, because honestly I'm just trying to help, if my help is not wanted, I'll stop wasting my time.

I have no control over what "tone" you infer from my post, but there was none implied. I was simply trying to point out that there was more information available, namely that we don't quite have all the facts yet. 

We aren't trying to hide anything from you. The files and results were posted publicly. You even posted in the thread. As Tibi just explained, at this point there really isn't enough data for a conclusive judgment to be made, but I felt there was enough of a question to warrant me mentioning it before any work is done on a tool that will automate changing rep counts. 

I have in no way made any attempt to discourage you from helping people with these compatibility issues. In fact, I very much believe that ST staff should take an active role in the matter. But you have to realize that I have pretty much been point man on the matter since the 64bit version was released back in February, with mmprog being a great asset with his testing. I've been following which files have been reported, which have been fixed, which haven't, new bugs as they're reported, etc. It's great to have Tibi up to speed and able to tackle files as they're reported now. 

I make myself available here, at SC4D, in the SC4D Discord chats, in the SC4 subreddit, and even on Facebook if you know me well enough. The overall SC4 community is not limited to the pages of one forum, nor will our discussions be. In fact, I prefer the ability to chat in real time about certain things, Some people are more inclined to ask questions when they can do so in a more private chat. 

You are more than welcome to help. Like I could stop you if I wanted to. But I do ask that you get yourself up to speed, so that we can all be on the same page. Like with the NAM stations. Those have been fixed since February 26th and have been included in the NAM 37 RC. From what I understand, once the RC is available, the support cycle for the previous version ends, as some bugs have already been fixed. Which is the case here. 

[Cyclone Boom 16,875]

4 hours ago, Tyberius06 said:

I wasn't able to send the PM due to some Error code: 2C137/2. @Cyclone Boom or @CorinaMarie any idea what that error code might be?

This has been previously reported as an issue with the ability to send PMs on occasions. Also the Messenger itself has been known to not load and display said error too when accessing it directly. I've cleared the site cache which often can resolve things like this, so give it a try and see if that might help.

As a general statement to anyone reading:

In terms of this topic, we truly hope it doesn't turn into another one of those ones. Quite frankly there's been too many of them recently, so let's not go there.

[rsc204 21,808]

12 hours ago, xxdita said:

I have no control over what "tone" you infer from my post, but there was none implied. I was simply trying to point out that there was more information available, namely that we don't quite have all the facts yet. 

No, there is not more information available, until it was added here, it was not public! No one can reasonably be expected to know about such things.

12 hours ago, xxdita said:

But I do ask that you get yourself up to speed, so that we can all be on the same page.

Again, how can anyone do this if conversations and findings are kept from public forums? I'm not saying no one should use discord, just that at some point important stuff like this should be communicated.

12 hours ago, xxdita said:

Those have been fixed since February 26th and have been included in the NAM 37 RC.

Once more, a classic fail, because nowhere on the NAM forums is this fact noted. I can't be expected to see everything that goes on, nor to start connecting dots from conversations in February to discussions taking place now. It's fine to point things out people have missed, fair enough, but it's the particular wording you use to do so that is a problem. 

If you don't want people to assume you are being snarky at them, I dunno, try not continually being snarky at them? Seriously, the undertone of your words are "you haven't done your research and are wasting peoples time". Particularly annoying for me, since it is you wasting my time by failing to document findings publicly. If as you state you've been working on this since Feb, why on earth has no such post explaining what we know ever appeared?

15 hours ago, xxdita said:

Testing done in this thread (on this same page) suggests that there are at least some Float32 properties that absolutely do require the rep count of 1. 

It's where you specifically call attention to how the information is on the same page, that comes across as aggressive. Why?, because you are implying that I should have read and known about it. In this way, your words would make it look as if I had my eye off the ball or wasn't very well read. Yet, as we can all clearly see, I had no chance in hell of knowing these facts that are so important, you've keep them all hidden.

[xxdita 1,097]

For the record, I did post in the NAM Team's private board. Since you have posted in that thread, I know that you have full access. But since Tarkus has been following this thread from the very beginning, he was well aware of the stations, and they have been included with the NAM 37 RC. 

NAM is the most commonly used custom content, so it should really be no surprise that these CTD issues were reported almost immediately with the 64bit release. Again, these fixes were posted in the thread we're in now. 

Sharing information and where it can be found is how a forum works. It is not intended as a personal attack towards you or anyone else. But it is not my obligation to spoon feed this information to you or to explain what it all means. 

[xxdita 1,097]

On 5/21/2020 at 7:58 AM, CorinaMarie said:

The solution has been for peeps to use Reader to manually set the Rep back to zero, save the file, and make it available for Mac users. Additionally, in a PM with @c4bl3fl4m3 a long while back, they discovered that a school's capacity was also affected by the 1/1000 bug. Medical is also likely to suffer from this.

I wonder if police and fire would also be effected. Any idea about how these rep counts are changed? Tibi seems to think that LE may be changing the LRK rep count. 

The timing of the CTD's may help us to diagnose the issue, or at least narrow it down. From what I understand, Plugins with the slope bug cause CTD at city startup, whereas the transit bugs are happening when trying to plop the building. 

I've found that updating the building and lot files in PIMX will correct all of the MAC compatibility issues we've found so far. 

It's kinda frustrating not being able to do the necessary testing myself. 

[CorinaMarie 29,605]

3 hours ago, xxdita said:

I wonder if police and fire would also be effected. Any idea about how these rep counts are changed? Tibi seems to think that LE may be changing the LRK rep count. 

That sounds like a possibility. I've not looked into either police or fire at all.

 

3 hours ago, xxdita said:

It's kinda frustrating not being able to do the necessary testing myself. 

Yeah, it was the same for me at the time and still is since I only have Windoze and Linux comps. As part of the test back then (when I knew even less about this), I tried setting every single Rep = 1 to Rep = 0 and that then borked a file on Windoze. Ofc, at the time I wasn't aware that it might be tied to only Float32 values.

[Tyberius06 12,189]

Just to be really clear @rsc204.
This information happened to get lost on my end at the first place. That conversation and my fix on the SM2 lot, which later led me to a still unconfirmed conclusion, that the LRK REP count might be an important thing, happened on 15th May. I had not returned to that project/topic until the eveing/night of 20th May, when I asked Nate in Discord whether he knew what the LRK REP count actually does, but we were stucked at that point and then the conversation was deverted to other topics, since I was in at least 3-4 different conversations and projects and side projects. So the information wasn't kept hidden, at least it wasn't intentional, but I have/had way too many things to deal with. I fixed that lot as a side project, and will fix some lots, when I have the time (for example the SM2 collection), but for now the main priority for me still the WMP files, which mostly suffer from these Transit Switch bugs, not to mention other nice things with them. And 2 nights ago I actually sent these infos via PM, and asked you if people start fixing the MAC bug, just it in case, do it in PIM-X, because there might be other issues. 
I ran some experiments which tool changing the those REP counts. 

7 hours ago, xxdita said:

Tibi seems to think that LE may be changing the LRK rep count. 

I don't seem to think actually. It's a fact. At least testing some TE modded lots and some regular ones too. Whatever was the LRK (lot resource key) REP count on a lot, when you save it with Maxis Lot Editor, it will be then 0. IF you save the building examplar in PIM-X, it will change it to 1. (I don't know if the PIM-X Lot editor part changes anything, but I don't think). SC4 Tool will not change the LRK REP count (so it will keep it either 0 or 1 depending on how it was when you opened the lot), but it will change the Transit Switch REP counts to 1. These are the facts.
This is a station fixed by Reader. PIM-X would remove the LD property upon save, so I can confidently say that it was saved in LE,  Ok, there might be an other application, which can provide the same Maxis LE like results, so now I'm not so confident, and I still don't know whether it has any importance or not. Also PIM-X is reorganizing these TE values, so I can see, that it wasn't fixed by PIM-X. Note: this is the originally uploaded version of this lot.

On this image I ran the building examplar of the lot through on PIM-X and saved it. You can see the difference. (also the LD property is now gone)

 

What I still don't know whether this LRK REP count 0 has anything to do with @mmprog previous issues, or it was just a special case. I also don't know that the LRK REP count only matters in the case of TE lots. In any way after I saved the file in PIM-X, it solved his problem. 
Ok, since the only obvious difference, what I could have seen between the two fixes was the LRK REP count, here is a link, which I know, that the lot were created/saved in Maxis LE and it has the TE bug. I fixed the lot by Reader and therefore the LRK REP count is 0 on it.
So what you (MAC users) need to do, is downloading the following lot. It's a pretty old lot, it has the MAC bug, I just checked it.

Now if you have this lot, place it into your plugins folder, then dowload my attached lot file, and replace the original lot with my version. Best if you remove the original lot and place this into the  same folder. On this attached file the two TE switch REP counts have been fixed by Reader and the Lot Resource Key has been kept as 0 for testing purposes. 

_ReaderFix_ITS_Brennt_Rail_Set_Through_30b86988.SC4Lot

So MAC users, please go for it and test this lot. What you need to pay attention for is checking if the station (ReaderFix version) is becoming abandoned and if it allows rail traffic to flow through properly or any other kind of issue with it. At least in one case, this issue was present with an other "reader fixed" lot with LRK REP value 0, so we need to see if that was a unique situation or it's a more general issue.

Thanks in advance!

- Tyberius

[Hubert 53]

Hi @Tyberius06

I'm running the 64-bit from the Mac App Store, macOS 10.15 Catalina, MacBook Pro 2018.

The original station CTD's as soon as it's plopped.

The fix plops without issue.

I can't see the station being abandoned but I may not have the necessary traffic to get to that level. However, it appears that traffic is not flowing through':

 

Let me know if you need more info.

[xxdita 1,097]

@Tyberius06 have you checked the LRK rep counts on Maxis stations in SimCity_1.dat? They are all set to 0. As are each and every station I've just looked at in NAM. 

But there have been absolutely no MAC compatibility issues reported with any @mattb325 lots. So let's not try to fix what ain't broke. 

[mattb325 28,880]

2 hours ago, Tyberius06 said:

PIM-X would remove the LD property upon save, so I can confidently say that it was saved in LE and then fixed by reader

Given that this is my station and work-flow you are making incorrect assumptions about (you could have asked me rather than making claims about what I do), let me list the work flow for these 30+ stations.

*Render day view in 3dsMax
*Exemplar + lot creation in PIM-X
*View the model in the Lot Editor (I always view it in the lot editor as there is a bug with 3dsMax that causes models to be distorted and they often have to be fixed in the reader)
*Night render x2 in 3dsMax (Dark and Maxis Nite)
*Lot decoration in PIM-X
*TE in SC4Tool
*Correct the values in the reader which included among others, correcting the switch point entries as well as adding all of the switch types (which at around 60+ per lot are way more than the usual run-of-the-mill stations)
* Save and repeat for each different type per building (El-Rail, rail, monorail etc)

It wasn't saved in the Lot Editor. The number of stations and variables that I made in this pack meant that I had a quite specific work-flow and it didn't involve the Maxis LE. 

43 minutes ago, xxdita said:

But there have been absolutely no MAC compatibility issues reported with any @mattb325 lots. So let's not try to fix what ain't broke. 

If there are issues, as always, the user (or any one else for that matter) can simply let me know and I'll fix it. I'm not in the habit of having troublesome content floating around and that is indicated by my track-record, but with the most content released - well over 400 lots and thousands of files - there is always the possibility of a mistake being made.

In light of all of the issues caused by the 64-Bit upgrade, I have been going through my work and have picked up a couple of stations that could be affected by this MAC bug and edited them and included what I've edited in the description of the file. It also includes fixing some of the older ones that Barbyw modded for me almost 20 years ago.

[xxdita 1,097]

Just now, mattb325 said:

If there are issues, as always, the user (or any one else for that matter) can simply let me know and I'll fix it. I'm not in the habit of having troublesome content floating around and that is indicated by my track-record, but with the most content released - well over 400 lots and thousands of files - there is always the possibility of a mistake being made.

The BSC Team has always set the bar high when it comes to quality control and tech support. That is why it is such a high priority for me as well. 

[rsc204 21,808]

The LRK (LotResourceKey) Property is a Unit32 Data type. As such, i'm not sure if the values are relevant in regards to this problem? So far as I'm aware, to date this issue has only come to light with Float32 Data types?

15 hours ago, Tyberius06 said:

when I asked Nate in Discord whether he knew what the LRK REP count actually does

Rep properties don't do anything as such, they are similar to defining different variable types when programming. It simply defines how the data should be stored/read in some way.

A much simpler way of thinking about this, imagine a spreadsheet, where for each row, you could only have one cell for a given column. But then imagine some items needed two rows or more for certain columns, you'd need to insert some new rows or cells to add the data. If you can visualise what I'm talking about, consider at the code level, how the "spreadsheet" and the number of cells it needs, must be defined, before adding data or there will be no place to store/retrieve it.

Behind the neat little graphical interfaces we usually see, is a complex array of differently formatted data, intended to optimise it's storage/retrieval. At this level, often an incorrect definition can cause problems with the data being written or read correctly (corruption). Although it may seem contradictory, just because 0 is the correct value for Float32 Data types with one Rep of data, doesn't mean that 1 can't be the correct value for the same situation with a Unit32 Data type. Just to be clear, I am not stating this to be the case, I do not know the ins and outs of how EA's proprietary database format sets up it's data arrays.

We can only draw conclusions based on what we're seeing, but generally speaking the Windows version doesn't seem to require all of these values to be correct. I.e. the code can handle parsing the data, even if these values are not set correctly. Likewise, even if the Unit32 Rep values were incorrect, it doesn't necessarily follow that this would lead to any sort of problem. All we can do is test out both ways of defining the data and observe the behaviour.

As it turns out, the testing of the previous patches may not have been for nothing, it's worth noting they both use 1 for the LRK and yet they worked when tested on a 64-bit Mac. Since I can point to countless examples of Maxis content*, using the alternative value 0, it doesn't seem Unit32 Data types are affected, either way I think we can rule out the Lot Resource Key Property.

*Every Maxis civic building uses the value 0. But there seems to be no rythme or reason to whether 0 or 1 should be used for Unit32 data. Either way, it doesn't seem to be causing any harm and it's nigh on impossible to know which, if any, is the "correct" setting.

[Enrique Feterman 1]

I'm a little confused, maybe because I'm not an expert, but it looks like the new steam version for Mac 64 doesn't work with NAM36, where can I find and download NAM37 for Mac ?

[xxdita 1,097]

24 minutes ago, Enrique Feterman said:

I'm a little confused, maybe because I'm not an expert, but it looks like the new steam version for Mac 64 doesn't work with NAM36, where can I find and download NAM37 for Mac ?

NAM 37 Release Candidate is currently available exclusively on the LEX. Please note that this is still under public testing, so if you have any issues, please let us know. Once NAM 37 is finalized, I believe it will be available on both the LEX and STEX, barring any unforeseen issues. There is no definitive timeline for this, so please check back. 

[xxdita 1,097]

2 hours ago, rsc204 said:

As it turns out, the testing of the previous patches may not have been for nothing, it's worth noting they both use 1 for the LRK and yet they worked when tested on a 64-bit Mac. Since I can point to countless examples of Maxis content*, using the alternative value 0, it doesn't seem Unit32 Data types are affected, either way I think we can rule out the Lot Resource Key Property.

So now there are 4 versions of these stations: NAM36, mmprog's, the ones included in NAM 37RC, and yours (in chronological order). Each of the first 3 also have a LRK rep count of 1, no different that yours. I don't see how that has helped. 

[CorinaMarie 29,605]

3 minutes ago, xxdita said:

I don't see how that has helped.

It looks to me like it is an additional example for that particular property. Since an unborked version is already in NAM 37RC, it appears that is resolved.

[xxdita 1,097]

1 minute ago, CorinaMarie said:

It looks to me like it is an additional example for that particular property. Since an unborked version is already in NAM 37RC, it appears that is resolved.

You're preaching to the choir on that one. I do believe that since we know we have a working version, it may be worthwhile to test a version with the LRK rep count set to 0, as that would be different. 

[CorinaMarie 29,605]

3 minutes ago, xxdita said:

I do believe that since we know we have a working version, it may be worthwhile to test a version with the LRK rep count set to 0, as that would be different. 

Sounds like a good idea to me.

I don't have the familiarity with the lotting tools (and this may have already been stated somewhere), but do we know if there are specific tools which do set this to 0? In other words, after testing there might need to be a message attached to the download page for said tool(s) if the LRK with rep zero is a game breaker for the 64 bit Mac version.

[Tarkus 6,932]

43 minutes ago, xxdita said:

Once NAM 37 is finalized, I believe it will be available on both the LEX and STEX, barring any unforeseen issues.

The plans also include it being on ModDB as well.

I'll also note, that I'm actually typing this message on my Mac Mini (currently hooked up to my TV), and as of just a few minutes ago, I now have the 64-bit Steam Mac port up and running with the NAM 37 RC.  I'll actually be able to investigate some things myself now.

-Tarkus

[xxdita 1,097]

5 minutes ago, CorinaMarie said:

Sounds like a good idea to me.

I don't have the familiarity with the lotting tools (and this may have already been stated somewhere), but do we know if there are specific tools which do set this to 0? In other words, after testing there might need to be a message attached to the download page for said tool(s) if the LRK with rep zero is a game breaker for the 64 bit Mac version.

Maxis tools seem to set the LRK rep count at 0, PIMX sets it at 1. All Maxis stations have the LRK rep count of 0. 

Honestly, I think we're borrowing trouble that isn't ours putting too much time into this at the moment. We have real problems reported and unresolved that are more worthy of attention. Like a certain PEG seaport that I'm not touching with a ten foot pole. The BSC versions have already been updated though. 

[CorinaMarie 29,605]

1 hour ago, xxdita said:

Maxis tools seem to set the LRK rep count at 0, PIMX sets it at 1. All Maxis stations have the LRK rep count of 0. 

Should it be determined that it would be preferable for PIMX to set this to 0, I have edited my copy of the new_properties.xml in the SC4PIM folder to set it as such. I can share that if it would help. And if it turns out this doesn't matter being either 0 or 1 then my tweak will be a moot point.

[xxdita 1,097]

6 minutes ago, CorinaMarie said:

Should it be determined that it would be preferable for PIMX to set this to 0, I have edited my copy of the new_properties.xml in the SC4PIM folder to set it as such. I can share that if it would help. And if it turns out this doesn't matter being either 0 or 1 then my tweak will be a moot point.

PIMX works just fine as it is. In fact, updating any file in PIMX has proven to correct all MAC compatibility issues without exception. 

[CorinaMarie 29,605]

20 minutes ago, xxdita said:

In fact, updating any file in PIMX has proven to correct all MAC compatibility issues without exception.

Ok. Then I wonder what the goal is with:

2 hours ago, xxdita said:

it may be worthwhile to test a version with the LRK rep count set to 0

 

It seemed like a test with LRK rep count set to 0 would be a possible prelude to adjusting PIMX to conform to how the Maxis stations are set as well as what LE does. Otherwise, I'm likely missing the point for what the test results would be used for.

[xxdita 1,097]

1 minute ago, CorinaMarie said:

Ok. Then I wonder what the goal is with:

 

It seemed like a test with LRK rep count set to 0 would be a possible prelude to adjusting PIMX to conform to how the Maxis stations are set as well as what LE does. Otherwise, I'm likely missing the point for what the test results would be use for.

Having taken another look at the SM2 file reported, along with the attachments to fix it, I don't believe further testing is necessary. 

PIMX works exactly as it should. Maxis tools work exactly as they should. But when using the two together, there seem to be problems. 

That SM2 station was created in PIMX, but then lotted in LE, as opposed to LE-X. This changed the LRK rep count to 0, creating a break in the station's functionality, even after the MAC transit bugs were fixed in Reader. 

This tells me that there is more at play than we understand yet. Meaning that LRK rep count is important for other reasons. 

[xxdita 1,097]

2 minutes ago, urbanbabel215 said:

Hi fellow SC4 Mac users, I've noticed a rather curious behavior that seems to coincide with my version of SC4 being updated to 64 bit on Steam: in tabbing through various menu items in the game (for instance, RRW curve puzzle pieces or RHW ramps — basically any items that allow you to tab through variations), the forward tabbing — that is, just pressing tab — seems to skip over every other item. But if I reverse tab (on my MacBook Pro using the Steam game, I press Ctrl+Shift+Tab), the skipped items will appear. I swear it's not user error, as I assumed it must have been when I noticed it yesterday; I've done some purposeful testing and it's a recurring behavior. I upgraded to the NAM 37 RC today and it's been happening there, but it also occurred in NAM 36 after Steam updated the game to the 64-bit version. I never noticed it using NAM 36 prior to that, and it's annoying enough that I think I'd have noticed it before. The 64-bit update is all I can pinpoint in the change in behavior. Has anyone else encountered this and/or have any ideas for a fix or what might be causing it?

To be clear, I fully understand that NAM 36 is no longer being supported and am not looking to initiate any verboten conversation around it; as I stated, I am running the NAM 37 RC and experiencing the issue with that, and only offer the NAM 36 references for context to support why I think it coincided with the 64-bit update of the game on Steam and at first glance seems likely not, for instance, a NAM-related issue. I also profusely apologize if this has been discussed elsewhere (I did try researching the issue prior to posting and didn't come across anything relevant) or if this is not the appropriate thread to post this in... a polite redirect or suggestion would be well-received and very much appreciated.

But timid formalities aside, anyone else? Any ideas?

We do have NAM issues being reported with the 64bit version. For future reference, you should probably post any NAM-specific issues in their area of the forum, so that they can see it. Hopefully a member of staff can move your post to the appropriate section. 

Unless it is building/lot related, most of us are not even remotely qualified to help. 

[Cyclone Boom 16,875]

8 hours ago, xxdita said:

Once NAM 37 is finalized, I believe it will be available on both the LEX and STEX, barring any unforeseen issues.

Sounds good, and Cori and I have direct access to the ST server nowadays, so just let us know when it's ready to be hosted and we'll get that sorted.

With being a large file at around 700 MB in size, it likely would be too large for uploading directly from the front end. The site software usually complains at such sizes, and it might cause difficulties otherwise. Seeing as Dirk tends to be busy nowadays, if you or @Tarkus give us the word and we'll arrange that straight away. Then once you've edited the NAM file description on the STEX and it'd be linked up to download the same way it is currently.

We can also remove NAM 36 from being available if that would be preferable. Either way we're here to help when the time comes.

 

41 minutes ago, xxdita said:

Hopefully a member of staff can move your post to the appropriate section.

That'll be useful for consolidation and so others with the same issue can come across it too.

I've moved it to a new topic in the NAM Forum here:

 

[xxdita 1,097]

Thank you CB. This whole thing is a lot. New and returning players are coming in and have no idea what's going on at all, or why things don't work like they did, because the Steam version is apparently updating on its own randomly. So I do seriously expect more tech support threads coming than we've already seen. 

So if staff could corral known MAC threads to the proper area, that would also make life much easier on all of us, I think. It would also show new members that there even is a MAC area. 

[xxdita 1,097]

On 2/26/2020 at 12:56 AM, mmprog said:

Regarding the Appalachian Terrain Mod: I noticed this caused a CTD. I went hunting through its files for Float32 values with Rep=1, and found a single offending value: TemperatureRangeFactor. Note that the Mac version of the AT mod includes 32 different controller files, you choose a single file with the combination of effects that you desire. I updated all 32 files, but I only tested the one that I actively use, which is LK_AppalachianTerrain_Snow_Coast.dat.

 @CorinaMarie you're more familiar with terrain mods than I am. So I wanted to make sure you see this. 

 

On 2/26/2020 at 9:28 PM, CorinaMarie said:

1. You quoted @rsc204 where he stated reasons why it might be very difficult to correct any of the existing tools.

You've now made an edit to the PIMX XML. How very difficult did you find it?

[CorinaMarie 29,605]

3 minutes ago, xxdita said:

 @CorinaMarie you're more familiar with terrain mods than I am. So I wanted to make sure you see this.

Thanks. Terrain Mods which include the Terrain Properties Exemplar follow the same format you are familiar with in LotConfigurations and Buildings exemplars so this appears to be the same sort of error that trips up the 64 bit version of the game when it's a Float32 and Rep = 1. Editing in Reader should be sufficient to correct these.

 

3 minutes ago, xxdita said:

You've now made an edit to the PIMX XML. How very difficult did you find it?

The XML file is text based and I opened in Notepad++. The commands/properties are delimited by tags much the same way as raw HTML code is. The edit I made and tested was as simple as changing one value and re-saving the file. Due to the file's location in a restricted area (Program Files where I installed it), I did have to to this with elevated UAC (Admin) rights. So, all in all, I'd say it was very simple, but does require knowing what to change.

[xxdita 1,097]

For anyone interested, I have made a thread at SC4D to document the MAC 64bit compatibility bugs we have encountered and been able to correct so far. There are still other issues that remain unresolved, and more may be reported. I will add to that thread as we have more verified information and reliably tested solutions. 

I understand that this information has been spread out in multiple threads, some going several pages with a lot of other conversation in between. So I hope that MAC players and anyone wanting to help them will find my thread as a helpful resource.