Jump to content

SC4Fix: third-party patches for SC4 1.0.7

   (32 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

Recommended Comments

6 hours ago, FOSC tule00 said:

Doesn't seem to work. It says my version is unpatched, even after I patched it. I have a retail copy.

Can you go to your SC4 installation directory, go into the Apps folder and check the properties for SimCity 4.exe? Some people have reported this happening, but the game may have patched your DAT files and reported an error patching the EXE itself.

Share this comment

Link to comment
Share on other sites
13 hours ago, simmaster07 said:

Can you go to your SC4 installation directory, go into the Apps folder and check the properties for SimCity 4.exe? Some people have reported this happening, but the game may have patched your DAT files and reported an error patching the EXE itself.

I checked and it's still on version 638. Is there a way to fix this?

Share this comment

Link to comment
Share on other sites

@FOSC tule00 I'd make sure you're using update 640, since it isn't a patch that's really promoted by Maxis. Should be the "Sim City 4 Buildings Update" on this page.

If you already tried that, it means the patcher doesn't see an exact match between the game EXE and its own list of accepted EXEs. You might need to reinstall from a retail copy. If you still have your CD key, you could also try redeeming a Steam copy.

Share this comment

Link to comment
Share on other sites

Your instructions say to put the unzipped DLL into my user plugins, but my habit is to put all DLL plugins into the program files plugins (C:\Program Files\EA\SC4\Plugins). Among other things, I suspect that DLLs must be kept in the root of a plugins folder; I do a lot of DAT-packing and do not want them to be caught up in any of those sweeps and bundled into a dat file.

I also want them loaded even when I rename my user plugin folder for testing some mod in "isolation" (where isolation still includes some essential elements kept in the program files plugin folder).

Are there any other reasons to prefer one over the other?

PS: Putting the DLL in the program files plugin folder produces the "SC4Fix r7" title.

Share this comment

Link to comment
Share on other sites

@jeffryfisher DLL files can be placed in any plugins folder just like any other plugin. If you rename your user plugin folder often that'd be a reason to prefer placing the DLL in the Program Files plugin folder, but otherwise there's no difference. I've tested the DLL in the Documents plugin folder and that's also worked fine.

Share this comment

Link to comment
Share on other sites

Now my problem is - you can only one time say "thank you", you can only one time rate it five stars. But while it's been updated I could do this a dozend times. First you eliminated one of the most disturbing bugs of SC4. Now you took away one of the biggest fears. How fortunated I was, you stepped in this community. I mean, you choose this game to make it a stable thing, even when voluminously modded. There must be a trillion games out there that could need your help.

But you choose the game I love most. I think I'll always will feel like a darling of fortune because of you.


Share this comment

Link to comment
Share on other sites

Create an account or sign in to comment

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

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

  • STEX Featured

  • Newest STEX Uploads

  • Similar Content

    • 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.
    • By JurisicSantiago
      Hello fellas!
      I am starting this topic because I've got an issue while trying to patch my digital copy of SC4, bought via Origin Games platform. A few years ago I managed to patch my game correctly, but now it seems impossible.
      My SC4 version is 1.1.610.0, but I can't apply the 1.1.638.0 version I need to start using mods again (I formatted my PC some time ago and I didn't reinstall the game until today).
      Is there someone who's experienced the same problem?? Please let me know if you found a solution.
    • By nRVOUS
      its only in one tile so should I wipe It and just move on to another region or do more? So far i deleted all my peg lots since they seem to be considered a problem so should I do anything else?

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