What causes Prop Pox (and how to avoid it)

[mgb204]

<snip>

I don't know where you are getting this idea from, it is not based on any facts I am aware of. If this was true creators like me would be the most poxed players of all. My plugins folder has never remained unchanged, I'm always testing/changing/adding/updating and generally mucking around, I spend a lot of time with the game and most of this is modding. If what you suggest was remotely true I can't believe no one would have noticed by now, I literally do what you are saying is bad constantly and have no problems.

The worst thing you can do is remove something from your plugins folder that resides in a currently saved city, the game will try to reference it, but can't, however the resulting problems are nothing to do with Prop Pox. If you remove any items from your plugins folder, you need to enter the game before you uninstall them to remove every saved instance of the item beforehand. Updates shouldn't change the ID's of props or RTK settings or anything else that would lead to problems for existing users, by and large most mods I see comply with this. Some downloads specify you must remove previous instances where changes like this are made, ultimately it's up to users to read the Readme to ensure they are informed about what an update does.

P.s. There is no plugin update fiasco, you've just made that up. I feel a little bad writing that, but there are enough issues the SC4 community faces today and such grossly inaccurate speculation is unhelpful at best.

However, the game has begun to crash at exit. I can ctrl-s save all day, but when I attempt to save and exit to region it will actually save but crash to desktop before I get back to region view. If I simply decide to exit it wont exit smoothly, but instead will kind of crash to the desktop.

There is a bug with SC4 where your save file can become corrupted in certain circumstances causing the behaviour you describe (sadly I have two important cities with the same problem). It is widely understood to be caused when switching focus to another program whilst SC4 is saving data, so if you are using Alt+TAB or some other method to do this, you need to avoid this whilst the game is saving. I can't say if I did or didn't switch focus when the first city had this problem, but I know for sure I was aware of it when my second city corrupted and that this was absolutely not something that happened.

There seems to be another issue here, when you use either the Save and Exit to region or Save and Quit options again such corruption seems possible, albeit rarely. If you always save using CTRL+S and then exit without saving this problem should not return in future, so far I've not had a repeat of the problem since I have been doing this. The good news is, your city isn't toast, so if you don't have a backup, barring the annoyance of the game CTDing when you exit the city, at least you can progress/save the city.

Once again though, such behaviour is not Prop Pox, whilst both problems are essentially a type of file corruption, the causes and effects of Prop Pox are totally different. Assuming the saving issue is the only problem you are having, this is not indicative of Prop Pox in any way and your cities should also still be usable.

[alexr19]

Thanks, but the prop pox is a separate problem I'm experiencing. Didn't mean to conflate the two, just wondered if they might be related. I've also never Alt-tabbed out of the game and I usually even pause it before I save. I think it's prop box because one area of my city looks completely barren, but when I open the game tonight I'll see if it has spread more.

[mgb204]

No the two issues would be completely separate.

I urge you to take the time to show what's going on in your cities, ideally a screenshot makes it real easy to be sure of what's happening. If you do have some form of Prop Pox, sadly there isn't anything you can do about it, but many users have confused other problems which are completely fixable with prop pox, so before you assume the cities are dead, it would be worth checking.

[joshua43214]

Sorry I have been away for a while. RL came out of no where and side tracked just about every project I was working on.

I was just preparing to dust my game back off and came here to see if people are still playing SC4 or not after CS came out.

I just re-read all my posts on my research into the cause and cure of prop pox to see if there was more detailed info than what is in my notes.
At the time I got side tracked, I was working on a tool for curing the pox. My tool will fix the portion of the savegame that wou's tool checks. The problem is that the pox will return. This led me to believe the actual corruption was in a different part of the savegame file, and I was hard at work trying to decode it.
Needless to say, decoding a file is a lot of work.

I turned my sights to trying to trick the game into rebuilding the savegame file for me. This was the point that I got side tracked, and I had no success at it.

For now, I am tabling the project. So if anyone wants to take a shot at it, please do so rather than wait for me to get back to it.

I am just the last of many people to confirm that the BDK beach umbrella will cause prop pox.
I have absolutely no doubt that something about that lot causes a problem. I did determine that some of the prevailing theory as to why (including some of my own theory) was wrong. For now, the root cause is not known, just the lots that cause them.
I wrote some very long and very dense posts in the last 3 or 4 pages of this thread. I hope that someone reads and has an idea of where to go with it.

-Josh

[joshua43214]

I was asked by another member for a copy of the test city and a link to the BDK.

This led to some more script debugging and the like while I was making sure I was uploading the right file.
I did find a minor bug in my script and I was able to streamline it a bit.
The script does still "fix" the corruption, but the corruption returns after the game is run for a while.
Here is Dropbox link to a test city with a compressed prop file
https://www.dropbox.com/sh/xyyjng0834k4slg/AADhjyg4v0pTOpVIvZGQJ8pRa?dl=0
There is nothing special about this city, any one can make it. It only takes a couple of hours tops to lay out the roads and the like.
This is a vanilla Rush Hour game, you will need Buildings as props 1 and 2. I used extracheats.dll to get the extra simoleans, you can probably use the city with out it.
The prop file will decompress between 60K and 85K sims. Just keep an eye on the city file, when you save the game and it goes from ~12 to ~24 size, the prop file has decompressed and the pox will manifest.

Here is a link to the BDK on the STEX. I did download this file and verify that this file is not the updated file from the former Simpeg website that is now defunct. This is the same old BDK that Peg never bothered to update on the STEX (trying very hard not to rant here...)
http://community.simtropolis.com/files/file/19111-peg-oww2-bdk-beach-development-kit/?st=20
if the STEX link goes dead (that never happens does it?), search for "peg OWW2 BDK"

To use:
Rename your Regions folder BU_Regions (not Regions_BU, it is important to change the beginning)
Create a new Regions folder
Save the test city to any place convenient outside the Regions folder
Copy the test city into the Regions folder (we do this so we do not accidentally over write the test city, the game is really good and ruining your day this way)
Create a new plugins folder with only the two buildings as props files
run the city till the prop sub file decompresses
Check the city with wou's SC4 Save, this verifies the city is good
Delete or remove this city from the regions (Make sure you rename it in the .ini if you move it)
Copy a fresh test city into the regions folder
Add the BDK to the plugins
run and check, this verifies the city will get prop pox (The BDK will always pox a city)

Now that we have done both a positive and negative control we can test any plugins we wish.
I suggest using your full plugins folder on this test city to verify that your plugins folder is good.
If you get the pox, you will have to repeatedly divide your plugins folder in half until you find the file causing the problem. Make sure you check both halves at each division, just because one half causes the pox, it does not mean there is not a problem with the other half as well.

-----------------
For those wishing to follow up...

I was never able to locate an index for the prop subfile in the save game. I do not know if one exists or not. Memory was still a concern when the game was written and I can see EA leaving out the index to save space, the format of the prop subfile is certainly not a robust system and is different than what we see in lot and building files.
It is possible that there is no index for the prop subfile and that it really does just go prop by prop through the subfile and load them. It is also possible that the offset for a particular prop is part of the save file for the lot. ie, the game loads a lot, and the lot tells the game what offsets in the prop subfile to use for the props.
My script parses the prop subfile in a very simple manner. The first 4 bytes is always the length of the prop. The length of a prop is always 88 + extra properties. The prop also always has the Instance repeated about 2/3 of the way through the file (this comes after any extra properties). My script simply compares the expected length to the actual length, and verifies that the Instance is repeated.
In practice, the vast majority of props are 88 bytes. Quite a few are 104 bytes.

The method I am using to repair the prop subfile is as follows:
copy the subfile
scan through the subfile and decode each prop one at a time.
-if the prop passes the logical test, the data is appended in hex from the copy to a new_prop.
--this ensure that the original data is copied, not a re-encoded version of it.
If the prop fails the logical test, scan forward one byte at a time and try to decode the prop
-I discard any prop with length >125
-when a valid prop is found, reset the offset to the beginning of that prop and append new_prop.
Once the repairs are completed, the old prop subfile is snipped from the save and the new_prop is inserted.
Edit the savegame directory to reflect the new length of the prop subfile.

NOTES: Python and other languages will sometimes add extra chars to hex or decoded hex (the L for long being very common). To ensure that you are not adding corruption to the file, it is important to copy data unmodified rather than re-encode the decoded file.
You can write the new prop subfile to a txt file and paste it into the save using the Reader. This was the method I used at first, and decided it was best to just write it directly into the save and not worry about stray chars being introduced by my txt editor.
My script saves each decoded prop into a list for use in a UI I wrote to make life easier. There is a sneak peak of the UI in action a page or two back in this post.
The info on the wiki contains some errors and inconsistencies. Expect to spend some time head scratching before the your script decodes properly.

Here is a Python code snippet that has all the information you need to decode an individual prop. You will notice that it is similar but different to what is on the wiki page. I used all the nomenclature from the wiki page. SaveOpener is the actual function that does the work, the other two functions are the ones called by it and are included for clarity.p_sub is the actual prop subfile, ind is the offset for a particular prop.
A thing to watch for. I sometimes see data_type = '0x00000000'. This data type is not used anywhere I can find in SC4. I do not know if this data_type is unique to saves or not. In this version of my script I use the else function to capture it and all these files get decoded as "c" format (char) in struct.unpack. Since this is only used for human viewing it has not been a problem, but might be a real source of corruption in the file itself.
see
https://docs.python.org/2/library/struct.html
for documentation on Format Characters in Python for basic understanding of struct.unpack/pack

The important thing is that this code contains to the best of my knowledge, all the correct offsets for each snippet of data in a prop.

Code Select Expand

def HexPadder(hex_num):
    return "0x" + hex_num[2:].zfill(8)
def SaveTypeFinder(data_type):
   
    if data_type == '0x00000001':
        b = "B"
        val_len = 1
    elif data_type == '0x00000002':
        b = "H"
        val_len = 2
    elif data_type == '0x00000003':
        b = "I"
        val_len = 4
    elif data_type == '0x00000007':
        b = "i"
        val_len = 4
    elif data_type == '0x00000008':
        b = "q"
        val_len = 8
    elif data_type == '0x00000009':
        b = "f"
        val_len = 4
    elif data_type == '0x0000000b':
        b = "?"
        val_len = 1
    else:
        #data_type == '0x000000c0':
        b = "c"
        val_len = 1
    return b,val_len
mem_dict = dict()
def SaveOpener(p_sub,ind):
   
    m = ind
    m_start = m
   
    size = struct.unpack('I',p_sub[m+0:m+4])[0]
   
    mem = hex(struct.unpack('I',p_sub[m+8:m+12])[0])[0:10]
    if mem in mem_dict:
        mem_dict[mem].append(m)
    if mem not in mem_dict:
        mem_dict[mem] = [m]
   
    maj_v = hex(struct.unpack('h',p_sub[m+12:m+14])[0])
    min_v = hex(struct.unpack('h',p_sub[m+14:m+16])[0])
    zot = hex(struct.unpack('h',p_sub[m+16:m+18])[0])
    unk_1 = p_sub[m+18]
    ap_flag = hex(p_sub[m+19])
    something = hex(struct.unpack('I',p_sub[m+20:m+24])[0])[0:10]
    min_tract_x = p_sub[m+24]
    min_tract_z = p_sub[m+25]
    max_tract_x = p_sub[m+26]
    max_tract_z = p_sub[m+27]
    x_tract_size = hex(struct.unpack('H',p_sub[m+28:m+30])[0])
    z_tract_size = hex(struct.unpack('H',p_sub[m+30:m+32])[0])
    prop_count = hex(struct.unpack('I',p_sub[m+32:m+36])[0])[0:10]
    if prop_count != '0x0':
        name_val = hex(struct.unpack('I',p_sub[m+36:m+40])[0])[0:10]
        name_val_1 = hex(struct.unpack('I',p_sub[m+40:m+44])[0])[0:10]
        something_2 = hex(struct.unpack('I',p_sub[m+44:m+48])[0])[0:10]
        data_type = p_sub[m+48]
        key_type = p_sub[m+49]
        word = hex(struct.unpack('h',p_sub[m+49:m+51])[0])
        key_type = HexPadder(hex(key_type))
        data_type = HexPadder(hex(data_type))
        b,val_len = SaveTypeFinder(data_type)   
        if key_type == '0x00000000':
            prop_val = struct.unpack(b,p_sub[m+51:m+51+val_len])[0]
            m = m + 16 + val_len       
        elif key_type == '0x00000008':
            rep_count = hex(struct.unpack('h',p_sub[m+51:m+53])[0])
            prop_val = hex(struct.unpack(rep_count*b,p_sub[m+53:m+53+rep_count*val_len])[0])
            m = m + 16 + 2 + rep_count*val_len
        else:
            prop_val = "corrupted"
    if prop_count == '0x0':
        name_val = "NA"
        name_val_1 = "NA"
        something_2 = "NA"
        data_type = "NA"
        key_type = "NA"
        word = "NA"
        prop_val = "NA"       
   
    GID = hex(struct.unpack('I',p_sub[m+36:m+40])[0])[0:10]
    TID = hex(struct.unpack('I',p_sub[m+40:m+44])[0])[0:10]
    IID = hex(struct.unpack('I',p_sub[m+44:m+48])[0])[0:10]
    IID_1 = hex(struct.unpack('I',p_sub[m+48:m+52])[0])[0:10]
   
    min_x = struct.unpack('f',p_sub[m+52:m+56])[0]
    min_z = struct.unpack('f',p_sub[m+56:m+60])[0]
    min_y = struct.unpack('f',p_sub[m+60:m+64])[0]
    max_x = struct.unpack('f',p_sub[m+64:m+68])[0]
    max_z = struct.unpack('f',p_sub[m+68:m+72])[0]
    max_y = struct.unpack('f',p_sub[m+72:m+76])[0]
    orientation = p_sub[m+76]
    state = hex(p_sub[m+77])
    start_time = p_sub[m+78]
    stop_time = p_sub[m+79]
    count = p_sub[m+80]
    chance = p_sub[m+81]
    lot_type = p_sub[m+82]
    obj_id = hex(struct.unpack('I',p_sub[m+83:m+87])[0])
    cond_ap = hex(p_sub[m+87])   
    actual_record_len = 88 + m - m_start
   
    vals = [size,mem,maj_v,min_v,zot,unk_1,ap_flag,something,min_tract_x,min_tract_z, \
        max_tract_x,max_tract_z,x_tract_size,z_tract_size,prop_count,name_val, \
        name_val_1,something_2,data_type,key_type,word,prop_val, GID,TID,IID,IID_1, \
        min_x,min_z,min_y,max_x,max_z,max_y,orientation,state,start_time, \
        stop_time,count,chance,lot_type,obj_id,cond_ap,actual_record_len]

    return vals, IID, IID_1

Good luck

EDIT: You might notice that there are many lines similar to

Code Select Expand

GID = hex(struct.unpack('I',p_sub[m+36:m+40])[0])[0:10]
and wonder about the odd indexing at the end, ie ...[0])[0:10]
struct.unpack returns a tuple, so we need the ...[0]) to only get the first part of the tuple.
hex will return a hex number that will sometimes have an "L" appended to denote a "long." [0:10] copies only the first 10 bytes and leaves off the 11th byte (the "L").

[catty]

...Here is a link to the BDK on the STEX. I did download this file and verify that this file is not the updated file from the former Simpeg website that is now defunct. This is the same old BDK that Peg never bothered to update on the STEX (trying very hard not to rant here...)
http://community.simtropolis.com/files/file/19111-peg-oww2-bdk-beach-development-kit/?st=20
if the STEX link goes dead (that never happens does it?), search for "peg OWW2 BDK"...

If you haven't already done so it might be worth asking Craig-Abcvs

http://community.simtropolis.com/forums/topic/68519-surplus-simpeg-luminary-society/?page=2#comment-1583824

If its possible to update it as he and the other SimPeg Staff have been given moderating rights on the STEX, otherwise I can add something to this list

http://city-builders.info/cb-documents/11-catalog-by-website/11-simpeg-exchange

explaining that its a known cause of the Prop Pox, I could even attach the up-to-date version of the file to this list, but that's only if they weren't willing to update it.

-catty

[dyoungyn]

I am not at all trying to say I am an expert or programmer or anything of the sort.  All I am saying is that my theory works for me and as has been for over a  year now.  I am only leading to this conclusion as again, one must work with what one has within one's control.  Again, I appears to be working for me and I must have discipline and be selective when downloading updates to buildings.   Again, I am not blaming any creator or anything and I DO NOT have any hard proof and only successes for my region.

Please forgive me if I offended anyone with my theory and only trying to pass along what works for me may be possible for others. 

dyoungyn

<snip>

I don't know where you are getting this idea from, it is not based on any facts I am aware of. If this was true creators like me would be the most poxed players of all. My plugins folder has never remained unchanged, I'm always testing/changing/adding/updating and generally mucking around, I spend a lot of time with the game and most of this is modding. If what you suggest was remotely true I can't believe no one would have noticed by now, I literally do what you are saying is bad constantly and have no problems.

The worst thing you can do is remove something from your plugins folder that resides in a currently saved city, the game will try to reference it, but can't, however the resulting problems are nothing to do with Prop Pox. If you remove any items from your plugins folder, you need to enter the game before you uninstall them to remove every saved instance of the item beforehand. Updates shouldn't change the ID's of props or RTK settings or anything else that would lead to problems for existing users, by and large most mods I see comply with this. Some downloads specify you must remove previous instances where changes like this are made, ultimately it's up to users to read the Readme to ensure they are informed about what an update does.

P.s. There is no plugin update fiasco, you've just made that up. I feel a little bad writing that, but there are enough issues the SC4 community faces today and such grossly inaccurate speculation is unhelpful at best.

However, the game has begun to crash at exit. I can ctrl-s save all day, but when I attempt to save and exit to region it will actually save but crash to desktop before I get back to region view. If I simply decide to exit it wont exit smoothly, but instead will kind of crash to the desktop.

There is a bug with SC4 where your save file can become corrupted in certain circumstances causing the behaviour you describe (sadly I have two important cities with the same problem). It is widely understood to be caused when switching focus to another program whilst SC4 is saving data, so if you are using Alt+TAB or some other method to do this, you need to avoid this whilst the game is saving. I can't say if I did or didn't switch focus when the first city had this problem, but I know for sure I was aware of it when my second city corrupted and that this was absolutely not something that happened.

There seems to be another issue here, when you use either the Save and Exit to region or Save and Quit options again such corruption seems possible, albeit rarely. If you always save using CTRL+S and then exit without saving this problem should not return in future, so far I've not had a repeat of the problem since I have been doing this. The good news is, your city isn't toast, so if you don't have a backup, barring the annoyance of the game CTDing when you exit the city, at least you can progress/save the city.

Once again though, such behaviour is not Prop Pox, whilst both problems are essentially a type of file corruption, the causes and effects of Prop Pox are totally different. Assuming the saving issue is the only problem you are having, this is not indicative of Prop Pox in any way and your cities should also still be usable.

[fefenc]

Just had to destroy my 4x4 industrial city which I invested 20 hours on it due to a damned prop-pox, I believe it was caused by a freeze followed with a forced closure on the process via task manager while I was saving and going to the region view, so I close the game via CTRL+ALT+DEL, which may have corrupted the savefile.

I noticed some strange stuff at the region view after I came back to the game. The city on the region view was blank when compared to the rest of the region (with only the terrain mod visible), then I entered the city and it was saved at the place it froze. I played on it for awhile and I noticed that some trees were lacking from the maxis plaza, then I also noticed that some soundwalls and objects of some houses were lacking too, so I got frustrated and I threw some meteors on the city, called some ovnis to the city and I finally put the city out of its misery by using the TNT tool to erase everything on it to start building on that tile again.

After destroying my biggest industrial city I was building with so much love for more than 20 hours, I went to its neighbour city by searching for any signal of prop pox and I found nothing on it.

Gladly I have a backup of the industrial city, but only at its early development stage, I would never figure out that a forced close due to a freeze while saving would ruin my city T_T

After reading this thread, I downloaded Ilivereader to verify my unaffected city size to see how much I would be close to face issues on that tile too, the city has 9MB size and the file inside it (I believe it's called 2977aa47) has 3.78MB. I have over 2GB of custom files, 1GB is owned by NAM and the other 1GB are mostly dependencies and buildings.

If I learned something with this embarassing situation, then these are 3 lessons: To back-up my region more often, to avoid force closing the game while saving a city (even through the game crashes) and to never use "save and go to region view".

Frustration puts my feels in short at this moment T_T

EDIT: It can happen to medium tile cities too, I had it on a medium tile some years ago.

[mgb204]

@ Fefenc

What you describe is simply file corruption. If the process halts mid-save then who knows what errant data is written at that point, even incomplete data can corrupt a file. This is not prop pox and a backup of the city would be sufficient to resolve the problem.

SC4 often will freeze if you use F8 / Save and Exit to Region or F12 / Save and Quit. The safer method is always just to save then exit/quit without saving as it's less likely to crash whilst saving.

[fefenc]

Well, props started to disappear from the city and it was a quite huge industrial complex, but I understand that forcing the game to close in mid save is a bad idea for every game and I knew I've done a big mistake by saving and exiting to region. I'll back-up my cities more often for now

Luckily I think I have a backup for that city, but in an early stage of development. Also, I'll have to search through my mods to see if there is no corrupted mod that can potentially cause this problem. My region is composed by 4x4 tiles :0

Thanks for the heads up

EDIT: I have PEG-CDK3-SP_ContainerShipFleet_101 (some ships that stops in front of some custom cranes) in my dependencies folder and built a seaport at the same day that my city got poxed, should this have aggravated the problem?

[mgb204]

Prox pox is also a file corruption issue, but the causes are very different to what you describe.

The file save corruption problem is well known about, it's nothing to do with any plugins, simply what happens when a save in progress fails.

[fefenc]

Understood, so there is the 6Mb subfile prop pox which is triggered by a problematic prop mod and the prop pox caused by a corruption in the savefile while saving the game at the wrong way (which was my case). Quite interesting, I'll back-up my cities more often to avoid this issue and save separately from exit to region. I messed it up by saving it while it was raining in the city and a lot of traffic were being shown, but I'll remove every Pegasus related mod (but the gray power pole). I'm at the 9th page of this thread and I'm a lot scared of developing future cities with anything CDK and PEG related in my system since my region is composed by 4x4 tiles and I like to zone low density buildings

Thanks for lighting my issue

[twalsh102]

Fefenc:
Just to be clear, there is only one specific Pegasus file (or any file for that matter) that is known to be related to Prop Pox.  That is PEG-OWW2_BDK_RESOURCE.DAT. 

Don't go overboard and shy away from using other Pegasus created content just because of problems related to this one file, because Pegasus created a lot of quality content that you would be missing out on. 

In fact, if you go back to the first few posts in this thread, bap gives pretty good explanations describing Prop Pox, how to avoid it, and even how to fix the above mentioned PEG file if you find some content that absolutely needs to use the file.

The bottom line is that with as much testing as has gone on over the years, if any other Pegasus (or any other) file was known to be related to Prop Pox, it would be well documented by now.  There has been conjecture over time that other content available in the early days of SimCity4 modding may have also possibly caused Prop Pox, but testing of currently available content has not come up with any other problem files (unless I missed some posts someplace).

[woodb3kmaster]

Well, I'm in something of a pickle here. I recently had my region's second-largest city get prop-poxed (as verified with SC4Save, as well as by manually examining the hex code for corruption), despite my having never had an unmodified BDK resource file in my plugins since long before I started developing this region. I made sure to delete the errant prop exemplars from that file before installing it, and that was in June 2010 (my current region dates from sometime in 2012).

Not wanting to lose all the work I'd done on the city, I attempted the fix that z detailed earlier in the thread, only to find that 1) the savegame was still poxed; 2) all the automata disappeared, and only later began reappearing in small areas of the quad; 3) all traffic volumes dropped to zero, and when they rebounded, mass transit usage was much lower than it had been and showed none of the usual fluctuations; and 4) all the residents lost access to their jobs, culminating in a ~90% drop in population a few months into playing the city. So I can say with great certainty that simply deleting subfiles doesn't help.

Fortunately, I have an unpoxed backup copy from December 9 on my external hard drive, so all is not lost. When I looked at the backup's prop subfile in SC4Save, I noticed that it had 674 disabled props, and that their TGI addresses had all been zeroed out (though the IID_1 was still intact). Cross-referencing their coordinates with the prop map revealed that at least some of the disabled props were xannepan's seasonal trees from the Palais de Luxembourg, which had not been visible since I updated my Quais de Seine installation (the QS planter prop also turned into a brown box at that time, but I later fixed it). To restore the trees, I ended up reinstalling the tree props from the original Quais de Seine release, making sure they overrode the newer versions. After that, I demolished and replopped the affected lots, which is most likely when the props were disabled.

I've also discovered that I can save the backup and keep it pox-free, but only if I don't unpause the game at any point after loading it. After playing the city for a few game years last night, the backup was once again poxed (again, according to SC4Save and the corrupted hex code itself). Curiously, the two poxed copies of the savegame I now have appear to be corrupted in almost exactly the same manner: they both contain what appears to be a truncated prop entry near the end of the subfile, followed by a string of bytes that looks nothing like a prop entry, but which at least starts off the same in both copies. The only differences between them are the offset at which the corruption begins, and the length of the final, corrupted entry. (It's also worth mentioning that the poxed version of the backup has a compressed prop subfile which is quite a way from the 16MB threshold, while the first poxed copy has an uncompressed subfile. I don't know what to make of these discrepancies.)

So that's my prop pox story. If anyone with more technical knowledge than I have wants to examine my savegames, I'll gladly upload them to my Dropbox.

[Wiimeiser]

Seems like the simple act of adding props may be enough to trigger the pox. Which begs the question of how extensively Maxis tested the game. I know for a fact that the thing with TE lots has been around since Rush Hour (The only reason it wasn't in the original game was because the only puzzle pieces were the diamond and cloverleaf interchanges (owing to the fact that the game even in RH was still as abstracted as Dwarf Fortress the original) and they could only be placed on top of existing networks, and the fact that no actual TE lots existed, heck, the only TE lots in RH are the car ferry, toll booth and freight, ElRail and monorail stations). Could simply saving a city, installing new props and then reloading the city, even if none of the props are pox-capable, cause the pox? If there was a way to reset the prop info...

[matias93]

I was thinking that, due to the recent developments in DLL-modding the game (and reverse engeenering of it), it could be possible to write a DLL to override the size limit for compressing prop files for large cities, which is the original cause of the pox. This could also allow smaller files for large cities. Of course that that method couldn't repair poxed cities, but at least would allow to use poxing props without the risk of damaging healthy cities.

[jdenm8]

Aside from overriding the buggy conversion code, DLL loading can't help us here. The 16MB limit is an inherent limitation of SC4's QFS compression.

[APSMS]

<Prop Pox>

Not wanting to lose all the work I'd done on the city, I attempted the fix that z detailed earlier in the thread, only to find that 1) the savegame was still poxed; 2) all the automata disappeared, and only later began reappearing in small areas of the quad; 3) all traffic volumes dropped to zero, and when they rebounded, mass transit usage was much lower than it had been and showed none of the usual fluctuations; and 4) all the residents lost access to their jobs, culminating in a ~90% drop in population a few months into playing the city. So I can say with great certainty that simply deleting subfiles doesn't help.
<snip>
I've also discovered that I can save the backup and keep it pox-free, but only if I don't unpause the game at any point after loading it. After playing the city for a few game years last night, the backup was once again poxed (again, according to SC4Save and the corrupted hex code itself). Curiously, the two poxed copies of the savegame I now have appear to be corrupted in almost exactly the same manner: they both contain what appears to be a truncated prop entry near the end of the subfile, followed by a string of bytes that looks nothing like a prop entry, but which at least starts off the same in both copies. The only differences between them are the offset at which the corruption begins, and the length of the final, corrupted entry. (It's also worth mentioning that the poxed version of the backup has a compressed prop subfile which is quite a way from the 16MB threshold, while the first poxed copy has an uncompressed subfile. I don't know what to make of these discrepancies.)

Hi Zack,
what's interesting is that I experienced a similar experience with my traffic simulation a few weeks ago. I didn't think my problem was related to prop pox because I had only installed new BATs. I had saved the game (but alt-tabbed at the last moment resulting in the familiar blank city region view image), and installed some of the wonderful new BATs that are now available. When I reopened the city, all traffic had ceased and so had all my jobs; the city stopped functioning for about 6 months, and when the traffic finally came back online, I had only cars, no pedestrians, buses, or trams, despite prodigious quantities of all these beforehand.

I hadn't a backup, but Windows is scheduled on my PC to regularly make save points, so I luckily had a recent (1-week old) copy of the city in question, and promptly overwrote the problem city. I never thought to check for prop pox because city detail was set to medium, and I was too worried about my city economy to mull over whether the props were still there. I chalked it up to a corrupted save (due to the alt-tabbing), and haven't thought twice about it until your post just now, because I had never seen anyone else have this problem, nor have I ever encountered it myself before (missing traffic, that is--Prop Pox I think I may have had once before, but the region in question is long gone).

At any rate, I wonder what really causes the missing traffic, whether it's actually related to Prop Pox or not, and if it's possible for vetted props to cause the Pox, or if something else is happening that is causing all of this (what it could be I have no idea).

As a final question, and to ascribe (or imply, insinuate, etc.) absolutely no blame whatsoever, do you happen to have the SC4 Fix for TE-Lots and Puzzle Pieces installed (by speeder, I believe)?

[vortext]

Unfortunate, yet rather interesting Zack. Given my own experience with the pox last year, it seems like removing RKT4 exemplars without bulldozing the associated lots (or network in my case) beforehand is setting the stage for prop pox. Or in other words, when the RKT4 exemplars are removed the savegame entries will become disabled once the lots are bulldozed afterwards.

Seems like the simple act of adding props may be enough to trigger the pox.

That seems highly unlikely. The RKT4 exemplars were removed first of all when Zack updated the Quays. Simply adding stuff will not trigger it (as far as we know now, that is).

[woodb3kmaster]

At any rate, I wonder what really causes the missing traffic, whether it's actually related to Prop Pox or not, and if it's possible for vetted props to cause the Pox, or if something else is happening that is causing all of this (what it could be I have no idea).

In my case, the missing traffic and economic woes were the direct result of deleting those subfiles, which happen to be the network index and sims-to-jobs matching file. So as far as the game was concerned, when I loaded the city, there were no longer any networks (as evidenced by my totally blank traffic congestion data view), and all the residents were unemployed. No wonder most of them left town!

As a final question, and to ascribe (or imply, insinuate, etc.) absolutely no blame whatsoever, do you happen to have the SC4 Fix for TE-Lots and Puzzle Pieces installed (by speeder, I believe)?

IINM, that fix is by simmaster07, but yes, it's installed.

A quick update: After setting my city details to low and saving at zoom 1 (as recommended earlier in this thread), it appears that I can play my backup of the city without triggering the pox. Doing these two things also dramatically speeds up the saving process. So it looks like I'll be using these techniques in this city for a while to come (along with not using save-and-exit, which I've avoided for years now).