What causes Prop Pox (and how to avoid it)

[Magneto]

Cogeo, if I understand you correctly, this means that if I make a prop replacement to replace, let's say a maxis tree (RKT1) by a semi-seasonal tree (RKT4) I will have prop pox once the sub network file reach the critical size?
So to avoid it, the replaced prop must have the same rep values as the replacement prop?

Sorry if my question sounds dumb, I'm still new to this.

[vortext]

Kergelen, that's an unfortunate side-effect of changing city details from high to low and back to high again. For some stupid reason I did this once and all the mmps on the lots were gone. With the benefit of hindsight this now seems obvious to me; when changing details to low, props on lots are no longer stored in the savegame (and hence the subfile size goes down). However, this also removes all the mmps from the lots and once the details are restored to high, mmps do not reappear because they are not present on the actual lot file. So it seems the game handles mmps on barren ground different from mmps on lots, at least that's what I inferred.

[cogeo]

Cogeo, if I understand you correctly, this means that if I make a prop replacement to replace, let's say a maxis tree (RKT1) by a semi-seasonal tree (RKT4) I will have prop pox once the sub network file reach the critical size?
So to avoid it, the replaced prop must have the same rep values as the replacement prop?

Trees are not props. But there are some props displaying a tree model (blue rectangles in LE). The prop pox can occur if you override the prop exemplar (same TGI, not new) and change it from simple to timed/seasonal or vice-versa. Still, the prop pox won't take place if the overridden prop is used throughout the city's/region's lifetime, ie after the first instance of the prop is created (in a grown or plopped lot or as a network prop) DO NOT install/uninstall the mod that overrides the prop. I don't how God- or Mayor-mode trees are implemented, and whether overriding such a tree with a modified one could cause a similar situation, so it would be better to be safe than sorry, so the same steps should be taken here as well, ie once you plant your God-mode trees, do not install or uninstall the tree mod. But I believe it wouldn't be a problem if the tree pack contains only new trees, and not overrides of the originals. In such a case you can install the mode even after your (Maxis-only) God-mode trees have been planted.

[Kergelen]

vortext, I had not seen your reply. Thanks for the explanation

[Magneto]

Cogeo: slight confusion here... I don't want to interfere with flora, I just want to replace the maxis props trees.

[Manwith Noname]

Wow, my head hurts.

I apologise for dragging up something quite dormant but a thread still going after 4 years is a rare sight, on a problem that has existed for nigh on 10 years too.

Having spent the best part of 8-10 hours, on and off perusing many sources on this issue, though mainly this thread, I feel inclined to quote from elsewhere something that seems to have not been covered here...unless my frazzled brain is confusing me.

...
In theory at least, the prop-pox won't occur as long as you do not install a modified version of a prop, to which the city file does contain references (instances of the prop). Ie if you start a new region, even with PEG's mods installed, you should not get the prop-pox if you don't unsinstall them (causing them to revert to their original version), or install another modified version...

I admire the scientific approach in trying to solve this problem but this explains why the BDK mod flagged as an issue in this test case. Whether or not you think the approach in said file is "bad practice" is entirely dependant on your view of modding and the required results. As I understand it, the required result was to effect all models regardless of location to further simulate their apparent usage by your population. Could this be achieved another way? Maybe as a seperate addon with the understanding of how it may impact your save file.

Something that my memory banks are failing to bring forward due to information overload, along with it being half past 3 in the morning, is whether there has ever been a case of pox in a completely vanilla scenario? If not, I suspect this is always going to be an issue as people update and expand their plugin collection due to the nature of the game engine, continual mod developement and generally the eagerness of most to simply grab the latest and greatest addon...and sometimes old and not so great.

That's not to say that precautions cannot be taken by creators and players alike but with such a vast amount of mods out there it is almost impossible to prevent situations like these, unless, over time, files that may cause problems end up in a list as they are discovered. Much like the dependancies list or the inCAMpatable thread. Lists are better, threads are arduous when checking for things like these. They tend to drift off topic on occasion and get filled with nonsense posts with people rambling about other things......ahem.

As has been stated, todays SC4 is far beyond the scope of what the developers expected. Half the reason I'm here typing this is because of the, erm, haphazard approach to the latest title in the series. As a long time gamer, requiring an internet connection to play a game, unless it is specifically an MMO, is a big no no. But that's a whole other subject.

For the record, I have no pox. I am currently playing vanilla SC4 and building an addon collection to suit my tastes before entering into modded SimCity. The last version I played was SC2000 before picking SC4 up recently in a certain summer sale.

Kudos to all those who make some quality content, looking forward to enjoying it.


*slips silently back into lurk mode*

[Kuewr665]

I recall recently building up a large city tile that was almost entirely developed with low density buildings. Last time I checked the 0x2977aa47 size of that city was 20,000,000 in Reader.

I had the OWW2 Beach lot most concerned, but never plopped it anywhere in the city. I have since removed the props in Reader.

I still have a backup of the city saved and am now playing a previous, undeveloped version of the same city, but I am concerned it will appear again.

[bap]

None of the plopable OWW beach lots themselves lead to Prop Pox. The modified Maxis props included in the corresponding OWW beach resource file are the ones that lead to Prop Pox. They are widely used in Maxis low-density residencial growable lots. The Pox appears after several Maxis lots with those modified props grow in a city tile and the 0x2977aa47 subfile reaches the 16 Mby (uncompressed) size. Thus, one alternative to prevent Prop Pox from appearing is having a mod which prevents Maxis residential lots from growing (this was already reported in this thread some time ago).

[Kuewr665]

That must be it. The city was a large tile low density city with mostly Maxis low wealth residential houses.

This is the city, since changed with low density medium wealth houses.



Note the stadium without seats in the southeast end, underneath a cloud. This was the first instance I noticed props disappearing from the city.

[rusekrax]

just to add a little more to the confusion, here is my humble commentary

I got the pox a while back, and solved it by completely overhauling my plugin folder, making sure there are no duplicate prop descriptions anywhere.
One entire region had to be rebuild, but has been free of the Pox ever since. In order to check I created a 1x1 lot with the maximum number of props. I bulldoze the entire city (after making a backup, of course), then plop the PropPoxCheckerLot 144 times to boost the prop file just beyond the 16 MB, then use the Savegame Explorer to see if I am in the green.

I also used that convenient PropPoxCheckerLot to conduct some more research, with the following results (Some have already been made clear, others seem a little obscure in this thread.)

- removing the following properties from a prop description will definitely cause the Pox:
   - "Simulator Date Interval", "Simulator Date Duration", "Simulator Date Start" (that's the seasonal props)
   - "Prop Time of Day" (the daily timed props)
   - "Nighttime State Change", when the value had been set to 1
   
- changing the property "Nighttime State Change" from 1 to 0 will definitely cause the Pox!

- obviously removing any prop description which contains any of these values will also lead to Pox (that would include roadside mods, and avenue mods, if you want to remove them, take the T21 exemplars out of your plugins folder, but leave the prop descriptions in place)

What does not cause the pox:

- changing the first value of each of the following properties to 0 will not cause the Pox:
   - "Simulator Date Interval", "Simulator Date Duration", "Simulator Date Start"
   - "Prop Time of Day"

- changing the "Resource Key Type", even from RKT1 to RKT 4 or vice versa

- even recalculating one of the most minimally described with the PIM-X did not lead to Pox

- adding any of the simulator values did not lead to Pox

- copying a prop, changing only the group id, removing any simulator values, and making sure it loads after the original, will make the game use the "un-simulated" for any new lots while still removing the "simulated" version properly when older lots are bulldozed or redeveloped (please note, the original prop description has to remain in the game)

I don't mean to say anything that did not cause the pox in my experiment is fine, there may be other problems, that did not show up in my test.


I still hope this helps a little,
My best wishes to any Mayors out there fighting this devious disease
rusekrax (aka Rane)

[Kuewr665]

I have prop pox in the same city now, showing up in the east of the city as usual. However, the 2977aa47 thing has a filesize of 5,049,168.

What happened?

[bap]

Kuewr665, the 2977aa47 file is saved in compressed format in the savegame whenever the props buffer size is below 16 Mby. Thus, the 5 Mby seems to be the size of your compressed 2977aa47 file (and it will keep shrinking as you have prop pox).

[Kuewr665]

So then, what size should I keep it at?

[Wiimeiser]

I just had a thought: How does deleting all instances of the broken prop not fix the problem? By all means it should at least stop it from getting any worse...

[z]

It's the deleted props that are the problem.  You don't get the prop pox until you start deleting both the correct and broken props.  Deleted props are stored in the saved game file, and the corruption spreads from them into the undeleted props as well.

[Kuewr665]

Wait, so deleting the props as advised on the first page actually worsens the problem?

[z]

Wait, so deleting the props as advised on the first page actually worsens the problem?

No; they were talking about deleting these props from you Plugins folder, which is important to do.  It's once they're in the game and you delete them there that the problem starts.

[jdenm8]

It's once they're in the game and you delete them there that the problem starts.

'Demolish or otherwise remove the lot it's on' is probably a clearer term.

[Wiimeiser]

So maybe it's clearing the wrong amount of data, which leads to the whole thing becoming horribly misaligned?

[jdenm8]

So maybe it's clearing the wrong amount of data, which leads to the whole thing becoming horribly misaligned?

That and/or it allocates too little data for the active prop when it's saved decompressed and either stops early (Unlikely) or continues writing into the next space without updating the index to reflect the new offset (Most likely what happens). It's not something we can fix without access to the source code.