Jump to content

SC4Fix: third-party patches for SC4 1.0.7

   (33 Reviews)

1 Screenshot

About This File

What does this do

  • Fixes a serialization bug that could corrupt the savegame, particularly when mods are installed that modify existing exemplars (i.e. prop pox).
  • Resolves a crash-to-desktop when hovering NAM puzzle pieces over transit-enabled lots.
  • Allows other DLLs to load into SC4's memory without a GZCOM framework.

This fix is made for versions 640 and 641 of SimCity 4 on Windows. Version 640 is a fully-patched SC4 retail copy, and version 641 is a fully-patched digital distribution version (i.e. Steam, Origin, GOG). Although v641 is supported, it has only been officially tested on Steam.

Unzip to Documents\SimCity 4\Plugins.

To see if SC4Fix is working properly, check the title of your game window. If you are playing in fullscreen mode, alt-tab out and hover over the SimCity taskbar icon. The titlebar will show "SC4Fix (version #)" if loaded properly.

Repairing cities already affected by prop pox
Thanks to kingofsimcity for these instructions:

  1. In the region view, open the graphics settings and change City Detail to Low.
  2. Close and relaunch SC4.
  3. Open the offending city tile and save immediately.
  4. Exit to region without saving and change City Detail back to High.
  5. Close and relaunch SC4.
  6. Open the offending city tile and save again.

Click here for a video showing the ability to hover puzzle pieces over transit-enabled lots with this DLL.

Development Thread and Source Code
Development Thread
Source Code

What's New 1.0.7   View Changelog


Added a fix for prop pox and similar savegame corruption issues, as discussed in this thread.

User Feedback

Create an account or sign in to leave a review

You need to be a member in order to leave a review

Create an Account  

Sign up to join our friendly community. It's easy!  

Register a New Account

Sign In  

Already have an account? Sign in here.

Sign In Now


   21 of 21 members found this review helpful 21 / 21 members

Out of nowhere you come and fix the most annoying bug the game has. One I predict few people ever realistically thought could be fixed.

Spent the day testing/playing and trying to get a CTD at every opportunity. Despite doing all the things you are not supposed to do, no CTDs.

If you are wondering whether to install this or not? It's like the EP1 update or I-HT fix, everyone needs this.

- Jan 2018 update -

Well I can't sit idly by ignoring the latest updates to this amazing fix. For those with cities long since thought of as dead, killed by Prop Pox, this update can bring them back to life. Not to mention the side benefit of prevention too. ZombieSC4 saves back from the dead, you should have saved this for Halloween :D.

In all seriousness though, your work on some fairly catastrophic shortcomings left in the game simply can not be understated. I'm sure your contributions will help to retain players who might otherwise, frustrated at loosing all their hard work, simply cease playing. That's really what makes this fix so special, thank you for all your hard work and amazing technical achievements.

Share this review

Link to review

   9 of 9 members found this review helpful 9 / 9 members

Wow, dunno how you gone an done it, but you've gone and done it . Fantastic this one  mod patch alone is one of the greatest assets to the Nam. I hope in the future you get in contact with the NAM team to get if officially incorporated into the NAM as a addon patch. Either way this is a must have file for NAM users.

Share this review

Link to review

  Edited by matias93  

   7 of 7 members found this review helpful 7 / 7 members

This is:

  • Fantastic
  • Perfect
  • Magical
  • Incredible
  • Completely bonkers
  • Wasn't this bug hardcoded?
  • Are you a SC4 developer?
  • I didn't think I would live to see this day
  • All of the aforementioned

Edit 21/01/2018: ok, all of those options were clearly an understatement, this little thing also CURES THE PROP POX!!! It's simply irrational...

Share this review

Link to review

  Edited by kingofsimcity  

   5 of 5 members found this review helpful 5 / 5 members

Essential on multiple levels, and warrants a legendary rating that goes beyond 5 stars. Thank you for squashing one of the most frustrating bugs that SC4 had with the NAM.

Update 1/21:

Well, now you managed to cure prop pox too. Makes the download even more legendary than before! Amazing work. :rofl:

Share this review

Link to review
A Nonny Moose

   4 of 4 members found this review helpful 4 / 4 members

We'll see how well this works under Linux/wine.  If I don't add to this, then it is fine.

Installed and tested.  Near as I can tell it works well except for the task bar manipulation since Linux has no such item.  The process status request (ps) returns the name SimCity 4.exe.  Hardly surprising since this fix is essentially messing with windows environment.  Not exactly the same with wine.

Share this review

Link to review

   4 of 4 members found this review helpful 4 / 4 members

Absolutely brilliant!

This is a real game changer.:party:

Share this review

Link to review

   3 of 3 members found this review helpful 3 / 3 members

I don't know how I feel about this. This bug created a whole mini-game in SC4. It's played similar to 'Operation'. I suppose uninterrupted gameplay while placing pieces is ok too. 5/5

Share this review

Link to review
Cyclone Boom

   3 of 3 members found this review helpful 3 / 3 members

Bravo, simply awesome! :D

Mods like this aren't supposed to arrive 12+ years later! This will kick-start a whole new perspective on SC4 modding. :party:

What a week of content this has been...

Share this review

Link to review

   2 of 2 members found this review helpful 2 / 2 members

This is really outstanding, and while this bug has caused a lot of grief over the years, I'm more looking forward to what is done with this next!!  :thumb:

Share this review

Link to review

   2 of 2 members found this review helpful 2 / 2 members

What they said...

Share this review

Link to review

   1 of 1 member found this review helpful 1 / 1 member

Just spent a couple of hours trying to create a CTD with TE lots and NAM puzzle pieces.  I am happy to say that I failed miserably.  This one should win you great honors.

Share this review

Link to review

  Edited by Tonraq  

   1 of 1 member found this review helpful 1 / 1 member

Absolutely Brilliant.

UPDATE (January 21, 2017):

You sir, is absolutely brilliant! Thank you for curing the Prop Pox!

Share this review

Link to review

   1 of 1 member found this review helpful 1 / 1 member

Oh my God! This is a revolution to all simcity 4 players!

Share this review

Link to review

   1 of 1 member found this review helpful 1 / 1 member

This actually WORKS! IT WORKS :party:

and it came in the exact right time to help me solve a STR situation which has been bugging me for the better part of a month! Thank you! :thumb:

Share this review

Link to review

   1 of 1 member found this review helpful 1 / 1 member

Thank you for solving one of SC4's greatest remaining flaws.  Good work!


Share this review

Link to review

   0 of 7 members found this review helpful 0 / 7 members

My Norton said this is not good to run, now I'm confused. I 'll give it 2 stars for now and that's just for the thought

Share this review

Link to review



Share this review

Link to review


The crashes are gone!!! I tried and failed to crash the game with hovering NAM puzzle pieces over a transit enabled station and couldn't! I can now build GLR networks without losing the progress! *:thumb::ohyes:

Share this review

Link to review
Talla 2XLC


This should get 6 Stars but i can only give 5

Share this review

Link to review


Just started getting back into the game again and this is a lifesaver. Thank you!

Share this review

Link to review


Works for me!! This is brilliant, thanks a million.

Share this review

Link to review


Thanks !!!  :thumb:

Share this review

Link to review


This is one of those brilliant things after three months you have forgotten about as you got completely used to it and don't remember anymore how it was before. I estimate you reduced my sc4-CTDs by 70 maybe 80 percent - I have what I never had before: hours of continously playing.

I even used to relot TE lots to gain more stability. Maybe this fix can even give a reniassance to TE lotting -> more interesting TE lots?

Thank you so much.

Share this review

Link to review
  • STEX Featured

  • Newest STEX Uploads

  • Similar Content

    • By soutinho
      Hi guys, I'm back to SC4 after a few years and I was looking after some basic fixes and setups to run the game and its mods, but I've seen that Origin's version of the game is unpatchable (that is, can't og to 1.1.641.0), but when I see properties of game's file, it is written 1.1.641.0. How can I verify if the update was installed correctly? Should I buy GOG's version?
      Another few questions:
      1. Is CAM incompatible with SPAM and IRM? By the way, where can I find it?
      2. Where can I find some good tutorials for building airports and ports with custom props and lots?
      3. Is Cities Skylines really substituting this? Haha
    • By etg-nc2nyc
      My apologies if this has been covered - I've searched extensively and can't find the answer and would like some help, please. 
      All of the trees and MMPs have disappeared from my latest city. I gather this is a result of "prop pox." So I read each of the following carefully: 
      I downloaded the sc4macinjector and ran it. All seems unchanged - no harm done. (I backed up plugins and regions just in case.)
      I downloaded sc4fix - which seems to be doing wonders for our Windows friends - YAY!!! It is a .dll file. I have no clue what to do with it. My VERY basic computer knowledge is that .dll files can't run on Mac. Regarding the sc4macinjector it says the following on its page:
      "What does this do
      SC4MacInjector allows the Mac equivalent of .dll mods to be loaded on Aspyr's port of SimCity 4 for Intel Macs.
      Note: you will not be able to use Windows .dll mods directly. They need to be targeted specifically for Macs as .so files."
      OK. I comprehend those words, but haven't a clue as to what that means in action - or if there is something I can do to target a .dll file as an .so file. <insert very confused llama, perhaps >
      1. Do I actually have prop pox? Have I made the correct assumption that the pox caused my MMPs and props on small residentials to disappear?
      2. Can someone guide on what, if anything, there is to be done about it? I feel clueless and in way over my head from a technological standpoint. Like... I understand technology better than your 90 year old grandma who just made you those amazing cookies*, but ... sometimes... not much.
      *A hypothetical grandma. Now I want cookies.
    • By simmaster07
      Update 2018/01/21
      SC4Fix has been updated with a stable build that fixes prop pox. Download on the STEX:
      I like a good challenge, so I decided to take this one up.
      Prop pox is a bug that causes decorative props in some cities to begin disappearing. The problem is exacerbated if the city continues to be played and saved, and persists even after adjusting graphics settings for prop detail or restarting the game. The prevailing hypothesis is bap's prop theory, which makes these main claims:
      In a normal game installation with absolutely no plugins, prop pox will never occur, even after updating. Prop pox is actually caused by plugins that redefine Maxis prop exemplars that add properties that were not originally in the exemplars. Prop pox will only manifest itself if one of these plugins is installed and the city's prop subfile* is sufficiently large. * bap refers to the prop subfile as the network subfile in his post, which seems to be a mistake.
      Testing this is pretty straightforward as all we need to do is clear our plugins, develop a city until the prop subfile is large enough (around 6MB, according to bap) and then use a plugin that causes pox by improperly redefining exemplars. For this I made a mostly flat large tile city with sprawling low-density developments to add as many props as possible in a short timeframe.
      When the prop subfile for the city was just under 6MB I made a copy of it and then allowed it to develop further until it crossed that limit. Why is this 6MB limit significant? The game determines whether a subfile should be compressed mainly by its filesize (along with a few other properties); subfiles smaller than 6MB can be compressed, but anything larger than that is saved decompressed in order to save time and computational resources when saving very large subfiles. Prop pox apparently begins most commonly when crossing this compression limit.
      With no plugins installed, the city was able to develop past the 6MB prop subfile limit without any pox or save corruption occurring, no matter how many times I saved or how long the simulation ran for, which I tested using wouanagaine's SC4 Savegame Explorer. If prop theory is correct, then pox should occur if we install a bad plugin and try to develop the city past that limit again. For this, bap used SimPEG's Beach Development Kit 1:
      In particular, you only need to extract PEG-OWW2_BDK_RESOURCE.dat as this contains the exemplar redefinitions. After installing this plugin, I loaded the test city, added some new zones to force new props to develop, ran the simulation for a bit and saved the city a couple of times. This immediately resulted in the city developing prop pox according to the savegame explorer.
      For your convenience for reproducing this, here are the savegame files I used:
      Test City, prop subfile under 6MB, no plugins and no pox Test City, prop subfile over 6MB, no plugins and no pox Test City, prop subfile under 6MB, BDK_RESOURCE installed and pox present
      Explaining the buffer corruption
      Since the savegame explorer reports buffer corruption at a particular location in the savegame, we should probably check out what's happening there to see if this improves our understanding of what causes prop pox. First we need to extract the prop subfile from the savegame using iLive's Reader:
      The pox-infected .sc4 save can be opened in the Reader. From there we need to extract the entry with type ID 0x2977aa47 (which is marked as Unknown, and that's fine). We also want to make sure we have the decompressed version of the subfile, so we'll save the decoded file and open it in an external hex editor since the one built into the Reader isn't great. I prefer using HxD.

      If we jump to the reported offset of corruption in the hex editor, we can read the bytes of the prop subfile as base-16 hex values, and the structure of the prop subfile is given in the SC4D wiki. (Note that DWORDs are four bytes large, WORDs are two bytes, and BYTEs are one.)
      Here's what the corrupted prop entry looks like in the hex editor:

      And here's what this looks like when filling it into the prop structure given on the SC4D wiki:
      DWORD Size: 0x00000058 DWORD CRC: 0x006C2462 DWORD Memory: 0x4CE00000 ??? : 0x59E6 ??? : 0xA084 ??? : 0x0F06 WORD Major: 0x0006 WORD Minor: 0x0004 WORD Zot: 0x0000 BYTE Unknown: 0x00 BYTE Appearance: 0x04 DWORD : 0xA823821E BYTE Min Tract X : 0x42 BYTE Min Tract Z : 0x6E BYTE Max Tract X: 0x42 BYTE Max Tract Z: 0x6E WORD X Tract Size: 0x0002 WORD Z Tract Size: 0x0002 DWORD Property Ct.: 0x00000001 SGPROP #1 DWORD Property Name: 0x89A1C16C DWORD Property Name: 0x89A1C16C DWORD : 0x00000000 BYTE Data Type: 0x03 BYTE Key Type: 0x00 WORD: 0x0000 DWORD Rep Count: 0x00000000 DWORD GID: 0xC977C536 DWORD TID: 0x6534284A DWORD IID Exemplar: 0x29000000 DWORD IID Given: 0x29000000 FLOAT32 Min X: 0x4308558C FLOAT32 Min Y: 0x43870000 FLOAT32 Min Z: 0x45386FA3 FLOAT32 Max X: 0x430A558C FLOAT32 Max Y: 0x43880000 FLOAT32 Max Z: 0x45389FA3 BYTE Orientation: 0x03 BYTE State: 0x00 BYTE Start Time: 0x00 BYTE Stop Time: 0x00 BYTE Count: 0x00 BYTE Rand. Chance: 0x64 BYTE Lot Type: 0x02 DWORD Object ID: 0x2A46EEFF BYTE Conditional: 0x00 Immediately something is wrong: there are six extra bytes after the first three pieces of data that don't correspond to anything in the prop file structure. Moreover, this entry gives its size as 0x58 (88) bytes but the hex editor says this is 0x72 (114) bytes in it. Where are the extra 26 bytes coming from? Well, first we can discount the seemingly random six bytes that appeared at the top. Next we can scrutinize the SGPROP since that's only an optional part of the prop subfile, and sure enough four DWORDs (16 bytes), a WORD (2 bytes) and two bytes add up to 20.
      And just out of curiosity, let's see what exemplar IID 0x29000000 maps to:

      Sure enough, it's a redefined residential beach umbrella exemplar from SimPEG's BDK resources. The main change in PEG's exemplar is that the Nighttime State Change entry (one byte large) in the Maxis exemplar was replaced by a Prop Time of Day entry (two Float32s, or eight bytes large). This is similar to what RippleJet observed when testing this.
      Because this prop entry is corrupted, closing this save and loading it will cause the game to believe that the entry really is only 88 bytes long, it will read several garbage values in the process, and after 88 bytes have been read it will attempt to read what it thinks is another prop entry. That prop entry will have a nonsensical size entry because it's being misinterpreted due to the corruption of the save, and that prop and all props that follow it in the savefile will not be present.
      As for why savefiles tend to continuously shrink on every save:
      When loading a file with corrupted props, incorrect size data and other malformed information will cause the corrupted prop and all props that follow it in the file to be misread. These misread props are discarded by the game, causing them to disappear from the city. Since the malformed props were discarded when loading, they will not appear when saving again, causing the filesize to shrink. On this new save, however, other malformed props could corrupt the savefile again, repeating the process. Towards a vaccine
      It's worth pointing out that bap originally speculated that prop pox was caused by a buffer overflow or some kind of memory error in the game that caused data for a modded prop to spill past the end of its buffer in memory. To test this, I installed the game on Fedora Linux 26 using WINE 3.0-rc6 and ran it under Valgrind, a memory debugging tool for Linux. However, I found no difference in the number of memory errors reported before and after installing PEG's beach resources.
      Since some reported instances of prop pox involve parts of the prop subfile being overwritten, we have to look at how the game actually writes data to disk. Since other prop poxxed cities appear to have prop definitions overwriting the middle of other prop definitions, it's possible that the game is incorrectly properly calculating where it should be writing when dealing with these overridden exemplars. Unfortunately this is where things go off the rails: in order to better determine what's going on in this process, I rewrote the function responsible for writing savegame objects, and this link shows what that looks like. Since the Mac version of the game contains the debugging symbols for this to work, I've only tested this on my Mac, and porting this to Windows is nontrivial.
      In another insane twist, I can't reproduce prop pox using my rewritten Mac serialization code, and can reproduce it immediately when not injecting that code, but I can't confidently say I fixed it since I can't demonstrate this to very many people without a usable Windows DLL, so that's my project for the time being. I also have no idea why my code doesn't cause prop pox to occur since I tried to recreate the original implementation of savegame serialization as closely as possible.
      For now, I'd speculate that prop pox is caused by a quirk in how the game saves records. Since the game may not know the size of all records in advance when saving a game, it has to resort to rewinding and fast-forwarding to arbitrary offsets in order to save data. For instance, when saving a prop record, the game will:
      Write the number 0 as a placeholder for the size in bytes. Write the number 0 as a placeholder for the CRC checksum. Write an identifier and the record itself. Rewind to the first zero. Calculate and rewrite the size based on how many more bytes there are in the file after writing the record. Fast-forward to the record itself and read the data in it back to a buffer. Rewind to the second zero and calculate and write the CRC checksum. Fast-forward to the end of the output stream to allow more data to be written. I think that miscalculated offsets when rewinding and fast-forwarding is causing previously written prop records to be overwritten by malformed props, corrupting the entire subfile in the process. How exactly does that relate to the redefinition of the prop exemplar?
      I'm working on getting my serialization code ported to Windows ASAP to see what happens there. In the meantime, if you have a Mac and want to try it out and report if you're still seeing prop pox:
      Grab this dylib which was built from the source code linked above (and again here). Go to Utilities in Finder and open up a terminal. I used Steam, so I used these commands: cd "$HOME/Library/Application Support/Steam/steamapps/common/SimCity 4 Deluxe/SimCity 4 Deluxe Edition.app/Contents/MacOS" echo 24780 > steam_appid.txt DYLD_INSERT_LIBRARIES="$HOME/Downloads/libinjector.dylib" ./Sim\ City\ 4\ Deluxe\ Editionsub Your game should now be running with some output labeled COMSerialize, particularly when saving the game. And if you want to help me out, just send me PMs with prop poxxed savegames for me to download so I can look at them.
    • By Tyberius06
      1. So I ran into a little problem after a longer hiatus from the game. I started to change a coulple of lot which were redone during the last couple of months, when I so the phenomena on the first picture. The diagonal roads which has any plopped item next to it reverts US style double yellow line road instead of the white dashed  european stlye, which is my NAM setting. The funny thing is, that the zones are not affecting to the road, only the plopables. My question is: could it be a NAM issue OR maybe one of @rsc204 or @rivit mod does this. I'm using NAM 36 with rsc/mgb204's No Grass NAM (NGN), with the Side Walk NAM 1.0 PSS (SWN) and rivit's Tarsealed Streets and the latest RUM for RRW v5. I used the same mods before NAM36 and I didn't experience any problem like this.
      2. I ran into this problem now I think the 2nd or 3rd times (first was sometimes end of summer, than today now 2 times.) I have a back-up from 8th october, and I didn't have any problem with that save file, however when I started to play and saved the city and quit, I don't know what happened, but the SC4 Save says I have Prop Pox. It used to come out (with a different map) when my save file reached the 12-ish MB, but now my save file is 43,2 MB and when I save the city it drops back to 42 MB, and the props from the right side of the map are completely wiped out. I brought back the file from the back up and import it into the map replacing the "damaged" file, but after little modification and saving the city I got the same result. It can't be the typical Prop Pox, since I don't have the BDK kit, and never was non of my cities, since I started to play with this map, and I don't remember I've ever met with this offset buffer error, but I don't really remeber either what is the standard prop pox error message. And the funny thing, that I don't have disabled props... So what the...?
      Any help or advise would be appreciated! 
      Thanks in advance!
      - Tyberius
    • By rsc204
      I've just come across a post by @Reddonquixote over on SC4D, it would appear our problems with using BAT4Max on newer 3DS max releases are over. In one of the scripts is a reference to a function that was removed entirely from 3DS Max, it would appear that trying to call this function was causing the scripts to fail on newer 3DS Max releases.
      Now of course right now, this isn't hugely tested so I don't want to jump the gun, but it seems if 3DS 2017 works with this fix, then it should work for earlier affected versions, am I right in saying that's 2016, possibly 2015 too?
      Anyhow, all credit obviously goes to RDQ for finding this problem, but rather than everyone edit their scripts. I've made a patched file you can simply use to replace the one with the faulty reference (attached).
      Instructions (Readme included with fix also):
      Download/Install BAT4Max as usual Find the install location for the scripts included with BAT4Max
      Default = 3DS MAX INSTALL DIR\gamepacks\BAT\scripts Copy the included SF_LtbL_functions.ms file, overwriting the original
      Remember to backup the original (just in case), by copying/moving it elsewhere outside of the 3DS Max install path Lastly, if you've not already don't so, don't forget to also get the Gamma Fix for 3DS Max from here too: Disclaimer: I personally use 3DS Max 2011, so have no way of testing this fix. But it can't cause any harm, it either works or it doesn't. Worst case scenario, restore the original file and you are back to square one (i.e. it still doesn't work).
      Lastly, please can those who might make use of the patch confirm if it works and which version of 3DS Max they've applied the fix too. This will help greatly with troubleshooting the issue for other users and helping ensure 3DS Max can be used for batting models into the future.

Thank You for the Continued Support!

Simtropolis relies mainly on member donations to continue operating. Without your support, we just would not be able to be entering our 15th year online!  You've really help make this a great community.

But we still need your support to stay online. If you're able to, please consider a donation to help us stay up and running, so that we can help keep bringing SimCity players together to share our creations.

Make a Donation, Get a Gift!

Expand your city with the best from the Simtropolis Echange.
Make a donation and get one or all three discs today!


By way of a "Thank You" gift, we'd like to send you our STEX Collector's DVD. It's some of the best buildings, lots, maps and mods collected for you over the years. Check out the STEX Collections for more info.

Each donation helps keep Simtropolis online, open and free!

Thank you for reading and enjoy the site!

More About STEX Collections