How to Install SC4DatPacker 2008 / CAM, the SysWOW64 Way!

[Leo -- 186]

You probably know if you try to install CAM on windows 10 SC4DatPacker 2008 will crash during setup. This is caused by missing libraries for 32-bit apps in the SysWOW64 folder. So if we put the required .dll s in the SysWOW folder SC4DatPacker, SC4 Mapper, and SC4TerraFormer (SC4TerraFormer might need more dlls to work read its readme) should work.

 

Step 1 : Get The dlls 

              Step 1a :Get MFC71.DLL https://www.dll-files.com/mfc71.dll.html

              Step 1b :Get MSVCR71.dll https://www.dll-files.com/msvcr71.dll.html

              Step 1c :Get GDIPLUS.DLL https://www.dll-files.com/gdiplus.dll.html (Note : my system already had this file so you might not need to download it)

Step 2 :Unzip the dll s and place it in the root of C:\Windows\SysWOW64

Step 3 :Reboot

Step 4 Run the CAM installer and enjoy 

I am not responsible if something goes wrong.

This Tutorial only applies of 64-bit versions of windows 10

[TMetzger28 3]

Just wanted to chime in for anyone having issues still following the PDF and suggestions above:

The MSVCR71.dll above apparently isn't the one needed, MSVCP71.dll is. Once you drop that in your SystemWOW64 folder alongside MFC71 and GDIPLUS, SC4DatPacker works fine!

[Leo -- 186]

On 1/13/2023 at 7:28 PM, TMetzger28 said:

The MSVCR71.dll above apparently isn't the one needed, MSVCP71.dll

Hmmm MSVCR71.dll was the .dll that I needed, well every system is different and Windows works in mysterious ways. So this documentation is appreciated.

[FoxtrotF 6]

Was unable to make this pile of ....t to run. Nothing halps, Just nothing happens when trying to launch SC4DatPacker, and installation of Colossus failing.

[Ulisse Wolf 4,459]

12 minutes ago, FoxtrotF said:

Was unable to make this pile of ....t to run. Nothing halps, Just nothing happens when trying to launch SC4DatPacker, and installation of Colossus failing.

Solution to CAM Installation Problem Using Windows 10 & 11

[FoxtrotF 6]

47 minutes ago, Ulisse Wolf said:

Solution to CAM Installation Problem Using Windows 10 & 11

Yep, I followed this instruction too... I'm unable to launch SC4DatPacker, just nothing happens. no errors, nothing. And I placed dlls in win sys folder, in SC4DatPacker  installation folder. Same. nothing happens.

[Ulisse Wolf 4,459]

2 hours ago, FoxtrotF said:

Yep, I followed this instruction too... I'm unable to launch SC4DatPacker, just nothing happens. no errors, nothing. And I placed dlls in win sys folder, in SC4DatPacker  installation folder. Same. nothing happens.

check if your antivirus is blocking SC4DatPacker. Windows Defender is giving a bit of trouble lately. Same thing with the "Controlled folder access" protection system

[rsc204 21,866]

9 hours ago, FoxtrotF said:

Was unable to make this pile of ....t to run

It's not really fair to call other people's work a pile of shit, please be more considerate towards people even when you are frustrated. Do you think the creator spent ages trying to make something that didn't work?, there are some problems with the installer, but it is by no means consistently broken. On some systems for reasons not entirely clear, the installer isn't able to function as intended. Bear in mind that a coder making such an installer, won't have the ability to test every possible setup, so issues like this can slip through. By the time the problem had come to light, the creator was no longer active and therefore to date no one has been able to resolve this problem directly.

That said there is a work-around (linked by Ulisse), you just need to find a way to manually DATPack the patch for SimCity_1.dat.

[FoxtrotF 6]

2 hours ago, rsc204 said:

It's not really fair to call other people's work a pile of shit, please be more considerate towards people even when you are frustrated. Do you think the creator spent ages trying to make something that didn't work?, there are some problems with the installer, but it is by no means consistently broken. On some systems for reasons not entirely clear, the installer isn't able to function as intended. Bear in mind that a coder making such an installer, won't have the ability to test every possible setup, so issues like this can slip through. By the time the problem had come to light, the creator was no longer active and therefore to date no one has been able to resolve this problem directly.

That said there is a work-around (linked by Ulisse), you just need to find a way to manually DATPack the patch for SimCity_1.dat.

Please do do not divert in this way, the problems are with obsolete libraries and dlls, and incompatibility with new os. this what I called pile.

[FoxtrotF 6]

8 hours ago, Ulisse Wolf said:

check if your antivirus is blocking SC4DatPacker. Windows Defender is giving a bit of trouble lately. Same thing with the "Controlled folder access" protection system

I lowered uac and shut down defender, before starting this topic.
Event Viewer tells that fault module is wxbase28uh_vc.dll don't know will try to put this dll into system folders. Or reinstall Visual C++ Redistributable.

[rsc204 21,866]

12 hours ago, FoxtrotF said:

Was unable to make this pile of ....t to run

Whatever your intentions, how that reads is that the installer is the pile of shit, so if that wasn't your intention, then you could clarify that in a way that actually sounded less like an attack on me for bringing it up.

Suggesting I am diverting things is a nice touch, but you seem to have missed that I am a moderator here, so when I suggest what you are saying is not acceptable, you should maybe reconsider if this is the hill you want to die on. I get that this problem may be frustrating to you, but you are asking random strangers to take their time to assist you, please be mindful of that.

19 minutes ago, FoxtrotF said:

the problems are with obsolete libraries and dlls, and incompatibility with new os

I don't believe that is the core of the problem, rather there is some sort of issue with the installer code. We don't have access to the source code, however I am familiar with NSIS since I use it for my own work. Honestly the absolute specifics of this will probably remain a mystery unless the source code becomes available. But I can tell you that on my Win7 system it never used to work, but after a re-install of Windows it works every time now. I simply don't have enough data to tie together what difference alters the outcome, put another way no reliable method to test things. I'll also add when it was not working, SC4DATPacker worked flawless as I had it installed, so it's definitely the installer where the error lies.

The whole point of the installer was to automate all this, precisely so users wouldn't have to go through installing DATPacker, packing files and such. When it works, the process is flawless and hidden from the user, but when it doesn't you need to do some manual stuff.

The libraries and .dll files are not obsolete, just old, you know like the software you are trying to use is. Nothing we can really do about that, all this was forced upon folks by Microsoft mostly, who back then only cared about monitising anything created using their software. Today things are much better, but legacy applications are by design stuck with the old way of doing things.

Step 1 here is getting SC4 DATPacker working, although if that's proving difficult an alternate exists, JDATPacker which runs under Java. The only dependency as such is to have Java installed, which is also needed by the NAM installer and very common, so chances are you have it already.

Another tip, why mess around trying to put these .dll files into a system folder, do you really know what you are doing enough to understand how all this works? By far and away the simplest solution is to put them in the root install folder for the App, that is guaranteed to work. So if you definitely have them all and they are definitely in the right place, stop messing with this, clearly it's not the problem and constantly shifting things about isn't helping you to get to the bottom of what is.

Make sure permissions are not causing a problem, for example you may need to run SC4DATPacker with Admin rights. If security software is interfering, temporarily disable it whilst you run the DATPacker, although I recommend you physically disconnect from the internet whilst doing so. If it's still not working, this isn't a compatibility or dependency issue, something you have installed on your computer is interfering with this process. Again, JDATPacker is probably the path of least resistance, it's unlikely to suffer the same issues unless your files are locked down tight by some overzealous security software.

[FoxtrotF 6]

I didn't have any problem with installer it worked as a charm, except part with  SC4DATPacker, for the system folder dlls this in case that I followed different instructions. And sometimes after Windows updates I need to reinstall all the redistributables, because they starting to fail. I did not mean that packer or installer, are pile, and I'm very sorry that you took it so personal, this community always amazed me, doing such thing for such long time, place of real enthusiastic peoples, who love this game and spend so much effort to bring all this to the others. And thank you for the JDatPacker will try to use it.
And please if you don't mind could you please help with I guess related to NAM, how to fix when sometimes railroad tiles(corner or junction) are the steel one, so all tracks are beautiful brown, but one tile is steel then followed again by brown one.

 

[rsc204 21,866]

42 minutes ago, FoxtrotF said:

please if you don't mind could you please help with I guess related to NAM, how to fix when sometimes railroad tiles(corner or junction) are the steel one, so all tracks are beautiful brown, but one tile is steel then followed again by brown one.

This is most typically a sign that what you are trying to do is unsupported. RealRailway (mandatory with NAM) changes the way the rail system works. Part of this was intended to remove illogical or ugly setups.

That said there are a number of situations where the code needs some updates to fix situations which really should be working but are not. Hopefully I can get all the testing done to add the fixes for that to the next NAM update.

 

[FoxtrotF 6]

1 hour ago, rsc204 said:

This is most typically a sign that what you are trying to do is unsupported. RealRailway (mandatory with NAM) changes the way the rail system works. Part of this was intended to remove illogical or ugly setups. That said there are a number of situations where the code needs some updates to fix situations which really should be working but are not. Hopefully I can get all the testing done to add the fixes for that to the next NAM update.

Exactly this. ))) Thanks, rebuilding corner most of the time fixing this, but now I know what is this. Thank you!

[FoxtrotF 6]

2 hours ago, rsc204 said:

Step 1 here is getting SC4 DATPacker working, although if that's proving difficult an alternate exists, JDATPacker which runs under Java. The only dependency as such is to have Java installed, which is also needed by the NAM installer and very common, so chances are you have it already.

With JDATPacker everything went smooth. Message told that everything is Ok. I look in to the target "SimCity_1.dat" filesize, and it the same as the vanilla, but "z_CAM_2.1.0_Stand_Permanent Merge" is also tiny, so I guess everything is Ok?
And also with "Colossus Addon Mod 2.1.0 Windows Installer v2"  should I manually copy "z_CAM_2.1.0_Stand_Permanent Merge" as the "What's New 2.1.0a" says? Or v2 is 2.1.0a?

[rsc204 21,866]

Once you have 'packed' the file "z_CAM_2.1.0_Stand_Permanent Merge" together with SimCity_1.dat, you don't need the first file anymore. In fact keeping it will lead to problems, exactly why it needs to be packed in this manner to begin with.

Make sure that SimCity_1.dat (the newly modified one) is returned to it's original home and you are good to go. This is a one-time patch, unless you re-install SC4 for some reason, you won't need to use it again.

[FoxtrotF 6]

5 minutes ago, rsc204 said:

Once you have 'packed' the file "z_CAM_2.1.0_Stand_Permanent Merge" together with SimCity_1.dat, you don't need the first file anymore. In fact keeping it will lead to problems, exactly why it needs to be packed in this manner to begin with.

Make sure that SimCity_1.dat (the newly modified one) is returned to it's original home and you are good to go. This is a one-time patch, unless you re-install SC4 for some reason, you won't need to use it again.

Thank so much for your Help!

[Leo -- 186]

On 4/16/2023 at 4:30 AM, rsc204 said:

I don't believe that is the core of the problem, rather there is some sort of issue with the installer code. We don't have access to the source code, however I am familiar with NSIS since I use it for my own work. Honestly the absolute specifics of this will probably remain a mystery unless the source code becomes available. But I can tell you that on my Win7 system it never used to work, but after a re-install of Windows it works every time now. I simply don't have enough data to tie together what difference alters the outcome, put another way no reliable method to test things. I'll also add when it was not working, SC4DATPacker worked flawless as I had it installed, so it's definitely the installer where the error lies.

You are actually incorrect, the installer is 100% and is working as intended, the issue lies with SC4DatPacker 2008, (it's actually packaged in the installer exe, however, is a separate executable file, you can see this if you open up the CAM installer with 7zip.) Missing libraries (specifically the MSVC runtime) are indeed the issue, and if I had to guess it's that SC4DatPacker 2008 was compiled for x86 while we all now use Windows on AMD64 and that the libraries are in the System32 folder (AMD64) and not in the SysWOW64 (x86 subsystem folder) This is an example of DLL hell.

Also here's more information on the Windows 32-bit on Windows 64-bit subsystem (it's just Wikipedia )

As for @Foxtrot I have no idea why this method didn't work for you as it did work on a fresh install of Windows 10.

[rsc204 21,866]

2 hours ago, Leo -- said:

You are actually incorrect, the installer is 100% and is working as intended, the issue lies with SC4DatPacker 2008, (it's actually packaged in the installer exe, however, is a separate executable file, you can see this if you open up the CAM installer with 7zip.) Missing libraries (specifically the MSVC runtime) are indeed the issue, and if I had to guess it's that SC4DatPacker 2008 was compiled for x86 while we all now use Windows on AMD64 and that the libraries are in the System32 folder (AMD64) and not in the SysWOW64 (x86 subsystem folder) This is an example of DLL hell.

Are you aware that it was me who troubleshooted this problem in the first instance and posted the first work-around for users? I mean seriously you come at me in such an absolute manner that it's almost insulting. But you clearly do not fully understand how the installer works and affects this operation, you've made an assumption on this that simply isn't correct.

The purpose of the Installer, is to put things where they need to be, in this specific example that means the SC4DATPacker.exe and its related files so it can run. The libraries are not missing, it installs them (temporarily), into the same folder as the .exe. Ergo the x86/x64 thing doesn't even apply in this scenario, it's literally nothing to do with the problem. You do realise that the CAM installer does NOT install these .dll files into system folders, you literally can't have seen it in action if you think it does.

Again, because you seem to not have understood or read my previous post, on the occasions when the Installer was not working, I had SC4DATPacker installed and working as a standalone application prior to using the CAM installer. So if my version was working, whatever causes the same .exe bundled in an installer to fail to run, simply can not have been missing libraries, because if they were missing the stand-alone version would fail to run also.

I'll note here, I do not use the .dll's in the install folder, mine were correctly installed in the relevant system folders needed for OS-wide access to them. Not that I messed around with any of that personally, I just used the correct official packages, rather than the individual .dll files when installing them.

Are you aware of how these .dlls were officially distributed?, or did you just download the actual .dll files from a dodgy website? And yes it would have to be dodgy, since it's against the terms of the licence to distribute individual .dll files, only the actual 'packages' containing them. If you want to re-distribute those, you must pay MS a licensing fee too, which is at the heart of all these problems to begin with. So yeah, if you downloaded a .dll file it's at best stolen property. 

Any user who properly installs the official packages as intended, will find regardless of x86 or x64, they are automatically placed where they need to be, so all Apps can 'see' them. This is the crux of the issue in this thread, but again it has absolutely nothing to do with how the CAM installer works or why it sometimes fails to run this component.

Sure, the last time I wrote up a guide to the official packages with links was many years ago and MS do have a habit of hiding, moving or removing legacy files for products they deem 'out of support'. (I'm not going to spend hours digging out a post from almost 10 years ago, but it exists somewhere). I get why people might want to use the .dll files or even need too. But again, rather than trying to understand how Windows handles 32-Bit apps within a 64-Bit environment, which is hideously complicated, just place them in the install dir of the app and you can't go wrong!!! Why would most normal users want to overcomplicate this? Sure it's a little redundant and in an ideal world you'd add them to system folders. But pushing this ideal is not helping the average user, who'd benefit more from the simplest fix rather than trying to understand a hideously complicated part of how their OS works. Of course for those who want to understand this area of the OS, great, but for everyone else, just put them with the App and save yourself the hassle.

[Leo -- 186]

34 minutes ago, rsc204 said:

Again, because you seem to not have understood or read my previous post, on the occasions when the Installer was not working, I had SC4DATPacker installed and working as a standalone application prior to using the CAM installer. So if my version was working, whatever causes the same .exe bundled in an installer to fail to run, simply can not have been missing libraries, because if they were missing the stand-alone version would fail to run also.

Maybe we are talking about 2 issues because I never had the installer fail to run and issues only arose when it came to launching SC4DATPacker and in my case SC4DATPacker spit out a log complaining about these files, now I do know that the required dlls are prepacked with SC4DATPacker but they didn't work and I don't know why but placing them in syswow64 allowed SC4DATPacker to run and DATpack SimCity_1.dat as normal. I had the same issue with SC4TerraFormer, adding the dlls in the program folder did not help and the program wouldn't work.

1 hour ago, rsc204 said:

Are you aware of how these .dlls were officially distributed?, or did you just download the actual .dll files from a dodgy website? And yes it would have to be dodgy, since it's against the terms of the licence to distribute individual .dll files, only the actual 'packages' containing them. If you want to re-distribute those, you must pay MS a licensing fee too, which is at the heart of all these problems to begin with. So yeah, if you downloaded a .dll file it's at best stolen property. 

I don't know why you are coming at me with this, did InvisiChem pay Microsoft to have those dlls bundled in the installer? I don't think so.

1 hour ago, rsc204 said:

Any user who properly installs the official packages as intended, will find regardless of x86 or x64, they are automatically placed where they need to be, so all Apps can 'see' them. This is the crux of the issue in this thread, but again it has absolutely nothing to do with how the CAM installer works or why it sometimes fails to run this component.

Again I had the MSVC installed on my old install of Windows and it didn't work, I don't why but it didn't.

1 hour ago, rsc204 said:

Are you aware that it was me who troubleshooted this problem in the first instance and posted the first work-around for users?

Actually no, the PDF credited you but I didn't you were the first to come up with a workaround, and after a quick look I can only find an earlier post from 2017 about you talking about the workaround.

In this case my assumption lined up with my reality, your reality might be different from mine and I'm sorry if my explanation of the solution for my reality is completely incorrect in other realities and sounding like a smartass about it. I didn't mean to come off like that and obviously lots of tone gets lost in text. It was those links they weren't you for you but for other people.

Also out of curiosity I managed pull part (if not all) of the NSI script via an old version of 7zip, maybe you can find out wants wrong (if the NSI script is useful) as if anyone knows anything about it's the NAM team with their monster NSI script.

[NSIS].nsi

[Max4k 727]

I just got a new Laptop with Windows 11 and using CAM.  I think they updated the download page here with information that you have to manually Datpack.  I got an error too, but no big deal, just do it manually.

[rsc204 21,866]

On 25/05/2023 at 10:51 AM, Leo -- said:

Maybe we are talking about 2 issues because I never had the installer fail to run and issues only arose when it came to launching SC4DATPacker and in my case SC4DATPacker spit out a log complaining about these files, now I do know that the required dlls are prepacked with SC4DATPacker but they didn't work and I don't know why but placing them in syswow64 allowed SC4DATPacker to run and DATpack SimCity_1.dat as normal. I had the same issue with SC4TerraFormer, adding the dlls in the program folder did not help and the program wouldn't work.

We absolutely are talking about two separate issues, given the user in question had problems with the installer, I was of course talking about that. You choose to quote my perfectly valid instructions with the words "You are actually incorrect, the installer is 100% and is working as intended".

Again, you are the one who is incorrect, the installer is known to have problems for some, a point you seem to be aware of:

On 25/05/2023 at 10:51 AM, Leo -- said:

Actually no, the PDF credited you but I didn't you were the first to come up with a workaround, and after a quick look I can only find an earlier post from 2017 about you talking about the workaround.

Given this, I can't fully understand why you felt the need to both call me out on the subject and in a factually inaccurate way. Sure, I get stuff wrong, when I do I'll own it, but if you are going to call me out on something, best to have your facts right before you do, otherwise I will correct the record.

On 25/05/2023 at 10:51 AM, Leo -- said:

In this case my assumption lined up with my reality, your reality might be different from mine and I'm sorry if my explanation of the solution for my reality is completely incorrect in other realities and sounding like a smartass about it. I didn't mean to come off like that and obviously lots of tone gets lost in text. It was those links they weren't you for you but for other people.

I mean, is this supposed to be an apology, an explanation or what?

Yes, I like many other people in this world do not take kindly to people publicly coming out and saying i am wrong about something, especially when it isn't even true. Perhaps you think it egoistic that someone who's taken the time to learn and understand things and has I hope, a fairly good reputation for technical matters, might think it could be done in a more respectful manner. Like, hey have you considered x, rather than very directly stating I am incorrect? That might go down better in the first instance?

Your reality seems to ignore facts that don't support it, whereas mine is open to adjustment on the basis of new information. So when again I tell you that mucking around in system folders is a bad idea for the uninitiated and completely unnecessary, I am sure you won't give it a second's consideration. If an App is unable to read/write from its home directory, then as a user you have installed something or changed something from the defaults, that causes this to happen. Windows 10, with the default install settings, does not do this automatically, I know because I have test systems I have used to try it out for myself.

On 25/05/2023 at 10:51 AM, Leo -- said:

I don't know why you are coming at me with this, did InvisiChem pay Microsoft to have those dlls bundled in the installer? I don't think so.

InvisChem didn't licence these files, because he just bundled the .dll files into his installer, OK morally speaking I don't have a problem with it per-se, but that doesn't make it any less illegal. Given you are one MS employee finding out away from a potentially life-changing letter from MS's lawyers, I couldn't recommend it. The idea was simply that certain users struggle with tools like the DATPacker and he wanted to make the install experience simpler for end users. I also stated before, MS created this mess through greed, but here with are with this as a legacy problem, it's not going away.

But I am not coming at you with anything except the facts of the matter, given the shady nature of distribution, why would you trust the site in question? I mean is it a friendly community of do gooders who are trying to help, or have you stumbled upon one of the too many to count websites that are essentially clickbait. Hey I need a DLL, I need a Driver, where does a Google search take you?, to a site that is monetised, i.e. seeking to profit from illegal sharing of files.

Red flag #1: in these cases, clearly there is a potential security risk just visiting such a site.
Those with excessive pop-ups or ads are the sort of sites I avoid opening as a rule of thumb. But clearly this isn't some form of legitimate enterprise.
Red flag #2: given the nature of how they operate, who's to say how safe the files you are downloading are?
This would be a perfect way to get malware onto users machines for example.
Then you come along and advocate that a bunch of people who probably don't really understand what they might be doing, should stick this file into a system folder! Have you any idea of the potential risk that opens up?

Sure, it's probably all fine, but that's like saying you probably have insurance for your house, it's better to be certain everything is in order than to assume it is. Many people rely on their computers, don't have good backups or a recovery plan, maybe even use it to run a small business or do something fairly critical. The point is, yes you can do it this way, but it's not the right way of solving the problem if you ask me. It's much safer to sandbox the .dlls (keep them with the Apps), if downloaded in this manner, which I accept is kind of hard these days to find them otherwise.

Here's an irony, by installing security software or using more secure OS settings, you've essentially blocked the ability for these Apps to work. Rather than correct for that, you'd rather install an 'untrusted' file into a system folder overriding your system security! Wow! Really think about that for a moment, this is almost certainly what you are doing/advocating.

Instead, it would be safer to keep these out of system folders, with the Apps that need them. Those apps might need Admin access, you may need to setup file/folder access rights to ensure the apps in question can read the .DLL files needed to run. You may need to go into any security software and alter the settings there such as to allow for correct operation. The absolute specifics will vary, but bypassing that whilst possible, just isn't the best solution for most people.

[TG24 355]

HOLY SMOKES!!! MOM BRING THE POPCORN!11!!

[TG24 355]

Ohh, where can i find more debates?

[rsc204 21,866]

On 08/03/2024 at 12:53 PM, Jidan said:

That's what you got if you debated with a moderator. @xxdita and @mattb325 are also got the same treatment.

What do you mean, that's what you got if you debated with a moderator? It sounds suspiciously to me like you think certain people were censored for disagreeing with a moderator, hell fuck it you mean me, why dance around facts, I don't.

Well let me be very clear, I didn't decide to lock those threads and left to me I wouldn't have done so. The reason they were locked was because the discussion wasn't going anywhere productive. Meh, objectively I have to agree that was at least true.

But the insinuation that there is an agenda here on the part of staff members, aside from being wrong is a violation of site rules. You'll note I'm stating that rather than sanctioning you.

On 09/03/2024 at 6:43 AM, Jidan said:

Basically the whole topic was civil until one guy showed up and said, "Woah, that's wrong, dude. Don't make accusations!"

Again me, I don't really like the way you are calling me out here at all.

Your comment in quotes completely misrepresents things IMO. In fact I was simply trying to correct some absolute rubbish that was being posted in an attempt to discredit the integrity of certain files. There is a whole (and ridiculous) history behind this and it doesn't bear bringing it up again.

However once more, your tone towards me is clearly on the side of unpleasant and as such violates site rules, you might want to reconsider how you address others in future.