Revisiting Prop Pox and Prop Theory

[simmaster07 1,221]

Update 2018/01/21
SC4Fix has been updated with a stable build that fixes prop pox. Download on the STEX:

---

On 11/01/2018 at 8:51 PM, twalsh102 said:

Don't forget that this is a community where even nine years after the fact, only one person has ever bothered to re-run the experiments performed by bap on Prop Pox.  No one else has bothered to re-run his experiments, or devise new experiments to confirm or deny his results.  Many have offered other hypothesis as to what causes Prop Pox, but few, if any, have actually bothered to experiment to even try and validate their hypothesis.

I like a good challenge, so I decided to take this one up.

Context
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:

1. In a normal game installation with absolutely no plugins, prop pox will never occur, even after updating.
2. Prop pox is actually caused by plugins that redefine Maxis prop exemplars that add properties that were not originally in the exemplars.
3. 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:

1. 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.
2. These misread props are discarded by the game, causing them to disappear from the city.
3. Since the malformed props were discarded when loading, they will not appear when saving again, causing the filesize to shrink.
4. 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:

1. Write the number 0 as a placeholder for the size in bytes.
2. Write the number 0 as a placeholder for the CRC checksum.
3. Write an identifier and the record itself.
4. Rewind to the first zero.
5. Calculate and rewrite the size based on how many more bytes there are in the file after writing the record.
6. Fast-forward to the record itself and read the data in it back to a buffer.
7. Rewind to the second zero and calculate and write the CRC checksum.
8. 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:

1. Grab this dylib which was built from the source code linked above (and again here).
2. Go to Utilities in Finder and open up a terminal.
3. I used Steam, so I used these commands:
   1. cd "$HOME/Library/Application Support/Steam/steamapps/common/SimCity 4 Deluxe/SimCity 4 Deluxe Edition.app/Contents/MacOS"
   2. echo 24780 > steam_appid.txt
   3. DYLD_INSERT_LIBRARIES="$HOME/Downloads/libinjector.dylib" ./Sim\ City\ 4\ Deluxe\ Editionsub
4. 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.

[Handyman 791]

Very interesting, well done. Hopefully this leads to a cure.

[T Wrecks 10,210]

Wow. Not only did you rehash the entire prop pox theory making it very easy to follow, but you even give us hope that the problem might be fixed? Of course it's too early to say much, but I wouldn't even have dreamt of the possibility!

I'd also like to commend you on the reconstructive part. While it was nothing new to me and I regarded the reasoning given for bap's theory  to be absolutely stringent and convincing (whereas people disputing it have never shown the slightest evidence, only rambling, accusations and wild speculation), some of that information is either somewhat elusive or hard to take in. I know it took me a lot of time and mental effort to get it all together, at least. Your post is a great tl;dr for the discussion thread on SC4D!

I'd love to give you more than one "Like" for this post, but I can't... so I hope others will join in, because that's the least you deserve. Thank you for going through all that hassle for us!

 

[mattb325 28,891]

Amazing work in getting us towards a fix for one of the remaining bug-bears of the custom content.

Like Twrecks, I'd also love to give you more than one 'like' for this....thankfully MOTM has returned for us to show our extra appreciation instead

[Tyberius06 12,267]

@simmaster07 Thanks for this revisit, amazing work indeed, finally I started to understand what is going on. My limited english and understanding the game processes still give me a lot of black hole, but at least not everything is black now...
I will send a PM with my latest Prop Pox-ish issues and the city save files. In the meantime, I have experienced prop pox-ish shymptones three times so far, and in only one case was the actuall guilty the BDK resource kit and its modified props. Second time I messed with some RTK4 properties, which I didn't understand at that time, third time (this happened last september and the a returning problem after Christmas) the somehow already damaged save file (which didn't show any singn about this) was triggered by a bunch of broken lots - there was a essential file update which accidently didn't contain the necessary prop family examplars which caused that the props disappeared from the lots, after that this essential was fixed but I started to demolish and rebuild the lots again, and that bulldozing process triggered the Prop Pox. But only in one affected city  by the broken lots, the other city thanks it's fine in a way.

But in this last two cases I didn't have the BDK kit at all installed or near to my plugin folder (and never was).

But the other question is, what is about the disabled props? It was told, that disabled prop can cause the Prop Pox too and they are hand-in-hand, but on your picture and what was my experience in the last case, there wasn't any disabled props. Also I have a city (which had the above mentioned broken lots, but bulldozing them hasn't caused any trouble) which has 4-5 disabled props, as I understand probably because once I made a huge rebuilding and redesigning project in the city and bulldozed most of the existing buildings and rezoned the half city. So how about this city, when it reach a point, because of the disabled props the Prop Pox is inevitable? Because according to the current understanding, this is the case...

- Tyberius

[CorinaMarie 29,894]

12 hours ago, simmaster07 said:

I like a good challenge, so I decided to take this one up.

Amazing. Simply amazing.

[Cyclone Boom 17,031]

A truly fascinating insight into arguably the single biggest mystery clouding SimCity 4 over the past 15 years. Existing theories can be difficult to challenge, especially when there's been so long since they were established and last discussed. But until confirmed or dismissed, any given theory can only at best be accepted as a plausible hypothesis. Research can be cumulative over a number of attempts, but it's really only until finding a proven solution where an idea is acceptable as fact.

Your findings not only provide a clear and detailed analysis of the issue, but already delve into a brand new perspective on the technicalities within. The mechanism how the save process operates, and conditions required to reproduce the bug. Since you've found it's possible to trigger from the steps described, I begin to wonder whether Prop Pox is as rare as we may have previously thought. Could it potentially be more widespread? By being able to initiate the process of corruption relatively easily, I feel it opens the door for additional testing. Perhaps there are differences between the CD and various digital versions of the game?

Right here and now, the fact there's mention of a possible cure is incredible to think. Beyond words in fact. Because up until this point, there was very little hope left. Instead just mere speculation surrounded by cluttered confusion. A case of reducing risk factors without fully understanding what the risks are. What you've done here is turned a faint glimmer into a brighter radiant light. Whichever way and whatever may happen next, unbelievably you've given us renewed hope.

For that the entire SC4 community (already) couldn't be more thankful for your efforts.

I've featured this topic and shall be following it with great interest...

[jeffryfisher 2,176]

9 hours ago, T Wrecks said:

I'd love to give you more than one "Like" for this post

And if a vaccine DLL emerges, nominate him for yet another breakthrough medal 

[Scarton 57]

Excellent analysis. Thank you for running additional experiments concerning this issue.   Unfortunately I don't have a prop pox infected savegame to send you for further analysis.

[Jasoncw 11,949]

Thank you.  

[jdenm8 362]

Been a very long time since I last thought about this over here.

Might as well dump my old second-hand knowledge (which was probably simplified in the threads I read for expediency) so don't know if it's 100% accurate. You probably already know it all.

The 6MB limit for compressed subfiles was chosen not for performance reasons, but because that's all that the compression algorithm (QFS) can do. It can't compress a file larger than around 6MB.

I think I read that there is a significant byte at the end of each entry in the prop subfile. A kind of 'End of File' marker. SC4 is obviously capable of finding this significant byte since it reads malformed entries correctly when the subfile is compressed. Either it doesn't look for the significant byte when reading an uncompressed entry or it discards it as part of the conversion from compressed to decompressed.

I recall it being observed that SC4 only ever creates prop entries of one of two lengths. I don't remember what the lengths were, but the game used the wrong one (IIRC, the shorter when it should have used the longer) on these malformed entries. In theory, scanning an infected savefile for mismatching lengths and correcting them should repair the subfile (or at least make it load correctly) provided the subfile's not been saved over with an irreparably malformed one.
The corruption definitely only occurs on load. All of the entries following the bad one are intact and present after conversion.

Thanks for looking into this again, it'd be great to finally have it fixed.

[Flat Raver 59]

Is it possible there's a Texture Pox, as well?

[jdenm8 362]

In theory it could happen to any type of subfile stored in the savefile, that stores overrideable objects, at decompression time.

Would it happen in practice? I don't know. It largely depends on the subfile structure and how the game loads it. It was assumed some time ago that the Flora subfile (That stores Flora objects on lots) would likely also be susceptible to this bug. Since nobody has really ever done anything with Lot Flora (Pretty much every flora pack (trees, shrubs, flowers, etc) I know of adds flora as props instead of as Lot Flora), it was considered dismissable.

[CoastRunner 24]

Amazing, kudos to you dude.  Prop pox has plagued us for so long, it's hard to wrap my head around that there might be a breakthrough here

[T Wrecks 10,210]

3 hours ago, Flat Raver said:

Is it possible there's a Texture Pox, as well?

Good question, but I honestly doubt that. Props are basically lot objects that refer to a pre-rendered model, which is identified by a "Resource Key Type n" property, where n can have different values for static props or props that appear/disappear over time. Depending on this, the "Resource Key Type" property has different lengths (timed props require more information!), and confusion with lengths causes this save file corruption.

Textures, however, don't have such a property AFAIK. Therefore, I don't think they are susceptible to the problem that is at the root of prop pox. The texture itself is identified by an instance ID (IID) that is a static, 8-digit hexadecimal value. Other parameters such as orientation or position on the lot are stored in the lot file. Inside the lot file, each object on the lot is assigned one line that defines at what position (X/Y/Z axis, Z axis (height) being a moot point for textures) and in what orientation (N/E/S/W) that object is placed. These lines have a default number of entries, but the number of entries can vary. Since the lines are specific to each lot and don't override a conflicting Maxis default, they shouldn't be able to cause save file corruption.

Why do you ask, though? Do you experience texture problems in game? Or just curiosity?

[madhatter106 3,931]

Trying to follow along here...

Is it possible to completely avoid prop pox by not using dependencies that modify original Maxis prop exemplars?
And if that's the case, is it a matter of identifying said dependencies and either a) avoid using them, or b) modify them such that they use custom props with the intended modified properties, instead of with the original (though modified) Maxis props?  Ie., does prop pox happen with custom props, too?

[matias93 7,535]

I think that by now we should be measuring time in terms of before and after the SC4fix, don't you think? It has changed and has the ability to change so much about the game that anything else would be an understatement!

About the possibility of a texture pox, it cannot happen for the same reason you can 'hot-swap' texture replacements without having to demolish or obliterate anything. On the other hand, the need to demolish the lots using props or buildings one is about to delete from the plugins folder spans from the same issue: to avoid keeping information on the savefile which has no relation to the plugins whatsoever, to avoid file corruption.

23 minutes ago, madhatter106 said:

Is it possible to completely avoid prop pox by not using dependencies that modify original Maxis prop exemplars?

 

24 minutes ago, madhatter106 said:

does prop pox happen with custom props, too?

Prop pox ocurrs when there is a property mismatch between existing and new props, so it can happen both between Maxis' and Maxis modified props or between custom props and custom modified props (for example, a custom static car prop replaced by a timed car prop with the same ID).

In principle (and this has been the main palliative method used), you can avoid the prop by not using modified props that share their IDs with the original ones, but if Simmaster's findings are consistent, a change in the way the game saves city tiles can make those cautions irrelevant, by fixing the way the city tile file gets corrupted.

[vortext 573]

1 hour ago, matias93 said:

Prop pox ocurrs when there is a property mismatch between existing and new props, so it can happen both between Maxis' and Maxis modified props or between custom props and custom modified props (for example, a custom static car prop replaced by a timed car prop with the same ID).

 

yep I can attest to this as I induced prop pox in a region with solely custom content of my own making - so I had only myself to blame. . 

[Flat Raver 59]

8 hours ago, T Wrecks said:

Good question, but I honestly doubt that. Props are basically lot objects that refer to a pre-rendered model, which is identified by a "Resource Key Type n" property, where n can have different values for static props or props that appear/disappear over time. Depending on this, the "Resource Key Type" property has different lengths (timed props require more information!), and confusion with lengths causes this save file corruption.

Textures, however, don't have such a property AFAIK. Therefore, I don't think they are susceptible to the problem that is at the root of prop pox. The texture itself is identified by an instance ID (IID) that is a static, 8-digit hexadecimal value. Other parameters such as orientation or position on the lot are stored in the lot file. Inside the lot file, each object on the lot is assigned one line that defines at what position (X/Y/Z axis, Z axis (height) being a moot point for textures) and in what orientation (N/E/S/W) that object is placed. These lines have a default number of entries, but the number of entries can vary. Since the lines are specific to each lot and don't override a conflicting Maxis default, they shouldn't be able to cause save file corruption.

Why do you ask, though? Do you experience texture problems in game? Or just curiosity?

Because I've been experiencing industrial lots having squares that don't have any texture at all, but instead just leaves a gaping hole down to the abyss

[T Wrecks 10,210]

Ah, okay. Good thing you asked. Do you have some screenshots and/or some links to the lots in question, or at least their names and a description of what's missing?

Chances are it's as simple as a missing, broken/damaged or outdated dependency. Might take a while to figure out, but it should be able to be fixed, and the worst case is that you'll have to demolish and re-grow/plop the affected lots, but you won't have to fear the effect spreading over to other stuff and permamently corrupting anything.

[redfox85 659]

I had that exact texture issue when I loaded IRM into a pre-IRM city.

[simmaster07 1,221]

On 17/01/2018 at 8:58 PM, Tyberius06 said:

the other question is, what is about the disabled props? It was told, that disabled prop can cause the Prop Pox too and they are hand-in-hand, but on your picture and what was my experience in the last case, there wasn't any disabled props. Also I have a city (which had the above mentioned broken lots, but bulldozing them hasn't caused any trouble) which has 4-5 disabled props, as I understand probably because once I made a huge rebuilding and redesigning project in the city and bulldozed most of the existing buildings and rezoned the half city. So how about this city, when it reach a point, because of the disabled props the Prop Pox is inevitable? Because according to the current understanding, this is the case...

I don't believe that a prop being disabled intrinsically causes prop corruption, but I also can't see what in the game internals causes a prop to become disabled. At a glance the code for serializing stuff like prop entries to disk doesn't seem to change its behavior based on the visibility/enabled flags; the game might disable props if they have invalid properties, but I honestly have no clue. I'd have to look at this later.

On 17/01/2018 at 9:32 PM, Cyclone Boom said:

Since you've found it's possible to trigger from the steps described, I begin to wonder whether Prop Pox is as rare as we may have previously thought. Could it potentially be more widespread? By being able to initiate the process of corruption relatively easily, I feel it opens the door for additional testing. Perhaps there are differences between the CD and various digital versions of the game?

If prop pox is the consequence of a bug in the serializer, it might also be responsible for other savefile corruption issues. The implementation of savegame writing in the digital and CD versions of the game are definitely the same, though.

---

Anyway, an experimental DLL for Windows is done and has been rolled into a prerelease build of SC4Fix, which you can grab here. I really need to stress that even if this is shown to be a valid fix it is not ready for primetime and you should not use this on any cities you don't have backups for. One big issue is this will probably cause memory to leak when you save the game.

The reason I'm calling this out as a potential fix is because of some experimenting I did with this city:

• Test City, prop pox timebomb

Without my DLL this city will immediately show buffer corruption in wouanagaine's Savegame Explorer the first time it's loaded and saved. This behavior's been pretty consistent on both Mac and Windows. With the DLL, though, a few props are marked as disabled but the prop subfile hasn't been outright corrupted after playing and saving it for a bit. Feel free to try it out for yourself and see what happens. I think I'd actually be relieved to hear that it doesn't work because I still have absolutely no idea how my DLL is more stable than the game's normal implementation.

---

Side note: the main reason getting this done for Windows took as long as it did is that unlike the Mac port, SC4 on Windows does use EASTL, but it uses a far older version of EASTL from when Paul Pedriana was first working on it, which means that publicly available builds weren't 100% compatible, plus there are some private implementation details specific to SC4 that I can't reimplement. This means things are somewhat hacked together and the code is ugly, but it works. ¯\_(ツ)_/¯

And a fun fact on that note: I remember reading people complaining that the Mac port of SC4 runs pretty slowly. One reason why is that Aspyr didn't use EASTL, which is optimized for games with large memory requirements to run as smoothly as possible by reserving memory in large pools and reducing the number of function calls. The standard library that Aspyr used is just what shipped with their compiler and isn't purpose-built or highly optimized. I wish I knew why they did this.

[matias93 7,535]

You are my hero! I'll test it as soon as possible

[jaredh 195]

consider the possibility that the original code compile had something bogus and simply re-compiling it fixes it?

I've seen such nonsense from compilers before....back in the day.  As in the era of compilers SC4 would have been compiled on......

[Tyberius06 12,267]

@simmaster07

Oh man!!!! Sorry I couldn't send the file, lack of time of so, but I tested your attached fix, with the above described/mentioned damaged city tile of mine (with that one where if I bulldoze certain lots, I got poxed, but if I'm not touching those lots, nothing special really happens). I bulldozed and rebuilt some all of those lots which usually triggering the prop pox in that city and...

I HASN'T GOT ****ING PROP POX!!! 

I saved a couple of times and while I finished the bulldozing rebuilding process I ended up with 16 disabled props according to the SC4 Save program, but that's it, I can't see visable missing props/wiped out city parts, I don't see any filesize dropping on the save file, rather it was increase a bit (from 44,2 to 44,3 and I only made the replopping stuff of these used to be Prop Pox triggering lots)

So, I'm actually can't say anything... First I realized, that your "fix" in this particular case is working it brought some teardrop into my eyes... Really... it's awesome... I can't actually belive...

Thank you very much, I can't be gratefull enough...

- Tyberius

 

[redfox85 659]

I have a tile that has disabled props - but no pox. I've destroyed the lots -  but its still disabled (unlike the other neighbouring tile I sent which is fully pox'ed). I would like to see what would happen if we could re-enable disabled props in a non pox city. As in a pox city - the ID's are all 0 for the disabled props, but with no pox the ID's remain and its a simple flag that needs to be reflipped.

[jeffryfisher 2,176]

11 hours ago, simmaster07 said:

I still have absolutely no idea how my DLL is more stable than the game's normal implementation.

Perhaps yours succeeds because you instinctively used correct as-modded prop-size values instead of whatever pre-mod short value that the original code assumed was still valid.

[mertzigzag 48]

huh, this whole time when people mentioned "Prop Pox" I thought they were referring to when seemingly random props replaced other props... i.e. a prop of some sort is visible, but is the completely incorrect one.   Somehow until now I never caught that it was actually when props disappeared from view.*  Thanks for the excellent opening explanation that included a basic definition for those of us who have heard the term plenty of times but never encountered its real meaning!

Is the situation I describe with random prop substitutes just a possible variation on the "Prop Pox" theme?
An example I have, which annoys me to no end, is that whenever I newly plop one of the Maxis default City Halls, I get a random selection of very incorrect props on that lot that are replacing Maxis originals:
- for flora, I end up with *HUGE* redwood and cedar trees that seem to correspond to a MMP pack I installed long ago... that's not so bad... but...
- for other "lot junk" I mostly end up with some of the ACB 747 airplane props... obviously a city hall with a British Airways 747 hanging off the lot looks, oh, a bit *odd* maybe?
This started happening quite a while after I installed the relevant content that's now showing up out of place, so things were fine for a while--until things went all haywire one day and have never been the same since.

I've never really been sure how to resolve this without just deleting those prop + MMP packs... which I don't want to do since I actually really like them in their appropriate use situations (My region's airports would be bereft of 747s for their many prestigious international connections! )

Has anyone had experience with this sort of problem? ...and how to possibly fix it, short of deleting lots of content?

(* notably I have run into the "real" Pox as well, but didn't know what it was at the time... though the one or two times it ever occurred for me in 10+ years of play very clearly corresponded with other problems, like a crash near the end of the save game process).

[kingofsimcity 5,740]

Reporting back on testing the new DLL. I think it works.

This was the state my city tile was in (dated 2/4/2015) before. Notice the two swaths of vertical emptiness across the city tile, a sure sign of a poxed city.

After installing the beta DLL, I did the following:

1. Set the City Detail graphics setting to Low. Exit and relaunch SC4.
2. Open the offending city tile, save immediately.
3. Exit to region without saving, then set City Detail back to High. Exit and relaunch SC4.
4. Open the offending city tile again.

To my surprise, a couple of saves after that:

It's gone! Most of my lost props were also "rediscovered" after messing around with the graphics settings. I still had a few lots here and there that had some missing props but as a whole, the tile is back in action!

As much as I dislike jumping to conclusions too quickly, I think the short-terms results I got so far speaks for itself. My almost 3-year old city tile is no longer poxxed according to SC4 Save, and I am eternally grateful for your incredible efforts. Thank you again, @simmaster07.

[matias93 7,535]

Ok, maybe I wasn't following the logic thoroughly because I simply assumed that the solution provided, even if it were proved effective on preventing prop pox, wouldn't be able to fix already poxed cities...

This is not only a game changer, is an outright MIRACLE!!!