Prop Pox and macOS

[Girafarig 1,379]

You know it, I know it, we all know it: Prop Pox. It can strike seemingly at random, and when it hits, it devastates your cities, turning them into flat expanses of nothing.

Windows users have had the SC4Fix for a while now, which gets rid of it with very little hassle. However, Macs don't seem so lucky for a number of factors:

1. Macs can't run DLLs —SC4Fix being one—, at least not natively.
2. Mac 64-bit savegames cannot be handled by Windows's 32-bit version.
3. While many people have reported the game to run with nary a hitch using WINE, as of Tahoe 26.2 (and an entire afternoon of my trying), it doesn't seem to be the case anymore.

I'll figure out some way of running the Windows version of the game at a later date (probably around NAM 50), and in the meantime I can use my wife's computer for a quick SC4 opening. But if the Windows version can't open Mac savegames, what solution is there to the dread Prop Pox? I really don't feel like nuking my cities again, so I'd appreciate any help. 

EDIT: I'm happy to report repeated but partial success by using the instructions copied at the SC4Fix download page, which seem to work despite the inability of the rest of the fix to work. I'll leave this thread nonetheless because I can't be the only one constantly running into this issue:

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.

 

[rsc204 21,808]

On 23/01/2026 at 12:54 AM, Girafarig said:

But if the Windows version can't open Mac savegames, what solution is there to the dread Prop Pox?

In fairness these two things have nothing to do with each other, one on hand you can never use a save file once it's been saved using the 64-bit version, with any other version of SC4. But on the other, using the native Mac game means you can not rely on the SC4Fix.DLL to prevent the problem from occurring.

In reality most people simply should not find themselves affected by Prop Pox, as an issue it has always been over-blown, granted because IF it happened it was pretty catastrophic. But it's nowhere near as common a problem as it has been made out to be, there were a lot of politics surrounding it and it was weaponised by some. Shit if I typed that sentence 10 years ago, I'd probably be insta-banned for having done so, which only serves to illustrate my point really. Many people also mistook other problems for Prop Pox and I would go so far as to say, many other instances of data corruption all got lumped in as Prop Pox, amplifying it.

In theory, provided you aren't using content in your Plugins that trigger the issue, then you should not suffer Prop Pox. The one file that was identified to trigger it has long since been updated on the STEX, so make sure you aren't using an older copy of PEG's Beach Development Kit. Of course, it's not really that simple and based on years of posts and feedback, it is very clear that others have managed to get Prop Pox, without having any known 'trigger' files installed. I've always maintained something else is at work, but no credible efforts were made to look into it and in my view, a large part of why is that it suited some to pin the blame on the Pegasus team. I'm not gonna dredge that up again here, but the Prop Pox thread on SC4D is a wonderfully boring read if you want to go through it yourself.

What I can say is that the DLL absolutely seems able to both prevent and fix the issue, should it arise. But that's never going to be an option for Mac users, so either run the Windows game or accept this is one of those things you can't control. Logically, there must be other files out there that trigger the problem, because folks who never had the BDK got Prop Pox, multiple such instances have come to light. But because it was never determined what other files might be a problem, you can't know what to avoid. Personally, I also feel the nature of SC4's method of saving is prone to the potential for problems, ultimately it's data corruption and it seems unlikely to me that this is somehow inherent to one specific property being altered. What SC4Fix does is alter the way the save data is created, avoiding certain ways that could corrupt your data.

Frankly speaking there really isn't a 100% foolproof way to protect yourself against the problem unless you use the DLL, which for the Native Mac port simply is never going to be an option.

[Girafarig 1,379]

55 minutes ago, rsc204 said:

In theory, provided you aren't using content in your Plugins that trigger the issue, then you should not suffer Prop Pox. The one file that was identified to trigger it has long since been updated on the STEX, so make sure you aren't using an older copy of PEG's Beach Development Kit. Of course, it's not really that simple and based on years of posts and feedback, it is very clear that others have managed to get Prop Pox, without having any known 'trigger' files installed. I've always maintained something else is at work, but no credible efforts were made to look into it and in my view, a large part of why is that it suited some to pin the blame on the Pegasus team. I'm not gonna dredge that up again here, but the Prop Pox thread on SC4D is a wonderfully boring read if you want to go through it yourself.

Uuuuh it has happened two or three times to me already, and the issue is not the Peg Beach Development Kit.

So far it has always happened (to me) in cities that:

1. Have lots of agriculture
2. Get certain lots that sometimes cause Prop Pox, but not consistently enough to raise fingers.
3. Maybe or maybe not, in cities with a certain street style.

Here's an example of right now, of a city that I formerly had obliterated and restarted —and now is poxed again:

And while there's a great comfort in knowing I can bring the city back to playability, it would be great to have a more permanent solution like that offered (I think?) by the SC4DDL, mostly because I don't feel like opening the game three times to get this back:

Also —I forgot to take screenshots of it, but it's fascinating seeing how the savefile size goes down when poxed and then shoots back up after the two-save method.

[rsc204 21,808]

On 25/01/2026 at 3:16 PM, Girafarig said:

Uuuuh it has happened two or three times to me already, and the issue is not the Peg Beach Development Kit.

Hence I used the qualifier, 'In Theory', because the general consensus for years was this was the only problem, but that simply doesn't fit with the facts we know.

On 25/01/2026 at 3:16 PM, Girafarig said:

Uuuuh it has happened two or three times to me already, and the issue is not the Peg Beach Development Kit.

So far it has always happened (to me) in cities that:

1. Have lots of agriculture
2. Get certain lots that sometimes cause Prop Pox, but not consistently enough to raise fingers.
3. Maybe or maybe not, in cities with a certain street style.

Here's an example of right now, of a city that I formerly had obliterated and restarted —and now is poxed again:

See when you say always, first thing that pops into my head is, you don't have Prop Pox, you do have a problem, but it's not specifically Prop Pox. Again, every time someone comes across corruption, the first culprit is Prop Pox, but often that's simply a misdiagnosis and when you make assumptions...

File corruption is not fixable, you might remove the corrupted data and somehow reformat it such that new data can not be corrupted again, but there is no way to fix the broken parts. Imagine you've a 3m MP3 file and 2% of it has gone bad, whatever you do that 2% is gone forever. How can a computer put that data back together if it doesn't know what sequence of 0's and 1's are needed to do it?

So if you obliterate a city, rather than create a new one, the latter of which actually creates a brand new save file, I suspect that might be your error. The corruption remains in the save file and so it keeps coming back eventually.

Not one of the three things you list has ever been connected with Prop Pox, ergo you probably don't have that and troubleshooting the wrong fix ain't gonna help you. I can show you large cities full of farms, nothing about that is an issue for the game. Certain lots may be affected by your problem, but that's not in any way connected to the cause. Heck, even with the BDK it isn't Lots causing the problem, it's Props from a dependency file. As for street styles, that's just a texture change, literally couldn't be less connected with the problem you are having.

On 25/01/2026 at 3:16 PM, Girafarig said:

And while there's a great comfort in knowing I can bring the city back to playability, it would be great to have a more permanent solution like that offered (I think?) by the SC4DDL, mostly because I don't feel like opening the game three times to get this back:

Also —I forgot to take screenshots of it, but it's fascinating seeing how the savefile size goes down when poxed and then shoots back up after the two-save method.

Right but you are playing whack a mole, which should tell you your efforts in the long run are futile. If my car had the same consistent fault that no matter how many times I had fixed it, kept going wrong, I'd replace my car. In the same way, I think you might need to accept this city is toast and move on.

The save file size changes because you are forcing it to switch between a compressed and uncompressed sate, the latter of course would be larger by its nature. But you aren't fixing anything, you are just shuffling the data and setting yourself up for the next time the data gets compressed and things inevitably go wrong again.

What is behind all this?, couldn't tell you, it would take a ridiculous amount of investigation to find the root cause. What I can tell you is that this save file is toast and you should start over. If this issue happens with multiple cities/save files, yeah that sucks I know.

It doesn't matter that a DLL solution exists, if you are using the 64-bit Mac version you simply will NEVER be able to use it. Blame Apple, in the name of security it is not possible to side-load code under MacOS from Catalina onwards. So, either Aspyr have to adopt and validate said DLL and incorporate it officially as signed code or Apple have to reverse course on security in MacOS. Since no pigs are flying around, you might have a long wait for either of those things to happen.

[Girafarig 1,379]

I had a pretty long answer with quotes and all, but the forum decided not to publish it (for whatever reason —I'm clearly not having a good day with tech—) so I'll just give you the summary:

1. I'm basing a lot of what I say on what I've seen in this thread:

In there you'll find some theories about filesize and prop pox triggering, as well as some people posting fixes that look an awful lot like what I've seen (up to and including not every lot getting fixed).

2. I feel like a lot of your arguments are based on semantics, like this can't be Prop Pox because it doesn't come from the Proppeaux valley in France and must be just Sparkling File Corruption or something. I don't feel like those arguments are helpful.

3. If there's no way to apply the SC4Fix to macos (which I agree with), but if I can solve this issue in a similar way as suggested by it *and* the macos SC4 file deals with memory in a different way, what with being 64-bit and all that — don't you think that warrants a bit more research?

And if you don't think that, with all due respect: what are you doing in this thread? Like, what's your end goal here? Because "it's not pox and you can't do anything anyway" is not a helpful answer at all.

[Ulisse Wolf 4,412]

On 27/01/2026 at 4:13 PM, Girafarig said:

3. If there's no way to apply the SC4Fix to macos (which I agree with), but if I can solve this issue in a similar way as suggested by it *and* the macos SC4 file deals with memory in a different way, what with being 64-bit and all that — don't you think that warrants a bit more research?

There is actually a solution for playing SimCity 4 (Windows digital version) on Mac, allowing you to obtain the functioning DLL Mods...

And honestly, it's pointless to find creative solutions for a version of SC4 that is in the terminal phase of support.

[Girafarig 1,379]

7 hours ago, Ulisse Wolf said:

There is actually a solution for playing SimCity 4 (Windows digital version) on Mac, allowing you to obtain the functioning DLL Mods...

 

As of macos Tahoe (26.2), that solution doesn't work. Trust me — I spent an entire afternoon trying, and I'm usually pretty good with WINE.

[rsc204 21,808]

On 27/01/2026 at 4:13 PM, Girafarig said:

2. I feel like a lot of your arguments are based on semantics, like this can't be Prop Pox because it doesn't come from the Proppeaux valley in France and must be just Sparkling File Corruption or something. I don't feel like those arguments are helpful.

If you misdiagnose a problem, then you are likely to misdiagnose the solution too, I feel you have misunderstood my intent here. Clearly it would appear you are dealing with save file corruption, but is that caused by Prop Pox?, there is a chance it isn't, the point I was trying to make is that file corruption, however it manifested ultimately leads to the same result.

But the method used to at least prevent this problem reoccurring, would differ based on what is triggering the problem, hence there are important distinctions to consider. I'm not saying it can't be Prop Pox, I'm saying that the only known file to be identified that caused it was the BDK dependency file, since you do not have this, there is only 1 other way that you can verify if the problem is or isn't Prop Pox. You'd need to identify whether any of the Mods you have installed are overriding existing props that are RKT1 based, but having switched to RKT4 props in the process.

Spoiler

The cause of Prop Pox was diagnosed as this, because the # of Reps of data increases, this is how a save file is 'triggered', such that the possibility of file corruption exists. Each save file in it's uncompressed (original) state, now has for the sake of simplicity, data written in a table something like this:

1. Type (i.e.Prop), data, XPos, YPos, ZPos, Rep1, Rep2, Rep3
2. Type (i.e.Prop), data, XPos, YPos, ZPos, Rep1, Rep2, Rep3
3. Type (i.e.Prop), data, XPos, YPos, ZPos, Rep1, Rep2, Rep3

So each line in reality looks very different, but the data is written such that the type is defined, for example it's a Prop, where it is placed in the game world (coordinates), then Rep1, Rep2, Rep3 specifically would be the Type, Group and Instance ID of the linked model. Now, let's imagine the Prop from this example has been overriden to an RKT4 one, how might that alter the data in the save file?:

1. Type (i.e.Prop), data, XPos, YPos, ZPos, Rep1, Rep2, Rep3
2. Type (i.e.Prop), data, XPos, YPos, ZPos, Rep1, Rep2, Rep3, Rep4, Rep5, Rep6, Rep7
3. Type (i.e.Prop), data, XPos, YPos, ZPos, Rep1, Rep2, Rep3

Note, these examples look nothing like the real thing, which is more complex and contains much more data, it's stored in an array and that must be defined in a manner that an expected number of Reps, or units of data can exist. So imagine you've eight cardbord boxes, each 100cm wide, then you have a shelf which is 800cm wide, you can fit exactly eight boxes on it. If we increase the number of boxes to twelve, now there would be two on each side that were not on the shelf, again to suit the analogy, lets say all four additional boxes are to the right of the shelf and the left side of the shelf is against a wall or something. This is essentially what has happened to the data when the RKT type was altered, but more specifically the number of Reps of data (boxes) was increased. It's not longer in the expected array (doesn't fit on the shelf), which provided there is 400cm of space to the right of the shelf, isn't really a problem. When a save file reaches the threshold for conversion to a compressed file, it expects a specific number of reps in every line, an array (multiple shelves of the same width, stacked vertically, only we can pretty much make it as high was we want).

Again, I am greatly simplifying these concepts, because I don't know what level of knowledge those reading this post will have. But hopefully I could put it into terms that allow a layman to visualise things to some extent.

So the RKT type changed from 1 to 4, we have more boxes, now consider the save file compression adding a partition wall to the right of the shelf, such that there was no longer space for the four additional boxes (reps of data) on each shelf (line of data), what happens? Well, the data gets written a bit like this:

1. Type (i.e.Prop), data, XPos, YPos, ZPos, Rep1, Rep2, Rep3
2. Type (i.e.Prop), data,, XPos, YPos, ZPos, Rep1, Rep2, Rep3
3. Rep4, Rep5, Rep6, Rep7
4. Type (i.e.Prop), data, XPos,YPos, ZPos, Rep1, Rep2, Rep3

So the shelves are labelled with a sticker under each box, denoting what was in them and in my example we have three shelves vertically, (a 3x8 array). Since the stickers are based on being able to fit eight boxes horizontally and three shelves vertically, when the boxes were reorganised due to the new wall, it was necessary to find a place to put the additional four boxes that can no longer sit next to it. So roughly speaking the four additional boxes were to the right of the middle shelf here, therefore they have been moved to the 3rd shelf (line of data), but only take up half of it. Because computer shelves are magic, we've now got an additional shelf (line 4) which happily appeared so we can store the boxes that used to be on the 3rd shelf. But, the original labels are still in their original places, now things have gotten disorganised or are in the wrong place. This is effectively Prop Pox in a nutshell, the extremely specific trigger creates additional data that gets written to the wrong part of the file. As more data in added, more of it ends up overwriting the data in the wrong place because the computer isn't expecting those shelves to be occupied.

So whilst Prop Pox is quite incredibly specific, what I'm trying to say is that the symptoms you have do seem reminiscent of Prop Pox, but not a single confirmed mod has exhibited the specific alterations in the god knows how many years since this issue came to light. What this means practically speaking is not that your problem can't be Prop Pox, but I have long suspected that Prop Pox should just be more generalised as File Corruption, but what matters here though, was it an RKT change that triggered your file corruption?

However once more and I assure you I'm not trying to be blasié, it doesn't matter, because there is no way to fix such a corrupted file once it has the trigger, there is data in the wrong place. Only it doesn't start causing data to be incorrectly written unless the save file grows such that it hits the threshold where the game compresses the data.

So what if it's not an RKT change behind this, which to me seems to be more likely, well that's a problem too because now it could be anything so we don't even know what to look for. However, since most users aren't able to look at their entire Plugins suite and check for RKT1 Props that have been overridden in this manner, it's quite possible that is the case, but how can we help you to locate the potential cause?

On 27/01/2026 at 4:13 PM, Girafarig said:

3. If there's no way to apply the SC4Fix to macos (which I agree with), but if I can solve this issue in a similar way as suggested by it *and* the macos SC4 file deals with memory in a different way, what with being 64-bit and all that — don't you think that warrants a bit more research?

No, because whether it is Prop Pox or isn't Prop Pox doesn't matter, it's all just semantics, since regardless of which it was, you are unable to take advantage of the only known fix for the problem, which is SC4Fix.DLL.

The solutions noted in the thread you linked do not apply to you and that's because the .DLL is necessary to provide a permanent fix, since it alters the format of the save data in such a way that no additional file corruption can occur. Which conversely also means that it prevents said corruption if it was installed before any corruption would have otherwise occurred.

I have personal experience here, I triggered file corruption that absolutely was not Prop Pox, simply by adding too many new Props into the save file in one go, rather than saving in chucks, overwhelming the save file. At least that's the best explanation I can give for everything that was going on, but that's not important, what is, having SC4Fix.DLL prevented that same corruption from happening, allowing me to continue using my otherwise damaged save file.

Does your problem warrant research?, well yeah if you were able to work out the specific cause of your corruption, yes. So if you can check for the RKT mismatch (Prop Pox), maybe you find a file no one else knows about that could trigger Prop Pox. But otherwise, I can't even give you anywhere to look or what to look for, it would be pure guesswork. The only reason I can tell you how I did it, was because I was messing around with modding and could de-construct things and use an unaffected backup and do a ton of experiments to make sense of what had happened. Motivated in no small part by my desire to make a fully seasonal T21 mod with random trees and because we can not safely override RKT1 with RKT4 props, the specific cause of Prop Pox, I had to find another way to approach it.

What I'm saying is, here's the most complete description of the problem I can give you, if you understand that and the limitations of what can be done, then this will greatly help you to look into the problem further. But if you are looking for an answer that involves what file do I have installed that causes Prop Pox (or file corruption in the manner shown)?, then the only answers anyone can give you are, do you have the BDK file, or this is the cause (trigger) scan your entire plugins for anything that might do this. 

What I can not do, is go through your specific Plugins folder looking for the cause, I can only lead this horse to the water. Off the top of my head too, I do not know of some automated method to do this, only sifting through a ton of data and ruling every file out to narrow it down. Which even if you could and would do that, should you find that no such RKT changes were present, there is no other specific criteria anyone can give you beyond that.

On 27/01/2026 at 4:13 PM, Girafarig said:

And if you don't think that, with all due respect: what are you doing in this thread? Like, what's your end goal here? Because "it's not pox and you can't do anything anyway" is not a helpful answer at all.

I feel you've failed to take into account the whole when coming to this conclusion, that's certainly not what I was trying to convey explicitly, but whether you like it or not I can't really summarise it otherwise. With the exception of adding (as I've attempted to today), how you might find the root cause, limitations in that regards notwithstanding.

[Lab Rat 13]

Automated Notice Message

All posts after 1 March, 2026 @ 01:37 GMT were lost in the site crash.

We've added this message thread divider in every topic across all forums for what were then active threads. (We decided active is if the most recent extant post (from the backup) was on or after 1 January, 2026.)

This divider serves as notice that the conversation was interrupted. Answers and further discussion which used to be here have been lost. Keep this in mind when replying. Our hope is to rebuild what is missing.