Mysterious Glitch For SimCity 4 Mac

[rsc204 21,866]

8 minutes ago, Hubert said:

Ok, the unpatched elevated version does not appear to crash the game:

Ideally someone who's had problems using the NAM and had to remove these stations to prevent CTDs would test them. Since if you are not having problems, there is no reason to believe the patched files would be any different. To be confident of the solution, we really need to know if just these updated files change things. Thanks for checking them all the same.

47 minutes ago, Hubert said:

I'm having trouble setting up a G-HSR network (I get monorail pylons on top of a ground-based HSR texture) but that may just be my ineptitude and I'll keep trying.

I've seen similar around the development builds for NAM 37, so I don't think there is anything you can do about it. Hopefully it will be rectified before the final release.

[urbanbabel215 16]

5 hours ago, rsc204 said:

Ideally someone who's had problems using the NAM and had to remove these stations to prevent CTDs would test them. Since if you are not having problems, there is no reason to believe the patched files would be any different. To be confident of the solution, we really need to know if just these updated files change things. Thanks for checking them all the same.

I'll be happy to test them tomorrow and report back if someone else doesn't beat me to it. Apologies I can't tackle it now, only jumped on for a minute to see if there were any developments.

And thank you for your explanation of the Float 32 bug. I'm still on Mojave at the moment and managed to get iLivesReader running with Wineskin just before this whole 64-bit debacle when I was trying to track dependencies for the small airport tram plugin by joerg/uploaded by suplado! that I couldn't get to show up in the game, so I'll be sure to use that when I come across my other plugins that cause the game to crash as I add them back in.

 

8 hours ago, rsc204 said:

Any chance you can tell me the exact files/folders you removed from z___NAM? I can patch them in minutes and see if we're on the right track (no pun, honest), to fix them.

Sure, prior to succeeding with a fresh install of NAM 36, I tried removing these folders (and their contents) from the following path: Plugins > z___NAM > Mass Transit Lots > High Speed Rail Stations

• Modern Arched GHSR Station
• Modern Arched HSR Station

When that didn't prevent a CTD after intro, I additionally removed the entire 'High Speed Rail Project' folder from the 'Network Addon Mod' folder, and still encountered a CTD after intro. I also went back to the 'Mass Transit Lots' folder in z___NAM after that and removed the entire 'High Speed Rail Stations' folder (and its contents) and still had the game CTD after intro after launching it again.

To be clear, it was only when I did a fresh, custom install of NAM 36 into a blank Plugins folder without any of the High Speed Rail options checked (though I did install the BTM) that I was able to successfully get into the game and play cities. 

 

8 hours ago, rsardachuk said:

Define what you mean by clean folders.

By clean, I mean empty. Wiped. Gone.

I made a copy of my entire Documents > SimCity 4 folder somewhere outside my Documents folder and then erased the folder and all its contents. So when I uninstalled and reinstalled the game anew in Steam and started playing it, the game created a new 'SimCity 4' folder with new Regions and Plugins folders and config files. Thus, when I did a fresh install of NAM 36, it populated 'Network Addon Mod' and 'z___NAM' in an empty Plugins folder that the game created, not the one leftover from my pre-64-bit gameplay.

Basically, I figured if I was going to have to take baby steps for trial and error to get the game running again after the 64-bit update, I might as well pretend I'm starting the game from scratch like I did for the first time a couple years ago and let the installers and software create all the infrastructure that I've ended up manipulating over time. Not sure if that's essential or not — like I said, I'm not particularly tech savvy — but it seemed like minimal extra work at this point to know that nothing legacy I may have created (including folder structures) was causing a conflict in the way the game and the NAM interact.

[urbanbabel215 16]

21 hours ago, rsc204 said:

Ideally someone who's had problems using the NAM and had to remove these stations to prevent CTDs would test them. Since if you are not having problems, there is no reason to believe the patched files would be any different. To be confident of the solution, we really need to know if just these updated files change things. Thanks for checking them all the same.

Hi @rsc204 I can confirm I was able to successfully play the game with HSR installed in the NAM by replacing the two files you added, so thank you very much.

I reinstalled NAM 36 with the HSR options this time, and while it allowed me into the game without CTD after intro, the game CTDed when trying to load a city. Replacing the two files you patched (HSR Station.SC4Lot and GHSR Station.SC4Lot) where they're installed in the NAM fixed the problem.

[Hubert 53]

I don't believe there's much to be gained by testing and retesting NAM36 bugs and fixes when NAM is about to move to 37 and the release candidate is already available. As I understand it, a number of Mac compatibility issues in NAM36 have already been resolved in NAM37.

[xxdita 1,097]

6 minutes ago, Hubert said:

I don't believe there's much to be gained by testing and retesting NAM36 bugs and fixes when NAM is about to move to 37 and the release candidate is already available. As I understand it, a number of Mac compatibility issues in NAM36 have already been resolved in NAM37.

The two stations that have been found to cause CTD's have been corrected in the the NAM 37 Release Candidate. The official support cycle for NAM 36 has ended, and the team has shifted all focus to putting the final touches on the final version of NAM 37. 

Some known bugs have been fixed. The MAC 64bit version may break things that worked perfectly fine. The only way to know for sure is to get feedback on the latest version, which is exclusively available on the LEX during this public testing phase. 

[Hubert 53]

I'm trying my best to break NAM37 on my Mac without much success - great work, guys. 

I suspect the main issue for anyone who's new to NAM and is running the Mac App Store version is that the new installer doesn't place the files in the correct location. I think I understand the reasons why, and I wish I had the Java skills to help fix it, but for now I can try to write an AppleScript that will move the NAM37 installation files to the correct location for the App Store version after the player has run the .jav installer.

Interested? Let me know.

[xxdita 1,097]

2 minutes ago, Hubert said:

I'm trying my best to break NAM37 on my Mac without much success - great work, guys. 

I suspect the main issue for anyone who's new to NAM and is running the Mac App Store version is that the new installer doesn't place the files in the correct location. I think I understand the reasons why, and I wish I had the Java skills to help fix it, but for now I can try to write an AppleScript that will move the NAM37 installation files to the correct location for the App Store version after the player has run the .jav installer.

Interested? Let me know.

I'm gonna tag @Tarkus so he sees this. I think the 64bit Steam version may have a different Plugins folder than the MAC store version? But I'm not sure that the Steam version had been released when the RC was being finalized. 

And just so nobody thinks they have to take my word for NAM team matters:

That's as official as it's gonna get. 

[Hubert 53]

29 minutes ago, xxdita said:

get feedback on the latest version

I've tried a couple of times to register on the SC4D forum but I'm getting rejected as spam. So here's one bit of feedback - hope it gets to the right folks.

I place the GHSR starter piece and drag out with the Monorail tool. I get  a ground texture that looks like HSR but with monorail pylons above it. Setup in my sig - up to date Mac. 

Cheers,

H

[urbanbabel215 16]

40 minutes ago, Hubert said:

I don't believe there's much to be gained by testing and retesting NAM36 bugs and fixes when NAM is about to move to 37 and the release candidate is already available. As I understand it, a number of Mac compatibility issues in NAM36 have already been resolved in NAM37.

Didn't you just participate in testing this NAM36 bug yesterday? Sorry to have put you out somehow in responding to rsc204's request that someone having CTD issues test the stations... 

[Hubert 53]

10 minutes ago, xxdita said:

I think the 64bit Steam version may have a different Plugins folder than the MAC store version?

It does.

[xxdita 1,097]

1 minute ago, Hubert said:

I've tried a couple of times to register on the SC4D forum but I'm getting rejected as spam. So here's one bit of feedback - hope it gets to the right folks.

I place the GHSR starter piece and drag out with the Monorail tool. I get  a ground texture that looks like HSR but with monorail pylons above it. Setup in my sig - up to date Mac. 

Cheers,

H

PM me your email and I will check on your account status. I should be able to manually activate your account. This is for the forum or the LEX? there is a separate registration required for each. 

[Hubert 53]

1 minute ago, urbanbabel215 said:

Didn't you just participate in testing this NAM36 bug yesterday? Sorry to have put you out somehow in responding to rsc204's request that someone having CTD issues test the stations... 

It was not clear that this was a NAM36 bug. I was running NAM37 and naively tried to help.

[Hubert 53]

5 minutes ago, xxdita said:

PM me your email and I will check on your account status. I should be able to manually activate your account. This is for the forum or the LEX? there is a separate registration required for each. 

Thanks @xxdita I've PM'd you.

[xxdita 1,097]

8 minutes ago, Hubert said:

It was not clear that this was a NAM36 bug. I was running NAM37 and naively tried to help.

And this is why the NAM Team's support policies are as they are. It is a very complex mod, with an untold number of moving parts, handled by an entire team of people that usually work together as a single unit. 

[rsc204 21,866]

15 hours ago, urbanbabel215 said:

Hi @rsc204 I can confirm I was able to successfully play the game with HSR installed in the NAM by replacing the two files you added, so thank you very much.

Thanks for confirming this.

8 hours ago, Hubert said:

It was not clear that this was a NAM36 bug. I was running NAM37 and naively tried to help.

Likewise.

There has been a problem here with a lack of communication, coupled with the fact that I'm running a NAM 36 build. I have much custom RUL and other stuff and simply didn't have time to port any of my ridiculous number of Plugins folders/regions to NAM 37 yet. It hasn't helped that internally we've been through so many builds, yet for my other activities I needed a stable environment to work with. Between these factors, it never came to my attention that issues found in February had already been handled.

Given that it seems no actual NAM team member has been dealing with the problems, I'm a little surprised this was never brought up in our private forums once. However it is clear to me now that at least in terms of the basic NAM Mass Transit Lots, there is probably not a lot left to check. So apologies if as a result of this I've wasted your time.

However, for the time being at least, patches exist for the affected files for NAM 36 users, of course it is better for Mac users to switch to NAM 37. I also believe it's the first time that someone has actually detailed both the problem and fix in a public setting. Frankly, that this issue has been worked on since February, but that no one yet bothered to do this, is precisely why it looked like this issue was very much outstanding.

Of course, whilst I am a NAM team member and therefore wanted to begin with the content there, this is clearly not limited in focus to the NAM as an issue. As such, I am hopeful at least that we can try to create a single-point to report such issues here on ST, so any other content with issues can be corrected.

9 hours ago, Hubert said:

I place the GHSR starter piece and drag out with the Monorail tool. I get  a ground texture that looks like HSR but with monorail pylons above it. Setup in my sig - up to date Mac. 

This issue has been present for a while, so I'm fairly certain it's known about. I'll make sure it's noted somewhere prominent, just in case I'm wrong.

[xxdita 1,097]

5 hours ago, rsc204 said:

I also believe it's the first time that someone has actually detailed both the problem and fix in a public setting. Frankly, that this issue has been worked on since February, but that no one yet bothered to do this, is precisely why it looked like this issue was very much outstanding.

There is this post and this one.

Where is it that you learned about the slope bug? 

[urbanbabel215 16]

On 5/22/2020 at 12:32 PM, rsc204 said:

It's important here to note that there are two separate issues, the first is a general problem running the 64-bit version of SC4. It's not entirely clear what's behind this, but if you can run the game and open a blank, new region/city, then this issue no longer applies to you. It's very important you also do this with no Plugins installed, the point is to know at least the game can work. I can only speak based on knowledge of the Windows version, but for example if you previously set things up to use settings other than the defaults, you probably will need to adjust these again after installing a new version. For example, if you were using the software renderer previously, you may need to change this once more to make the game work.

The second issue is more complicated and is the result of using mods which have some incorrectly defined data types. Whilst technically an error, the use of such has never really came to light as a problem, because it never caused problems with the 32-bit Mac and PC versions of the game. With one exception, two Properties that are used specifically for TE Lots (Stations), again the PC version simply works regardless, but it led to problems for 32-bit Mac version players. This is known as the Mac TE bug, but is actually a ridiculously simple problem:

As I explained in this post, see those two Properties Transit Switch Entry Cost and Transit Switch Traffic Capacity, in the third column we see it uses a Float32 Data type and in the fourth column (Reps) both contain the value 1. Simply put, where a Float32 Data type exists and there is only one value or rep, the Rep. field should contain a 0, not a 1.

I have to explain Reps here to prevent misunderstandings, Reps are the number of values or data fields, which contain data. Look at this example:

Here we have multiple Properties using Float32 Data types, some contain a higher number than 1. I've expanded the Occupant Size Property, which has 3 Reps. See how the value 40,33,36 is actually represented as three separate values, separated by commas, hence it has 3 Reps. Note here only 3 other Properties use the Float32 Data type, the next two correctly have 0 for one Rep, whilst the last has 4, but has 4 Reps. I know this seems complex, but it boils down to something very simple:

If any Property in an Exemplar is a Float32 value that contains only 1 Rep, the Rep. value MUST be set to 0 or Mac users see problems.

Fixing this problem requires iLives Reader, a 32-Bit Windows application (a problem for users without access to Windows), we can just update the faulty values, save the affected file and all should be fine (instructions in previously linked post).

Here in Reader is one of the files (by Spa - Since Patched), identified to contain such problem values:

Note how once more the Float32 Property is used for the highlighted values and that again they contain one Rep but not the correct 0 Rep. value. Long and short, we don't yet know how far this problem goes. If it can be caused by both Buildings and LotConfiguations Exemplars, why not Prop, Flora or pretty much any Exemplar Type, which might have the incorrect value. The change seems to be that when compiled as a 64-bit App, it's suddenly essential this value is set correctly.

 

Why is this happening?

We have known about problems with TE Lots for a very long time and subsequently traced them to a modding tool, SC4 Tool, which is pretty much the only tool we have to Transit Enable Lots. When such a Lot is saved with the tool, it erroneously uses the Rep. value 1, not 0. Sadly the tool can not be updated, so it's reliant on modders to know about this issue and remember to subsequently edit all such values in Reader, every time they save a Lot in SC4 Tool.

There may of course be other tools behind this, because until now we were only focused on TE Lots, it's not yet clear if this is limited to SC4 Tool. What has become clear is that suddenly it's very important for Mac users, that these incorrect values are fixed.

 

Is this a NAM problem?

Technically, no, it's a general problem for all modded content, however indications are that some NAM files are affected. They key things to remember are that until the latest Pre Release NAM37, there has never been a native Mac NAM installer. This causes all sorts of complications for many Mac users, all of which can be avoided by using the new Java (multi platform) based version. Any of these errors leading to issues using NAM 37 content, will have been present in previous NAM versions anyway, none of the affected Lots are new content. The NAM 36 installer itself is 32-bit, so you can't run it or use emulation such as WINE, if you have updated to Catalina. When these issues are fixed, we won't be updating old NAM builds. In other words, you'll need to install an updated NAM 37 build or later to get these fixes at some point.

Long and short, NAM 36 is dead, long live NAM 37, i.e. Mac users are better off using the latest NAM, as is everyone really.

@memo, a currently inactive NAM Team member, after the previous update to the Mac game, found some content other than these TE Properties, which was causing problems. But the basic problem is the same in all instances, it's just as the game gets updated, the issue expands to affect more Properties. Most such problems should have been addressed within the NAM already, thanks to memo's efforts previously, but certainly any remaining content in NAM will be fixed.

I can also confirm, having checked the current RTMT 4 build, this issue is not present for RTMT. Just to show how easy it is to screw up, I did find 5 instances of the TE Properties with the wrong Rep. Count in the process. Keeping track of manually reverting this after every save, it's real easy to miss when you're working with many hundreds of stations.

The wider problem though is all the content out there on the exchanges, because seemingly this is no longer limited to Stations.

 

One hypothesis for issues opening existing save files, after updating to the 64-bit game

I can only base this on my knowledge of SC4 save files, but I'm wondering if this problem may be due to the following:

• Affected content was added and saved with the 32-bit version.
• The game was updated to the 64-bit version.
• Unused/New Cities can load and be played (without Plugins), but existing ones not.

We know that certain Properties are embedded into the save file, when content is placed in-game, whilst other data is non-static. In the above scenario, if an affected file's Properties were read, as part of the loading process, could that be triggering the CTD. Just as normally, it only triggers when you try to use an affected Lot, when the game reads all it's Properties.

Even less clear, assuming the above explained what we're seeing, if we correct the affected Plugins, will that correct the issue. There is some possibility, this data may be part of the Save File and fixing that is a lot harder. One things for sure, since these issues are only triggered by the use of Custom Content, no one at Aspyr is likely to offer support or resolution.

Some interesting developments (starting) here, maybe a solution can be found to find and correct these values? Otherwise...Lastly, all of what I've written above comes from feedback from the Mac users within our community. We're in a paradoxical situation, where most of those who can fix the problem, can't trigger it. But those having issues, can't fix them, (because you can't run iLives Reader easily on a Mac). I'm guessing far more files with potential problems are going to come to light as more people get updated to the 64-bit App. But without help identifying specific downloads, these issues won't get resolved. It's unthinkable to go through every file on the STEX for example, to look for and fix these problems. Therefore, I've started a dedicated thread here, if you have found a file/download causing problems, post there and someone will check into it and where possible, provide fixes.

Hi @rsc204, I tried posting in the dedicated thread you indicated, but it appears closed. I'm in the process of troubleshooting all of my non-NAM plugins since the game was updated to 64-bit on Steam. One of the files that causes a CTD when plopped is any of mattb325's suite of train stations that I downloaded from the LEX (no implications of any kind intended, simply using this file for example purposes). I'm using NAM 37 RC on Mac Mojave (Steam version). I'm not looking for support with this, per se, but wanted to confirm my understanding that based on your reply, an analysis of the Float32 exemplar in iLivesReader of one of the stations being a value other than "0" is the cause of the CTD? 

[xxdita 1,097]

4 minutes ago, urbanbabel215 said:

Hi @rsc204, I tried posting in the dedicated thread you indicated, but it appears closed. I'm in the process of troubleshooting all of my non-NAM plugins since the game was updated to 64-bit on Steam. One of the files that causes a CTD when plopped is any of mattb325's suite of train stations that I downloaded from the LEX (no implications of any kind intended, simply using this file for example purposes). I'm using NAM 37 RC on Mac Mojave (Steam version). I'm not looking for support with this, per se, but wanted to confirm my understanding that based on your reply, an analysis of the Float32 exemplar in iLivesReader of one of the stations being a value other than "0" is the cause of the CTD? 

Let's tag the man himself, @mattb325. He does all his own stunts. 

[mattb325 28,891]

17 minutes ago, urbanbabel215 said:

One of the files that causes a CTD when plopped is any of mattb325's suite of train stations that I downloaded from the LEX

Hi urbanbabel215. That station was updated on May 16th after reports of potential Mac issues on another thread, so I  am going through my oldest files (this being one) that myself and/or barbyw made and have made changes as needed. After you download the updated version from the LEX, you should have this:

 

[xxdita 1,097]

4 minutes ago, mattb325 said:

Hi urbanbabel215. That station was updated on May 16th after reports of potential Mac issues on another thread, so I  am going through my oldest files (this being one) that myself and/or barbyw made and have made changes as needed. After you download the updated version from the LEX, you should have this:

 

Thanks. You're moving faster than I am tonight. 

Checking the LEX account under the same name, I see that your Terminus pack has been updated since they've downloaded last. 

All LEX users can view every file they've downloaded, as well as those that have been updated since they last installed it by viewing their Download History. 

[urbanbabel215 16]

Thanks @mattb325, I do appreciate the response and did see the update to these stations on LEX (and will definitely update them on my end), but I'm actually trying to understand the underlying exemplar conflicts so I can learn to help myself (especially where files may not have been updated by their author) and not burden you wonderful people during what is clearly a very stressful time. I just happened to reference one of your old files and, like I said, wasn't looking for support, just confirmation. If you're willing to help me with that, I'd be very much obliged. And if not, I fully understand, and hope the member to whom I addressed my response will be able to assist.

[mattb325 28,891]

No worries at all, @urbanbabel215, the issue (as far as it is known, based on discussions from other threads there still appears to be some unknowns at this point until further testing is done by Mac users) with the MAC 64 bit upgrade which causes a crash to desktop if either of the Transit Switch Entry Cost or the Transit Switch Traffic Capacity (both of which are Float32) entries have a Rep Count of 1. They should both have a Rep count of 0. 

With the exception of the filling degree (listed as 'unknown' in the older version of the reader), other Float32 entries in the list are not 0|1 type entries and all of those Float32 entries are fine the way they are.

 

[rsardachuk 98]

Whoa, a lot of discussion has occurred here over the weekend.  I'm a little confused as to what Solved the problem.  @urbanbabel215 you said you had tweaked NAM somehow to get it to work?  (excuse me for my lack of computer expertise)

[rsc204 21,866]

8 hours ago, urbanbabel215 said:

I'm not looking for support with this, per se, but wanted to confirm my understanding that based on your reply, an analysis of the Float32 exemplar in iLivesReader of one of the stations being a value other than "0" is the cause of the CTD? 

I think we can conclude that any Property that uses the Float32 Data Type of 1 should be changed to 0. So far it appears only five specific Properties have been identified within such problematic files, but given the patterns we're seeing, it's surely safer at this point to update them all. Of course it could be that some Properties need a 1, but this seems unlikely, certainly there seems to be an inconsistency in which value 0 or 1 has been used when I checked a random sample from my Plugins folder.

Note this probably doesn't apply to the Filling Degree Property, since SC4 doesn't look at this, it's something used only by PIM-X.

Just bear in mind, any Float32 Properties using a Rep value higher than 1 are probably correct:

Quote

On 22/05/2020 at 6:32 PM, rsc204 said:

Here we have multiple Properties using Float32 Data types, some contain a higher number than 1. I've expanded the Occupant Size Property, which has 3 Reps. See how the value 40,33,36 is actually represented as three separate values, separated by commas, hence it has 3 Reps.

If you check the screenshots from that post, you can see the difference between a Property with a single Rep and those with multiple Reps. It's only those with a single Rep that seem to be affected.

4 hours ago, rsardachuk said:

I'm a little confused as to what Solved the problem.  @urbanbabel215 you said you had tweaked NAM somehow to get it to work?  (excuse me for my lack of computer expertise)

Some affected lots in the NAM have been updated to prevent problems, so if you're not using the NAM37 RC, you should update to that first. If thereafter you are still having problems, make sure no old NAM files from previous versions are lurking in your Plugins folder. If then you still have issues, that's something else we'll probably need to look into.

[Tarkus 6,933]

On 5/23/2020 at 5:44 PM, Hubert said:

I place the GHSR starter piece and drag out with the Monorail tool. I get  a ground texture that looks like HSR but with monorail pylons above it. Setup in my sig - up to date

I fixed this one at least a couple times during NAM 37 development.  Aggravated to see it's come back again.  I'll look over it once more.

-Tarkus

[rsardachuk 98]

5 hours ago, rsc204 said:

Some affected lots in the NAM have been updated to prevent problems, so if you're not using the NAM37 RC, you should update to that first. If thereafter you are still having problems, make sure no old NAM files from previous versions are lurking in your Plugins folder. If then you still have issues, that's something else we'll probably need to look into.

I think i'm running NAM 37, but i'm looking in my NAM files to confirm that, and i'm not seeing a readme or anything.  is there a spot i can look to see what version it is, or am i Missing something?

[xxdita 1,097]

13 hours ago, urbanbabel215 said:

Thanks @mattb325, I do appreciate the response and did see the update to these stations on LEX (and will definitely update them on my end), but I'm actually trying to understand the underlying exemplar conflicts so I can learn to help myself (especially where files may not have been updated by their author) and not burden you wonderful people during what is clearly a very stressful time. I just happened to reference one of your old files and, like I said, wasn't looking for support, just confirmation. If you're willing to help me with that, I'd be very much obliged. And if not, I fully understand, and hope the member to whom I addressed my response will be able to assist.

I appreciate your eagerness to handle it on your own, but please understand, these issues won't just affect you, but every MAC player old and new. As such, whenever a BSC file is reported, we strive to have it corrected and updated on the exchanges within 24hours. These are the standards we impose on ourselves, in order to provide the highest level of quality with each and every upload, for all SC4 players. 

Not everyone else is going to provide the same level of tech support though, so learning the problems and how to fix them will become a necessity, I fear. It would still be extremely helpful if you could report problematic files as you find them. Because unless these files are corrected on the exchanges, then future MAC players will suffer too, and anyone trying to provide tech support will be chasing their tails. 

At this point, the information is scattered in multiple threads, some of which are several pages long. I've been part of pretty much every conversation on the matter since the 64bit version was released, have fixed a number of files personally, and have investigated each and every file reported, as well as any attempted fixes for them, whether verified to work or still problematic. I have successfully talked a few people through making the necessary corrections. 

I will try to put together a thread to summarize what we know so far, including the bugs we've confirmed, how to detect them, and how to correct them. Then speculation, testing, bug reports and other topics can continue normally where ever they may occur, and i can keep that thread factually correct. I'll add a link in my signature when it's done and post back here when I finish typing it out. 

[xxdita 1,097]

Updating my siggy is a tad slow, but I have finished typing out a thread at SC4D with everything we know so far. I will try to keep this updated as we can confirm and resolve other issues. 

[urbanbabel215 16]

15 hours ago, rsardachuk said:

Whoa, a lot of discussion has occurred here over the weekend.  I'm a little confused as to what Solved the problem.  @urbanbabel215 you said you had tweaked NAM somehow to get it to work?  (excuse me for my lack of computer expertise)

@rsardachuk Yessir, I actually removed all my plugins and upgraded to the new NAM 37 Release Candidate, and that's fixed the problems. Now I'm trying to add all my previous plugins one by one to see which ones trigger additional problems based on some of the other issues discussed in this thread, but so far it's been pretty smooth sailing.

Regarding your NAM version, I'm pretty sure you would know if you have the new NAM 37 RC as it was just released in the past month and would have required you to delete your previous NAM files out of your Plugins folder to install, so let's assume you don't. You can find the new NAM here: https://www.sc4devotion.com/forums/index.php?topic=18616.0. It's been really great so far.

[xxdita 1,097]

You can find out the NAM version you're using by opening the highway menu and scrolling down to the very bottom. You'll see a NAM logo icon. Hover your cursor on that and it will give you the release date of the NAM controller.