Index
1. Introduction (http://sc4devotion.com/forums/index.php?topic=7066.msg224880#msg224880)
2. Hunting the cause of Prop Pox (http://sc4devotion.com/forums/index.php?topic=7066.msg224886#msg224886)
3. Face to face with a cause of Prop Pox (http://sc4devotion.com/forums/index.php?topic=7066.msg224888#msg224888)
4. How to avoid the problem (http://sc4devotion.com/forums/index.php?topic=7066.msg224892#msg224892)
5. Testing Prop Pox by yourself (http://sc4devotion.com/forums/index.php?topic=7066.msg229603#msg229603)
Introduction
What is Prop Pox?
A brief description is as follows. The last time you saved your city everything was fine. The next time you open it, you notice that props are missing from several lots. It includes props both in Maxis and in custom content lots, as well as street props. Parts of your city start looking strangely ... empty. Not all the city is affected, only some parts of it. The affected lots continue to work normally – you can query them as usual. If you destroy and replop the affected lots they will usually go back to normal, with all props appearing. But don´t foul yourself. If you save the city, logout and login again, you will notice that props are missing again, perhaps on different lots then at the previous time. It seems a waste of time trying to destroy/replop the affected lots and keep going, because the problem unfortunately spreads with time: every time you save the city, more and more lots are affected by this decease. This is way it was named "The Prop POX".
Prop Pox should not be confused with other bugs of similar graphical appearance such as the growing empty lots problem (see here (http://sc4devotion.com/forums/index.php?topic=907.0)) or when one runs one of Maxis updates (EP1 or BAT), which resets the graphics settings to low, making most of lots props to apparently disappear.
What do we know about Prop Pox?
Prop Pox was first reported about the same epoch by BruceAtkinson (http://sc4devotion.com/forums/index.php?topic=993.0), Snorrelli (http://sc4devotion.com/forums/index.php?topic=1201.0), and Fledder200 (http://sc4devotion.com/forums/index.php?topic=1322.0) back in April-May 2007. It is a rare decease. It seems only a dozen or so players have been affected among the thousands of SC4 users, most of them after early 2007.
Thanks to the patient collection of information over time and to several tests ( see here (http://sc4devotion.com/forums/index.php?topic=1201.0)) it was learned that:
1) It is not a graphical bug. Prop pox is not solved by making the graphics settings to high, nor by selecting hardware or software rendering.
2) It is not a computer memory issue or a conflict with other software. Desfragmenting and cleaning disc space as well as increasing virtual memory also doesn't solve the problem.
3) It is not a hardware or operational system problem. It occurs on both Windows XP and Vista, on all sorts of processors and video cards.
4) It occurs mostly on large (4 x 4 Km) city tiles, when most of the city surface is occupied/developed. It is not a matter of population, but of number of lots (and, or course, props).
5) The problem is in the city game save file (city_name.sc4 in the corresponding region sub-folder at MyDocuments/SimCity 4/Plugins/Regions). The affected city sc4 file shrinks by 200-400 Kby when prop pox strikes for the first time and continues shrinking if the users keeps saving the city after it is affected ( see here (http://sc4devotion.com/forums/index.php?topic=1201.msg46116#msg46116)). The sc4 city file is made up of a large number of subfiles, identified by TGI (Type, Group, Instance) addresses. It was discovered ( see here (http://sc4devotion.com/forums/index.php?topic=1201.msg57116#msg57116)) that the props in the city (including street props) are stored in the subfile of Type 2977aa47, also called the 'network' subfile. This file grows in size as the city develops. When Prop Pox strikes this file shrinks in size by 200-400 Kby with respect to its size in the previous save game file, causing the sc4 city file to also shrink. The next time you open the city those 200-400 Kby of props will be missing. They were lost in the save game process.
6) It seems a memory overflow somewhere is leading to the corruption of the network subfile and the city save file ( see here (http://sc4devotion.com/forums/index.php?topic=1201.msg164798#msg164798)). There was a suspicion that the EP1 update program could be the cause of Prop Pox. Another possible culprit would be a plugins folder infected by multiple definitions of a same prop.
Hunting the cause of Prop Pox
Below I describe the series of tests I performed in the search for a cause of Prop Pox.
My game directories are organized as follows. Buildings, Lots and Mods go into MyDocuments/SimCity 4/Plugins (hereafter MP), while Props, Textures and Maxis plugins go into ProgramFiles/SimCity 4/Plugins (hereafter PP). All tests were performed on large city tiles grown on suburbia style (mostly low density RC lots).
A) Initial frustration
The largest city in my region showed Prop Pox when its save file reached 15 Mby (network subfile of about 6 Mby). As a first test, I developed two comparison cities on a test region to see if they developed the pox too. Prop Pox appeared on each city as soon as their network subfile went beyond 6 Mby. Prop Pox is not a random problem. It is a systematic bug and will appear in every city the affected user develops provided they grow up to the proper size.
B) Two basic tests
I uninstalled and installed the game again from scratch, without performing the EP1 and BAT nightlightning upgrades. I also removed all lots from MP folder and started developing test City #1 only with Maxis lots. No custom lots. I saved a copy of the City #1 when it had 13 Mby for future tests. When the city reached 14 Mby (the network subfile reached the magic 6 Mby limit), Prop Pox made its appearance. I was about to believe there was some silly limitation intrinsic to the game when I realized I grew the city with all custom dependency props at PP folder. Whatever caused Prop Pox it was still there, being read by and affecting the program. (it sounded an obvious after thought, that if one is looking for a problem affecting props, one should concentrate on props and not on building or lots.) I tried removing the custom props from PP folder and further developed the pre-Pox saved version of City #1. It got Prop Pox when it reached 14 Mby. Even if the cause of Prop Pox is no longer in your game folder, if your city has been saved while the pox "virus" was there, you are infected and will get Prop Pox.
I developed another test city, City #2, this time removing everything from PP, including Maxis plugins. So, no custom content at all. Exclusively Maxis vanilla stuff. To my relieve, this city got no Prop Pox (this was the first time I developed a city beyond the magic 15 Mby size without suffering from the pox – lots of beer to celebrate this). I saved versions of this city while I was building it for future tests. City #2.1 has 15 Mby file size with a 5.5 Mby network subfile. When it reached the 15 Mby limit it was still far from the 6 Mby network file barrier. With only Maxis contents, the city has several hundreds of props less to store. I used City #2.1 for additional tests. I tried further developing the city in my laptop (largely different hardware setup) and with different screen resolutions. I got no Prop Pox in any case. Without custom content, no Prop Pox appears. This was a promising start.
Interestingly, the lack of Prop Pox allowed me to see an important effect. When the network subfile goes beyond 6 Mby, it increases suddenly to 16 Mby and the city save file accordingly grows by 10 Mby. This has nothing to do with Prop Pox. It seems a change in the way Maxis handles the information about props in the city. That's why I haven't seen anybody reporting a city save file with 17-24 Mby. It is either 12-16 Mby or larger than 26 Mby. It seems if one gets Prop Pox after the jump in network file size and starts loosing track of the props in its city, one will probably get back to the initial save size and ones city file will jump back to 14-15 Mby size after being on the 26 Mby size for a while. This is consistent with what Snorrelli reported.
C) Is the EP1 update responsible for the pox?
I installed the EP1 and the BAT nightlightening updates and further developed City #2.1 without anything in PP folder. The city goes up to 27 Mby in size with no sign of Prop Pox. So, the EP1 update does not cause Prop Pox (nor the BAT nightlightening update). I then installed only the custom props at PP and started developing City #2.1 again. Prop Pox strikes when the city reaches 16 Mby. I saved a version of this city prior to the pox appearance (City #2.2). I removed the now suspect custom props packages from PP folder and further developed City #2.2. Prop Pox strikes again at the same sc4 city file size. The cause of Prop Pox must be in one or more of the custom content prop packages. Once the city is saved with the infected file installed, it will get Prop Pox.
D) Narrowing down the search
I ran SC4Tools (merge file option) on all custom prop packages in search for multiply defined props. It was able to find several conflicts and hundreds of multiple definitions of props. I eliminated all conflicting and doubly defined props from the prop packages, installed the corrected files back on PP, and ran another test with City#2.1. Prop Pox sets in when the city reaches 16 Mby (again, network subfile about 6 Mby). Multiply defined props per si are not the cause of Prop Pox.
The 'virus' was still there. In order to find it, I performed binary search (take half of the prop package files out, test with the other half; if you don't find Prop Pox, you can eliminate the tested half from the exercise; take half of the other half and proceed with the testing). After several such tests, I was able to narrow down the search to only one file: a blend of props from Pegasus CDK3 and OWW2 packages. Only when this package was in PP folder, did the city developed Prop Pox.
I tested developing the City #2.1 with only the texture packs and Maxis plugins in PP folder. No sign of Prop Pox. I then added all other prop packages except for the suspect one, and installed back all lots in MP (except for the lots which depend on the excluded prop package). Almost all my custom content back. No sign of Prop Pox. (another box of bier to celebrate.)
I broke my Pegasus mega prop into its CDK3 and OWW2 parts and performed a few more tests to find that I only got Prop Pox when the PEG-OWW2_BDK_RESOURCE.DAT file was installed. Removing everything except this file from the plugins, I got Prop Pox. Including everything in the plugins except this file (and the associated lots), I got no Prop Pox.
Face to face with a cause of Prop Pox
I could have stopped at this point and refraining from using Pegasus' beach package. But I wanted to know specifically what causes Prop Pox and I also wanted to correct the problem, if possible, in order to continue being able to use that great package.
PEG-OWW2_BDK_RESOURCE's file has 19 props, of which 12 are time-dependent props. I did some binary search again. I removed everything from MP and PP leaving only the 7 non-time dependent props and developed City #2.1 again. No sign of Prop Pox. Getting closer.
Except for one, the time-dependent props in that file are modified versions of Maxis props (swimmers, picnic on blanket, beach chair & umbrella, etc) that Pegasus modded to appear only during beach time. One does this by creating another prop (i.e., using another instance number) with the modification from the original one. Unfortunately, four of the modified Maxis props (see below) were kept with their original TGI numbers. But because they were transformed into time-dependent props, their ResourceKeyType1 property (3 numbers to store) is now replaced by a ResourceKeyType4 property (16 numbers to store). This extra information requires additional 73 bytes for each prop.
Now, when SC4 game reads its vanilla files, it sets a buffer of Ni bytes to store the info of prop i in memory. When it later reads again the info of that prop in the custom prop file it find 73 extra bytes of information to store and it keeps writing beyond the expected final memory position of that prop. Thus, it overwrites other things and messes up the program buffer. This is memory overflow, an easy way of loosing track of how many props you have installed and where in memory the corresponding info starts/ends.
Prop Pox seems to be caused by the program reading again an already stored prop the exemplar file of which is of different size at the second read. This causes memory overflow and messes the information about props in the city. This becomes a problem (and leads to perceptible effects) when the number of props in the city is large enough for the network subfile to reach the 6 Mby limit where Maxis changes the way it keeps track of props (or at least the size of the buffer where it stores the props). For a medium size city (4 times less area), this limit should be about 1,5 Mby, For a small size city (16 times less area), this limit should be about 400 Kby. A player may not know he/she is infected by Prop Pox if his/her cities are not developed to the point where these limits are reached.
How to avoid the problem
If you want to avoid the above described cause of Prop Pox, you have the following choices:
1- Refraining from using Pegasus CDK3-OWW2 lots (the beach resource file contains a couple of SSH files used by the other OWW2 lots). Wait Pegasus to release a patch to his package correcting the problem props.
2- Open the PEG_OWW2_BDK_RESOURCE.DAT file with the ilive Reader, delete the items 11, 12, 13 and 14 (exemplar names R1x1x2_BeachChair_29B2, R1x1x3_PatioChair_290D, R1x2x2_Recliner_2911, and R2x3x2_$$Beachumbrella_2900), and save the file again. The three first props will no longer be time-dependent (the umbrella will still be time-dependent, appearing only during day time). But the lots will work fine. With no Prop Pox.
3- Open the PEG_OWW2_BDK_RESOURCE.DAT file with the ilive Reader, change the exemplar name (p.ex., add a PEG_ before each name) and the instance of the items 11, 12, 13 and 14 (mark each one and select "generate new instance"), and save the file. Load each of the beach lots into LotEditor and replace each occurrence of these props by the corresponding new PEG_* prop and save the lots. Replace the original lots by the modified ones. They will work exactly as designed, but will no longer lead to Prop Pox.
While the time dependent props of Pegasus' beach pack are a cause of Prop Pox, they may not be the only cause of it. Any other modding of Maxis prop which changes (=increases) the prop exemplar file size will equally lead to Prop Pox. For instance, Pegasus' beach pack was released on 2007 December 11, well after the original Prop Pox reports of BruceAtkinson, Snorrelli and Fiedler2000. Thus, their Prop Pox must be caused by another, possibly similar, memory corruption occurrence.
If you have Prop Pox and does not have Pegasus' beach pack, I suggest you scan your prop packages in search of modified original Maxis props. Changing the values of the properties of a Maxis prop is fine. Changing the number of properties (p.ex., adding a new property) opens a way to Prop Pox. You are also advised to search for multiply defined custom props. They may also lead to Prop Pox if the exemplar of the last read definition of the prop is larger than the first read one.
We found what causes Prop Pox, and we devised ways to avoid it or to find and eliminate the problem. However, at the time of writing there is no way to restore an infected city. I am afraid it would not be possible to restore poxed cities. It seems once the sc4 city file is corrupted, there is no way back. The best way to remedy this limitation is to make frequent backups of the region one is developing and to keep a record of when each custom content file was installed in ones plugins folders. If you find a custom file which leads to Prop Pox you can avoid the problem by eliminating (or correcting) the affected file(s) and by restoring a region backup prior to the installation date of the affected file(s).
It is worth noting that the file merge option of SC4Tools was not able to identify/warn the double definition of Maxis props in Pegasus prop file. It seems the program only searches for multiple definitions of custom-defined props. If this is right, being able to recognize redefinitions of Maxis props in custom files would be a great addition to this program on a future update.
I would like to thank all those batters and modders the work of whom led a great game to became even better. I would also like to thank ilive (Reader), Simrolle & Andreas Roth (SC4Tool). This work would not have been possible without their tools.
bap, this is the best analytical process I've ever seen in tracking down an "unsolvable" problem in SC4.
A well earned Karma point from me!
Quote from: bap on February 24, 2009, 08:53:46 AM
While the time dependent props of Pegasus' beach pack are a cause of Prop Pox, they may not be the only cause of it. Any other modding of Maxis prop which changes (=increases) the prop exemplar file size will equally lead to Prop Pox. For instance, Pegasus' beach pack was released on 2007 December 11, well after the original Prop Pox reports of BruceAtkinson, Snorrelli and Fiedler2000. Thus, their Prop Pox must be caused by another, possibly similar, memory corruption occurrence.
Pegasus has other releases out there that I'm sure employ the same modifications to Maxis material....Thank you for identifying the cause which should go a long, long way to helping people keep their hard work, as long as they have the knowledge to reverse-engineer Pegasus releases, until such time as he fixes the problem packages himself.
A karma from me too, for the same reason as Ripplejet :thumbsup:
And a 3rd from me. I usually try to avoid giving multiple Karma for the same thing, but 3 posts, 3 points, a million thanks!
That is :o :o :o Excellent A Grade information. Glad someone found a solution to it.
Joe
Ohh my wow a solution to the Prop Pox!!! WOW this is awesome Bap and a thank you over a million fold!!!! I wish I could give you a karma point for it...
It seems you have enough Karma points for this research yet :D but big thanks from me too! :thumbsup:
Your messages could be showed as a model of the research work
Adam
awesome testing process :thumbsup:
Thicky thread
Bap, even though I have never been a victim of the Prop Pox, I have followed the discussion on other threads whenever I could, and I must admit to getting a chill as I read through your post. And I realized it wasn't because the problem seems to have been solved, but because there are people like you who go to such lengths to make this game enjoyable and playable for all.
While I am a relative nobody when it comes to the mechanics of the game, I do enjoy playing it. And not just because it is a great game, but also because of the SC4 Community as a whole. You (and those who helped you) are a perfect example of the best of that community, and I offer you a huge thanks and :thumbsup:
Wish it could be more...
Sorry if this seems a bit dramatic, but I just had to let it out. :)
I have found an earlier instance of changing the file size of Maxis props without giving them new TGIs. It is in another Pegasus file - PEG Trail Parks III released in October 2004. This has three Maxis props in the PEG_TrailPark-Engine_305a.dat with the same TGIs but bigger filesize.
As bap seems to have the cities set up to test for the prop pox, would he care to test with this?
Edit: I also found many examples of modded Maxis props with the same TGI in PEG_CDK--IND_205.dat which was released in Dec 2004.
Much to my chagrin I also found that I could have contributed to this as well. I found a set of modded Maxis props that I did some time ago that have also been combined into BSC MEGA Props Misc Vol02 (http://sc4devotion.com/csxlex/lex_filedesc.php?lotGET=1771)
I have corrected these and uploaded the revised pack to the LEX. I am also checking other BSC packs to see if there are any other incidences in any other files.
I would like to thank Bap for the outstanding analysis performed here.
And a big thanks to Barby for taking the initiative to look into the BSC prop packs to assure us all that the BSC work is always as close to perfection as possible.
Thanks to yuo both,
Robin &apls
One thing that I am curios about... the existince of one of these files in your plugins, regardless of whether the lot is used or not, will still cause the prop pox?
And when you say it changes in size to the one in the memory... if the file was in the plugins from the start of the city will it still cause a proplem? And if I get the props out of my plugins now will it mean I won't get the pox? I have a city on the verge of getting it.. (ie got it, but I have a back up :)) so want to avoid it.
Quote from: Diggis on February 25, 2009, 05:11:41 AM
if the file was in the plugins from the start of the city will it still cause a proplem?
Yes, if I understood
bap correctly, you might have a "proplem" (is that the same as a "prop problem"? ::))
Quote from: bap on February 24, 2009, 08:48:11 AM
Even if the cause of Prop Pox is no longer in your game folder, if your city has been saved while the pox "virus" was there, you are infected and will get Prop Pox.
However, I'm not sure if that would be the case if the prop has only been in the folder, but not used in any lot in the saved city file...
If it wasnt used, I doubt it would have been saved to the city file, so wouldnt be there to break. So fixing/removing it before its used should work
Quote from: JoeST on February 25, 2009, 05:29:18 AM
If it wasnt used, I doubt it would have been saved to the city file, so wouldnt be there to break. So fixing/removing it before its used should work
Except from Baps post he indicates he got the prop pox with only Maxis lots used but all his prop dependencies installed, indicating the file is saved in some way... (d'oh, lightblub just came on) expect the prop that was modded was a maxis prop so could well have been used.
Quote from: Diggis on February 25, 2009, 05:49:42 AM
(d'oh, lightblub just came on) expect the prop that was modded was a maxis prop so could well have been used.
Right, I think all Maxis lots use Maxis props... ::)
Well, I feel the need to publically thanks bap for his clever finding, which has finally solved one of the most annoying SC4 "misteries" out there Thank You Very Much :thumbsup:
I suffered "Poxed" cities in SCR and Simtropia, a looong time ago, and I guess that all my current cities are "poxed" in one way or another. It is time now to find out all the corrupted props and fix them... and enjoy the game again without fearing what will happen the next time we open a saved city... ::)
Excellent work done of finding a solution to the "pox".
Thank you so much for dedicating your time and effort to finding a solution.
:satisfied:
TTC
I think Barby needs a K-point for taking the lead on checking BSC Props to make sure they are of high quality standards!!
Quite...it's a noble person that can admit to their own mistakes :thumbsup:
Quote from: callagrafx on February 26, 2009, 12:35:22 AM
Quite...it's a noble person that can admit to their own mistakes :thumbsup:
Indeed. Its so easy to just ignore a problem, but it takes quite a lot to admit a mistake, then actually fix it too. We could all learn from this example &apls
Quote from: XiahouDun on February 26, 2009, 02:33:18 AM
Indeed. Its so easy to just ignore a problem, but it takes quite a lot to admit a mistake, then actually fix it too. We could all learn from this example &apls
We and someone else, but I guess it will be a waste of time waiting to some of this problematic lots ever being fixed. ;)
Just a tiny question here: Is it safe to assume that any modified Maxis props are the blame for this?
I find it little unfair to say Pegasus is the cause of this. I, for one, use lots of Pegasus' work, but have never experienced any "prop pox" problem.
Quote from: Meastro444 on February 26, 2009, 08:40:03 AM
Just a tiny question here: Is it safe to assume that any modified Maxis props are the blame for this?
My understanding is that the issue is with props (in theory it could be any prop, I believe) that was modified but kept the original TGI values.
Quote from: Meastro444 on February 26, 2009, 08:40:03 AM
Just a tiny question here: Is it safe to assume that any modified Maxis props are the blame for this?
I find it little unfair to say Pegasus is the cause of this. I, for one, use lots of Pegasus' work, but have never experienced any "prop pox" problem.
No one said Pegasus was the
sole cause...indeed, Barby has discovered she'd done the same thing as Peg in an old prop pack, which she has quickly corrected. Unless your cities grow really quite large and a number of factors come into play, chances are you won't, or haven't realised. Bap's testing has been thorough, rigorous and done over a long period of time. With Ilive's reader, so much more can be done than Maxis ever figured we could (after all, LE is sooo basic), so I guess they never planned that people would make new instances of their props, change the properties but keep the same TGI. They also never figured we'd still be playing it in 2009
Quote from: Meastro444 on February 26, 2009, 08:40:03 AM
I find it little unfair to say Pegasus is the cause of this. I, for one, use lots of Pegasus' work, but have never experienced any "prop pox" problem.
Very few people play the same city tile(s) long enough for them to get a network prop file of more than 6 MB.
There is a lot more discussion about it in
snorelli's thread
The Prop Pox! (http://sc4devotion.com/forums/index.php?topic=1201.0), where distinguished members have posted about it, in addition to snorelli e.g.
Nardo69,
Bruceatkinson,
Fledder200,
jabezscratch,
silentbreaker,
Diamond,
Cowcorn,
Swesim,
ltrskn,
Piyer,
BarbyW,
j-dub, ...
You can probably recognize several of those from having CJ's at ST, where the prop pox was first reported.
I'd recommend that you read that thread to see how to check if your network prop file is even close to 6 MB yet.
On a side note, BAP has been accused by certain members of the community of "scare-mongering" and making false accusations. This thread is neither perceived, nor should it be, of scaremongering but the result of detailed analysis and logical testing, and as such has been endorsed by this site. While some willl deny the very existence of this problem, the evidence is there that it does exist and the information provided should allow players to avoid this problem in future. Burying ones head in the sand with a big sign saying "not my problem" is not helpful to this community IMO.
I find interesting the different points of view in our community about the Prop Pox Theory ??? ?¿
This Theory has been posted by an important and respected member and creator from our community, and since most, if not all, of the players have the pleasure to use his custom content, which has also been referenced in this topic, I think that this must be posted in this discussion as well. Pegasus is invited to post here whatever he feels the need to post, but usually he is a short-time man, and he is quite busy creating custom content, so I'll take the liberty to post his words here, to save him some time and for everybody to be informed about this new theory. The Non Prop Box Theory :o
(https://www.sc4devotion.com/images/plex/PropPoxbyPeg1.jpg)
(https://www.sc4devotion.com/images/plex/PropPoxbyPeg2.jpg)
I invite to all the members involved somehow with the Prop Pox issue to carefully read what is being said here, and seriously re-think about the Prop Pox Thing.... are you all sure that you are suffering such a "syndrome"?¿ . I am really starting to doubt if all the missing props I had in my cities are not just mirages...
In the meantime, thanks Barby for checking the BSC files, and fixing whatever is necessary to avoid the PP?¿ caused by any of them in the future. And thanks for taking care of mine as well. I'll admit that I get really mad when I go into modding ::) $%Grinno$% ....
I'm at a loss for words (yet somehow not surprised). I think my words from very early this morning have never held more true. Thank you again to Barby for her honesty and dedication.
I have never had the prop pox, but I've read both Peg and Bap's posts, and Pegasus has written thing's that have been explained in Bap's post, so I'd say he hasn't thought about what he wrote.
So just ignore it Bap, and well done on finding the cause of this problem. :thumbsup:
Jonathan
I haven't experienced the true Prop Pox because no city that I have ever been big enough. My biggest city is less than 10MB saved game with just over 2MB in the network file. However, I don't dismiss the problem as not existing as I have had seen enough reports of it over the years to accept it is a problem for some. Just because I haven't experienced it, even though I may have contributed to it via one file, doesn't mean I don't want to find a solution and correct any errors I may have made.
Quote from: BarbyW on February 26, 2009, 02:24:39 PM
However, I don't dismiss the problem as not existing as I have had seen enough reports of it over the years to accept it is a problem for some. Just because I haven't experienced it, even though I may have contributed to it via one file, doesn't mean I don't want to find a solution and correct any errors I may have made.
And this would be why I, and so many others in the community, respect you Barby. It would be so easy for you to just feign ignorance, then bash anyone supporting fixing the issues along with anyone who has ever expierenced it. If I could give you reputation points, you'd have gotten one from me for this thread, along with Bap.
How do I check if my cities soon will develop the prop pox?After helping Barby to check the size of her "network subfile" of her saved city files,
I thought others might be interesting in checking their own cities as well.
Let me first quote
bap from his findings:
Quote from: bap on February 24, 2009, 08:37:13 AM
It was discovered ( see here (http://sc4devotion.com/forums/index.php?topic=1201.msg57116#msg57116)) that the props in the city (including street props) are stored in the subfile of Type 2977aa47, also called the 'network' subfile. This file grows in size as the city develops. When Prop Pox strikes this file shrinks in size by 200-400 Kby with respect to its size in the previous save game file, causing the sc4 city file to also shrink. The next time you open the city those 200-400 Kby of props will be missing. They were lost in the save game process.
Quote from: bap on February 24, 2009, 08:48:11 AM
Prop Pox appeared on each city as soon as their network subfile went beyond 6 Mby.
In order to check the size of your city's network subfile, you need to open Reader.
Click
Open and find your
Regions folder under My Docs\Simcity 4.
Browse further into the region you want to check. In my example below the region is Ireland:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi232.photobucket.com%2Falbums%2Fee198%2FRippleJet%2FPropPox-OpenCityFile.jpg&hash=d1a1b75d3478466db62cf02c5a98abefae2957da)
In the example above I've chosen Dublin, which is the largest city I've built so far.
As you can see (if you understand a little Swedish), the size of the file itself is just 5 MB, so that's pretty encouraging.
Once you've opened the saved city, it will look as below in Reader.
Now, click the column heading
Type in order to sort the files consecutively, according to their Type ID's.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi232.photobucket.com%2Falbums%2Fee198%2FRippleJet%2FPropPox-SortType.jpg&hash=8815ef5f6dc6cd670692bfa1c0add745f0d7f8ad)
You may have to click twice in order to get them sorted starting with the lowest number on top.
After this, it should be easy for you to locate the file with the Type ID
2977aa47In the filesize column you can now see the size of that file (you may have to widen the column in order to see it completely).
As you can see, my network subfile is just 1,851,828 bytes... pretty far from 6 MB (which is 6,291,456 bytes).
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi232.photobucket.com%2Falbums%2Fee198%2FRippleJet%2FPropPox-Filesize.jpg&hash=a658f7b3453258e8be507fdaa51601c5d9bbe21b)
Thus,
no panic here at least! ;D
And no panic in any of my cities either. :thumbsup:
So we got a solution to fix the problem and a way to check to see if there is a problem at all right??? Thats what I am understanding at this point at least, so in other words if the prop pox strikes someone there is a way to reverse it or at least keep it from causing further damage... Plus there is a way to examine your cities if you so choose to see how everything is looking, it just takes a bit of little know how of the reader...
Does my understanding of whats happening sound right?
bap, thank you for the very enlightening and well-thought out discussion on the Prop Pox issue! It goes without saying it is greatly appreciated! :thumbsup:
And Tage, thanks for sharing that little tutorial there, too. I just checked my largest cities and didn't find any with Network subfiles larger than about 4.2MB, so I'm good to go.
-Alex
Quote from: Pat on February 26, 2009, 03:41:39 PM
so in other words if the prop pox strikes someone there is a way to reverse it or at least keep it from causing further damage...
Unfortunately there doesn't seem to be any way of removing the prop pox if your cities already are "infected".
The only thing you can do is not to play so long on it that the network subfile would become close to 6 MB in size.
It's at that point that the subfile wants to expand to some 16 MB, but fails due to the props not being saved correctly.
Now... Earlier I was lurking around when I found this.
What scared me, though, is that I'm using PEG's OWW2 Beach Lots in one of my largest cities... which is of concern... due to the fact that it supports a very large population of 300000 - 400000 people.
I ended up removing the modified exemplars and replopped the lots to be on the safe side. However, does this mean I'm now pox-free? Or is the city going to be forever doomed by this?.
- Allan Kuan
Quote from: RippleJet on February 26, 2009, 03:34:14 PM
How do I check if my cities soon will develop the prop pox?
Once you've opened the saved city, it will look as below in Reader.
Now, click the column heading Type in order to sort the files consecutively, according to their Type ID's.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi232.photobucket.com%2Falbums%2Fee198%2FRippleJet%2FPropPox-SortType.jpg&hash=8815ef5f6dc6cd670692bfa1c0add745f0d7f8ad)
You may have to click twice in order to get them sorted starting with the lowest number on top.
After this, it should be easy for you to locate the file with the Type ID 2977aa47
In the filesize column you can now see the size of that file (you may have to widen the column in order to see it completely).
As you can see, my network subfile is just 1,851,828 bytes... pretty far from 6 MB (which is 6,291,456 bytes).
Just a tip here, if you sort by filesize, it should be at the top.
Quote from: allan_kuan1992 on February 26, 2009, 10:57:56 PM
Now... Earlier I was lurking around when I found this.
What scared me, though, is that I'm using PEG's OWW2 Beach Lots in one of my largest cities... which is of concern... due to the fact that it supports a very large population of 300000 - 400000 people.
I ended up removing the modified exemplars and replopped the lots to be on the safe side. However, does this mean I'm now pox-free? Or is the city going to be forever doomed by this?.
- Allan Kuan
As you can see from Tage's post above yours, once a city is infected there is nothing that can be done (at present at least) to repair this. I would suggest you check the file size of your network file and see how close you are to seeing the problem appear.
One thing that I am unsure of, is if the file was in place from the moment the city was started will it be OK?
Quote from: Diggis on February 26, 2009, 11:30:54 PM
Just a tip here, if you sort by filesize, it should be at the top.
Quite right! :thumbsup:
Quote from: allan_kuan1992 on February 26, 2009, 10:57:56 PM
I ended up removing the modified exemplars and replopped the lots to be on the safe side. However, does this mean I'm now pox-free? Or is the city going to be forever doomed by this?.
If I understand correctly, you're doomed if the prop pox appeared ( or is present even if not visible ) ie your network subfile is bigger than 6Mb
I bet you get BarbyW' updated file, but I doubt you bulldozed all lots using it ? And I bet no one can give a list of lots using any of the offending props ( being from Peg or BSC ).
The best way if you don't want an already developed city to be infected ( if you're not yet ), is to keep your city under the 6Mb for the network ( and backup )
Thanks Stéph, you took the words out of my mouth! ::)
EDIT: Allan, can you check the size of the network subfile in your cities?
Regarding the size of that network subfile in my own cities, I noticed that Dublin above actually isn't my largest city, even by far.
My largest city (about 10 times the size of Dublin) is the one that I originally tested CAM in.
That one has a network subfile size of only 695,262 bytes.
Dublin is the city I've been testing all the seaports in, and thus a city that I've saved and resaved quite often (which I suppose is what those running MD's often do as well)... whatever that information is worth...
I've checked my Shosaloza and Little Italy cities and the biggest have around 2.3 Mb size, so, I guess only the ones close to full filled and on large quads would be more likely to have sizes over 6 Mb. &mmm
Quote from: Rayden on February 27, 2009, 03:08:46 AM
I guess only the ones close to full filled and on large quads would be more likely to have sizes over 6 Mb. &mmm
And those are the cities you've been developing for ever, and do not want to loose... &mmm
I need to clarify something in my mind....
You will only encounter this problem IF your Network filesize exceeds 6MB while the problem files are still located in your plugins folder, correct? If you remove the problem files (or in the case of the BSC prop pack, update it) before the network file passes the golden number, you will be OK?
Oh, and just in case you missed it, thanks to Pegasus for clearing the issue up ::) ::)
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi95.photobucket.com%2Falbums%2Fl151%2Fcallagrafx%2Fpegshit.jpg&hash=34c390ae406922f11ed3958afa3e424a31f721ff)
Quote from: callagrafx on February 27, 2009, 03:23:21 AM
You will only encounter this problem IF your Network filesize exceeds 6MB while the problem files are still located in your plugins folder, correct? If you remove the problem files (or in the case of the BSC prop pack, update it) before the network file passes the golden number, you will be OK?
No...
...at least not the way I interpret this:
Quote from: bap on February 24, 2009, 08:48:11 AM
I uninstalled and installed the game again from scratch, without performing the EP1 and BAT nightlightning upgrades. I also removed all lots from MP folder and started developing test City #1 only with Maxis lots. No custom lots. I saved a copy of the City #1 when it had 13 Mby for future tests. When the city reached 14 Mby (the network subfile reached the magic 6 Mby limit), Prop Pox made its appearance. I was about to believe there was some silly limitation intrinsic to the game when I realized I grew the city with all custom dependency props at PP folder. Whatever caused Prop Pox it was still there, being read by and affecting the program. (it sounded an obvious after thought, that if one is looking for a problem affecting props, one should concentrate on props and not on building or lots.) I tried removing the custom props from PP folder and further developed the pre-Pox saved version of City #1. It got Prop Pox when it reached 14 Mby. Even if the cause of Prop Pox is no longer in your game folder, if your city has been saved while the pox "virus" was there, you are infected and will get Prop Pox.
So, if you have any LOTs that use the problem props, they are also "carriers", as such and would still cause the Pox, if they remain? What about if these are removed too? Sorry, just trying to simplify....
Quote from: callagrafx on February 27, 2009, 04:05:14 AM
So, if you have any LOTs that use the problem props, they are also "carriers", as such and would still cause the Pox, if they remain? What about if these are removed too?
That would require you to identify all in-game and all custom lots using certain Maxis props (which have been used by virtually every lot builder, especially those aiming for no dependencies) that some time, somewhere have been modded without giving them a new TGI address.
And we still don't know if that would actually cure the city...
Following Pegasus on his site, I take the liberty to post my thinking here:
Pegasus deny of the Prop Pox cause is based on the fact modified props don't crash or produce the prop pox and lot of such props has been done
I mostly agree with him on that point
Where I disagree, is that no one tried to make the same thing ( ie modifying a prop like Bap described ) with a 6Mb network sub file. Given the replies here and at Simpeg we can all conclude that it is hard to get to that size, this is also why there is not so much people experiencing it.
If someone have a ~6Mb network subfile, then we can test the assertion that modified props don't crash or produce the prop pox no matter what the others parameters are
But where I totally disagree is that Pegasus is focussing on the fact that Bap explanation about memory overrun problem ( guessing on how a game written 8 years ( and even more ) ago is actually performing memory allocation - remember game programming is my working job ) instead of focussing on the fact that :
With an empty plugin => no prop pox
With an empty plugins but thoses modified prop => prop pox
Maybe Bap explanation about the memory problem is not true, but who really care, there is a problem with such props and the main visible difference with other props is that they are using same TGI. maybe there are other explanation, but the fact is there, theses props are the problem.
Given Pegasus is clearly against finding what might be the real problem with his props, and until someone find the exact cause ( if the memory one is not the one ) I suggest to follow Bap advice to remove the props from the offending dat file. But I really think it is Pegasus responsability toward the communauty to remove them and re upload the files. It will take him 2 minutes of his valuable time and will hopefully reduce the prop pox occurence.
Wow, bap... An answer after all these years... I'm stunned. Thanks so much for your patience and careful research. :thumbsup:
Although I can't understand the unwillingness of any creator to make a simple fix if there's even a chance his or her creation may be causing problems for users, I will happily modify the offending files myself. Can we make a list of "known offenders?"
I have checked BSC prop packs and corrected the only one I found with problems.
The only way to find possible problem props - I stress possible - is to check packs in Reader and look for incidences of props with a GID of 0xc977c536. These need then cross checking against simcity_1.dat to see if the IID has been changed. If it hasn't but the exemplar has been modded then this could cause a problem. Once that has been found then all lots containing that exemplar need bulldozing before the file has its IID changed. This will not cure the Prop Pox but may prevent it in future.
Maybe some of the community might like to compile a list.
OK, have been talking to Barby about repairing her files and whether the lots need to be updated or not. This is from a new user point of view. From what I understand, any city that has been built while one of these files is installed is going to get the Pox.
As I understand it the issue is making a static Maxis prop into a timed one without giving it a new IID. To repair this issue all props that have been modded in this way need to be given a unique IID.
If this is a stand alone prop (ie not in a family) then any lots that have used this prop will reference the original static prop, not the timed version, if they are not updated.
If this prop is part of a family then the family would need to be updated with the new prop IID and have the Maxis one removed, meaning any lot that references the family will get the new IID.
So it sounds to me that the lots DON"T need to be updated, unless you want the timed prop on lots that had the stand alone prop.
Can someone with a better understanding of game machanics pick holes in my agrument (or preferably confirm what I saying :P)?
I'm not a programmer so forgive me if my questions will be unprofessional or simply stupid ;D
1. Is it possible that such coincidence can exist between a custom prop and another custom prop? I can imagine that somebody modifies a prop created by another person, leaving its ID.
2. Is it possible that terrain textures could cause similar problem? I must explain it. The FSH file of terrain texture can consist of 1 or 2 PNG files, and it can have an alpha file or not. Let's imagine that we replace Maxis terrain texture consisting of 1 PNG by custom texture consisting of two PNGs. There will be more bytes of information about this second texture (am I right?), and the ID will be of course the same.
We can also make custom lot textures which have up to 4 "subtextures" appearing randomly. If they have unique IDs, everything is OK. But if somebody use them to replace any Maxis texture?
As an official SC4D Landscaper :D I felt the responsibility for checking something connected with ploppable flora and another similar stuff. You say that 2977aa47 subfile shouldn't exceed 6 MB. We can guess that using a large amount of ploppable trees can increase the savefile size significantly. It concerns also everything what we can find in the flora menu, ie. ploppable rocks, water and ploppable props made using the "Plopperizer" technique, such as Barby's new tractors and military vehicles. So I asked myself:
- Does ploppable flora increase the 2977aa47 file size and how much?
I made the following experiment:
1. I opened the new, clean large city file. 2977aa47 doesn't exist.
2. I covered all the tile by God Mode trees (Olympic Terrain Controller). 2977aa47 didn't appear. The same for another clean city tile covered by Mayor Mode trees. (This time I covered about 1/4 tile)
But where the game saves an information about flora? After some searching I found this place. This is a9c05c85 subfile. It doesn't exist in empty city savefile too and appears fter plopping first flora. If the large city tile is completely covered by trees, the a9c05c85 subfile has 1 587 175 B (1,587 MB). Quite a bit. It will be much more if we will use small props such as grass or small bushes. Why? Because the game saves an information about every prop - its ID and coordinates (x,y,z).
I made some experiments plopping trees, then Jeronij's TPW, then Barby's tractors one by one, saving the game each time and opening the city savefile. Of course I was only able to look at the code and check how much rows I see, if they change or not, and how much increases the file size. Here are results:
- every prop increases the filesize by 30-100 B. Not too much. 3 average trees + 1 tractor = 178 B.
- Some trees add 1 row of code to the file, but usually one prop adds 2 rows of code. At this occasion I checked that every prop is described (it would be possible that every tile would by described). Placing 5 identical small bushes on one tile I achieved 5x2 identical rows of code.
Conclusion: Everything from flora menu leaves an information in another subfile, not 2977aa47. So extensive use of flora doesn't increase this subfile size, so - knowing what you say - it doesn't increase the risk of Prop Pox.
I made also some other experiments. 1 average building increases the 2977aa47 filesize by 1,5 - 2 KB. Transit networks without buildings doesn't increase this file size. More experiments to come ;D
Adam
Thanks for those experiments, Adam. Since plopping a building increases the subfile by some 1 or 2 kB, I would assume that the game stores an entire copy of the building exemplar file. This seems to be true for civic buildings as well, which is causing all those "phantom slider" bugs if you edit a building's budget or capacity properties without bulldozing all instances first. Since the values from the modified exemplar file clash with the ones that are stored in the savegame, the budget gets completely screwed up and your budget sliders slowly go to zero over the time. I would assume that the game also stores a copy of all prop exemplar files in the savegame, this is why it can reach some 6 MB in large cities with lots of items. One should test thís by plopping a lot with a single prop and then using a modified (i. e. timed) prop and see if there's any (ever so slight) difference in the filesize.
I don't think that textures are creating any problems, though, since you can edit the textures on a lot, and after loading the game again, the textures are changed - however, plopping a lot when some props are not installed won't get back the props if you install the dependency files afterwards, so you have to bulldoze the lot and replop it. Maybe texture references are stored somewhere, but apparently not in the network subfile (and you already found out that flora items are stored somewhere else as well).
Quote from: Andreas on February 27, 2009, 11:54:07 AM
Thanks for those experiments, Adam. Since plopping a building increases the subfile by some 1 or 2 kB, I would assume that the game stores an entire copy of the building exemplar file. This seems to be true for civic buildings as well, which is causing all those "phantom slider" bugs if you edit a building's budget or capacity properties without bulldozing all instances first. Since the values from the modified exemplar file clash with the ones that are stored in the savegame, the budget gets completely screwed up and your budget sliders slowly go to zero over the time. I would assume that the game also stores a copy of all prop exemplar files in the savegame, this is why it can reach some 6 MB in large cities with lots of items. One should test thís by plopping a lot with a single prop and then using a modified (i. e. timed) prop and see if there's any (ever so slight) difference in the filesize.
Yes, the game stores an entire copy of the building exemplar for every building placed in the city. But these exemplars are outside of our "critical" subfile.
Yes, it is true for civic buildings as well, I checked it for power plant and water tower.
Edit: Your proposition, Andreas, about careful checking the subfile size with a single prop can be difficult to perform. I noticed small but strange changes:
- After opening the game, doing nothing and saving, the subfile size increased by 19 B.
- After placing the Wave3 Freestream Mod (1 piece) the subfile size
decreased by about 20 B. And I didn't bulldoze anything!
Been doing a small test. After each change I ran the game saved and exited.
Medium city tile
No custom stuff at all.
Opened city, named city. Savegame file size 226k
Plopped wind turbine. Savegame file size 227k
Plopped community garden. Savegame file size 229k
Plopped small park green Savegame file size 232k Network file appeared
Added Peg's Trail Park Fountain Plaza to plugins
Plopped plaza Savegame file size 247k Network file 3667
Bulldozed plaza Savegame file size 234k Network file 747
Removed Trail Park fountain Plaza
Added Trail Parks 305a
Plopped a single section Savegame file size 234k Network file 1010
Added a x3 section Savegame file size 236k Network file 1641
Added single tile plaza Savegame file size 238k Network file 2584
Bulldozed all trail park pieces Savegame file size 240k Network file 748
I am using these files as they have no external dependencies but do contain modded Maxis props with original TGIs. I shall continue tomorrow with some BSC stuff.
I am computer stupid and know nothing about modding, but I am interested in what's happening here, because I have one infected city, and one I think will get the pox soon. Both are large city tiles with populations over a million. The city that is poxed has a .sc4 file size of 50.8mb, and a 2977aa47 file size of 18.5mb. There is one other large file in that city - 6a0f82b2, which is 24mb. (I have no idea what that means.) The city that I think will fall victim soon has a .sc4 file size of 59.9mb and a 2977aa47 file size of 19.4mb. The 6a0f82b2 file in that one is 30.6mb. There are no other files over 5mb in either city. I hope that info can help. I use downloads from both Simpeg & SC4D.
I have another question - in poxed cities, there is a phenomenon of peeps showing up in a crowd in the upper left corner of the tile. How might this be related? I went into my poxed city last night & observed that they are time dependent - a huge crowd shows up at 8am, and there are only a few in the corner at night. And, well, this really sounds nuts, but if you look at the bottom edge of that corner of the tile, you can see peeps appearing, and some sort of weird shadow. I have pics, if anyone is interested. It sounds crazy, but that's what I saw.
Thanks.
Kendra
%confuso
Honestly, I'm starting to worry for my cities now, and this has begun to scare me just a little. It's one thing to have a temporary glitch like the Water Bug affect a city; at least that is not permanent. It's another to have something like Prop Pox occur that could permanently ruin a good city. If the props disappear as a result, are they gone for good? At least my cities are small enough in file size (despite being large quads) that they won't be affected by this crazy epidemic. Whatever it is, it sounds positively frightening. Thankfully, I have enough advance warning to start monitoring my file size before anything bad happens, but I do have and use some of the mentioned content. Does using it at all automatically set me up for Prop Pox, or should I just not use too much of it?
%confuso
Okay...
All three cities currently are in the 3000 - 4000 KB range (total filesize), which means 3 or 4 MB I think. Not bad I guess.
However expansion is planned for two cities (Oceania and Vanier), which are both around 3922 to 3942 kb. There's still some space left for it to grow.
The other city (Mount Oceania) may grow still but I tend to have trouble building on hills with skyscrapers xD. However, if I do (probably with suburban housing) the file will certainly bloat quickly (it's at 4230 kb at the moment).
I have replopped all beach lots after changing the exemplars (although i didn't destroy them beforehand).
I'll stay on the lookout for other potential problems... but so far so good...
- Allan Kuan
I am now totally confused. On 26th Feb Pegasus stated:
QuoteThe game save file is an XML file and one of the sub files within it is the network file that stores the street and street prop data.
On 27th Feb he said:
QuoteYou can remove or add almost anythig you want to the save file... and the city will still load. Its in XML format so its very flexible... and certainly does not use predefined memory locations or data block sizes. XML just don't roll that way
After being asked how to display the file in XML Peg posted a screenshot of a Hex Editor screen and the following:
QuoteOh... any old sector editor will do. There's one in the reader. No so great... but its integrated so helpful. I've used it to create HLS files for random query sound effects.
You are so not from the DOS era.
Yea!! Chalk one one for the Old School!!
I have used a Hex Editor many times in the past - yes I am from the DOS era - and this does not appear to be the same as XML which looks like this:
Quote<recipe name="bread" prep_time="5 mins" cook_time="3 hours">
<title>Basic bread</title>
<ingredient amount="8" unit="dL">Flour</ingredient>
<ingredient amount="10" unit="grams">Yeast</ingredient>
<ingredient amount="4" unit="dL" state="warm">Water</ingredient>
<ingredient amount="1" unit="teaspoon">Salt</ingredient>
<instructions>
<step>Mix all ingredients together.</step>
<step>Knead thoroughly.</step>
<step>Cover with a cloth, and leave for one hour in warm room.</step>
<step>Knead again.</step>
<step>Place in a bread baking tin.</step>
<step>Cover with a cloth, and leave for one hour in warm room.</step>
<step>Bake in the oven at 180(degrees)C for 30 minutes.</step>
</instructions>
</recipe>
Ref: http://en.wikipedia.org/wiki/XML#.22Well-formed.22_and_.22Valid.22_XML_documents
Could one of our more knowledgeable members please explain if these formats are the same or different?
HEX and XML are distinct and no, XML doesn't need to be read with a HEX editor. Obviously the person in question is simply making it up as he goes along, without really knowing what he's talking about. ::) XML (or Extensible Markup Language) was developed as a way to create simple databases whose data could be re-purposed...in effect a repository of data that could be read by a variety of different sources and displayed. I have used it in the past to create a database of product that was part of a Director program, at the same time as a web app. All you need is Notepad. I'm pretty sure the gamesave file is proprietary to Maxis....it just includes SOME markup.
Sir Arthur Conan Doyle wrote "When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth." Bap has done that and come up with the theory that Maxis props, remodded to be timed, but retain the original TGI will cause the issues (and it is an issue with props, after all). This has been accepted by pretty much all of the modding community with the glaring exception of the person who's releases are suspected of causing the issue. It takes a big man to admit when they're wrong..... ::)
Quote from: Pegasus
Yes... absolutely. And its my humble opinion that that should have been done before the folks at SC4D went nutso with the doom and gloom, started a panic, changed their files and pressured other developers to do the same. I feel that was irresponsible to do based solely on a single post by an unknown individual before any attempt to validate the claims was made.
To clarify, no one's gone "nutso" or are scaremongering or are pressuring anyone to change their files...If Peg wants his stuff to be the cause of the loss of peoples' work, then that's his perogative.
Stage 2 Testing with BSC works. In each case city was run then saved and exited after each addition or bulldoze.
Added deadwood's Raised Parks plus all dependencies. Plugins is now 87.4MB
Opened test city. Plopped nothing. Network File 747 Savegame file 243
Plopped one corner piece. Network File 910 Savegame file 237
Added single tile with tree Network File 946 Savegame file 237
Added 3x3 market Network File 2497 Savegame file 248
Added 2x2 with azaleas Network File 3328 Savegame file 247
Found I had missed a prop pack so added it. Plugins now 92.3MB
Bulldozed and replopped all above Network File 4588 Savegame file 250
Bulldozed all Network File 748 Savegame file 238
At this stage there are no roads or any other form of transport network in the city.
Stage 3 Testing with BSC Basic Parks set plus all dependencies. Plugins is 66.6MB
Nothing plopped Network File 748 Savegame file 237
Single tile with bench Network File 1056 Savegame file 247
Added single tile with flowerbeds Network File 1225 Savegame file 240
Added 3x3 with SG fountain Network File 3913 Savegame file 246
Added 2x2 Azalea Park Network File 5606 Savegame file 259
All bulldozed Network File 748 Savegame file 240
There are still no transit networks of any type in this test city and I believe that the sub file is misnamed and should be Prop File.
Quote from: BarbyW on February 28, 2009, 02:51:20 AM
There are still no transit networks of any type in this test city and I believe that the sub file is misnamed and should be Prop File.
That seems pretty obvious. ;)
Especially after Adam's testing:
Quote from: Ennedi on February 27, 2009, 11:42:51 AM
I made also some other experiments. 1 average building increases the 2977aa47 filesize by 1,5 - 2 KB. Transit networks without buildings doesn't increase this file size.
With the help of Dustin, Barby posted a comment on Simpeg explaining what she had corrected in the one prop pack where she had included modded Maxis props with unchanged TGI addresses.
She had added the property
Building/prop family to them, which increases the size of the prop exemplar with 5 bytes.
Since...
Quote from: Pegasus on February 28, 2009, 02:54:56 AM
Note - No further comments or propaganda from the BSC will be accepted in this topic or anywhere else on this site regarding this matter. They will be deleted immediately.
...I will have to reply to Pegasus here and correct him on one particular statement:
Quote from: Pegasus on February 28, 2009, 02:54:56 AM
Barby... Dear... changing a prop's family or adding it to a family... has ab-so-lute-ly nothing to do with what Bap stated about the issue with modified props. You changed the material and propagated further panic for absolutely no reason at all. That's not "erring on the side of caution"... that's an irresponsible knee-jerk reaction to mass panic.
This is what
bap has said about the size of the prop exemplar:
Quote from: bap on February 24, 2009, 08:51:00 AM
Face to face with a cause of Prop Pox
Prop Pox seems to be caused by the program reading again an already stored prop the exemplar file of which is of different size at the second read.
Quote from: bap on February 24, 2009, 08:53:46 AM
How to avoid the problem
While the time dependent props of Pegasus beach pack are a cause of Prop Pox, they may not be the only cause of it. Any other modding of Maxis prop which changes (=increases) the prop exemplar file size will equally lead to Prop Pox.
I agree with Alex (Tarkus) and Andreas (as posted on Simpeg), can we please keep this civilized, and only discuss
bap's findings?
Some of you say that the savegame file subfiles are of XML format. Would it be possible to decode them and see what data exactly are written in them?
Quote from: Ennedi on February 28, 2009, 04:12:10 AM
Some of you say that the savegame file subfiles are of XML format.
The savegame format (like all other game files) is in Maxis proprietary
DBPF (http://www.sims2wiki.info/wiki.php?title=DBPF) format.
Quote from: Ennedi on February 28, 2009, 04:12:10 AM
Would it be possible to decode them and see what data exactly are written in them?
That would be a test with plopping a lot with a single prop and saving the city...
Then checking the prop subfile (2977aa47) and comparing any newly added data with the prop exemplar itself...
There seems to be a misunderstanding with what the XML format is.
Instead of rewriting it here, I'll copy a post that Andreas made,
comparing the HEX representation of the prop subfile's DBPF content,
and the content of an XML file, also included in a Maxis game file:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi232.photobucket.com%2Falbums%2Fee198%2FRippleJet%2FXMLvsHEX-1.jpg&hash=5a2ff5b3575f0234acb9df314084546c5a178cb1)
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi232.photobucket.com%2Falbums%2Fee198%2FRippleJet%2FXMLvsHEX-2.jpg&hash=c5be0e523a87b81214357468f17b434aaf441a3b)
The structure of the prop subfile (2977aa47) is so far unknown, as the case is with most subfiles in a saved game file.
Because of that Reader doesn't provide a decoder for it, and can only show it in HEX or garbled text format.
Well, I have to say I've found all of this very interesting. Bap's approach to the testing impressed me very much and gives much credence to his findings - well done on this piece of work.
Luckily I've never been effected by PropPox but of course am concerned by it. I did some checking that RippleJet suggested to see the size of my network sub folder in my West End cities. I have three that have exceeded the 6MB file size:
Kingly: 18,700,726 (lots of P-E-G canals and custom lotted buildings - I spent three months on this one quad so am not surprised it is so big)
Carnaby: 16,654,648 (contains a modular airport with quite a few custom lots)
Piccadilly: 6,362,324 ("normal large quad with lots of custom lots)
None of these cities have been infected/affected. I've checked my plugins (I keep a seperate plugin folder for each city to allow for diversity of building styles) and can see that I do not have any of the P-E-G OWW2, CDK-IND or Trail Parks and nor do I have BSC Mega Props Misc Vol2. So even though these cities are larger than the 6MB size, the absence of the prop pack already identified with problems seems to suggest that I do not have any props with the PropPox problem. But it should be noted that I did use P-E-G's canals extensively in Kingly but assume that these do not use any Maxis props that have been modified.
My concern however is with the quad I am currently working on which is almost complete. The city of Hanover has a network file size of 6,214,290 which is VERY close to exceeding 6MB. This is the first quad I've developed using virtually all of the content from the LEX disc (I just wanted to see how it would look). One of the prop packs in the plugins folder I created for Hanover is BSC Mega Prop Pack Vol2.
Now given this - the fact that my city is close to going over 6MB and it has one of the infected prop packs, I am happy if this quad is used for testing. I will make a back up of the quad as it stands and not do anything else with it yet. If someone would like to test it please PM me and I can email you the quad file plus a list of the plugins folder, or even just send the whole file (if that's something that's allowed). If there is a simple test that I can perform then let me know and I'll happily share the results here.
Once again, great work Bap - I know this has been one of the unsolved mysteries of SC4.
In one of these posts I seem to remember reading that if the original maxis props load after the modified versions, the problem would be avoided. Is this correct or did I misunderstand? In other words, if I placed simcity1.dat in a ZZZ folder, would that solve the problem?
Quote from: snorrelli on February 28, 2009, 05:36:28 AM
In one of these posts I seem to remember reading that if the original maxis props load after the modified versions, the problem would be avoided. Is this correct or did I misunderstand? In other words, if I placed simcity1.dat in a ZZZ folder, would that solve the problem?
If it would really solve the problem, you should extract only props data from simcity1.dat and place it into zzz subfolder. In other case you would lose the possibility of using lot of valuable things such as terrain mods, custom transit networks and many others.
Paroch I think you'll need to post your file somewhere on the net so we can investigate, first only the savegame
If I can't load it, I'll ask for a plugin list. I'm also interest in seeing a screen shot of your city with network visible, so I can get a rough idea of what is needed to get a subfile close to 6mb
At least you proved half of Bap's assumption. I hope you're known enough in the community to be trusted and no one will discuss your report
I just want to go on record to answer this comment made by Pegasus on his site (he is free to post here, but seemingly hides behind his admin tools ::) ):
Quote from: PegasusI will again ask that the BSC keep their speculations to themselves and stop trying to use this unjustified scare to further their own agenda.
First, this has absolutely nothing, zero, nada, the square root of sod all, to do with BSC....these findings were made by a member not affiliated with any team, organisation or alliegance. To suggest otherwise smacks of a persecution complex. Second, this is not an unjustified "scare"....the Pox is real and all evidence to date points to mis-modding practices. Third, the BSC "agenda" hasn't changed from when it was founded, to provide assistance, advice, guidance and quality to the hundreds of BATers, MODers, LOTers and game players for SC4. The BSC is not the Illuminati, despite what people and their "acolytes" mistakenly believe. ::)
Sticking purely to facts, I am posting the latest round of testing which convinces me even more that the network file should be called the prop file.
Using the same city as before I added in my BSC Props, BSC Textures and my BLS folder. These are all uncompressed and made a plugins of nearly 2GB. The three original Maxis items - the small park, wind turbine and community garden have been left in place throughout all the previous tests and also this one. As before after each line the city was saved and exited.
City opened but nothing added. Network file 747 Filesize 248
Added single tile with water spout Network file 804 Filesize 246
Added swi rail crossing bridge Network file 3148 Filesize 247
Added SNM MAAM Halifax Park Network file 5392 Filesize 261
Bulldozed all including the 3 Maxis items. There was no network file in the savegame file and the Filesize was 244.
Paul, so far as I can see, and I admit I haven't checked all the CSK files as I don't have them all, the only one with Maxis props that have been modded but with the original TGIs is the CSK Fountains. These are the same in the Trail Park fountain as well.
Hey Lee I could have sworn I seen this around floating ;)
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg22.imageshack.us%2Fimg22%2F4278%2Filluminatitwo.jpg&hash=2e840b8b3cf7f9ab666cbc02685af5574a38795f)
Sorry I couldn't resist it... :D
I think its pure well you know what!!! But anyways I know first hand how hard you all work to help everyone including myself on several dozen occasions even when I was part of BLaM/LBT and now on ITC when I needed help when a team mate didn't know the answer someone from BSC was there helping me out!!!
Thank you to all of BSC!!!
Pat, the biggest thank you in this thread belongs to
bap! :)
Quote from: RippleJet on February 28, 2009, 04:27:58 AM
Quote from: Ennedi on February 28, 2009, 04:12:10 AM
Would it be possible to decode them and see what data exactly are written in them?
That would be a test with plopping a lot with a single prop and saving the city...
Then checking the prop subfile (2977aa47) and comparing any newly added data with the prop exemplar itself...
With the help of Barby I decided to try to take a look at the file structure of the prop subfile (2977aa47).
Barby created a custom park with one single Maxis prop on it, the portable toilet, TGI 0x6534284A, 0xC977C536, 0x03040000.
It's a static prop that looks like this in Reader's Exemplar Analyser:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi232.photobucket.com%2Falbums%2Fee198%2FRippleJet%2FMaxisPropPortableToilet.jpg&hash=56e3b3a129b03e56b021be6d895373f0185f8201)
Barby plopped this lot in a new city, saved it and sent the SC4 file to me.
The size of the prop subfile (2977aa47) size was 88 (0x58) bytes.
After this Barby made a mod that changed this Maxis' portable toilet prop into a timed one.
However, she kept the TGI address unchanged:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi232.photobucket.com%2Falbums%2Fee198%2FRippleJet%2FMaxisPropTimedPortableToilet.jpg&hash=80925641b0b82e5ef660163f4f3caf3915fa67ad)
Back in the city she plopped another of these parks, and saw that the prop was now timed.
She saved the city, exited, and sent it to me again.
The size of the prop subfile had now increased to 120 (0x78) bytes.
Comparing the prop subfiles to each other was the next step, and this is where it might become interesting.
The first DWORD clearly indicates the size of the record (0x00000058 and 0x00000078):
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi232.photobucket.com%2Falbums%2Fee198%2FRippleJet%2FPropSubfileSizeIncreased.jpg&hash=0103a4fbece1a781e4cd3d28cc57283bd67f41ab)
There are two chunks of numbers that are identical, underlined in yellow.
There is also clearly a reference to the TGI address of the prop exemplar:
0x6534284A - underlined in green is the Type ID
0xC977C536 - underlined in blue is the Group ID
0x03040000 - underlined in red is the Instance ID
However, and this is the alarming bit, it seems as if the instance ID has changed to 0x05040000 in the second file.
There are also fewer bytes between the yellow chunks and the TGI address in the middle.
If the Instance Address has changed to an invalid one, the prop exemplar would of course not be found.
- There is no prop exemplar with the address TGI 0x6534284A, 0xC977C536, 0x05040000.
- There is a prop exemplar with the address TGI 0x6534284A, 0x47BDDF12, 0x05040000 though.
On the other hand, we do know that Barby could clearly see the now timed props in her city...
I'll stop speculating here...
As we don't know what the other numbers in the prop subfile are, we cannot draw any final conclusions.
None of those numbers seem to match any property values in the prop exemplars at least.
Quote from: RippleJet on February 28, 2009, 11:57:25 AM
(...)
However, and this is the alarming bit, it seems as if the instance ID has changed to 0x05040000 in the second file.
There are also fewer bytes between the yellow chunks and the TGI address in the middle.
If the Instance Address has changed to an invalid one, the prop exemplar would of course not be found.
- There is no prop exemplar with the address TGI 0x6534284A, 0xC977C536, 0x05040000.
- There is a prop exemplar with the address TGI 0x6534284A, 0x47BDDF12, 0x05040000 though.
On the other hand, we do know that Barby could clearly see the now timed props in her city...
(...)
1. Which prop is described by this second exemplar with changed Group ID (0x47BDDF12)?
2. Maybe it wouldn't be difficult to get to know which props are collected in this group?
3. Maybe changing a prop to timed one forces moving it to another group, and the game do it automatically? Everything would be OK in this case.
4. I understand that the whole TGI must be different for different objects, ie. if the Instance ID is the same, but Group IDs are different, addresses are different?
Hello everybody,
First, thanks a lot for the several positive and encouraging messages. This certainly makes it worth the large amount of time spent in doing careful but boring city developments in seach for the cause of Prop Pox. I underestimated the impact this thread would have in the SC4 community. I was not prepared to drop by and answer questions at the pace needed to handle the rate at which posts are appearing here. Thank you to all of you who have taken this responsability. Thank you RippleJet for the illustrative tutorial on how to check the size of one´s 2977aa47 props subfile (yes, I agree with Barbyw that this file should be better renamed as the props subfile).
CaptCity: I share your feelings about the SC4 community. I appreciate being part of it, and benefit from the dedication & hard work that hundreds of people put towards making this nice game an even better one to play. SC4 would certainly not be so fun if it was not by the great custom content and modds people developed over the years, and by the fan sites where you can see how other players build their cities and where you can share your experience and problems with other players. The nuisance of being not treated respectfully and of seeing your work subject to prejudice and rough irony over one specific site is fortunately not able to change that feeling.
Snorrelli: I am glad to see your here again. I was afraid you had quited playing the game. As you see, your efforts to understand what causes Prop Pox was not in vain. I share the relief with & credits for the findings presented here with you and all those who posted at the original Prop Pox thread.
Barbyw: I appreciate your fast response to the results presented here. It is fine to give new instances to the affected props, as this allows lot makers the chance to edit their lots and replace Maxis prop by the modded one with new instance. But it would also be fine to simply drop the modded props from the dependency file and let the lots that use them appear with the original, unmodded Maxis props. Loosing some time dependent prop behaviour in a few lots seems a fair price to pay to avoid Prop Pox. I am performing other tests concerning Prop Pox and I will be glad to test the other suspected props you already found as soon as I can.
Diggis: As RoppleJet said, if you have an affected prop in your plugins folder but it is not used in any of the lots installed in your city, then you are on the safe side. The problem with those specific props that cause Prop Pox is that they are part of two prop families (A000005E for the beach & patio chair and the recliner, A0000001 for the umbrella) that Maxis used to fill the backyard of almost every low density residential lot. One swallow alone does not make summer, but hundreds of them do. A couple of props with extra bytes floating in the save game file apparently do no harm; but it is a different story when there are hundreds of them. Pegasus beach lots themselves, do no harm. But the infected Maxis low density residential lots do if there are several of them in the city.
Ennedi: there is no such thing as a stupid question, although there may be stupid answers. Thanks for sharing the results of your experiments. It will be great to hear about your new findings.
In his reply to Pegasus´ arguments Callagrafx made an important point. Maxis only gave us the LotEditor, BAT and Plugin Manager. When they developed the game, they expected us to create new lots with existing buildings and props, and later to add our own buildings & props to the game. Thus, it is reasonable to imagine they were careful in the way the information about lots and buildings are stored in the game. This must be flexible & robust to account for things the users would do outside of the game creators control. However, they didn´t created the Reader or SC4Tools. They did not expect us to modd the game, to change their stuff. In particular, there is nothing in LotEditor or Plugin Manager that allow one to change values or add new properties to Maxis props. Thus, it would not be a surprise if the way props are stored in the game are not as protected or flexible as the way lots and buildings might be. Writting props as a fixed-length array in memory is only foolish and poor programming practice if the programmer expects those variables to change in size somehow. More specifically, if they could imagine the same prop (same TGI address) would be read several times while loading the game, and that the prop will have different sizes at different time it is read. Could they imagine we would do that back in 2003 when the program was written? Maxis programmers were not foolish. They simply did not expected us to change their game the way we do. We don´t know what is in the EXE file. We don´t even know how the information is stored in the sc4 game save file (at least not yet). We have been doing modding at our own risk for more than 5 years. It shall not be a surprise that we "touch the wrong button" here or there. Prop Pox seems to be just one of such cases.
Cheers,
Bap
"Everyone is a fine person when every thing goes fine. The real character of a person only appears when he/she is under pressure."
I am not sure what to do really, one says it's there, someone else says it doesn't. Confusing and disturbing, to me anyways.
I am curious, though not sure if it will work; Is deleting the props subfile, while running the game (and having loaded the city) a 'cure', so to speak? If I interpreted all these posts correctly, the 'pox' is triggered, so once infected it stays. But if there is no file to be infected, could it be cured?
It's an idea, though I am not sure if this will be deleted.
No, you can't delete the "props" (or "network") subfile, as this would result in a complete loss of all props in your city. PEG claimed that he recognizes the file structure, so if he actually has that knowledge, maybe you can ask him how to proceed with such a task.
It is good to see you, bap. I hope you realise that here we are trying to help and find a solution.
The thread at SimPeg is now locked but I am posting here a copy of his final post:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi5.photobucket.com%2Falbums%2Fy171%2Fbarbyw%2FPegfinalreply.jpg&hash=c2163f716b3212aeab7e29104e5a5843bc72aaae)
Unfortunately he makes one incorrect assumption as several of his earlier files contained modded Maxis props with original TGIs.
CDK_IND_205.dat - dated Dec 2004
Trail_Park_Engine_305a - dated Oct 2004
These are two that I found with dates from 2004. His Snake Petting Zoo dated Dec 2003 also has modded Maxis props with the original TGIs but that has only been available on his CD for some time now.
I have no idea if these files may cause the Prop Pox but am not happy that the person responsible for irresponsible modding for a number of years is not willing to either come and post his views here or to accept that he may, just may, be wrong.
Quote from: BarbyW on February 28, 2009, 01:26:58 PM
It is good to see you, bap. I hope you realise that here we are trying to help and find a solution.
The thread at SimPeg is now locked but I am posting here a copy of his final post:
(//)
Unfortunately he makes one incorrect assumption as several of his earlier files contained modded Maxis props with original TGIs.
CDK_IND_205.dat - dated Dec 2004
Trail_Park_Engine_305a - dated Oct 2004
These are two that I found with dates from 2004. His Snake Petting Zoo dated Dec 2003 also has modded Maxis props with the original TGIs but that has only been available on his CD for some time now.
I have no idea if these files may cause the Prop Pox but am not happy that the person responsible for irresponsible modding for a number of years is not willing to either come and post his views here or to accept that he may, just may, be wrong.
I have them both... This is without mentioning that there may be other, non-PEG, modified Maxis props among custom content available from the STEX at that time.
Quote from: Meastro444 on February 28, 2009, 01:15:14 PM
Is deleting the props subfile, while running the game (and having loaded the city) a 'cure', so to speak?
That would actually instantly trigger the prop pox, as Wouanagaine showed when he removed the prop subfile (2977aa47) after it was discovered that the source of the pox was in there:
Quote from: wouanagaine on January 03, 2008, 11:46:10 PM
I removed the 0x2977aa47 of one of my savegame and I've got a lot of prop disapperead ( not networks props but lots ). I still have some props, my first guess is that I still have those that are 'timed' props, which may be saved in an other subfile
as you see, a typical Prop pox pic :
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg50.imageshack.us%2Fimg50%2F120%2Fscreenshot001fi9.jpg&hash=00aac2a334fc43647f770c307b3d17fd7557e004)
The trees are here because they are flora, and you can spot parked cars that are timed props
btw the subfile 0x2977aa49, seems to be the one where effect props are saved
I wonder if the fact that Wouanagaine still had those timed cars in his city would indicate that they are saved in another subfile, and that they thus would be in the wrong subfile if you modded static props into timed ones... &mmm
@bap, you made your experiments very correctly from the scientific point of view :) and you made an excellent preparation to the next research work. But we must remember that we are in the beginning stage of researching now. We are far from final conclusions.As for your theory about fixed-length arrays in the memory is very probable but not proven yet.
But I'm sure we go in the good direction. We not only want to find an ultimate answer ie. get to know the mechanism which acts here, but we also want to know what to do in the meantime. Looking at everything what was written here I think we should use the method of thinking similar to Pascal's proof of the existence of God :): "We can't prove if He exists or not, but it will be better for us to act as He would exist". And we just do it in this case. Assigning an unique Instance ID number to every game object modified by us will not cause any harm in any case. So it will be safe to take it as a principle in future and to improve existing game objects according to this principle.
I think it can be also a polite and objective answer to PEG http://sc4devotion.com/forums/index.php?topic=7066.0's arguments. I don't say what is true or not, I only say we should make more experiments but we know what is the best for us now.
Quote from: bap on February 28, 2009, 12:35:30 PM
(...)
"Everyone is a fine person when every thing goes fine. The real character of a person only appears when he/she is under pressure."
Very true!
Bap, one of good methods of testing the theory is trying to falsify it. So don't be surprised if I will try to dio it, it is simply a testing method as I said ;D. I also suggest others to take another possibilities into account, it can only increase our knowledge, maybe we will get to know another important things too.
Tage and Barby, I suggest the next experiment:
- Put the unmodded toilet into Plugins and build it in your city (that's a really good choice of this prop! :D) as you did earlier, save Hex data;
- Put the modded one into Plugins and build it in your city too (timed toilet - that's really a good joke ;D),
but don't remove the unmodded one;
- Now open the 2977aa47 subfile, identify/separate data for both props; compare Hex data
for unmodded prop for both cases: when you had only this prop and now when hou have them both.
Adam
Edit: At this stage we can't eliminate the possibility that other Prop Pox sources can be collected in other subfiles too. I will try to find another subfiles where particular data are collected.
Quote from: owlsinger on February 27, 2009, 03:59:44 PM
I am computer stupid and know nothing about modding, but I am interested in what's happening here, because I have one infected city, and one I think will get the pox soon. Both are large city tiles with populations over a million. The city that is poxed has a .sc4 file size of 50.8mb, and a 2977aa47 file size of 18.5mb. There is one other large file in that city - 6a0f82b2, which is 24mb. (I have no idea what that means.) The city that I think will fall victim soon has a .sc4 file size of 59.9mb and a 2977aa47 file size of 19.4mb. The 6a0f82b2 file in that one is 30.6mb. There are no other files over 5mb in either city. I hope that info can help. I use downloads from both Simpeg & SC4D.
owlsinger, the 6a0f82b2 subfile stores the underground network. I presume your million hab city has a well developed metro system. This files grows quite fast. In one of the tests I made with a city without getting Prop Pox, I created two simple metro lines running north-south and east-west and the sc4 city save file grew from 27 Mby to 42 Mby after I build my metro lines. All the extra bytes were in the 6a0f82b2 file (16 Mby). It didn't exist before the lines were installed.
By the way, to whom it may concern, the 49c05b9f subfile stores the water pipes in the city.
Quote
I have another question - in poxed cities, there is a phenomenon of peeps showing up in a crowd in the upper left corner of the tile. How might this be related? I went into my poxed city last night & observed that they are time dependent - a huge crowd shows up at 8am, and there are only a few in the corner at night. And, well, this really sounds nuts, but if you look at the bottom edge of that corner of the tile, you can see peeps appearing, and some sort of weird shadow. I have pics, if anyone is interested. It sounds crazy, but that's what I saw.
This has also been reported by another player affected by the Prop Pox (I can't remember exactly who).
The upper left corner of a city is that one with x=0, z=0 coordinates. If the infected props cause memory overflow and overwrite the information about the location of the following prop, one may have a prop appearing at the wrong place in game, p.ex., at the tile with x=0,z=0 coordinates. Alternatively (see the last post of RippleJet), the infected prop my destroy the information of its own position (zeroing its coordinates) while evoking a completely different prop (does anybody knows if the prop with TGI 0x6534284A, 0x47BDDF12, 0x05040000 has anything to do with peeps and/or a crowd of people?).
Thanks for posting and reporting your findings. And don't worry. Nobody here will dismiss your report simply because you are not a famous (or "serious") game player - whatever that might be.
And sorry to know you have Prop Pox. I know exactly how disgusting it might be.
Bap
edit: Ok, there is no 0x05040000 prop, and 0x47bddf12 group is for Maxis buildings (thanks RippleJet!)
"Everyone is a fine person when every thing goes fine. The real character of a person only appears when he/she is under pressure."
Quote from: Ennedi on February 28, 2009, 12:28:45 PM
1. Which prop is described by this second exemplar with changed Group ID (0x47BDDF12)?
That is actually not even a prop, it's a building exemplar. &ops
GID 0x47BDDF12 comprises all Maxis building exemplars.
Quote from: Ennedi on February 28, 2009, 01:50:03 PM
Tage and Barby, I suggest the next experiment:
- Put the unmodded toilet into Plugins and build it in your city (that's a really good choice of this prop! :D) as you did earlier, save Hex data;
We actually tested by plopping two lots with the in-game unmodded prop, and actually got the same result as above.
Based on yet another test with a third custom prop having a unique number, I can pretty safely say that if you have two or more instances of the same prop in the city, the Instance ID seems to be split up, so that the highest byte gets an offset position that's increased by two (underlined with red in the picture below)... doesn't really make sense to me though... ???
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi232.photobucket.com%2Falbums%2Fee198%2FRippleJet%2FPropSubfilewith2MaxisProps.jpg&hash=ff1f8b49fd8bd880243b5a16b0b81da43707f645)
We've also tested the city with two timed props and saved the city at different times of the day.
Every time the bottom part of the prop file (after offset 0x50) has contained completely different numbers.
I'm starting to wonder if the prop file contains a quick lookup of all props with their current states (on/off, brightness, shadow, etc.) in order to speed up the rendering process...
Quote from: Ennedi on February 28, 2009, 01:50:03 PM
- Put the modded one into Plugins and build it in your city too (timed toilet - that's really a good joke ;D), but don't remove the unmodded one;
- Now open the 2977aa47 subfile, identify/separate data for both props; compare Hex data for unmodded prop for both cases: when you had only this prop and now when hou have them both.
Back to the testing facilities... ::)
Quote from: bap on February 28, 2009, 02:18:42 PM
This has also been reported by another player affected by the Prop Pox (I can't remember exactly who).
By Silentbreaker...
Quote from: silentbreaker on August 01, 2007, 12:31:20 AM
And something weird that somehow has to do with the bug: SC4 spawns tons of pedestrians in the northwest corner after the bug appeared:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg231.imageshack.us%2Fimg231%2F7594%2Fandermatt2dez6831185922ed2.jpg&hash=9eac54774f574d24da12601dd6d5ab5ec5d121f1)
Thanks Tage for the report!
Maybe it will help:
- When you build a new kind of object in your city, two subfiles appears - not only 1 (I saw it in every case I checked till this moment). When you build the first building, not only 2977aa47 appears. You can see also the second new subfile - 2977aa49. It is much smaller, but it also stores some data and grows with placing new buildings.
Next report:
- I built 10 tiles of street in an empty city. Two new subfiles appeared: 896e714a (290B) and c9c05c6e (703B).
Adam
Edit: Something beyond my knowledge, but maybe it should be taken into account if you read Hex data: if the subfile is compressed, data will look different and it can be misleading - am I right?
This is one of the best brain storming I have seen in a while :thumbsup:
Whatever it comes from it will be an improvement about the game mechanics, and consequently about how we can properly modify and enjoy it. It is a pleasure to me to see this happening at this site, because this was its main purpose when it was created. Thanks to all for your participation ;)
why in the world is there a constant link showing up when ever someone mentions about Pegauses but uses just the three worded version only? yes I even intentionaly misspelled the name as well to keep the link from showing up to this thread... sorry just a tad bit confussed when trying read the post and the link keeps poping up it distracts me..
Quote from: Ennedi on February 28, 2009, 01:50:03 PM
- Put the unmodded toilet into Plugins and build it in your city (that's a really good choice of this prop! :D) as you did earlier, save Hex data;
- Put the modded one into Plugins and build it in your city too (timed toilet - that's really a good joke ;D), but don't remove the unmodded one;
- Now open the 2977aa47 subfile, identify/separate data for both props; compare Hex data for unmodded prop for both cases: when you had only this prop and now when hou have them both.
In this case, when there is only one instance of both the original prop and the modded prop (with a unique TGI), both records (separated by a yellow line below) in the prop subfile are exactly 88 bytes, and look very much the same (in other words, no size difference between static and timed props). It also appears as if the Instance ID is always doubled if there's only one instance of a prop in the city:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi232.photobucket.com%2Falbums%2Fee198%2FRippleJet%2FPropSubfilewithMaxisandCustomTimedP.jpg&hash=fe8783cfc57661ad89758b01423a8c0996cf349b)
Quote from: Ennedi on February 28, 2009, 02:29:53 PM
Maybe it will help:
- When you build a new kind of object in your city, two subfiles appears - not only 1 (I saw it in every case I checked till this moment). When you build the first building, not only 2977aa47 appears. You can see also the second new subfile - 2977aa49. It is much smaller, but it also stores some data and grows with placing new buildings.
That's the subfiles containing effects (see the post above by Wouanagaine that I quoted).
It hasn't appeared in our test city as we have no effects around the portable toilets... ::)
1. Which effects can be connected with a street (I built only a straight stretch 10 tiles long, no sidewalks, buildings around etc.)?
2. No effects around a toilet? ;D
Btw I'd like to ask if this timed toilet appears at particular time of the day or randomly? (I'm asking not as the Prop Pox hunter but as a potential toilet user :D)
QuoteIt hasn't appeared in our test city as we have no effects around the portable toilets...
Yet ;D
Adam, the toilet appears from 08:00 until 20:00 each day. :thumbsup:
It is pleasing to see the abundant knowledge that has been brought to a potentially chaotic situation. I haven't had the Prop Pox yet (knock on wood %wrd), but I must applaud the efforts that you have all undertaken to put a stop to it, with a big thanks to bap for coming forward with this.
&apls
Quote from: metarvo on February 27, 2009, 04:13:41 PM
%confuso
Honestly, I'm starting to worry for my cities now, and this has begun to scare me just a little. It's one thing to have a temporary glitch like the Water Bug affect a city; at least that is not permanent. It's another to have something like Prop Pox occur that could permanently ruin a good city. If the props disappear as a result, are they gone for good? At least my cities are small enough in file size (despite being large quads) that they won't be affected by this crazy epidemic. Whatever it is, it sounds positively frightening. Thankfully, I have enough advance warning to start monitoring my file size before anything bad happens, but I do have and use some of the mentioned content. Does using it at all automatically set me up for Prop Pox, or should I just not use too much of it?
%confuso
If you destroy the affected lot and rebuild it, all props are back. Some of the people suffering from the pox tried to do this and attempted to keep going with their infected cities. However this seems pointless. Once the city is infected, more props will disappear everytime you save the city. The next time you enter the city, different and more lots with have missing props. It's an unfair battle. At some point you will loose your entusiasm in replacing a progressively larger number of lots whenever you enter the city. Having the affected props in your plugins is enough to make you "infected" because they are used in most low density residential Maxis lots (those that grow all over the place). It makes no difference if you plop or not the
lots of the OWW2-BDK package. They are not the real problem.
Please remember that having the affected props is a necessary although not a sufficient condition in order to develop Prop Pox. Your cities must grow large, the prop/network subfile must go beyond 6Mby size.
This is quite hard to achieve (this is why Prop Pox is so rare). If geographical reasons (mountains, water, etc) prevent you from fully occupying a city tile, you will probably be far from the critical 6Mby file size. If you build your city mostly with high density lots, you may also end up in the safe side. What one should avoid is having too many props installed in the city. If you build your city mostly with low density residential zoning, a typical 4x4 tiles block may have, say, eight 1x2 lots. At an average of 6 props per lot, you have about 50 props per city block. Now, if you switch to high density zoning, your block may instead contain a single 4x4 residential building filling most of the space. The block population grows by a factor 10, the numbers of props per block drop by a factor of ten. If this policy is applied to the whole city, you may have it grow until it fills the whole surface while keeping the 2977aa47 props subfile under the 6 Mby limit. You may also leave lots of free space (like natural parks) around your city. Just remember to fill those spaces with God mod or Mayor mod flora and not by lots with trees as those also contribute to increase the number of props in the city.
Bap
"Everyone is a fine person when every thing goes fine. The real character of a person only appears when he/she is under pressure."
The last test for tonight is a city with four lots;
two having the in-game static portable toilet, TGI 0x6534284A, 0xC977C536, 0x03040000,
and two of them having the modded, timed toilet, TGI 0x6534284A, 0xC977C536, 0x42468D06.
With this setup the prop subfile contains only one record, sized 183 (0xB7) bytes.
Obviously the game saves space by merging the prop records, and omitting at least the Type ID and Group ID for those props that have them in common. In this case only the IID is recorded for the custom, timed prop:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi232.photobucket.com%2Falbums%2Fee198%2FRippleJet%2FPropSubfilewith2Maxisand2CustomTime.jpg&hash=7d40a3f97cd1c8cd7c2284fbadfd4c8dc298cd04)
I've checked a few larger cities of mine and Barby's, and they all seem to have one single, large record in the prop subfile.
Quote from: bap on February 28, 2009, 03:21:11 PM
What one should avoid is having too many props installed in the city.
This is something I've actually been thinking about... the city where I tested CAM did not have many custom lots other than the skyscrapers (which have fewer props), whereas Dublin, the smaller city which had a much larger prop subfile, has mostly low density residential and industrial zones, and with a lot higher percentage of custom content.
Quote from: Diggis on February 26, 2009, 11:30:54 PM
One thing that I am unsure of, is if the file was in place from the moment the city was started will it be OK?
Nope. One of the first experiments was developing a city from scratch only with Maxis lots, but will all custom content props (including the infected ones) in the plugins folder. It got Prop Pox when 2977aa47 subfile reached 6 Mby. I went back to a version of this same city prior to showing Prop Pox signs, removed every custom content (props files) from the plugins (including the affected ones) and further developed the city. It got Prop Pox again at about the same stage.
One may conclude the problem is not changing the definition of a prop that is used in a city
after the city started (this would only affect the new occurrences of that prop), but changing the properties/exemplar size of a given prop while reading files at the start of the game (this occurs every time you start the game with Maxis modded props).
Bap
Quote from: Ennedi on February 28, 2009, 02:29:53 PM
Edit: Something beyond my knowledge, but maybe it should be taken into account if you read Hex data: if the subfile is compressed, data will look different and it can be misleading - am I right?
No, Reader automatically always shows the decompressed content of all compressed files when you're viewing them.
Quote from: RippleJet on February 28, 2009, 03:32:17 PM
(...)
Obviously the game saves space by merging the prop records, and omitting at least the Type ID and Group ID for those props that have them in common. In this case only the IID is recorded for the custom, timed prop:
(...)
OK, it was an intention of the test suggested by me, and this is an answer for my question (is it something bad in having two props with the same Instance ID but different Group ID? Looking at your result the answer is yes. The IID should be unique in any case.)
Quote from: BarbyW on February 28, 2009, 01:26:58 PM
It is good to see you, bap. I hope you realise that here we are trying to help and find a solution.
Sure, I never doubt it.
Quote
The thread at [url=http://sc4devotion.com/forums/index.php?topic=7066.0]simpeg (http://sc4devotion.com/forums/index.php?topic=7066.0)[/url] is now locked but I am posting here a copy of his final post:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi5.photobucket.com%2Falbums%2Fy171%2Fbarbyw%2FPegfinalreply.jpg&hash=c2163f716b3212aeab7e29104e5a5843bc72aaae)
Two things annoys me concerning the behaviour of such a key batter/modder when it comes to the Prop Pox:
1) his insistence in adhering to wild speculative theories that bear no support in the facts. Facts are not prone to sympathy/antipathy or to acceptance/dismissal. One may freely propose and throw away explanations if they don't fit the facts. But one cannot throw away the facts when they don't fit ones convenience of beliefs.
2) his obstination (and clearly his only concern) in convincing the community that his creations has absolutely nothing to do with Prop Pox.
The facts are: (1) a group of props in his oww2-bdk-resource file cause Prop Pox, and (2) there must be other affected props around in the community because there were players affected by Prop Pox before the oww2-bdk-resource file was released. This is not the Santa Inquisicion. Nobody is tring to burn witches. Nobody is pointing fingers accusing any one to be "responsible" for the Prop Pox. It is absolutely irrelevant who modded Maxis props in a way they cause Prop Pox. This is the past. The only thing that matters is to find all occurrences of infected props (wherever they are, whoever modded them) and correct them at least to avoid new city developers from being infected by Prop Pox.
There are a few distracting and erroneous affirmations and insinuations made at simpeg (http://sc4devotion.com/forums/index.php?topic=7066.0) that I have to refute for the records.
1) "Prop Pox is a random effect".
False. I developed test cities 31 times. In 15 of these tests, I ended up having Prop Pox. It appeared always at the same 2977aa47 file size, just beyond 6 Mby. These tests were done at different computers, with different screen resolutions, some with & some without the EP1 and BAT updates, and with different combinations of custom prop packs & lots.
The 4 infected props were in the plugins folder in all 15 tests. For the other 16 tests I got no Prop Pox.
In none of these 16 times the 4 infected Maxis modded props were in the plugins folder. Therefore, there is no random behaviour. And there is a statistically significant correlation between the presence of those 4 specific props and the appearence of Prop Pox.
2) "Prop Pox may well be caused by NAM".
False. None of the modds, bats and lots in my plugins folder causes Prop Pox. I performed two tests will all my custom content bats & lots in the MyDocuments/plugins folder without the 4 affected props in the ProgramFiles/plugins folder. I got no Prop Pox in both cases. Thus, I can say that NAM, SAM & RHW mods cause no Prop Pox. To the benefit of Pegasus (http://sc4devotion.com/forums/index.php?topic=7066.0), I can also say that his RiverTool kit, Pond kit, Stream kit, CDR-recreational kit, CDK-OWW kit, CDK3 kit and CSK2 kit cause no Prop Pox.
3) "Using CSK, CDK, OWW2 and related stuff helps prevent Prop Pox".
False. Having sizeable parts of a city covered by water helps to prevent Prop Pox because in this case there is not enough land space to develop the city up to the point where it will show Prop Pox. Zoning mostly high density residential areas also helps as there will be, on average, less props per lot in the city (see one of my previous posts here). It certainly has nothing to do with the custom lots one install or not in the city, although most custom lots have, on average, more props than Maxis ones and will contribute to reach the undesired 6 Mby 2977aa47 subfile limit at an earlier city development stage. Prop Pox is a matter of modded props and city 2977aa47 subfile size.
Bap
"Everyone is a fine person when every thing goes fine. The real character of a person only appears when he/she is under pressure."
Quote from: Ennedi on February 28, 2009, 01:50:03 PM
@bap, you made your experiments very correctly from the scientific point of view :) and you made an excellent preparation to the next research work. But we must remember that we are in the beginning stage of researching now. We are far from final conclusions.As for your theory about fixed-length arrays in the memory is very probable but not proven yet.
But I'm sure we go in the good direction. We not only want to find an ultimate answer ie. get to know the mechanism which acts here, but we also want to know what to do in the meantime. Looking at everything what was written here I think we should use the method of thinking similar to Pascal's proof of the existence of God :): "We can't prove if He exists or not, but it will be better for us to act as He would exist". And we just do it in this case. Assigning an unique Instance ID number to every game object modified by us will not cause any harm in any case. So it will be safe to take it as a principle in future and to improve existing game objects according to this principle.
.....
Bap, one of good methods of testing the theory is trying to falsify it. So don't be surprised if I will try to dio it, it is simply a testing method as I said ;D. I also suggest others to take another possibilities into account, it can only increase our knowledge, maybe we will get to know another important things too.
Ennedy, I feel confortable with the scientific method as I am doing this for living over the past quarter of century.
I would not call that a theory but simply a working hypothesis. One may put an alternative hypothesis on the table by saying that it is not the increase in prop size that matters, but the transformation of a static prop into a timed one. If this second hypothesis is true, then the umbrella prop (which is originally already a timed prop) alone would not cause Prop Pox. I am able to test this.
Please be assured I will not take it personally if you (or anyone else) proves my working hypothesis is wrong. I will certainly not die defending an explanation if it doesn't fit the facts. :D I will happily accept any other explanation if it gives a better match to the facts and help us to find a cure to this pox. It really doesn't matter who proposed what, but only if our game of proposing-testing hypotheses lead us to answer the questions we are up to.
Quote
Edit: At this stage we can't eliminate the possibility that other Prop Pox sources can be collected in other subfiles too. I will try to find another subfiles where particular data are collected.
This is an interesting approach. Good luck!
Time for me to stop interacting (pleasant thing) and do some more testing.
Bap
"Everyone is a fine person when every thing goes fine. The real character of a person only appears when he/she is under pressure."
Just out of interest I checked in simcity_1.dat for 0x6534284a, 0x47bddf12, 0x05040000 and found it to be the building exemplar for a growable building: CO$$56x36_8ChiOfficeBldg5_0504
Why this should show a crowd of people the corner or a poxed city I have no idea. ::) unless they are waiting for the office to open to complain. ;D
Thanks for clearing that up bap with some straight facts bap. Although his credibility did go down the drain when he posted a screenshot of raw hex and said, quote, that's how XML used to be read in the DOS days ::) I had to pick myself up from the floor after that one...
alright, back to the topic at hand...
Quote from: bap on February 28, 2009, 03:46:54 PM
Nope. One of the first experiments was developing a city from scratch only with Maxis lots, but will all custom content props (including the infected ones) in the plugins folder. It got Prop Pox when 2977aa47 subfile reached 6 Mby. I went back to a version of this same city prior to showing Prop Pox signs, removed every custom content (props files) from the plugins (including the affected ones) and further developed the city. It got Prop Pox again at about the same stage.
One may conclude the problem is not changing the definition of a prop that is used in a city after the city started (this would only affect the new occurrences of that prop), but changing the properties/exemplar size of a given prop while reading files at the start of the game (this occurs every time you start the game with Maxis modded props).
Bap
Rats, I was afraid you would say that... :'( Thanks for all your hard work on this, you really have done an amazing job on this.
Andreas, I am sorry to see one of the last members at Pegs with any real experience and knowledge leave there. It concerns me that new players will go there looking for support and find none.
A lot of drama over what should be a simple situation.
"Hey I found what causes this rare bug."
"Great lets fix our files so that this doesn't happen again. Thanks so much for your hard work."
Isn't that how things are suppose to go? It's what Barby did with the BSC file that could cause problems. It's a real pity that others refuse to participate in the SC4 community. Oh well, at least we know which files to avoid.
aint it against SC4D rules to post personal matters from another site here? im pretty sure it is. just pointing that out. i remember the fall out from the seaport controllers it was stated there that it would not be tolerated by any member. i do believe that your post and mine should be deleted from this topic as they violate Devotion rules. good luck andreas and i will stick to my word in my post at peg. i respect you as a member of this community.
tahill79, I really hate to do this, but it has to be done. bap was posting here about his findings about the prop pox, and were were trying to set up a communication with PEG this way, since most of the BSC members are banned from there. I did take the opportunity to post at PEG's, but one of my postings was removed there, and now I'm completely banned after officially resigning from being a staff member. I was told that my posting at PEG's was reduced to the last paragraph, therefore I posted the unabbreviated version here, since it deals with a problem that I can't discuss any longer at PEG's. Maybe I should have posted in a thread about Mayor Mode ploppables, but this place seemed appropriate, as it was dealing with PEG's modding as well. Since I cannot continue my work at PEG's, I will try to contribute my knowledge here instead.
EDIT: I just realized that you can barely read the screenshots, as the size was reduced by PEG's forum automatically, so here are the original ones:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg239.imageshack.us%2Fimg239%2F6647%2Fpegmm01.th.gif&hash=af73e51533e9af42aaee979d0962262b0905fbe4) (http://img239.imageshack.us/my.php?image=pegmm01.gif) (https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg239.imageshack.us%2Fimg239%2F3782%2Fpegmm02.th.gif&hash=0dd540334627694c853f4606f128ecdbccff78b6) (http://img239.imageshack.us/my.php?image=pegmm02.gif) (https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg239.imageshack.us%2Fimg239%2F4307%2Fpegmm03.th.gif&hash=7fcd5efa2f208e6330405119fc4cae60d71fbd5c) (http://img239.imageshack.us/my.php?image=pegmm03.gif) (https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg239.imageshack.us%2Fimg239%2F1920%2Fpegmm04.th.gif&hash=7cc39b2d2febdca1fa2ce29b2d17b69c5c4a4d8f) (http://img239.imageshack.us/my.php?image=pegmm04.gif)
I see I have two reasons to write something here ;)
Quote from: bap on February 28, 2009, 06:41:43 PM
Ennedy, I feel confortable with the scientific method as I am doing this for living over the past quarter of century.
I would not call that a theory but simply a working hypothesis. One may put an alternative hypothesis on the table by saying that it is not the increase in prop size that matters, but the transformation of a static prop into a timed one. If this second hypothesis is true, then the umbrella prop (which is originally already a timed prop) alone would not cause Prop Pox. I am able to test this.
Please be assured I will not take it personally if you (or anyone else) proves my working hypothesis is wrong. I will certainly not die defending an explanation if it doesn't fit the facts. :D I will happily accept any other explanation if it gives a better match to the facts and help us to find a cure to this pox. It really doesn't matter who proposed what, but only if our game of proposing-testing hypotheses lead us to answer the questions we are up to.
(...)
Bap
"Everyone is a fine person when every thing goes fine. The real character of a person only appears when he/she is under pressure."
Bap, it's a real pleasure to share an experience and knowledge with people like you. We don't know one to another, but as we can see, there is a common language that can be used by us in our contacts. We would only wish ourselves to see scientific discussions in the real life made in similarly objective and respectful manner ;D. I am sure our science would be much better and useful than it is now. I don't know how are your own experiences connected with your work, but personally I am happy that scientific research is not my job and I can use my mind for my personal pleasure and for pleasure of some of my friends :)
One of the best things caused by this game and this site is an opportunity to contact with other people in a very different way than most often happens in RL - in an objective, repectful and often enjoyable and even funny atmosphere :thumbsup:
I hope we will continue our experiments and maybe we will learn something new and interesting together :)
@Andreas, I see your actions at many places costantly from the day of my access to SC4D and I must say you have my full confidence in everything you do and everything you say - and I can say this about very few people :). One must be incredibly stupid or maybe fully isolated from the reality ;D to don't see and appreciate an objective and quiet manner of your argumentation.
You did it very good showing this example with tree controllers. It was fully reasonable in this case.
Even bad situations can be used to create positive things, if only people think positive ;). Reading your post in Simpeg I experienced a (little ;D) illumination - I have an idea how to make creating tree controllers easier... (the graphical representation will be helpful, I'm going to make a table identical as the Terrain Texture Map Table for every kind of flora instead of the single row with 256 repetitions. Then some simple formulas in Excel and we will be able to automatize most of the process. In addition it is possible to harmonize flora with terrain textures this way).
Adam
Jeez, you should think that this was a common thing to happen in a modding community that has been forced to rely on trial and error rather heavily due to lack of official support - someone finds a method for making something new that seems to work, others adopt it, but then problems occur. Finally these problems are traced to that method, and quite often these findings lead to a method that really works.
Happened with the RCI blank lots before, and today we know better. So what? I guess nobody blamed RalphaelNinja (or the people who used his method) because all knew how much he had contributed and stuff like that was just bound to happen - after all, you can't have trial without error, it's that simple. And the current situation is exactly analogous to the one with the RCI blank lots - well, except for the reaction, that is. &mmm
What a sad moment.
Not sure just how to take that post, but nobody was actually pointing fingers and shouting "it's all your fault!"...Bap identified a prop pack that was a cause of the pox...note "a" cause, not "the" cause. Did the creator go and fix it and say "thanks, I'll quickly update it to prevent a lot of people losing months or years of work"? No, he basically said it was a hoax and we're all scaremongering. I think the reaction to that, given the nature of this community, was and still is only natural. Sad day yes, but at least we now know how to avoid losing carefully crafted cities....simply don't use any content identified as being a cause of this problem.
I come from a background in database management, so apologies if I've gone off on a tangent here re Prop Pox or repeating whats already been worked out and has already been stated in a previous PM.
If Maxis wanted to save file space it would make sense rather than for example having 100 beach chair props on 100 different LOTs, have one beach chair prop based on the TGI with the 100 LOTs all referring back to that one prop.
The problem would come if you have 99 beach chairs and the same TGI with one set of identical contents and 1 beach chair with the same TGI, but with slightly different contents the system would still try to merge to one prop with a unique TGI reference but the prop data would be slightly different so the prop data would start getting screwed up and you would end up with missing props on the LOTs as the referencing system would no longer work.
EDIT: its called a One to Many Relationship or maybe in this case One Prop to Many LOTs :)
ty, now I know %confuso
:angrymore: need to rewrite the long post, I hit close
So to get back on Prop pox topic, because at least here we're looking for explanation and deep analysis ( and by "we" I don't mean BSC, but the whole SC4 community that have some membership at SC4D )
I have read quickly over the last pages, and I come to a theory. feel free to correct me if I'm wrong, I may have read last bit of information to quickly
On the old Prop pox thread, and Ripplejet post some of my screenshots and some thougths on it, we discovered that the timed prop are not save in the same subfile as normal prop, and this is a fact, everyone can do what I did if they don't believe me, no denial can be done on this
Now on my theory, and following informations from here which is at least where we can find informations
When a prop is saved, it is saved either in the 'normal prop' subfile or either in the 'timed prop' subfile ( there might be other subfile with different kind of props ).
We also can easily guess that a timed prop need much more information than a normal prop to be saved and I clearly think this is why there are 2 differents subfiles
Now programming wise, I expect the prop object to handle the code to save, I also expect the code to be optimized for reading/saving. What does it means ?
We already have a proof of optimisation, maxis clearly handle different code path for saving when the number of prop hit a certain number ( the subfile change at 6mb )
For optimization , It means that to prevent even longier time to load, the code expect data to be in certain format, ie the code for reading the normal props subfile expect the data to be valid normal prop data, the code for reading the timed props subfile expect the data to be valid timed prop data. This will allow the code to be as efficient as possible.
Now I also expect maxis programmers to code efficiently and as game coder are used to write code, ie using lookup table to speed up things a lot. It means they certainly have write code to categorize kind of prop ( timed or normal ) to speed the code. It will in effect speed up the rendering, a timed prop need to be redrawn when the condition of the timed prop are meet, whereas a normal prop is need to be redrawn only when a screen refresh occurs. it will be very efficient to only iterate along the timed props instead of all prop in that case.
As for savegame ( and back to prop pox ) we indentified that timed and normal prop are saved in different subfile. The same lookup table can be used to filter which saveing code path are used for each prop ( save normal or save timed ).
Now what happen if a prop is not correctly categorize ? bad thing
Now how can a prop be not correctly categorize ? if a prop is categorized at SC4 initialisation time when it parse maxis file, it is categorized at a normal prop, but when reading your plugin folder it is then categorized as a timed prop because an old modding practice has been done, how the code will handle that ? I don't know, maybe correctly
Now back on the prop pox.
The normal prop code reading of normal prop subfile expect data in a certain way ( and it might be different format for different number of prop, where with low number of prop, some values can be store with 2 bytes, but with higher number of props, it need to be store with 4 bytes - this is only an example, but a very common practice in gamedevelopement ). Now what happen if for some reason a prop data in the normal prop subfile is not in the correct expected format ?
-CTD ? maybe sometimes
-discard of all subsequents props in the subfile ? yes, it leads to prop pox
A CTD will only occurs if the data don't make anysense to the game. What happen if a timed prop data are stored where a normal prop data is expected ? maybe the data are valid enough - just because I expect all data of a normal prop to be in a timed prop but not the contrary - but then the data after the length are still there ( the specific data of a timed prop ), which the code can't handle, and it won't look like a new prop at all. So maybe in that case maxis decide to discard all the following bytes in the subfile and stop reading it instead of just crashing, leaving the player with prop pox city
Disclamer:
Of course this is a theory, as I and noone have the SC4 source code. This theory can't be prove yet, but at least it can be tested, and the result may confirm it. I just know that even in that case some members will still find the theory wrong and won't do anything to find what the prop pox problem is as they don't experience it anyway. For the record I never experienced a prop pox, lot of people in this thread activily researching the prop pox root cause have never expereinced it. It does't refrain them to look for the problem and search a solution
Quote from: catty on March 01, 2009, 11:47:52 AM
If Maxis wanted to save file space it would make sense rather than for example having 100 beach chair props on 100 different LOTs, have one beach chair prop based on the TGI with the 100 LOTs all referring back to that one prop.
Correct, that's the same as what we do when we create prop packs (well, when I say "we", I mean Barby, Hex to me is a clockwork computer with an "Antill Inside" sticker on the side :D)....the content is re-used over and over, irrespective of how long ago it was created.
Quote from: callagrafx on March 01, 2009, 12:10:30 PM
"Antill Inside"
This will be a wee bit off topic, but great Prachett reference!
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg132.imageshack.us%2Fimg132%2F2084%2Fcanofwormsmp5.png&hash=47f2cc28a62d5229bd820190e252fb700baa0848)
...I know, I know. I used that pic in 3RR a couple of years ago. I just read the level of tech detail in this thread, and my head starts to hurt.
One thing I'm sure of is that, if a definitive answer can be found, the folks posting here will be the ones to find it.
David
While I've never had PP hit any of my cities , and since there has been so much info lately , I am wondering if this is limited only to Maxis props? If I understand this correctly , what has changed is static props were turned into timed props without changing the TGI values. Can this also be caused by T-21 mods where a prop (Maxis or otherwise) did not have the TGI (mainly the instance) changed , ie , a seasonal tree or traffic prop? I'm sorry if my question is confusing since , as far as I understand, by not creating a new instance ID, the new mod can "contaminate" the original prop info (and possibly create even more instances than the original and the newer instance of the prop ie , 2 becomes 4)? I am sorry if this is a dumb question , as I only understand a fraction of a fraction of what you "old timers" :) have been able to uncover by looking under the hood of this game!
Jayson
Maybe, I'm pretty sure that T21 props are stored elsewhere ( as seen in my pic Ripplejet reposted, we can see T21 props ( I think they are T21 props I'm not expert in those ) ). Maybe they can instead of produce prop pox on lot, produce prop pox on network which might be less visible
We need a T21 expert in here... ::)
Just in case
dahemac (as posted elsewhere, see quote below) does indeed suffer from the pox, wouldn't those avenue median props be T21's?
Quote from: dahemac on March 01, 2009, 01:28:36 PM
I have all the dependencies from the LEX DVD. However I find that lots of lots are losing their props between sessions. For instance I plop the University or MAS71's walls and they look fine, with all their props. When I reopen the city later however the props have vanished and I am left with a kind of MT lot. This also happens with Avenue medians. When I place the Avenue, the median looks normal. Later even in the same gameing session, when I go back to them the median is blank. If I drag Avenue over the Avenue the median reappears. Any ideas?
Yes, the avenue median props are placed via T21's. I don't know who came up with the term "network file" in the first place, but T21's are basically "network props", so to speak - it wouldn't surprise me if they are actually stored in the affected file as well.
First: hats off to bap for that marvellous work :thumbsup: &apls &apls &apls from one of those unlucky ones who experienced the Prop Pox.
I wasn't able to check my city save files and plugin folders as I am 3000 km away from my (not very good working) pc but I think I have a pox-free backup of the infected city with which I will try to verify your theory ASAP in my case.
But I do clearly remember that all kind of tiles were affected by the pox - lots as well as Network pieces = T21. This is shown also in the pictures in snorelli's opening post here: http://sc4devotion.com/forums/index.php?topic=1201.0 (http://sc4devotion.com/forums/index.php?topic=1201.0).
And yes, even though I haven't seen any screenshots I do believe to that dahemac is suffering the pox from what and how he describes it.
So I guess my question wasn't as dumb as I thought! Now here is another question: Has anyone messed with Darkmatters Datgen version 0.7.9 for extracting DBPF files from save games? I can't get it to work properly as I am now on Vista , but it may make it easier to read those files.
Jayson
I haven't used DatGen in ages, but as far as I know, I tried DatGen 0.7.9 once or twice, but found out that it even didn't work as well as the 0.6.0 release. IIRC, the 0.7.9 version was an attempt to make it Sims 2 compatible, but it never got very far. It couldn't hurt to give it another try, though.
DatGen shows the content of "unknown" files in exactly the same way as Reader, either as HEX code or as garbled text. The prop subfile is an unknown one, meaning its internal structure is unknown.
Some more food for thought...I'm not a modder, but heres an experience I had two weeks ago. I was making a lot.. (https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg301.imageshack.us%2Fimg301%2F2469%2Fb4uf8.th.bmp&hash=0fbe560248746508be51674edd45b791b598b85b) (http://img301.imageshack.us/my.php?image=b4uf8.bmp)
I placed it in AN EMPTY, UNSETTLED SMALL BLOCK. This is what showed up... (https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg141.imageshack.us%2Fimg141%2F4214%2Fafterx.th.jpg&hash=e73a5eb6f07fb87430a14b6c8b4445e1baa9ae96) (http://img141.imageshack.us/my.php?image=afterx.jpg)
I exited the game, and immediately returned to LE... This is the same lot as earlier... (https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg140.imageshack.us%2Fimg140%2F1194%2Fafterhb9.th.jpg&hash=c273e7bc6e9c9833776950f25c5685062b16d7f2) (http://img140.imageshack.us/my.php?image=afterhb9.jpg)
Also, I don't have pics, but in SC4 tool, the transits were also deleted in certain areas. I can get a pic if you like.
If I re-complete the lot, and put in game again, same thing happens, but with different tiles and props.
Is this prop pox?
Any help is sincerely appreciated..
I have one large city tile that measures 26 mb that has quite a bit of custom context is also a CAM tile that has never experienced prop pox. Also, terrian greatly effects a tiles size of well, a slight modification can result in a size change of quite a few kb's. This could explain why tiles can shrink in size from time to time.
Quote from: Kitsune on March 01, 2009, 02:59:20 PM
I have one large city tile that measures 26 mb that has quite a bit of custom context
Can you check the size of the prop subfile (Type ID 2977aa47) within that SC4 file?
If it's above 16 MB, then you've obviously survived the jump from 6 to 16 without getting the pox.
Quote from: bob56 on March 01, 2009, 02:57:35 PM
Is this prop pox?
I honestly doubt that would have anything with the pox to do.
There are above all textures missing, and the prop pox has never affected any textures, only props.
The reason I brought it up was , a while back I came across that version , which seems a little buggy , but gave better descriptions than the one from ST:
0.7.9
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi180.photobucket.com%2Falbums%2Fx262%2Fsithlrd98%2FUntitled-1-3.jpg&hash=26a438bf53d33b5034dbff304fb62f70cabecbe0)
Datgen4 From ST
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi180.photobucket.com%2Falbums%2Fx262%2Fsithlrd98%2FUntitled-2-2.jpg&hash=12d1e9cecea6b23ea5a258ee6fb3fba9408c1281)
Jayson
Quote from: RippleJet on March 01, 2009, 03:03:55 PM
Can you check the size of the prop subfile (Type ID 2977aa47) within that SC4 file?
If it's above 16 MB, then you've obviously survived the jump from 6 to 16 without getting the pox.
That type sits at 17.5mb currently.
Quote from: sithlrd98 on March 01, 2009, 03:07:16 PM
Datgen4 From ST
In the second image, you have an item called unknown, just under the city name which is selected (blue).
Click that one, and you'll get all unknown files.
Among those you will also find the prop subfile, having a Type ID of 2977aa47.
When you open that file, you will see the same as you'd see in Reader.
Quote from: sithlrd98 on March 01, 2009, 03:07:16 PM
0.7.9
If you open up that file called Network Props (2977aa47), listed on top on the right,
you'd also probably get the same content showing up.
Quote from: Kitsune on March 01, 2009, 03:10:41 PM
That type sits at 17.5mb currently.
That would be good news for you! ;)
Yea, but you can export it out , but it saves as a .tnet , which I can't find info on.
Jayson
Duh...(.TNET)...Transportation Network.....
noticed it when I tried to extract the Network Props....(.NPROP)
Nevermind!
It would be also good to make a little summary of our knowledge in its present state, and repeat this operation from time to time if we will not solve the problem quickly. Otherwise we will have more and more repeating questions and our work will not go ahead.
Now we have two additional hypotheses (catty's and Wouanagaine's), we also identified the content of some savegame subfiles. Some other details were also discussed here.
I would help with pleasure, but the summary should be made by a person who knows English better than me (a single word can make a difference) and with better sc4 and computer knowledge than me.
Adam
I did a search for some of the subfiles like 2977aa47 and come up with these links
http://old_wiki.modthesims2.com/SAVEGAMES?show_comments=1 (http://old_wiki.modthesims2.com/SAVEGAMES?show_comments=1)
http://www.sims2wiki.info/index.php?title=SAVEGAMES&redirect=no (http://www.sims2wiki.info/index.php?title=SAVEGAMES&redirect=no)
How relevant it would be is another matter
Quote from: catty on March 02, 2009, 09:50:37 AM
I did a search for some of the subfiles like 2977aa47 and come up with these links
http://old_wiki.modthesims2.com/SAVEGAMES?show_comments=1 (http://old_wiki.modthesims2.com/SAVEGAMES?show_comments=1)
http://www.sims2wiki.info/index.php?title=SAVEGAMES&redirect=no (http://www.sims2wiki.info/index.php?title=SAVEGAMES&redirect=no)
How relevant it would be is another matter
catty, this is where the association of the 02977a47 subfile with "network props" came from.
If I remember well, wouanagaine suggested this file could host more than simply the network props (which we soon found it was true) and that one should look at the size of that subfile in Reader to see if it increases/shrinks when Prop Pox strikes in a city. This very piece of information is what allowed me to perform all those experiments. It may no longer be relevant, but it was important to help us reaching the stage we are now.
Cheers,
Bap
Thnks Bap
Quote from: bap on March 02, 2009, 02:02:01 PM.... It may no longer be relevant, but it was important to help us reaching the stage we are now.....
It was more whether the links were relevant
but here's another link which may or may not be useful to know about.
QuoteGame Extractor has the ability to read and write archives from many different games including Simcity 4
http://www.watto.org/extract/games.html (http://www.watto.org/extract/games.html)
Not really Catty, it simply reports back "unknown data" for most entries...unless I'm missing something.
Quote from: callagrafx on March 02, 2009, 03:15:59 PM
Not really Catty, it simply reports back "unknown data" for most entries...unless I'm missing something.
I had to wait till I got home from work before posting a picture, but this is what I see ...
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Ffarm4.static.flickr.com%2F3634%2F3324436115_c674724272_o.jpg&hash=962484a7eb3dcb2c3348fea70d2230072c563697)
Hi, everyone,
You can't imagine how tickled I was to find this thread. I have a city that is infected. I saw the original thread quite some time before it happened, so that is how I recognized that it was probably the Pox. That thread had gone quiet, by then, however. I'm convinced that there are more than a few of us. I see threads about this fairly often at ST. The usual consensus is that "It is probably the Prop Pox, but what to do ()what() --the cause is an unsolved mystery..." So the questioner usually deletes or gives up on that city. And it doesn't reoccur again soon, because, as has been determined, it takes a good bit of content, detailing, time, etc., on one tile to cause it.
The city of mine that is infected is a large tile, low density, rural, with many farms and seasonal trees. It is almost covered with lots, and is over 500 years old. I do have the Pegasus Trail Parks, the CDK file, and the OWW file. I also have the BSC Mega Pack Vol 2, but downloaded it after I last played the city. I just checked the size of the 2977aa47 file. It is 21,913,616 bytes, which would be close to 22MB, I think? Another thing I remember was that, as well as lots, the avenue dividers were also affected. I have since reorganized and cleaned prior to starting a fresh region, determined to test and research all content, so I don't know if the city is playable. I do have Plugins backed up on disc from when I was playing it. If any other info is needed, please let me know.
I would like to thank bap so much for all his research. He has brought a very scientific mind and process to address the problem. I have learned a great deal from his methods. I now have hope that this problem will not reoccur, and plan to use bap's method of celebration, too. (https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi98.photobucket.com%2Falbums%2Fl252%2Fsimdiary%2Fdrinking-43.gif&hash=7e421bf21685680268a11c6837e7a79dc8650e32) I would also like to thank all the great "SC4 Technicians", wouanagaine, RippleJet, barbyw, callagrafx, Andreas, Ennedi, and others who have also spent precious time on this and take the difficulties we players have to heart. It is only a game, but a most delightful hobby as well. When one has expressed themselves artistically through playing this game, it becomes rewarding to see the result of one's efforts. It is especially gratifying to realize there are others who not only share that enjoyment, but want to help enhance and preserve those efforts. In other words, you guys rock. ()flower()
Bye for now.
--Liv
Liv, let me also take the chance to thank you for all help you're giving, especially to newcomers, both here and on Simtropolis. :)
Quote from: catty on March 02, 2009, 10:30:25 PM
I had to wait till I got home from work before posting a picture, but this is what I see ...
It's basically the same that Reader or DatGen would show, however with one important difference.
Game Extractor doesn't show the Type, Group and Instance ID's of the subfiles,
and also doesn't show the structure of those files whose structure is known (e.g. exemplars).
This is going to be a long post so bear with me. In the early days of SC4 - 2003 - there were clever people who decoded parts of the game and also who provided mods of various types. TWrecks mentioned one - the RCI Blank Lots file from ralphaelninja - that has caused pain in various ways and is actually still being used so still causing problems. There were only modders and lotters in those early days as BAT did not exist. Colyn and mrbisonm were two of the most innovative and productive lotters at the time and GrampaAl worked with both as a modder. When Maxis released the two buildings as props files they left out the Query as Main property which means that if, as was done frequently in 2003, props were joined to make bigger lots then the props didn't show the name of the lot when queried. As one of the earliest respected modders GrampaAl found this unacceptable and to get round the problem he copied the exemplars from the buildings as props files into the lot files and added Query As Main BUT he did not change the TGI of the exemplar.
I have looked at Colyn's lots - sorry I can't check everyone's from way back then - and found all the following have modded Maxis exemplars with no TGI change. Fortunately most of these lots are now withdrawn from the STEX and only available on the STEX disks. I have started to update them but am waiting for Colyn to tell me which he wants to be uploaded apart from the ones that I have posted for him. I have no idea if these lots could be the cause of the Pox but would rather err on the side of caution and advise against using them.
CSX Abbatoir_6c31d500.SC4Lot
CSX Admin Centre_4c39087f.SC4Lot
CSX Agricultural Centre District Office RH_6ca4a64d.SC4Lot
CSX Agricultural School RH_4ccb9b02.SC4Lot
CSX Centennial Plaza RH_ed09e452.SC4Lot
CSX Commercial - Ali Baba RH_2c81a24f.SC4Lot
CSX Commercial - Keg and Tankard RH_cc991a3d.SC4Lot
CSX Commercial - Vivaldi RH_8ca834fe.SC4Lot
CSX Corporate HQ RH_2c9ef1b2.SC4Lot
CSX Farming - Fuel Depot_ed15ffb7.SC4Lot
CSX Farming - Welding Works RH_ed1bb9eb.SC4Lot
CSX Fun Palace_RH_0c9cf9aa.SC4Lot
CSX GA Farm - Bob's Chili Peppers_cd663162.SC4Lot
CSX GA Farm - Don's Produce RH_0d018b4b.SC4Lot
CSX GA Farm - Grampa's Barley_6d6c7eaa.SC4Lot
CSX GA Farm - Hopeless RH_4cf214f3.SC4Lot
CSX GA Farm - Nexis Chickens RH_ecf64d62.SC4Lot
CSX GA Farm - Nexis Hops RH_ed303d0b.SC4Lot
CSX GA Farm - Nexis Strawberries RH_ace4e7c9.SC4Lot
CSX GA Orchard - Owensby Apples RH_0d15b3a1.SC4Lot
CSX GA Orchard - Washington Cherries RH_cd33cbaa.SC4Lot
CSX GA Vineyard - Tuscany Merlot RH_4d045aa6.SC4Lot
CSX GA Wine Estate - Nexis RH_aced43ec.SC4Lot
CSX GM Farm - Coconuts RH_ac940fa4.SC4Lot
CSX GM Farm - Eggs_6d1b2e4c.SC4Lot
CSX GM Farm - Mystery RH_8cb0cc52.SC4Lot
CSX GM Farm - Rainbow Trout RH_8d1870a6.SC4Lot
CSX GM Research Centre_ac23463b.SC4Lot
CSX GM Test Centre RH_4cc725df.SC4Lot
CSX Hi Tech Coal Power_6c452095.SC4Lot
CSX Hitech Security HQ RH_4c2571b8.SC4Lot
CSX Home - Sandton_cc7926b7.SC4Lot
CSX Industrial - Bloodsweat RH_4c6f176b.SC4Lot
CSX Industrial - Cement Plant RH_8caee7cf.SC4Lot
CSX LSU Crop Duster RH_acce044d.SC4Lot
CSX Mini Generator_0cc1301b.SC4Lot
CSX Mini Power Plant RH_ec56b1eb.SC4Lot
CSX Nexis Cattle Auction_ac40d4d8.SC4Lot
CSX Planning - Business Affairs_4cbef037.SC4Lot
CSX Produce Market RH_0cc42ab8.SC4Lot
CSX Produce Packaging RH_6c5d05d6.SC4Lot
CSX Resort - Black Rock RH_0cc41637.SC4Lot
CSX Restaurant - Al Fresco RH_ccafa5a9.SC4Lot
CSX Rising Sun Oil Refinery RH_ecc00109.SC4Lot
CSX Rural 911 Centre - RH_ac3aef5f.SC4Lot
CSX School of Design and Architecture_0ce7124e.SC4Lot
CSX Services - DustBusters RH_0ccc0118.SC4Lot
CSX Services - Girl Friday RH_4ccccf9e.SC4Lot
CSX Services - The Mews_2d129b17.SC4Lot
CSX Unemployment Office_2c5c7e2d.SC4Lot
FirstNationalBank_BSCLarz_ad6dc33e.SC4Lot
If bap and anyone else who is testing out the theories would care to try with one or more of the above lots in I have them all in the original format and can send for testing.
Now to the second part of this long post. In one of his posts Pegasus said this:
Quote<snip>
and obviously influenced by the BSC.
<snip>
Fortunately, the majority of the community can see it for the senseless & petty attack that is it is. You further the BSC agenda of trying to spread fear of using material from any developer other than their own. Meanwhile, the material you attempt to spread fear about is being used extensively by the entire community without any problems whatsoever. Despite the personal and vicious nature of your attack, the facts and reliablity of the material does not support any of it.
Andreas is first and foremost a member of the SFBT community. He is BSC affiliated but does not contribute to BSC other than to make translations and offer advice. BSC have no agenda and never try to prevent anyone using any GOOD game assets. The original concept of the BSC was to help, through the use of experienced modders and lotters, all BATters to provide the best possible upload. This concept is still the underlying reason for the existence of BSC and many in the community can testify to that.
Last year Ripplejet tried to help Pegasus with the seaports as originally he announced that his new one would only replace the Maxis one; there being no way to make custom seaports without causing CTD problems. The result was a ban from his site for Ripplejet, jplumbley, wouanagaine and me. At no stage did any of us do other than try to help but, as with Andreas, telling the truth or trying to correct erroneous statements at SimPeg is not welcome. Andreas and Warrior tried to correct Pegasus' idea that XML and Hex are the same thing and that .sc4 files are XML. As has been stated they are in a proprietary format DBPF and have never been completely decoded. I shall return to the comments about his material later.
This was followed by:
QuoteThe BSC is not even remotely interested in this pox issue. They have been aware of it for years... and have never made a single effort, as a group... to do anything about it. But as soon as one unknown person indicated that PEG material might be involved, they throw 100% of their effort into the issue with a full focus only on manufacturing evidence that supports that.
The one verifiable fact with this issue is that it is extremely rare and random... and only strikes very large cities with a very large number of props in it. City size actually does not appear to be factor... but apparently only large cities can contain enough props to trigger it.
No player that uses PEG material exclusively has ever gotten this prop issue. And the simple and obvious reason for that is that almost all of the PEG material is ploppable. PEG material is geared more toward the sandbox player and for development of CJs. Growable material has always been more a BSC thing.
Ploppable lots do not add many (overall) props to a city... because players normally don't plop very many of them in a single city. Growables, however, can show up hundreds and even thousands of times in a large city... with each occurrence adding new props to the city and inflating the overall prop data size to well beyond the 6 meg pox-trigger mark.
And who are the kings and queens of Growables... with more mega prop pack dependencies than all developers combined? The BSC, of course. To use any one BSC lot may require installing up to 7 or more large dependencies files.
It appears that every documented "poxed" city was loaded to the hilt with BSC material. So if that is true, then any one with a poxed city should try uninstalling all of the BSC material, loading up their poxed city, deleting all the BSC lots in that city and allow default lots to redevelop. Save the city, reload and see if the "pox" is still there. If the assumption that "once poxed, always poxed" is true, it won't make any difference. But that still doesn't mean that all those extra props were not the cause.
* In fact... if someone would zip up and email me a poxed city (normal large city map), I'd like to test that myself.
Prior to this post Pegasus had denied categorically the existence of the Prop Pox. Now he has once again done a U turn and decided that maybe it does exist. Unfortunately he has omitted to read carefully the whole testing report from bap. He states:
Quoteran SC4Tools (merge file option) on all custom prop packages in search for multiply defined props. It was able to find several conflicts and hundreds of multiple definitions of props. I eliminated all conflicting and doubly defined props from the prop packages, installed the corrected files back on PP, and ran another test with City#2.1. Prop Pox sets in when the city reaches 16 Mby (again, network subfile about 6 Mby). Multiply defined props per si are not the cause of Prop Pox.
The 'virus' was still there. In order to find it, I performed binary search (take half of the prop package files out, test with the other half; if you don't find Prop Pox, you can eliminate the tested half from the exercise; take half of the other half and proceed with the testing). After several such tests, I was able to narrow down the search to only one file: a blend of props from Pegasus CDK3 and OWW2 packages. Only when this package was in PP folder, did the city developed Prop Pox.
I tested developing the City #2.1 with only the texture packs and Maxis plugins in PP folder. No sign of Prop Pox. I then added all other prop packages except for the suspect one, and installed back all lots in MP (except for the lots which depend on the excluded prop package). Almost all my custom content back. No sign of Prop Pox. (another box of bier to celebrate.)
I broke my Pegasus mega prop into its CDK3 and OWW2 parts and performed a few more tests to find that I only got Prop Pox when the peg-OWW2_BDK_RESOURCE.DAT file was installed. Removing everything except this file from the plugins, I got Prop Pox. Including everything in the plugins except this file (and the associated lots), I got no Prop Pox.
This is the conclusion from many months of testing and his poxed test cities were not "loaded to the hilt" with BSC material. In one test he had no custom lots but only custom props. Once he had narrowed down the cause by binary search he replaced all his custom content except for anything that depended on the now excluded RESOURCE packs. No sign of Prop Pox. The problem seems to occur when props used by Maxis on their own lots have been modded and included in a custom prop or RESOURCE file without giving the exemplars a new IID.
At this point in time no one is saying that Pegasus is the only creator whose props may cause problems. BSC found one occurrence and have corrected and updated that file. Unfortunately if it has poxed your city all we can do is apologise. As you can see from the first part of this epic I am spending a good deal of my time checking and have now given a second heads up with that list of Colyn's 2003 lots and I also noted that the Snake Petting Zoo from Pegasus also has the same characteristics. No has pointed fingers or tried to pass blame apart from one person who continues his vituperative tirades against one group. At no stage did Andreas make any personal attacks other than to correct him on one point and then to demonstrate that Pegasus had modded his Mayor Mode Ploppables incorrectly and using a cycledogg - who is BSC - base. This was known to BSC some weeks ago but as none of us can post there we could not help and we could not correct his mods and upload as that is against his EULA.
It is up to all creators to check their material, no matter how old, to see if they may have contributed to this problem.
RE: the CSX lots mentioned----do these lots all need to be bulldozed before removal, or is it safe to remove and just clean up the empty lots as I encounter them, if not might as well just start over :'(
Quote from: jabl0me on March 03, 2009, 07:00:49 AM
RE: the CSX lots mentioned----do these lots all need to be bulldozed before removal, or is it safe to remove and just clean up the empty lots as I encounter them, if not might as well just start over :'(
As a general rule, it is a good practice to remove all the lots in your cities before removing the files from your plugins folder ;)
Quote from: jeronij on March 03, 2009, 08:06:51 AM
As a general rule, it is a good practice to remove all the lots in your cities before removing the files from your plugins folder ;)
I know it's a general rule but do they NEED to be? I've seen occasionally that some mods/lots say that no bulldozing is necessary or they just need to be deleted and re-plopped. I just want to know if they absolutely have to be deleted first. Thanx!
Definitly needed
This will at least remove the prop from those lots from the savegame
Quote from: jabl0me on March 03, 2009, 08:18:08 AM
I know it's a general rule but do they NEED to be? I've seen occasionally that some mods/lots say that no bulldozing is necessary or they just need to be deleted and re-plopped. I just want to know if they absolutely have to be deleted first. Thanx!
so, you are a man of short answers then.... $%Grinno$%
YES
Sorry wou, perhaps your answer was still open to doubts... :D :D
Barbyw, I much appreciate your considerate policy of choosing to err on the side of caution.
I haven't been able to finish the further tests I planned to do. But even though, I can add a few comments to the discussion now.
Among the other prop packs I have in my plugins folder there are several Maxis modded props which keep their original IID. In most cases, the modding is either including the prop in a prop family (by adding the Building/Prop Family property) or adding the prop to another prop family (to an already existing Building/Prop Family property). This leads to increases in exemplar size by 4-17 bytes. None of these props lead to Prop Pox. I do have [url=http://sc4devotion.com/forums/index.php?topic=7066.0]Pegasus (http://sc4devotion.com/forums/index.php?topic=7066.0)[/url]' cdk-industrial package. It also doesn't lead to Prop Pox. I also found one Maxis modded prop in [url=http://sc4devotion.com/forums/index.php?topic=7066.0]Pegasus (http://sc4devotion.com/forums/index.php?topic=7066.0)[/url] cdk-oww package (not the oww2 package) which is a timed prop for which he replaced the "Nighttime Change" property by a "Prop Time of Day" one. This also leads to a small <10 bytes increase in the size of the prop exemplar. This is identical to what he did with the umbrella prop. As I do have the cdk-www package and it does not cause Prop Pox, I am convinced that the Maxis modded umbrella prop (IID 29000000) does not cause Prop Pox. I could confirm that by performing another experiment with only that prop exemplar in the plugins folder, but I did not have time yet.
This weakens my original hypothesis that is the increase in size of the modded Maxis props that lead to Prop Pox. The important feature which is exclusive to the other 3 Maxis modded props in the bdk-resource file is being originally a static prop modded into a timed one (this is something no other prop in my plugins folder has). This strengthen the idea that what causes Prop Pox is changing an originally static prop into a timed one without changing its IID. This narrows the search for possible infected props in other prop packs.
For instance, I do have some of the CSX lots you listed (GA Farm - Nexis Chickens, GA Vineyard - Tuscany Merlot, CSX Produce Packaging and others) together with GrampaAl modded props and they also do not lead to Prop Pox.
So, Jabl0me, I suggest you keep your CSX lots and give us a little bit more of time to confirm the findings.
Bap
Thank you for the quick response, bap. It is good to know that the list I posted and the BSC MEGA props Misc Vol02 are unlikely to cause the Prop Pox in the same way that the other Peg files are probably fine as well. On the other hand the Prop Pox was known well before the release of the BDK file so there must be some other instances in the community. I have checked all the BSC prop packs that I know have Maxis modded props in and have not yet found any others without changed TGIs. I shall continue to search.
Snorrelli could be of great help in this regard, as he is one who was infected prior to the release of the oww2-bdk pack. There must be at least one static prop modded into a timed prop without chaging IID sitting in his plugins folder waiting to be uncovered. I note that it may not necessarily be a Maxis prop. It may just be a custom static prop with a later (in term of reading sequence) redefinition as a timed prop.
Bap
Oh wow, this is a known bug with a known fix! The Near West Side of Chicago can be saved! &hlp
I guess this makes it about a dozen and one affected players.
Thanks everybody! &apls
One possible known cause but to date there is no fix if you have the Prop Pox, sorry. Some of us are working to try to find the exact problem as there are other causes than one file and once we have more information it will be posted.
Dear friends,
I accidentally found this thread very shortly after I discovered some pox also in one of my cities.
After having opened I found the Schönbrunn palace incomplete. The central prop was missing. I pityfully did not make a screenshot, but you can believe me.
This city, though, was not very large. It inhabits at the moment around 100.000 sims. The 2977aa47 file is 3.355.919 bytes large (so not even close to the 6Mb) and the cityfile as a whole measures 8.296.228 bytes.
I use extensive amounts of plugins. Some of the old CSX ones, a lot of PEG's, a lot of BSC's, and more.
The city is a large tile in a region of 18 (6x3) large tiles.
Here is an overview.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi277.photobucket.com%2Falbums%2Fkk63%2FFrankU_bucket%2FAdoorn%2FCity-Adoorn-Zuidlandoverview.jpg&hash=3fc6d2c26ac8bf43083aad18a86a6f81689cd760)
Would this information give new light on the subject?
FrankU
First make a backup
then Make sure that by saving / loading multiple time that city, others props are disappearing. When prop pox strikes, it , as this date, usually removed more than one prop the first time.
If no, then you aren't prop poxed ( yet, as you use files that trigger the prop pox )
If yes, I'll definitely need the savegame
Brief report
I performed an additional test. I changed the IIDs of the three Maxis modded static into timed props of the bdk-resource file and updated the corresponding lots to show the new IID props. Then I developed test city #2.1 with all my custom content, the props at PP and the buildings, lots and modds at MP, including the changed props. Just to make sure people understand the test, let me explain that, up to this point, city #2.1 has been developed exclusively with Maxis vanilla lots, buildings and props. No custom props, no modding. The city was developed up to the point where it has a 15.9 Mb savegame file with a 5.9 Mby 2977aa47 subfile size. So, it is close to the critical point where Prop Pox may manifest itself. If developed further exclusively with Maxis content, it shows no Prop Pox. Developing this city with all custom content and the corrected props also leads to no Prop Pox (this is the new result). Developing this city with all custom content and the infected props with their original Maxis IIDs lead to Prop Pox.
Because the only difference between the two latter tests is the change in IID of the three Maxis static props that were modded into timed props, one must conclude that the cause of the Prop Pox is having a static and a timed prop sharing the same IID in one's plugins, the static prop being read first by the program. By changing the IID of the timed prop one eliminates the conflict, and avoids Prop Pox. Beware: this statement does not mean we found a cure for an already infected city, just that we confirmed how can we avoid Prop Pox for brand new cities.
Cheers,
Bap
Can't fault the logic there....thank you Bap for your efforts.
bap, thank you so much for all the time and energy you've spent on illuminating the cause of this issue. :thumbsup:
Upon reading your latest report just now, I had an idea--what happens if the original Maxis Static Prop Exemplar is copied into a new .dat and loaded after the problematic Timed Prop?
-Alex
Well I'm glad to see some light shed on this problem. This problem along with others inherent to collecting custom content for so long is what had caused me to get sick of the game.
Searching my memory about the state of what was my infected city I think I can bring some more information. The city had lots of medium and low density residentials, mots of which were custom content. However like all my cities in this region nearly all undevelopped space was covered by peg seasonnal trees which are timed props.
Knowing that, did anybody examine the possibility that those or any older version of them could also be associated with the pox.
I would also ad that I had a mod that added peg seasonal trees on the streets instead of the palms. I don't remember what the mod is named nor whose it was.
Cowcorn,
The problem isn't caused by timed props in general. The problem is caused by static Maxis props that get modded into timed props and still have the original ID. Those seasonal trees were created from scratch and have their own ID's. None of them have Maxis ID's. If they had Maxis ID's, then there will be a problem. I've checked the ID's myself.
That particular mod was Ardecila's and it used the same seasonal tree props, which shouldn't cause a problem.
-Swamper
Thank you for Swamper for clearing this to me. I was just trying to provide more information but I see this was not relevant.
Quote from: Tarkus on March 07, 2009, 03:36:46 PM
Upon reading your latest report just now, I had an idea--what happens if the original Maxis Static Prop Exemplar is copied into a new .dat and loaded after the problematic Timed Prop?
Alex, if this is done
after the city has been infected (i.e., lots have grown using the problematic timed prop) it will not help preventing Prop Pox. At best, this would be equivalent of removing the infected file from ones plugins. We already know this is not enough to prevent the manifestation of the pox if the 2977aa47 subfile reaches the 6 Mb limit. If this is done
prior to city infection (no lots grown/plopped with the affected prop) it may help preventing the pox, but this still has to be tested. However, in this case I believe it would be better to simply delete the affected props from the prop package or to change their IIDs to avoid the conflict.
Regards,
Bap
bap, thank you for the quick response--I was thinking that would probably be the case, but thought I should ask.
-Alex
Testing Prop Pox by yourself
Basic Information
For those willing to check my experiments with Prop Pox, I uploaded three versions of the test city #2 at fileden.com. They can be downloaded at the following addresses:
City - Riquelandia 4.sc4 (http://www.fileden.com/files/2009/3/3/2347164/City%20-%20Riquelandia%204.sc4)
City - Riquelandia 5.sc4 (http://www.fileden.com/files/2009/3/3/2347164/City%20-%20Riquelandia%205.sc4)
City - Riquelandia 6.sc4 (http://www.fileden.com/files/2009/3/3/2347164/City%20-%20Riquelandia%206.sc4)
The relevant information about these cities is as follows:
filename total size(Kb) 2977aa47 size (Kb)
Riquelandia4 15967 5926
Riquelandia5 16159 6162
Riquelandia6 15923 5742
Riquelandia4 was build exclusively with Maxis vanilla lots & props up to this point. If developed in a plugins without Maxis-modded infected props it will not show Prop Pox. There is room for further zoning in the south and east outer bounds of the city, just inside the highway belt. There is also room for development at the southeast corner outside of the highway belt.
Riquelandia5 is a further development to Riquelandia4 made while the infected props were in the plugins folder. Thus, it will get Prop Pox if you let it grow just a little bit more -- even if the infected props are no longer in the plugins folder. No big development effort is needed here because the city is on the verge to show signs of Prop Pox. Because only custom prop packages were in the plugins (not the lots), anyone can play with this city without being in risk of seeing brown boxes. All installed lots up to this point are Maxis vanilla ones.
Riquelandia6 is a saved version of Riquelandia5 just after it got Prop Pox. As you can see, the city file and the 2977aa47 file both shrank. Several props are missing at different places around the city (look for city parks, water treatment plants, farms).
Relevant warning before doing the tests
This city (all three versions) was built in a region with neighboring connections to the west, south and east. Therefore, there are a lot of sims that work at the neighboring cities as well as residents of the neighbor cities filling job positions at Riquelandia. If you install the city in an empty region it will take a few game years (and a bit of your Mayor abilities) to stabilize the city against unemployment. Increasing Airport budget to maximum helps relieving commercial/office caps and allowing more commercial buildings to grow. Reducing commercial taxes to 5.5-6 per cent, industrial taxes to 5.0 (manufacturing) and 6.5 per cent (hi tech), and residential taxes to 7 per cent also helps to speed up city grow. There are a couple of gaps in police, fire and educational coverage (south & east, the regions that need to be developed). Filling those gaps help speeding residential grow.
In order to incorporate one of the cities in an existing region (to alleviate the neighbors connections), please copy the downloaded cities into your My Documents\SimCity 4\Regions\Downloads folder, then in SC4 use the 'import' button on a large city tile.
Test #1: getting Prop Pox
Install Riquelandia5 in a test region. Either create connections to neighbor cities and/or apply your Mayor skills to stabilize the city against the sudden change in jobs filled inside/outside the city. Zone exclusively low density residentials in the empty regions. Let the city grow. Save and exit the city at about every 2000 extra habitants and check the size of the savegame file (explorer) and the 2977aa47 subfile (with Reader). If the 2977aa47 file keeps increasing in size with the city population, you still have no Prop Pox. Load the city again, let it grow, and save again. At some point after the 2977aa47 file goes above 6 Mb it will start to shrink. The next time you enter the city you will notice several props missing. The easiest places to look for missing props are city parks, water treatment plants, and farms (p.ex., Pedriana's plant has lots of props). You may keep saving the city after it got Prop Pox. Every time you enter the city you will see more and more lots with missing props. Don't be sad. This is just a test city, nor the one you spent several months carefully developing.
Test #2: if you are skeptical
If you believe there is some unknown voo-doo with Riquelandia5, you can do the following test. Make a backup copy of Riquelandia4. Install this city in your test region. Move all files in your MyDocuments\Plugins and ProgramFiles\Plugins folders to temporary folders outside the Simcity directory tree. Now you only have the Maxis vanilla version of the game. If you develop Riquelandia4 following the same guidelines stated in test #1, at some point the save game will jump to 26 Mb because the 2977aa47 subfile has jumped to 16 Mb in size. Both files will keep increasing in size as the city grows. This city will not get Prop Pox. This test is to convince you that Riquelandia4 is a pox-free city, i.e., it is not yet infected by the Prop Pox. Remember to zone low density residentials as this helps to increase the number of props in the city and reach the desired 6 Mb limit.
Now let's infect the city. Install the peg-oww2-bdk-resource.dat file (or any other infected file that might be found) in one of your plugins folders. Install the backup copy of Riquelandia4 over the previously developed version of it, and repeat all the stabilization and developing procedures as before (at this point one may realize how boring doing this 31 times might be &mmm). Repeat the save-exit-check size procedure as before. This time Riquelandia4 will show Prop Pox when the 2977aa47 subfile grows larger than 6 Mby. The only difference between these last two tests is the presence of an infected dat file in your plugins. Remember to zone low density residentials as this helps to increase the number of props in the city and reach the desired 6 Mb limit.
Confidence in a given experiment is only achieved if that experiment can be independently reproduced by other researchers. If you are willing to repeat the tests, we would appreciate if you post your findings here at this thread.
Thanks a lot Bap :thumbsup:
Quick followup
We have found what cause the jump in the savegame at 6mb
We might have found a way to "fix" a city with prop pox, it won't restore the missing prop, but it might prevent the spreading of the prop pox ( only if you remove/update the modified timed prop from your plugin )
I am not sure if I am considered an independent researcher but here are my findings:
I have been trying out bap's tests and so far have confirmed the existence of prop pox in Riquelandia 5. Interestingly I found that after its arrival the 2977aa47 file drops but then rises again even though props are still absent from lots. It is also erratic in where it strikes. There are four water treatment plants in the city but only one has lost all its props. Avenues lose their medians for some stretches then get them back later along the road.
Results of test 1 - Riquelandia 5 pre pox
Population Save game filesize 2977aa47 filesize
131857 15.9MB 6305633
134634 16MB 6335339
136751 15.7MB 5874948
139772 15.7MB 5833379
140695 15.8MB 5866407
Now to do test 2 but using the Trail Park Engine instead of the BDK file.
I put Riquelandia 4 into the region. This is non poxed city.
I started with nothing other than vanilla SC4 - ugh. At each population change I saved then exited and took a back up of the city.
The starting population is 119K
Only Maxis
Population Savegame 2977aa47
124254 15.6 5985656
125180 16.8 6214666
130058 16.1 6310482
132158 25.7 16304909
Replace the original Riquelandia 4 and added Peg Trail Park Engine 305b
123063 15.7 6001232
125183 15.8 6087109
128031 * 25.3 16044101
No pox is showing at this stage.
Removed the Trail Park dat and put the BDK one in but did not replace the city
130648 15.3 5708398
The city immediately got the pox.
Removed the BDK dat and replaced with city *
130527 25.4 16158393
I have subsequently tested with many other single files in plugins and have yet to find another file that gives the pox BUT there must be others as it appeared well before the release of the OWW2_BDK_RESOURCE file. It would help if some of the sufferers could give a better idea of when it struck and what they had in plugins at the time, if this is possible.
First, thanks again to everyone for the work they're doing on this.
I got hit by the pox 13 months ago, with all the classic symptoms. It was, of course, not immediately obvious what was causing it. But I thought it might be some dodgy download from the STEX. I remember removing a few things I had recently tried and that had low download counts, as they seemed the most suspicious. Unfortunately, I don't remember what most of them were. But the one I was most suspicious of, I do remember - it was BLAM UninSpire (http://www.simtropolis.com/stex/index.cfm?page=1&type=all&keyword=uninspire#). What made me suspicious of this building was though it looked nice, it was improperly constructed. Hovering the cursor over it didn't show the usual information - in fact, it showed nothing at all. I had only recently been using this building, so I bulldozed it out of all my cities, and then deleted it from my Plugins file. The pox never appeared in any other city.
However, there is another event that I think is even more likely to be connected with my city's contracting the pox. Right before the pox occurred, I realized for the first time that for the CAM dependencies, I needed only the model of the original building, and that leaving the other files in the dependencies in my Plugins folder had led to a lot of non-CAM versions of my CAM buildings. So I went through each city, painstakingly finding each non-CAM building of this type, and then bulldozing it. After I had done this with all my cities, not letting them run in the mean time, I removed everything from all my CAM building dependency files except the models. The pox struck my city about a day after this. I have long thought that I may have missed one building in that one city, and that that was the cause of this problem. I don't know if that's possible or not, but I thought I'd pass it along.
ummm... Z, have you read the thread? Specifically the first 4 posts that outline the cause of the pox? It's not buildings, it's static maxis props that were converted to timed props without a new IID.
There is nothing in any of the CAM original upload files nor in the BLaM Uninspire upload that might cause the Prop Pox. As Shaun said it has been identified so far as being Maxis props that were modded without changing the IIDs. There may be other reasons but they need to be directly related to props rather than buildings.
Many of the files on the STEX are badly modded but that in itself does not cause PP.
Yes, I understand that it's a prop problem - I just thought that if the building download was bad, it's possible that it came with some modified props that were causing the problem. Same thing with the CAM dependencies - and I want to stress that it was the dependencies I was suspicious of, specifically files that shouldn't have been downloaded, and not anything in the CAM itself. But since I didn't remove any prop packs, why did none of my other cities ever come down with the pox?
QuoteAnd since I didn't remove any prop packs, why did none of my other cities ever come down with the pox?
The prop pox strikes at a specified size of the 29AA7747 subfile, around 6Mb, which is usually when your city will get around 150K 200K different props
Quote from: z on March 12, 2009, 03:22:25 AM
I just thought that if the building download was bad, it's possible that it came with some modified props that were causing the problem.
Modifying Maxis props without changing their IID's is fortunately something not the average batter/lotter would be doing.
It requires the use of Reader, and so far we've only seen two modders (one in the past and one recently) who've done this.
Most ordinary bats/lots only might include prop exemplars of the creator's own custom bats, but not modified Maxis props.
Quote from: wouanagaine on March 12, 2009, 03:25:59 AM
The prop pox strikes at a specified size of the 29AA7747 subfile, around 6Mb, which is usually when your city will get around 150K 200K different props
I just checked all six cities in my region. The affected city has a subfile of 16 MB. Three cities have subfiles under 6 MB, although one is 5.8 MB. But one other city has a subfile of 16 MB, and another has a subfile of 17 MB. Yet those were played for months after the pox struck the first city, and they're fine.
EDIT: I just checked a large city in another region that I have played sporadically since the pox hit. It, too, has a subfile size of 16 MB, and has no problems. I use the same Plugins files for all my regions.
if your subfile is over 16Mb we only get one occurence where it shrink back to 6Mb caused by the prop pox
if your subfile is over 16Mb than it is almost safe
Can you post the city which is prop poxed and which have a subfile of 16MB please ? I'll decypher it
OK, here's a link to the Near West Side (http://filehost.justfreespace.com/788City%20-%20Near%20West%20Side.sc4). It's over 80 MB. I've also located a version apparently from just a few days after the pox hit, if that would be helpful. But I'm going to bed right now...
Quote from: z on March 12, 2009, 03:42:40 AM
EDIT: I just checked a large city in another region that I have played sporadically since the pox hit. It, too, has a subfile size of 16 MB, and has no problems. I use the same Plugins files for all my regions.
Yes, but you may not have used LOTs that have affected props in all the cities.
Quote from: z on March 12, 2009, 04:19:50 AM
OK, here's a link to the Near West Side (http://filehost.justfreespace.com/788City%20-%20Near%20West%20Side.sc4). It's over 80 MB. I've also located a version apparently from just a few days after the pox hit, if that would be helpful. But I'm going to bed right now...
Your city is prop poxed for sure, but the corruption occurs after the 16Mb hence why it has not shrink to 6Mb
I don't know if this has gone unnoticed, but NAM contains an overridden SC4 prop too: the $$ lamppost. The change is the addition of a Resource Key 4 xm property (the original RKT4 is unchanged). This is different to replacing RKT1 with RKT4 though (as in PEG 's props). The addition of the RKT4xm was needed for using the lamppost as a network prop (in "mirrored" tiles).
Maybe someone should check if this causes the prop pox too.
Tip: Lots using the $$ lamppost are the ingame parks and plazas.
Cogeo, can you please give me the TGI of that prop ?
So far, we clearly identified that changing a static prop to a timed prop result in a change of 16 byte in savegame. We didn't notice anything about RKT4xm but such props are quite uncommon, so I prefer to check
0x6534284a, 0xc977c536, 0x1dfb0000 - C1x1x8_$$lamppost_1DFB
Barby replied just before I clicked the Post button!
Apart from the ingame parks and plazas, it's being used by a bunch of other (ingame and custom) lots too. Actually it's one of the most commonly used SC4 props, and one of the most recognisable ones.
It is in fact very common, and it doesn't have any influence on the savegame as far as I can see ( I've looked thru 5 differents big cities with lot of props)
So for now, I think that adding the RKT4xm doesn't lead to prop pox.
PS : I assumed the original prop is already a timed version as it use RKT4.
Quote from: wouanagaine on March 12, 2009, 01:47:01 PM
PS : I assumed the original prop is already a timed version as it use RKT4.
Hmmm, both yes and no. The RKT4 property (in both the original and the modified one) is used for combiing multiple models (the lightpost model for both day and night, and the Lightflare/halo one). So this is not strictly speaking a timed prop, but of course, the light halo is displayed only during the night (this is controlled by the Nighttime State Change property).
Quote from: cogeo on March 12, 2009, 02:05:26 PM
Hmmm, both yes and no. The RKT4 property (in both the original and the modified one) is used for combiing multiple models (the lightpost model for both day and night, and the Lightflare/halo one). So this is not strictly speaking a timed prop, but of course, the light halo is displayed only during the night (this is controlled by the Nighttime State Change property).
I've done more experiments and looked at 2 savegames with that prop, one with NAM and one without NAM, same data, same size, ie no influence
Quote from: wouanagaine on March 06, 2009, 03:24:08 AM
FrankU
First make a backup
then Make sure that by saving / loading multiple time that city, others props are disappearing. When prop pox strikes, it , as this date, usually removed more than one prop the first time.
If no, then you aren't prop poxed ( yet, as you use files that trigger the prop pox )
If yes, I'll definitely need the savegame
Wou, I looked more closely into the city. I reopened it and searched for missing props. I found one lot that had only textures and some parked cars. There was no query anymore. I tried to find out which lot this was. By doing this I changed into "Area" view (where you can see if the area is residential, industrial, commercial or other). After going back to the normal view all the textures were missing.Only parked casr on the terrain base were visible. Now I also missed the textures in the Schönbrunn Palace lot and in the Airforce base. Is this Prop Pox?
After having left the city, without saving, and entering again I found exactly the same things.
There are so many lots with so many props.... I did not see really obvious props missing besides these three.
I'd say: very funny indeed and it does not look exactly like the Prop Pox as described here.
Doe this mean anything to you all? I have a bakup of hte city and the whole region. If you want it??
OK , just to re-cap...it appears that even though the Pox struck before OWW2_BDK_RESOURCE file was released , this particular file is a contributor. I also realize that it's creator more than likely will not fix the IIds for the modified props. If that is the case , are we all supposed to change the IIDs ourselves to help prevent possible poxing in our cities , or is this a special exemption to the rules and will be updated by some one in the community?
Jayson
Quote from: sithlrd98 on March 12, 2009, 06:08:56 PM
OK , just to re-cap...it appears that even though the Pox struck before OWW2_BDK_RESOURCE file was released , this particular file is a contributor.
Indeed.
Quote
I also realize that it's creator more than likely will not fix the IIds for the modified props. If that is the case , are we all supposed to change the IIDs ourselves to help prevent possible poxing in our cities , or is this a special exemption to the rules and will be updated by some one in the community?
Assuming that the creator will not update its affected props, the answer is
yes (we are all supposed to make the changes by ourselves). Each user has two alternatives of how to correct the problem by him/herself (see here (http://sc4devotion.com/forums/index.php?topic=7066.msg224892#msg224892)). They are relatively simple procedures that require loading & modifying your version of the bdk-resource file with ilive's Reader. As I understand, no one other than the creator is allowed to make a corrected version of the affected prop pack available to the community as this is proprietary material. Sorry ... ()what()
Thanks! I figured as much. I'm also still wondering if improperly done T-21 mods may also be a contributor? I understand that , as far as we can tell , the NAM,etc.is fine.
Thanks for all your hard work in trying to nail this issue and keeping us up-dated!
Jayson
Just a little heads up though on the pack being referenced. His EULA prohibits modifying his uploads (I'm assuming "in any manner" includes for personal use as well).
QuoteThis product may not be modified, reused or redistributed in any manner.
Just didn't want to see any legal boohooing going on because of this proposed fix.
Quote from: sithlrd98 on March 12, 2009, 07:43:21 PM
Thanks! I figured as much. I'm also still wondering if improperly done T-21 mods may also be a contributor? I understand that , as far as we can tell , the NAM,etc.is fine.
Jayson,
Since T21's are not props, they shouldn't contribute to the Prop Pox. T21's merely reference props to place on specific tiles of networks.
Quote from: XiahouDun on March 12, 2009, 08:47:53 PM
Just a little heads up though on the pack being referenced. His EULA prohibits modifying his uploads (I'm assuming "in any manner" includes for personal use as well). Just didn't want to see any legal boohooing going on because of this proposed fix.
Before I left his site, I showed him a project I was working on based on his MTP content. He said he didn't mind that I was creating it from his files. He did say that I am not to upload the files anywhere though, as I did modify his content to suit my needs. So modding for personal use is okay, but the final results of personal modding are not to be released, from what I understand. So there aren't any hard feelings, I left his site for various personal reasons.
-Swamper
Quote from: XiahouDun on March 12, 2009, 08:47:53 PM
Just a little heads up though on the pack being referenced. His EULA prohibits modifying his uploads (I'm assuming "in any manner" includes for personal use as well). Just didn't want to see any legal boohooing going on because of this proposed fix.
Think about it, he will have no way of knowing if you edited his files unless you tell him. And there is realistily nothing he can do to stop you anyway.
from http://simpeg.com/forum/Themes/default/PLEX_license.html
Quote
You may use and modify this product for your own use but this product may not be redistributed in any manner without consent of the author.
so you can modify it
And even if wouldn't have until you don't redistribute it, you're safe
I think we can take it as gospel that those files will not be changed, so the choice is simple.....modify them yourselves following Bap's tutorial or don't use 'em. EULA aside, I think personally it's extremely poor form to know there is a problem and not correct it, irrespective of how many people actually have this problem. It merely shows a contempt for the community.
Quote from: callagrafx on March 13, 2009, 01:52:10 AM
I think we can take it as gospel that those files will not be changed, so the choice is simple.....modify them yourselves following Bap's tutorial or don't use 'em. EULA aside, I think personally it's extremely poor form to know there is a problem and not correct it, irrespective of how many people actually have this problem. It merely shows a contempt for the community.
But we're all out to get him, well at least the BSC is ::) :D My concern was more him running around saying that SC4D encourages people to violate other creator's EULA. I'll leave out my commentary on his behavior, since you and I agree on it and at this point would be like beating a dead horse. Just wanted to get that statement out there.
(For the record was taking that quote from the EULA in the zip of the download)
For the record I did the following test
Riquelandia4 is not prop poxed and if you run it for 100 years with an empty plugins, it will not show prop pox
I used Riquelandia4 and made a dat file with only the 4 examplars Bap identified, this is the only file in my plugins folder
Then I load Riquelandia4 , run for 2 years and save => prop pox
Quote from: XiahouDun on March 13, 2009, 02:47:21 AM
But we're all out to get him, well at least the BSC is ::) :D
Now that's just wrong....Despite what he would have you believe, the BSC
does not engage in witchhunts, we have much better things to do ::)
Quote from: wouanagaine on March 12, 2009, 01:47:01 PM
So for now, I think that adding the RKT4xm doesn't lead to prop pox.
This does make sense to me.
I have always been wondering waht exactly the game saves in the city files. Having experimented with props early on, and esp with prop overrides, I have concluded that the game actually saves very little information, for each prop instance:
- A reference to the prop, namely its TGI (or most probably I-only) ID(s).
- Placement information, ie coordinates and orientation.
That is, the props' properties are NOT saved. The above assumptions are sort of verified by the following facts:
- If you make a modded version of the prop, changing any of its properties, like RKTx, Orient To Slope, Light etc, and you reload the city, all prop instances (in lots and networks) immediately reflect the changed properies.
- If instead, you change the lot (move the props) the game will display the "old" lot design, as the game saves the placement information for each prop instance, something that's very expected.
That is, for each prop instance the game stores just a reference to the prop, and the information that changes for each instance, which is the placement data. This is indeed a senseful and well-done implementation.
Now about timed props, using properties like Simulator Date Interval, Simulator Date Start, Simulator Date Duration and the like, I think it's quite reasonable to suppose that the game saves some additional information for each prop instance, like prop state (whether it's reset, visible or invisible) and maybe the number of days elapsed since reset. This information is seemingly stored individually for each prop instance, thus increasing the size needed for storing the prop(s).
So it may be a good explanation why the Prop Pox bug occurs. The game first reads the prop exemplar from a datfile; while loading a city, it reads props based on the prop exemplars in the datfiles: if a prop is timed, it expects a longer record (containing the additional data, as described above). Now if the prop's definition differs to what is actually stored in the city file (ie if the prop definition contains timed properties, but the city file does not contain the additional data - or maybe the opposite?) the program might not read the data properly, as it is probably not programmed to cope with this situation. Now, why this happens only if the subfile exceeds a certain size, this is another point.
I will post more on this, two of my packs (Plaza Addentum Mega-Pack and Streetlight Colour Pack V2 on the STEX) do contain some overrides to SC4 props. Most are bug fixes, but the latter is what the mod is exactly about (change the lightcones' model/colour), and does so by overriding the ingame streetlight props. None of above changes a simple prop to a timed one (or the opposite) though.
I'll have to go to bed now, it's 00:45 here.
As far as we've managed to decode the prop subfile within the savegame,
we can confirm that at least the following information is saved for each prop:
- Prop Exemplar Type ID
- Prop Exemplar Group ID
- Prop Exemplar Instance ID
- Minimum X-Coordinate
- Minimum Y-Coordinate
- Minimum Z-Coordinate
- Maximum X-Coordinate
- Maximum Y-Coordinate
- Maximum Z-Coordinate
- Orientation
- State, if applicable
- Start Time of Day, if applicable
- End Time of Day, if applicable
- Interval (in days), if applicable
- Duration (in days), if applicable
- Start Date, if applicable
- End Date, if applicable
- Random Chance
- Object ID
In addition to these there are a number of flags and other bytes contining (so far) unknown information.
Quote from: callagrafx on March 13, 2009, 07:15:01 AM
Now that's just wrong....Despite what he would have you believe, the BSC does not engage in witchhunts, we have much better things to do ::)
Oh I know, I was mocking his paranoia :thumbsup:
So it seems that some tests are conducted at Simpeg about the prop pox and that Pegasus come to the conclusion it is caused by a massive amount of custom content growables. I'm glad Pegasus is willing to conduct some tests even if a low number of people experience the problem
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg24.imageshack.us%2Fimg24%2F8966%2Fscreenshot120h.jpg&hash=65a45d0190b2a32b4402395ebbb0bcc14688a679) (http://img24.imageshack.us/my.php?image=screenshot120h.jpg)
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg17.imageshack.us%2Fimg17%2F8271%2Fscreenshot121.jpg&hash=4ecfe8ec45fb219654115e609b1ae2db251692e0) (http://img17.imageshack.us/my.php?image=screenshot121.jpg)
However, in order to save some time to Pegasus in doing many tests that takes a big massive amount of time and as Bap said it is quite boring and which he should rather likely spend on batting, I will rewrite some of stuffs already said previously
Bap gently upload various savegames made without any custom contents, so that anyone can load them and play with them ( maybe not playing, it is quite a shock to see a big city without any custom content )
Riquenlandia.sc4 is easily incorporatable in one of your region with an empty plugins as far as you have a region with a big city tile available, run it for 10/20 game years then save ( you can even zone low density Residential in the south, Bap already laid down some streets for us ), quit and reload then see if the prop pox is there
You can after, reincoporate the same city ( not the saved one ) and do the same test with some prop pack Bap identified, for the same time.
It is up to you to do the same test, which are quite quick as you won't have to build the city from scratch. If you think the city is not prop pox free, then it is up to you to build such a city, you have an example, and I don't think it is hard ( but it is boring and time consummnig ) to build such a city. Just to let you know I have made a tool that ensure a city is prop pox free or not and I tested it against all savegames people gently upload and I can guarantee you the city is prop pox free
So as far as I can see from the tests ( and I successfully reproduce them ), and Bap' savegames, prop pox strikes without any growables custom content, as it only strikes with some modified ( in a certain way ) maxis props Bap identified. I'm really eager to know from what testing process Pegasus come to his conclusion so I can reproduce them.
Of course I don't ask you to believe me and I'm pretty sure Pegasus don't ask you to believe him either, you just have to redo the tests by yourself and I leave you to draw the conclusion
However, if for any reasons you come to the same conclusion as Pegasus, please let us know because so far we have identified an issue with modified Maxis props in a certain way, but don't really see any relation with massive amount of custom growable and prop pox and it will really help us to know and hopefully I'll be able to develop a tool that eradicate prop pox from you city
It will for the same reasons very handy if Peg can join the discussion here as we are unable to get at his site
EDIT:
Fixed your image link
/Tage
Thanks
/Wouanagaine
I have also conducted tests and have the same conclusions as Wouanagaine. In fact I have identified two of the props that Bap identified as specifically causing prop pox. We would be more than happy to have others replicate the testing using Bap's cities as the more independent people confirm the problem the better.
I'm going to jump into this thread blindly, just having read the first paragraph and Peg's rebuttal. I've been playing SC4 for 6 years now, quite the veteran and all, and I have had one very strange experience where the game totally f*cked up one of my cities.
On my other computer, I was running ~1.5 GBs worth of plugins, and one of my small cities in a med-sized region, pop ~15,000, started to have several lots - mostly Marrast's train stations - go black. All textures and props would disappear, and the lot would cease to function. I could load the city next to it, and the same lots worked just fine. Well, I dozed the problematic lots and replopped them, and was fine. After about a month of playing with this city on and off, saving many times, it came to pass one day that attempting to load that particular city would case a CTD. Every time, although every other city in the region (using the exact same lots) functioned perfectly.
So, I deleted the city and started over again. Never had anymore problems...
Not very scientific, but I believe something with the plugins was malfunctioning.
well i've played some pretty large cities in the past and never spotted this, but then again it was a long time ago.... warning noted
A couple of weeks ago I noticed props disappearing from the city in the large center tile of a Paris region I have been working on. I posted a question about it on the BSC Help page and received fast courteous help from some of the great experts here. I was directed to this Prop Pox forum, read it and followed the advice.
I updated BSC MEGA Props Misc Vol02 and removed PEG_TrailParks_305b.dat PEG_TrailPark-Engine_305a.dat and removed a couple of duplicate dependencies from my plugins. I have since built a large city tile to 31Mb with no sign of Prop Pox recurring.
I would like to thank Bap, BarbyW, callagrafx, RippleJet etal. who have done a great job of sorting out this problem so far.
I have been doing more testing starting from bap's unpoxed city. I can confirm again once again that on its own the modded beach umbrella from the BDK pack - extracted exactly as it is in the pack - does cause the pox.
here is riquelandia prop pox free that Bap upload, and that I get up to the point of being prop poxed using the involved prop
as you can see in this pict, the prop pox is clearly visible
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg4.imageshack.us%2Fimg4%2F8785%2Fscreenshot129.jpg&hash=b98b9d8c221fc4c4b56d365e29c96b3a0f7b331e) (http://img4.imageshack.us/img4/8785/screenshot129.jpg)
and here is what is in the savegame ( of course it is a visualisation of what is in the savegame ):
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg23.imageshack.us%2Fimg23%2F5822%2Fscreenshot130.jpg&hash=640b2b8b762917352f4d023398e67db465c30223) (http://img23.imageshack.us/img23/5822/screenshot130.jpg)
as you can see almost all the middle props have disappears, and all the right props have totally disappeared ( the SC4 shot is from the top right )
This city has been played for only 10 years since I added the involved prop and this is the only custom content used
On 3rd March bap posted the following:
QuoteAs I do have the cdk-www package and it does not cause Prop Pox, I am convinced that the Maxis modded umbrella prop (IID 29000000) does not cause Prop Pox. I could confirm that by performing another experiment with only that prop exemplar in the plugins folder, but I did not have time yet.
This weakens my original hypothesis that is the increase in size of the modded Maxis props that lead to Prop Pox. The important feature which is exclusive to the other 3 Maxis modded props in the bdk-resource file is being originally a static prop modded into a timed one (this is something no other prop in my plugins folder has). This strengthen the idea that what causes Prop Pox is changing an originally static prop into a timed one without changing its IID. This narrows the search for possible infected props in other prop packs.
This was taken to be a recanting of his theory that a certain group of props caused Prop Pox. Since then a lot of work has been done on investigating and testing. I have previously posted some of my findings but have continued to test and experiment.
I started by taking bap's unpoxed city - Riquelandia 4 - and building the city and savegame file from 119394 population and file size of 15.5MB to 126253 population and a filesize of 25.4MB. I modded two other Maxis props that had a Nighttime State Change to have a Prop Time of Day like the previously identified ones. I made a lot with these - picnic baskets - and played with just that dat and the lot in plugins. After plopping two of the lots, I was able to increase the population to 129173 and a file size of 25.5MB without any sign of PP.
At this stage I removed my modded props dat and after re-entering the city plopped two more of the picnic basket lots. The props on the picnic basket lots were using both sets of timing information. The original two had the props disappear at 18:00 but the other two had props disappear when night fell.
I was able to increase the size of the population to 131054 with a savegame file size of 25.9MB
I then added a dat with the single modded umbrella from the BDK Resource Pack.
I ran the city to a population of 132021 and then saved and exited. The savegame file was now 15.6MB - the PP had struck.
Here are some images of the city after re-entering:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi5.photobucket.com%2Falbums%2Fy171%2Fbarbyw%2Flargeparkgreen.jpg&hash=77691c1596579f6cffbfc5544bb6104d823e77ec)
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi5.photobucket.com%2Falbums%2Fy171%2Fbarbyw%2Ffarmersmarket.jpg&hash=f9a416e71702b07fb567040d9a15a07a789a6d10)
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi5.photobucket.com%2Falbums%2Fy171%2Fbarbyw%2Fflowergardens.jpg&hash=4600f1dd0fb202e2044f3ffb349328fb27fa89c0)
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi5.photobucket.com%2Falbums%2Fy171%2Fbarbyw%2Fwatertreatment.jpg&hash=ee55e8a3c256b5ae2506106fb79e30f22c93c519)
The only difference between the props that I modded and those that Pegasus modded is that mine are used rarely but his are used a great deal in Maxis low density residential lots.
I too seem to be having this issue and in my case it seems to be particularly bad, losing about 80% of my props.
Farms:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi344.photobucket.com%2Falbums%2Fp348%2FQuinRiva%2FBalstirion-May28771237617364-1.jpg&hash=9dbd80df849d92c9683cb01f6d09e68f4a6cc399)
Note that it appears as if a line has been drawn through the rice, wheat, etc fields and props below/right are not drawn.
More farms, again showing a band of props:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi344.photobucket.com%2Falbums%2Fp348%2FQuinRiva%2FBalstirion-May22771237617327-1.jpg&hash=364a3e53077345ef3ec3e459120194f5cb2a6c33)
Yet more farms:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi344.photobucket.com%2Falbums%2Fp348%2FQuinRiva%2FBalstirion-Jun15771237617486-1.jpg&hash=ba4c03d46b5802cd9abbb5506cd4d4c47fb741cc)
A military base:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi344.photobucket.com%2Falbums%2Fp348%2FQuinRiva%2FBalstirion-Jun9771237617453-1.jpg&hash=c38dae1db90f48c8cccdb7de6e459171e8020a55)
Residential zone:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi344.photobucket.com%2Falbums%2Fp348%2FQuinRiva%2FBalstirion-Jun5771237617424-1.jpg&hash=56ad714f98c73042cdd9ffdde8143010b658f2dc)
Etc:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi344.photobucket.com%2Falbums%2Fp348%2FQuinRiva%2FBalstirion-Jun1771237617393-1.jpg&hash=abfaa4f9fe6bc0e19e79860a814afa5eaedd4d28)
I'm not sure what the file size was before I discovered this problem, but base on how slowly this city runs I would assume it was pretty large. I've noticed that heavy farming areas take longer to load than other areas, and although this region was about 40%, about 70% of the land was covered in farms. My plugins folder is about 2.5Gb so the problem could be anything.
Fortunately the region shouldn't be particularly hard to replace.
Wow... a total loss...
except you may want to resize your images a bit... they're sticking outside of the forum border.
- Allan Kuan
Yeh, sorry. They displayed just fine on my screen (my big screen ;D ), I've shrunk down to 1280 so they should display fine now.
Max image size should be 1024 wide, please. Can you have a look at the save game for this city and tell us the size? If you can use Reader, you can also open the save game in that and see the size of the sub file with the Type ID 0x2977aa47.
If it is possible I would like you to upload your savegame somewhere on the net ( yousendit, fileden, etc.. ) and post the url here so we can check stuff inside the savegame
Thanks in advance
Wouanagaine: The visualization of the PP pattern in your earlier post on this page exactly matches the pattern in the two cities I had that developed the pox. I did not have the BDK file in my plugins, but I did have the CDK_IND-205.dat and the TrailPark-Engine_305a.dat that BarbyW identified earlier, and I used the TrailParksIII in all my cities.
Kendra
I need to go back and test those two files again and also to test out other earlier packs.
I did revert to the unpoxed Riquelandia city and played to over the critical file size with my BSC Props and BSC Textures folders in and it did not corrupt the city. I am trying to cover all bases but it is tedious and lengthy work.
I have tested out again with the CDK_IND-205.dat and the TrailPark-Engine_305a.dat in plugins and passed the critical point without any prop pox. I also tested with all the contents of the Legacy CD and that also is clean. Now to work on other files from 2003/2004.
Quote from: BarbyW on March 21, 2009, 02:47:06 PM
I have tested out again with the CDK_IND-205.dat and the TrailPark-Engine_305a.dat in plugins and passed the critical point without any prop pox. I also tested with all the contents of the Legacy CD and that also is clean. Now to work on other files from 2003/2004.
Sorry for being absent from this discussion. I just don't have ANY time lately - even to help research the problem that has troubled me the most over the years of playing SC4. I know there was a question about what plugins I might have had the first time I observed it. The industrial seawalls and the trail parks were my leading suspects... :(
Well... it may not be just that...
If I read Bap and Barby's minds correctly, the cause might be due to modification to a specific group of original Maxis props without changing the ID.
In that case many more default and custom lots could have used those same modified props. And any of those lots might therefore become a trigger of the pox.
EDIT: Can someone give me the green light on whether the rest of Pegasus' stuff is okay to use? Did bap test the CDK3 port docks?
- Allan Kuan
It isn't the lots that are the problem but the props that are used on them. If the props have been modded without changing the IID of the prop then this will affect all uses of the prop in game. The props that we definitely know cause PP are widely used on Maxis low residentials. Thus if a lot of them are present it would seem to result in the PP. We have all been testing in a city that is Maxis only content and reverting to a clean version for each test.
It is never good to mod Maxis props without giving them new IIDs as the modding will affect the instances in a city. We hope to have more of a definite solution with in a couple of weeks but it is a long and boring process. We really would have appreciated some other people doing the tests as the files are available for you to try. That way some other independent results could be shown.
Edit: I haven't tested any of the later stuff as this was first commented on earlier than the release of the BDK. You could always do the tests yourself.
I have downloaded Riquelandia, and am playing it with the plugin file I used on my PP'd cities. I have also enlisted a special group of workers in the northwest corner for a special project! :P
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi124.photobucket.com%2Falbums%2Fp36%2Fowlsinger%2FSimCity4%2FPeepWatch.jpg&hash=4a4d061b40a4afede08bfa108d2f7915b39e4d8f)
I will keep track of my results and let you know.
Kendra
Funnily enough I haven't seen the crowd trying to escape the pox but then I never cleared a small area of land for them.
I hope you have just the prop/resource/textures in place and not the lots - especially the growables as that could make a difference to the the final result. I also see that you have plopped the Census Repository. The testing so far has only been done with Maxis content in the city and the assorted prop/resource/texture packs.
Thank you for testing this out, Kendra. Another voice will be appreciated. Once you have your results maybe you could test out from the base city again but with just the BDK Resource pack - just to corroborate the findings already shown.
Why is it all the peg links leads to the prop pox thread? I didnt think MTP lead to prop pox.
They don't cause Prop Pox, it was establisht that it was caused by another of his files. However to warn people for it, any form of PeG's name leads to the page. PeGaSuS himself also has an opinion about why, one which I shall not post here.
(Sigh) I have so much to learn! &mmm
However, I am determined to find out what in my folders caused this problem for me, so I will do the best I can, and learn it along the way. I have one question........when testing with the vanilla city, should I have all the Maxis updates and landmarks installed? It seems that has already been shown to be safe, and I would need those when I add custom prop packs to the plugins to test.
Kendra
Yes you should have as much Maxis content as you wish plus as many custom prop/resource packs as you had. Try to leave out lots especially growables as they may skew results. We are trying to identify any props so custom lots may cloud the issue.
How immature ::)
I hope that the Maxis update and Maxis landmark are not causing any problem :)
Kendra, can you please give us the list of plugins you're using so we can have a look at them
To do that, follow the below process:
open a command line
navigate to your My documents\Simcity 4\Plugins folder using cd
( if you're on XP this will be cd \Documents and settings\[your account name]\My documents\Simcity 4\Plugins, on Vista it will be cd \Users\[your account name]\My documents\Simcity 4\Plugins )
If you use datpacker, we need to original folders, not the compressed one
then at prompt type dir *.* /s /b > pluginslist.txt
this will create a file called pluginslist.txt which you can attach ( after zipping it ) here
Quote from: owlsinger on March 22, 2009, 01:19:27 PM
However, I am determined to find out what in my folders caused this problem for me, so I will do the best I can, and learn it along the way. I have one question........when testing with the vanilla city, should I have all the Maxis updates and landmarks installed? It seems that has already been shown to be safe, and I would need those when I add custom prop packs to the plugins to test.
Kendra, the only (downloadable) Maxis landmarks you need to have installed in order to be able to play Riquelandia without getting a brown box is the Plugin_002_TheLivingMall. There are a few other Maxis landmarks installed in the city, but those already come with the vanilla distribution. EP1 and BAT updates cause no Prop Pox. So, it doesn't matter if you have them installed or not. I can also say that
Plugin_005_EstadioSeul.dat
Plugin_006_GlobeArena.dat
Plugin_007_AirForceBase.dat
Plugin_00D_Parthenon.dat
Plugin_00E_SchlossSchoenbrun.dat
Plugin_017_SanFranCityHall.dat
Plugin_030_TaipeiArtMuseum.dat
Plugin_031_AdlerPlanetarium.dat
also do not cause Prop Pox. They were included in my plugins for the tests where the city does not show Prop Pox.
I cannot say anything about other Maxis plugins as they were not tested. But it is probably safe to play with the rest of them, as one does not expect Maxis to mod their our props (without chaging their IIDs).
It is great to know you are willing to check what in your folder causes Prop Pox. As Barby says, this may be a tedious and lengthy process. May I suggest you first make a control experiment, temporarily removing every single custom content (lots, bats, props and modds) from your plugins folders, and developing Riquelandia until it goes beyond 25 Mb (prop subfile larger than 16 Mb) in order to be sure that it does not get Prop Pox. Then, when you get Prop Pox in a future test from the original Riquelandia city you will be sure that the culprit is something you have put back in your plugins folders. If you are going for the binary search procedure, please have in mind that the idea is progressively eliminating the prop packages that
do not cause Prop Pox, while narrowing down the search.
Good luck with your tests.
Bap
Are the NAm little stretlights prop pox? Before my comp broke I remember they were all over the place ()what()
No,LE0, I don't think the NAM streetlights will cause prop pox.
Quote from: LE0 on March 23, 2009, 03:03:10 PM
Are the NAm little stretlights prop pox? Before my comp broke I remember they were all over the place ()what()
No. After removing the affected props in the BDK resource pack I tested again with all custom content I have in my plugins folder and got no Prop Pox (see here (http://sc4devotion.com/forums/index.php?topic=7066.msg224886#msg224886)). Therefore, nothing I have left there causes Prop Pox. This includes NAM, SAM and RHW (versions of mid-2008).
Actually it wasn't caused by ANY of P.e.g's files, as there were confirmed (err as best as they can be confirmed) cases of the prop pox long before P.e.g even started making content. I do think that is a rather ...inappropriate use of the forum's censor thing, but that is left up to the site staff and their opinions.
Not quite correct. There are some of that persons files which DO cause prop pox, however they are not the sole source. There are others. My understanding is that further research is being conducted by several sources, and more information will be made public in a while.
I think the time has come to make some statements about this situation and where we are with investigating it.
1. After extensive and meticulous research, bap identified that four props in one one particular file had caused his city to get the Prop Pox.
2. This was taken seriously by some of the community but treated with disdain by others.
3. BSC tried to identify if any props modified by any of them were of the same type as those identified. One set were found as having been modified without a change of IID from Maxis. These were corrected and an update posted to the LEX.
4. bap provided 3 files for investigation. These have been tested by a number of people and his findings have been corroborated.
5. Testing also continued to see if the individual props could be identified. Two of the four were found to cause PP. The other two were cleared.
6. Wounanagaine made a tool to analyse the savegame. This has been refined and he has shown screen shots from it. With this our number crunchers have been analysing the savegames and much has been done in the way of decoding - something that was discontinued in 2004 by the early modders like Karybdis.
7. I tested with a full set of BSC Props and textures. No PP was caused.
8. I have been testing again with a full set of PEGProd files. I have not yet reached the critical mass point but will soon and will report here with the results.
9. owlsinger is also testing and will report back with her results when she has them.
At this stage of research there is only one certainty - two Maxis props that have been modded without changing the IIDs have been identified as causing PP. This is not to say that there are no others and at this stage no one can satisfactorily explain why these two in particular cause the problem. The work being done behind the scenes is tedious and lengthy and unless you have actually had a problem with PP there is no need to worry.
If you have had a problem, then posting your poxed city to a file sharing site like fileden so we can look at it would be helpful as that can be added to the cities being analysed. This would help to identify any problem props so they can be cross checked with further testing.
Although it has been treated as a joke by some, for the people whose carefully crafted cities have been poxed it is not at all. It needs the maximum amount of investigation so if you can help by testing, please do. If you have a poxed city, post it somewhere that we can collect it for analysis.
Thanks to all for this meticulous research. I think I still have at least two poxed savegame files that I will post. I may also have pre-pox and post-pox versions. Does it matter which I upload or would both be helpful? Since I understand the pox exists in the save file, even if it hasn't visually appeared yet, maybe it doesn't matter?
Snorelli, please upload the pre and post files, as we can totally explore the prop pox free version, but not the prop poxed one ( as SC4 ). The prop poxed one can be cheated to appears correct only to my tool, but not to SC4 because SC4 is doing savegame validation upon loading and we can't validate a modified savegame by hand. Also the more I have prop poxed cities, the more my tool can be 'immune' ( ie not crashing ) to different kind of invalid data in savegame ( the effect of prop pox )
Edit
Please do also the same process I asked Kendra, ie if you can provide us with the list of plugins you have. As you are one of the earliest member who suffer the prop pox and as it strikes you before the already identified props were release, it will certainly help us to narrow our search for the others ones
Hey there,
I made some prop pox testing too. I was able to produce and reproduce the Prop Pox. I tested all situations several times.
Test environment:
- a big city map with a 609xxxx byte (5,8MByte) big network file
- 2,25Gbyte big plugin folder
- nearly all downloads from http://www.simcityplaza.de/
- many downloads from the lex and the plex
- many downloads from stex
- some downloads from japanese batters (somy as example)
- some downloads from http://www.simcitypolska.pl
- OWW2 Set within plugin folder
or
- no OWW2 Set within plugin folder
Test Results:
1. Without the OWW2 Set and it's essentials I wasn't able to produce the prop pox. No matter what I do.
Everything that follows now only occured with the OWW2 and it's essentials in my plugin folder.
2. If the game changes the memory management to the "big" version (network file above 6 MByte) there is a high chance (aprox 33%) this will lead to prop pox. However it's possible that the management changes and no prop pox will appear. In fact this happens more often.
3. If the "big" memory management is active and you bulldoze enough buildings the game will change back to the "small" memory management. And this will always (!) lead to prop pox!
4. Once I installed this beach set (http://www.simtropolis.com/stex/stexdetails.cfm?id=2045). I don't use it anymore so I deleted it from my plugin folder long time ago. However some lots were still present in my test city. This set is using maxis beach props. I want to know what happens when I bulldoze the lots and this leads to prop pox most time (aprox 75%).
I found out that there is another "version" of prop pox related to this. You bulldoze the lots and save the city. You load the city and everything seems to be fine. But if you save and load a second time the prop pox is there even if you changed nothing at all. This "version" of prop pox only seems to appear when you bulldoze lots with affected props that are already deleted from the plugin folder.
5. The size of the savegame can determine prop pox. Most time the file shrinks about a few hundred Kbyte. But this don't happens always. Sometimes there will be no change in size or the file gets even bigger but the prop pox strikes anyway. And sometimes the file shrinks and there is no prop pox.
6. There seems to be no way to save a poxed city. If you get the pox your city seems to be lost forever. Only solution is a clean BACKUP!
My résumé: There are many things which can lead to the pox, but don't have to. Just a few things I know for sure: Without the OWW2 Set and Essentials I wasn't able to produce prop pox. If the "big" memory management active and you will bulldoze enough buildings so that the "small" memory management will be reactivated you will get prop pox. Only with OWW2 Set and Essentials in the Plugin Folder of course. So I think the whole prop pox problem is indeed prop ID related. But as I stated I have thousands plugins from various sites in my plugin folder and only one is causing the pox. So make backups of your cities and don't panic ;)
Something I have to add: I know there was lot of chit chat. I don't want to blame anyone because no modder could know this. But I want this to be fixed because I wish nobody to have a poxed city! Well and I want to use the OWW2 again^^
Thanks a lot for the detailled analysis Lord_Morpheus
I have a hard time figuring out what you call "Big memory managment", can you explain it deeper please ?
As for not beeing able to reproduce the prop pox 100%, I have to make more tests, but I think that there is a critical mass for the prop pox to appears, if you don't save often ( or more exactly if you let the city grows for a long period without saving) so that the resulting subfile will be way bigger than 16Mb, then chance are that your city won't be prop poxed.
And as for your addition, we never blame anyone because of the modding, we only blame people that don't want to fix their stuffs. Also on the first page of this thread, Bap explain how to fix the props yourself. However and you may have notice that yourself during your tests, if a city has been built when the non fixed props was present on your folder, and one lot exists with that prop in the city, fixing the prop will not guarantee you to be prop pox free.
Thanks again for sharing your thoughts and findings, the better we understand how prop pox happen, the better chance are we can avoid it
Steph, I believe the 'big memory managment' Lord Morpheous is refering to is when the prop subfile changes from 6mb to 16mb.
Diggis is right - Lord_Morpheus uses the term Big Memory Management for the size of the subfile after the big increase at 6 mb (I do know as he first posted over at the German SimForum (http://www.simforum.de/showthread.php?t=158926&page=2) and Iasked him to post here, too)
1st, can i get a DL link to one of these cities. i perfer the one that everyone seems to be working on most.
2nd, ive never had this in any of my cities. not saying it dont exist. ive seen the pix that have been posted here. also at one point i had a 4 gig plugin folder. has the size of a plugin folder been discussed?
with all the custome comment from all the fan sites you would think things would get a little crowded in there.
3rd, who came up with the term Prop Pox? wth does it mean?
4th, said developer never said he wouldnt change his files. show me 100% proof then ill make the changes. but he has also requested one of these cities also and to my knowledge never got one.
As explain there is no relation to plugin size, beeing 4gb or 10mb it doesn't matter, it is just the fact that some props are modded in a certain way to make the prop pox happen, and as Bap pointed out, there is not only peg stuff modded that way
I think the term is from Snorelli on ST on the Prop pox thread, but I'm not sure
Did you really read the thread, is there something that make you feel it is not a 100% proof somewhere ?
it seems you didn't read it anyway as you ask for DL links, so instead of giving you the DL links, I'll invite you to reread the thread from the start, you'll find the DL links and all the facts
100% proof has been made since Bap first post, and confirmed by others since then. but this obviously is not a proof to said developer. BSC members reproduced it, but said developer doesn't believe in it just because we're BSC, now Lord_Morpheus reproduced it and make a long post about it, but as he is also not a well known member, I'm pretty sure what will be the conclusion of said developer. Now what will happen if you can reproduce it ? As you're enough well known from peg and not related to BSC, will it be enough ?
Remember he claimed it was a hoax then he claimed that as Bap is not well known member hence his explanation are BS, he claimed that massive amount of growable custom contents might be the culprit ( obviously he claims a lot of thing but without doing any tests, as no one seems to have send him a prop poxed savegame )
I'm really wondering why said developper can't fix his file ( only 1 along his > 300 he uploaded , not that hard ), and acknowledge that file is part of the problem ? There is nothing wrong in it, no one blame him for modding it that way as no one knew by that time, only blaming for not fixing it once it is known to be bad.
And why said developer doesn't come here and explain his findings ( as we can't get to him ) or his counter argument ? Really I'd like to know his counter arguments on all the facts that has been said here. I want to get rid of prop pox so anyone with a correct reasonning of the problem will be welcome. And if he doesn't come here because there are BSC members here, because we"re blaming/flaming him for not fixing his files etc.. etc... , please agree with me that it is not really an argument. Tarkus already invited him, but he refused for the above reasons.
So if you're willing to help, just make him comes and posts here about his findings.
actually i did and have been reading this from almost the start. a lot of my earlier posts have been deleted but you can see them on Andreas off topic thread for PP. yes i defended Peg and still do, just as you all do the same here.
also with me being more of a downloader of the LEX and not a poster in these forums i didnt even notice that links were provided. forgive me for that. post count says it all. lol. anyways. i just want to experience these for myself. i see the pix posted and believe them to be real. i mean why in the hell would ppl make up something like this? that would be some good photoshoping.
if i remember right Barby fixed 2 of the files that are or from BSC that also might have been the problem. right?
so is it just the 2 BSC files and the 1 Peg Prod file that caused this? or is it more and just waiting for other custome content to be found?
could it be from a certain mix of custome content from numerous develpers?
my plugins have BSC, Peg, Polska, Somy and others from ST and german sites.
you are obviously a BSC supporter and im a PegProd supporter but im not really here to argue. i have tons of BSC items. almost every thing on the lex to be exact and any mod here can see what ive downloaded as proof. there are very few things here on the LEX that i havent downloaded.
SimPeg is more my style so i choose to hang there, lurk at SC4D and talk every now and then on ST.
*
If you read my last post you will see that as of this moment we don not have a full list of which props cause Prop Pox. We have a number of theories at this time but research and investigation are on going. It is tedious and lengthy but I have no doubt we will find the root cause if not the actual files until more people do the testing.
As for said developer, he has been invited here. He will not be flamed, decried or any thing else if he posts. He does not even have to post to read and then collect the files for his own testing.
tahill, this not a matter of who supports who, it's a matter of having a specific problem fixed. Like has been explained Barbye found among BSC props 1 or 2 with the same problem, and even before it was proved or not they would be the cause of th problem, she fixed them. Everyone that has little experience on modding knows that there shouldn't be two props with the same IID. Even if it doesn't cause apparently any problem, it's bad modding. So, it would be very simple to your said developper to have his props fixed as soon as it was known about the IID duplicating, just for the sake of having done what should have been done on the first place, but nobody knew. Is that too difficult to understand?
There is no real problem of you being a peg defender. I'm not a BSC defender for that issue, I'm a Prop pox defender :)
There are unfortunatly more than just 1 BSC file and 1 peg file, as Snorelli experienced the prop pox way before those files were released. Barby is doing extensive testing for older files that might have been modded the same way. However it is really time consuming and most of us don't have such old files. I hope that when Snorelli upload his plugins list, we can narrow our search. Of course that doesn't mean there is no others not so old file with the same problem. At least we expect now that no one will ever produce such file anymore. We also expect that any custom content creator be now aware of the problem, and if they are still active, to upload a patch for their files if they modded them that way.
You didn't reply to one of my questions however, and I'm really interested in your answer, where or why do you think the facts and experiments ( and their results ) posted here are not a proof ? As I said in an earlier post, I'll be glad to hear any reasonning about the prop pox, why it shows, why it spreads etc... I'm coding a tool to for prop poxed cities, so anything that can help me is welcome.
You didn't reply to one of my questions however, and I'm really interested in your answer, where or why do you think the facts and experiments ( and their results ) posted here are not a proof ?[/quote]
i never actually said i didnt question the existence of PP. and again ive seen the pix posted here as proof. so please quit saying i dont believe in PP. lol. just that i wanted the city to look a little closer. below is my first post stating this.......
Quote from: tahill79 on March 24, 2009, 02:08:31 PM
2nd, ive never had this in any of my cities. not saying it dont exist. ive seen the pix that have been posted here. also at one point i had a 4 gig plugin folder. has the size of a plugin folder been discussed?
again in the last post you will see this........
Quote from: tahill79 on March 24, 2009, 03:28:11 PM
i just want to experience these for myself. i see the pix posted and believe them to be real. i mean why in the hell would ppl make up something like this? that would be some good photoshopi
and now that i think about it aint it a certain prop? cant remember which one off hand. enlighten me please?
is there anything in the German or Polish sights mentioning the PP? cant read either and translation sites dont work that well. im just a PCG member trying to help the community. i will try to talk with Peg and see if he will jump in on this.
I have identified for certain one of the props from the BDK Resource pack that does cause Prop Pox. The beach umbrella causes it every time.
Your earlier posts weren't deleted but moved out of this thread as they were not contributing to the discussion. They are still available in the forums.
Nothing gets deleted here....we're hoarders :D Seriously, this thread is for the discussion of the PP (aha! another new acronym) so everything that went off on a tangent was moved.
Quote from: callagrafx on March 24, 2009, 05:32:13 PM
Nothing gets deleted here....we're hoarders :D Seriously, this thread is for the discussion of the PP (aha! another new acronym) so everything that went off on a tangent was moved.
i know i know. i even stated where they were moved to. jeez. lol. its cool.
PP. i tell my boys to call it a worm. ;D its PG13. lol.
Well you are right I am not a well known member too. But I am active in the german forum for some years now and I tested this for many hours to verify! And btw I like Pegasus mods. They have a high quality and are looking very good. But he needs to change his opinion about this topic...
If somebody has some webspace I can send a poxed savegame file.
EDIT: Well maybe the bsc should remove the auto link to the prop pox thread if you write Pegasus. This is a little bit stupid. And I think it won't help anyway to change his mind!
I never say you don't believe in PP, but from your earlier post I have the impression you don't believe BDK prop causing it. I may have misunderstood you, so please forgive me
Quote
show me 100% proof then ill make the changes.
So I was only questionning you why you need more proof.
The only thing I can say is that we've not a definitive and complete explanation of why it happen with such modding, but we know 100% for sure it happens with that kind of modding
As I said, I'm really interesting in any theory or finding being in line or not with what we already found
Lord_Morpheus findings for example seem to get to the conclusion that PP will not strike 100% of the time even with a prop modded that way, so that means there are some others yet unknown factors in the problem, and I wish we can get all the factors sorted out so we can fix the PP
As you're willing to test yourself, I will be glad to see your results
So I will sum up some stuff
-Prop pox appears because of a corruption in the savegame file. The corruption appears only if your subfile savegame is around 6Mb ( which can be check with Reader ), which is approximatly when you have around 150k-200k props in your city. If the subfile goes up to 16Mb, then when you save again, it will shrink back to 6Mb and if you didn't bulldoze half of the map ( which might explain the shrinking ), the prop pox appears.
- The corruption appears only if a prop modded the way described is actually in the city
- I can with reader take any savegame and make it prop poxed even without closed to 6Mb, this ensure the prop pox is a result of a corrupted savegame ( corrupted in a certain way )
- If you use Bap's file, the prop pox appears almost all the time on the right side. And I'm pretty sure that any prop poxed city will first shows prop pox signs on this side
- The jump of the subfile from 6Mb to 16Mb is easily explainable and related to how SC4 store subfiles in DBPF file
- As the modded beach umbrella is used in a lot of maxis lots ( growable and plopable ), and if you don't bloc Maxis lots, chance are high that such a prop will be in your city and so chance are high that your city will be prop poxed when reaching the critical mass.
- If you however don't intend to have such a big amount of props, there is nothing to worry about.
- Prop pox can appears in all 3 cities size, as it is just related to the size of the subfile. However it will be very hard to get 150k-200k props in a small or medium city
Things that need more testings:
- Is there an upper limit the size of the subfile ( and hence of number of props ) for the prop pox to not strike as Lord_Morpheus didn't get it all the time ( which can also be explain because there might not been that such modded props in his city )
- What exactly in the modding cause the corruption
Quote from: Lord_Morpheus on March 25, 2009, 12:58:16 AM
Well you are right I am not a well known member too. But I am active in the german forum for some years now and I tested this for many hours to verify! And btw I like pegs (http://sc4devotion.com/forums/index.php?topic=7066.0) mods. They have a high quality and are looking very good. But he needs to change his opinion about this topic...
If somebody has some webspace I can send a poxed savegame file.
I hope you didn't take any offense beeing called not a well known member, as it was not the goal of my sentence
You can upload the file using http://www.fileden.com or http;//www.rapidshare.com, you'll need to register but it is free
If you can upload some of the savegames that didn't get prop poxed even with the modded prop, I'll take a look at them and see if the prop is or not in the savegame and hopefully we might find one of the other factor of PP appearance
wouanagaine
thats what peg had said
Ah , so sorry I mixed it up
QuoteI hope you didn't take any offense beeing called not a well known member, as it was not the goal of my sentence
You can upload the file using http://www.fileden.com or http;//www.rapidshare.com, you'll need to register but it is free
If you can upload some of the savegames that didn't get prop poxed even with the modded prop, I'll take a look at them and see if the prop is or not in the savegame and hopefully we might find one of the other factor of PP appearance
I don't take it as offense and I know that your sentence wasn't meant that way ;)
I will upload the files this evenning.
Oh and by the way, the prop pox always started at the right (or east) side of the city.
Quote from: Lord_Morpheus on March 25, 2009, 07:09:57 AM
I will upload the files this evenning.
Oh and by the way, the prop pox always started at the right (or east) side of the city.
Thanks for the files and thanks for the confirmation of right side. It makes sense as the props are, as far as we can see, saved from left to right, top to bottom. As the savegame corruption occurs at the end, it seems logical it strikes at the right.
Here is my test city:
Big memory management (network file over 16Mbyte), no Prop Pox but OWW2 was in my plugin folder as the memory management change happens.
http://rapidshare.com/files/213419012/City_-_Berlin.sc4 Size ca. 24Mb
Small memory management (network file under 6Mbyte) and no Prop Pox, this is the initial state before I started testing.
http://rapidshare.com/files/213419013/City_-_Berlin.sc4 Size ca. 13,7Mb
And here for everyone who doesn't believe in Prop Pox. The same City with Prop Pox.
http://rapidshare.com/files/213432998/City_-_Berlin.sc4 Size ca. 13,2Mb
On the issue of where they dissapear from, would it possibly have anything to do with where you start development? So Baps city will always start in the same place, cos it's the same city?
I hit the wrong key, and lost a long post :(
I'll try to rewrite it
Thanks Lord_Morpheus for the savegames
I have first downloaded the big city and used my tool to explore it ( my tool will be uploaded at LEX very soon )
The tool confirm it is not prop poxed
The tool find 18 instance of the umbrella beach ( one of the prop identified to be trouble )
None of them are timed, which might explain why the prop pox didn't strike. Even on small city, the modded umbrella beach is saved as a timed prop.
Then I downloaded the prop poxed one, to see if I can find a timed umbrella beach prop in it
This time, the tool found only 8 instances of the umbrella beach prop. and one of them is saved as a timed prop, in state 0 ( ie it is visible and I bet you saved between 9am and 6pm in game hour time ).
One thing worth noting, is that the same instance of the prop exist in the big savegame ( ie at the same location ) around 4090,2565 so on the right side a bit below the middle . The lot from which the prop belongs to is on the very side of the map
So to be sure I downloaded the original non prop poxed city, that prop exist also at the same location. By that time you have 19 umbrella beach prop, none of them are timed as you didn't use the modded file.
So further research are needed to understand why the prop change from non timed to timed version, as in almost all tests we've done previously, as soon as we put the modded files, all props become timed in the savegame. If anyone has any ideas to look into, please post
Quote from: Diggis on March 25, 2009, 12:21:04 PM
On the issue of where they dissapear from, would it possibly have anything to do with where you start development? So Baps city will always start in the same place, cos it's the same city?
The props are saved in a pattern that seems to be from left to right, so the rightmost props are at the end of the subfile. if a corruption occurs, no prop after the corruption can be read, so this lead to having no props on the right side
I changed the format of the first post of this thread so it now contains links to the set of 4 initial messages as well as a link to the message explaining how to download the test city and check Prop Pox by yourself. Hopefully this will make it easier & clearer for newbies.
Bap
I took a few minutes to play with the new savegame tool (Great Stuff!) on the poxed city I have, and came up with this:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi124.photobucket.com%2Falbums%2Fp36%2Fowlsinger%2FSimCity4%2FGlitterDataSavgame2.jpg&hash=f36dd1100a7f477f6755383ca6d5aaa3070f0baf)
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi124.photobucket.com%2Falbums%2Fp36%2Fowlsinger%2FSimCity4%2FGlitterSavgame.jpg&hash=287f9a87ded55aa46b4b32d48685dcf5051e278c)
The link for the zips are:
City: http://www.fileden.com/files/2009/3/12/2361237/PPCity.zip
Plugin Folder: http://www.fileden.com/files/2009/3/12/2361237/My%20Documents/PPPlugins.zip
Thanks,
Kendra
right, the Prop Pox are now on the wiki, [here] (http://www.wiki.sc4devotion.com/index.php?title=Prop_Pox). I personally know very little, would be nice if anyone interested would add to it whenever they are free, just PM me for permissions if you dont already have them :)
Joe
Thanks a lot Kendra
something I came across...
I was playing a city and got prop pox. I have a theory that the problem is PEG's Area 52. It has timed, modded, Maxis props. I am testing this theory in a new city using only that plugin. It will take time to get results, so I'm just letting everyone know I might have a cause.
Bob
EDIT: It was simply disappearing props. I will stay out of posting before thorough testing and leave it to the pros. :)
Quote from: bob56 on March 27, 2009, 12:47:20 PM
It has timed, modded, Maxis props.
It does indeed include one modded Maxis prop:
- Street2x6x2_FedSUV, which is an untimed version of Maxis' Street2x6x2_$$$LuxerySUV_1D73
However, it has been given a unique Instance ID, and thus won't replace the ingame Luxery SUVs.
In other words, it won't lead to the prop pox.
Another prop included in Area 52 is Aper2x2x4_military_Armed Guard, which is a timed prop (set to appear between 13:00 and 12:00).
However, the RKT0 model (TGI 0x29A5D1EC,0x49A593E7,0x0AD00C00) referenced to by the RKT4 is not one by Maxis, and it is not included in the dat file either.
There are s few people who seem to think that solutions have been found and fingers pointed. This is not so. Many hours have been invested by some members of SC4D trying to find out how the savegame file works, what happens and how to prevent future incidences of prop pox. We know for certain that one prop causes prop pox - in every test this has been shown to be true. This is not to say that others may do this too but until we have far more cities to examine - both poxed and non-poxed - no one can say exactly what causes it.
No one is pointing fingers at anyone in particular. It is unfortunate that this is seen to be a an exercise in proving one person wrong. This is far from the truth and unfortunately the people who could explain better cannot post where they need to.
It is disheartening to see posts that demonstrate a complete lack of understanding of the problem. It is known that prop pox existed before the release of the BDK file but so far we have not identified any specific cause. As I said earlier we can only say that as one specific prop does cause prop pox then it appears that if there are other props similarly modded then they too could cause it.
I can also tell you that today I could easily have reported an outbreak of prop pox in one of my cities in GRV II. It wasn't prop pox as I checked the file in SC4Save but it gave the same appearance. I found out why. I had two folders for GRV II as I want one area to be predominately agricultural and one industrial and commercial. One folder did not have my farms. I had the other folder in place and entered my farming city to add a neighbour connection. That was all I did then I saved. When I returned to the city with the other folder in place all my farms were missing textures and props. Fortunately I had a back up from two days ago so was able to restore that city but it could easily have been reported a prop pox.
The tests that have been done DO confirm prop pox as no other custom lots have been used. Tests have been done with other props and textures in place but so far the only custom content identified is the umbrella prop from the BDK. This is fact not conjecture.
Quote from: BarbyW on March 27, 2009, 03:40:24 PM
I had two folders for GRV II as I want one area to be predominately agricultural and one industrial and commercial. One folder did not have my farms. I had the other folder in place and entered my farming city to add a neighbour connection. That was all I did then I saved. When I returned to the city with the other folder in place all my farms were missing textures and props.
A clear case of
Disappearing Props - not to be confused with Prop Pox (http://sc4devotion.com/forums/index.php?topic=7264.0) :thumbsup:
Quote from: Lord_Morpheus on March 24, 2009, 11:25:08 AM
2. If the game changes the memory management to the "big" version (network file above 6 MByte) there is a high chance (aprox 33%) this will lead to prop pox. However it's possible that the management changes and no prop pox will appear. In fact this happens more often.
3. If the "big" memory management is active and you bulldoze enough buildings the game will change back to the "small" memory management. And this will always (!) lead to prop pox!
The appearance of the prop pox is very much related to what you're calling the "memory management".
Thus, I feel we need to explain why the size of the prop subfile suddenly can jump from 6 MB to 16 MB and v/v.
Thanks to Wouanagaine's excellent tool, SC4Save (an easier-to-use version of which is available on the LEX),
we are able to read the structure of the prop subfile in a lot simpler way than using Reader's HEX dump.
The images below are all from his tool, showing your different versions of Berlin.
In your large, unpoxed city, sized 24 MB, the prop subfile is uncompressed, having a size of 16,143,668 bytes (0xF65534):
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi232.photobucket.com%2Falbums%2Fee198%2FRippleJet%2FBerlinuncompressedpropsubfile.jpg&hash=c533be413392afb070c310d37173538d75da26c8)
Usually, the prop subfile is always compressed. However, when the size approaches 16 MB, it always should become uncompressed.
This is the reason for the jump from a compressed size of about 6 MB to 16 MB.
In the second city you uploaded (renamed City_-_Berlin 2 by me), the prop subfile is compressed.
Looking at the raw hex dump of the subfile, we see the following:
- The size of the compressed file is given by the first four bytes (0x005CF3DD = 6,091,741)
- The size of the uncompressed file is given by the three bytes at offset 0x06 (0xF0C9E8 = 15,780,328)
The reason for the city always becoming uncompressed when surpassing 16 MB, is to be found in the above.
For some strange reason, in the compression algorithm, Maxis only reserved three bytes to indicate the size of the uncompressed file.
The maximum value that can be stored in these three bytes is 0xFFFFFF = 16,777,215.
This is thus the maximum size of a subfile that can be compressed.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi232.photobucket.com%2Falbums%2Fee198%2FRippleJet%2FBerlincompressedpropsubfile.jpg&hash=a962ca3e4c9f118b196653a0ddd6c7e8a5daf818)
Now, to explain why we can say if a city is poxed, without even playing with it:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi232.photobucket.com%2Falbums%2Fee198%2FRippleJet%2FBerlinpoxedproprecordview.jpg&hash=b13b76b105485ff30ffbb10307813011065f58bf)
Wouanagaine's tool says there's a buffer corruption at offset 0x00DD6444.
Let's take a look at this offset in a "structured view", right down at the bottom of the prop subfile:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi232.photobucket.com%2Falbums%2Fee198%2FRippleJet%2FBerlinpoxedstructuredview.jpg&hash=1bcf782b9b80bb6930b8621a6620d9e1272ef444)
The record at offset 0x00DD6444 is the last one having a normal record size (0x58).
There are only a few possible record sizes available, 0x58, 0x68, 0x69, 0x6C and 0x94.
The last record, at offset 0x00DD649C has a record size of 0x28462CB4.
This is of course rubbish, and indicates that the savegame has stored some records at incorrect offsets.
This always happens when the city becomes poxed, erroneously stored records overwriting existing ones.
For each subsequent save after this, the number of erroneously stored records increase in numbers,
overwriting more and more properly stored prop records, which all disappear in the game.
The erroneously stored record size above is actually the memory address (third field) of a prop record
that has been erroneously stored 8 bytes earlier, at offset 0x00DD6494.
We know that each prop record normally occupies 104 bytes (0x68) in memory,
e.g. the difference between the last two records, 0x27F4B674 - 0x27F4B60C = 0x68.
Thus, comparing this last memory address (0x28462CB4) with the previous one (0x27F4B674),
we get a difference of no less than 0x517640. Dividing that by 0x68 would indicate some 51,333 missing props...
All props appearing with erroneous offsets in the end of the prop subfile also always seem to be flagged as "disabled" (or deleted).
At the moment we cannot explain exactly why the savegame screws up the records in the end of the file.
It is quite obvious that it does happen when the prop subfile's size approaches 16 MB (or 0xFFFFFF).
It most likely is due to the savegame trying to compress the prop subfile when surpassing this limit.
And it has also been confirmed that the savegame screws up only if there are modded Maxis props involved.
Tahill, can you do me a favour (or anyone else with access to Pegs site)? Can you put a post up, feel free to say it's from me, pointing out that Pegs theory of file size and custom content being installed has been disproven by Bap's original set of testing, and all subsequent testing on the files Bap provided. He developed a city up to the 6mb limit using soley MAXIS CONTENT. These cities are the ones linked in the original post now and are available for download. He then added in ONLY the BDK resource kit (or what ever the hell it's called) and got the pox. Thats it, nothing else. He proved, beyond doubt to most people, that those files DO cause the Pox. We are now trying to find out what else does, as it has been pointed out the Pox is older than the BDK.
Yes, and it might be nice to stress that nobody blames him for that, because the problem is very weird and nobody could ever have foreseen that.
So no blame, but please believe us PEG, and maybe you will be so nice to reedit the BDK set?
Tahill, let me quote you from
over there (http://simpeg.com/forum/index.php?topic=7360.msg152694#msg152694):
Quote from: tahill79 on March 28, 2009, 06:02:19 AM
combination of plugins size and city size?
Tahill, I think you need to read
bap's post below once more.
This is also the post where you should have found the links to his saved cities:
Quote from: bap on March 11, 2009, 09:22:57 PM
Testing Prop Pox by yourself
Basic Information
For those willing to check my experiments with Prop Pox, I uploaded three versions of the test city #2 at fileden.com. They can be downloaded at the following addresses:
Riquelandia 4 (http://www.fileden.com/getfile.php?file_path=http://www.fileden.com/files/2009/3/3/2347164/City%20-%20Riquelandia%204.sc4)
Riquelandia 5 (http://www.fileden.com/getfile.php?file_path=http://www.fileden.com/files/2009/3/3/2347164/City%20-%20Riquelandia%205.sc4)
Riquelandia 6 (http://www.fileden.com/getfile.php?file_path=http://www.fileden.com/files/2009/3/3/2347164/City%20-%20Riquelandia%206.sc4)
The relevant information about these cities is as follows:
filename total size(Kb) 2977aa47 size (Kb)
Riquelandia4 15967 5926
Riquelandia5 16159 6162
Riquelandia6 15923 5742
Riquelandia4 was build exclusively with Maxis vanilla lots & props up to this point. If developed in a plugins without Maxis-modded infected props it will not show Prop Pox. There is room for further zoning in the south and east outer bounds of the city, just inside the highway belt. There is also room for development at the southeast corner outside of the highway belt.
Riquelandia5 is a further development to Riquelandia4 made while the infected props were in the plugins folder. Thus, it will get Prop Pox if you let it grow just a little bit more -- even if the infected props are no longer in the plugins folder. No big development effort is needed here because the city is on the verge to show signs of Prop Pox. Because only custom prop packages were in the plugins (not the lots), anyone can play with this city without being in risk of seeing brown boxes. All installed lots up to this point are Maxis vanilla ones.
Riquelandia6 is a saved version of Riquelandia5 just after it got Prop Pox. As you can see, the city file and the 2977aa47 file both shrank. Several props are missing at different places around the city (look for city parks, water treatment plants, farms).
When developing Riquelandia 4,
bap had a plugins size of
0 bytes.
For Riquelandia 5 and 6,
bap only had four props by Peg in the plugins folder.
The size of the plugins folder
does not matter... unless four props (a few bytes) is what you'd consider sizeable.
Tahill, you may copy
that post by bap (http://sc4devotion.com/forums/index.php?topic=7066.msg229603#msg229603) in its entirety over to Pegs,
so that he can have a city to test that doesn't require any custom content, other than his own.
Quote from: Pegasus on March 27, 2009, 08:46:07 PM
There is nothing that really indicates that any particular type of prop... default custom or modified... would cause this problem with the game's save routines. But there is quite a bit of evidence that indicates that having too many props in a city will trigger the glitch.
Yes, there is evidence that the city prop subfile must be close to 16 MB (uncompressed) for the prop pox to appear.
There is also evidence that the prop pox can be triggered with certain specified props.
Quote from: Pegasus on March 27, 2009, 08:46:07 PM
As we stated before, growable lots are the largest collective source of props in a city. We know the game can handle all of the game-default lots no matter how large and well developed the city. So logic & simple deduction then points us toward custom growable lots that use a large amount of extra custom props.
What would be considered too many props in a city?
We know that each prop (whether it's an in-game prop by Maxis or a custom prop), is saved in the prop subfile.
We also know that if you have 100 instances of the same prop in the city, they will each occupy one record in the prop subfile.
Having 100 separate custom props will occupy exactly the same size in the prop subfile, as 100 identical props, whether by Maxis or custom ones.
We know that each prop has a record size of 88, 104, 105, 108 or 148 bytes.
104 bytes is the record size of a prop being timed between two dates.
148 bytes is the record size of arrow props indicating neighbour connections.
To reach a filesize of 16,777,216 bytes, we'd need 190,650 props having a size of 88 bytes.
In a large city (256×256 tiles) that would mean an average of 2.9 props per tile.
Now, let's take a look at some of Peg's own recent creations:
| PEG Corner Starbucks Growable | Lot Size 2×2 | 26 props | 6.50 props per tile |
| PEG Corner Starbucks Ploppable | Lot Size 2×2 | 29 props | 7.25 props per tile |
| PEG Area 52 | Lot Size 6×4 | 108 props | 4.50 props per tile |
| PEG MTP TLC Rail Transfer Yard | Lot Size 4×5 | 69 props | 3.45 props per tile |
| PEG MTP Log Town Cross Roads Center | Lot Size 3×3 | 66 props | 7.33 props per tile |
| PEG MTP Log Town Fuel Depot | Lot Size 2×2 | 49 props | 12.25 props per tile |
| PEG MTP Gazebo Park | Lot Size 1×1 | 15 props | 15.00 props per tile |
| PEG UT Large Plaza | Lot Size 3×3 | 64 props | 7.11 props per tile |
| PEG-UT Mall Canal Corner | Lot Size 3×3 | 70 props | 7.78 props per tile |
Most in-game lots also have more than 3 props per tile. Below are a few extreme examples:
| Grass Park | Lot Size 1×1 | 0 props | 0.00 props per tile |
| Gazebo | Lot Size 1×1 | 29 props | 29.00 props per tile |
| Large Plaza | Lot Size 3×3 | 52 props | 5.78 props per tile |
| Urgent Care Clinic | Lot Size 1×2 | 15 props | 7.50 props per tile |
| Small School | Lot Size 2×3 | 13 props | 2.17 props per tile |
| City College | Lot Size 5×3 | 59 props | 3.93 props per tile |
| University | Lot Size 12×10 | 577 props | 4.81 props per tile |
| R$1_1x2 | Lot Size 1×2 | 12 props | 6.00 props per tile |
| R$1_1x2 | Lot Size 1×2 | 19 props | 9.50 props per tile |
| CO$$$8_4x4 | Lot Size 4×4 | 56 props | 3.50 props per tile |
| CO$$$8_4x4 | Lot Size 4×4 | 8 props | 0.50 props per tile |
Peg's MTP gazebo is better than the in-game one.
Otherwise, I cannot really see any advantage in using e.g. ploppable log town lots over growable ones.
It's another matter that nobody would be filling a complete large city tile with ploppable lots.
However, it isn't a question of which lots give the most props and which to avoid,
it's a question of loosing a city after you've developed it to a point having more than 150,000 props.
Quote from: Pegasus on March 27, 2009, 08:46:07 PM
Of course, I'm sure it hasn't escaped anyone's notice that the group trying to accuse a handful of modified props as being the source of the issue... are also the number one providers of custom growable lots that use a very large amount of custom props.
Nobody is accusing you, Peg.
However, bap was accused of presenting the prop pox as a hoax.
As i said above, the number of custom props is irrelevant.
All props, whether custom, in-game or modded in-game ones occupy one record in the prop subfile.
Quote from: Pegasus on March 27, 2009, 08:46:07 PM
The final conclusion we can draw from all this is that to avoid "Prop Blight" or issues related to the game save bug... just use some common sense in what custom growable material you install or use.
Indeed, I think most of us know which files to avoid by now.
@RippleJet
I already opened a topic on simpeg. Thanks for excellent explanation about the compressed and uncompressed network file.
Well now my topic on simpeg got deleted^^
Oh my god. Nice one. Well I just tried to help and this is the answer. Nice &apls
I did manage to download Helmstedt before the thread disappeared though!
Maybe you'd like to post the links to RapidShare here as well?
The unpoxed Helmstedt is a perfect test ground,
having an unpoxed prop subfile sized 0x1005198 (only just over the limit of 0xFFFFFF).
Helmstedt unpoxed: http://rapidshare.com/files/214572578/City_-_Helmstedt.sc4
File Size over 26Mbyte, uncompressed network file
Helmstedt poxed: http://rapidshare.com/files/214578158/City_-_Helmstedt.sc4
File Size under 16Mbyte, compressed network file
If you want to test the issue yourself:
- delete your plugin folder (make a backup elsewhere ;))
- download the large city file and verify you can load the city
- quit the game
- install OWW2 set
- load the city again
- there are four maxis beaches in the city, bulldoze them!
- save the city
- quit the game and take a look at the savegame size
- restart the game
- load the city
- go to the east side of the city and look around a little bit, it will be poxed now!
Thanks,
Lord_Morpheus! :thumbsup:
I'd say what you posted on Simpeg was all in line with
this post (http://simpeg.com/forum/index.php?topic=7276.msg151162#msg151162) by Pegasus:
Quote from: Pegasus
Note - No further comments or propaganda from the BSC will be accepted in this topic or anywhere else on this site regarding this matter. They will be deleted immediately. However... any legitimate member of the community who has been a victim of this scare tactic, may post about their concern and will we alleviate your fears with documented facts.
I suppose your fears have been alleviated by documented facts now:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi232.photobucket.com%2Falbums%2Fee198%2FRippleJet%2FAPoxonPropBlight.jpg&hash=f95f2d4afdbf04c60845ba4364bf49d481d7c386)
Yes, the issue is rare, but that won't comfort those who've lost their largest cities.
Knowing that 10,000+ other players have not experienced the pox won't help much once you're there.
Besides, the solution to keep the pox from spreading in the future is so incredible simple, as
bap showed already in his first posts.
Quote from: callagrafx on March 28, 2009, 09:07:36 AM
It's obvious that the creator in question will not modify his work, so I think the safest thing is either to mod it yourself or simply not use it or any other that has been identified as a cause.
Oh. Hey look everyone, a simple answer for a small problem. Or just dont use the content. Its pretty simple when it comes down to it. There are some things in the LEX that i wont use. Reasons being too many dependencies. The community found out about this over 2 years ago, so why the all of a sudden freaking out over it now?
Listen, Im a big fan of what everyone does for this game. Im the lucky one who has never had PP. So to all of you that have had it happen, sorry. Demolish the building and put something else there.
Morpheus, im sorry again that your thread was deleted. Im not a mod over at SimPeg.com. Just a PCG. A Beta Tester. Thats all I am there. Peg posted a reason and I hope you read it. I dont want to make any cyber enemies so please dont be mad at me for what I have posted here and at SimPeg.
This is my last post in this thread. If you guys have any questions or just wanna say hi, please PM here, at ST, or on SimPeg.
thank you
Quote from: tahill79 on March 28, 2009, 10:46:32 AM
Im the lucky one who has never had PP. So to all of you that have had it happen, sorry. Demolish the building and put something else there.
Maybe you should re-read what has been posted so far. Bulldozing a building that might cause prop pox doesn't help, it isn't even necessary to build it at all, as the mere presence of it in the plugins folder might lead to prop pox. Also, prop pox is not reversible, so bulldozing will do nothing. It's sad to see that something that simple to fix is called "stirring panic" and denied eventually. However, I have to admit, it doesn't surprise me, after all what happened recently.
No one is freaking out....Why does Peg still insist that we're creating a scare? The Pox exists and it's a fact, and instead of burying our heads in the sand and deleting anything of relevance, certain members have been labouring away really quite hard to understand WHY it's happening. Wouanagaine has written a program that helps better understand the savegame file, Ripplejet has done the most exhaustive research into the raw data I've ever seen, Barbyw, Ennedi, Bap and Lord Morpheus have done test after test after test and that has resulted in Barby discovering a potential problem with a BSC release, but instead of denying that one of her files could be a cause, she promptly fixed it and re-released, which is all that has been asked of Pegasus. Instead they are presented with a diatribe of nonsense posts from Peg and his acolytes who have no understanding of the undertaking. The Pox is rare yes, but so is Ebola...should people stop trying to cure that too, as it only affects a handful of people. And NOWHERE has Bap "recanted" that any Pegasus releases are a contributory factor....in fact it has been proven by Lord Morpheus that one is. Why is Pegasus so against this research? Maybe it's because it has been proven that they are responsible and he is not man enough to admit when he's wrong.
Once again Pegasus is denying that there is a problem and doesn't just lock a thread but deletes it as if what has been posted is unimportant. He will not log in here to discuss this subject and Ripplejet, Wouanagaine, Andreas and I are all banned from his site so cannot post there.
To answer his points in the above post:
1. Panic? I see no panic being generated here nor is there any finger pointing as I explained in my last post. In fact I posted that I had tested with all other Peg lots and packs in place apart from the BDK and had not had a poxed city. I have been testing with a variety of other custom content but as I have also explained before it is a long and tedious process.
2. Pegasus has obviously not seen the previous posts at Simtropolis and here about the problem. He has not seen the posts of CJers who have lost whole cities to this problem. bap reported a problem last year and was interested enough to conduct tests over a long period of time. These have been dismissed as not valid as bap does not appear to be a known member of the community.
3. bap has never recanted his staement and it has been corroborated by others independently. I posted my findings on 20th March.
4. None of the props are corrupted per se. The problem seems to occur when a prop that is widely used on Maxis growables - especially the low density R$/R$$ - is modded to a different timing but without changing the IID of the exemplar. I have checked many of Pegasus' dats and the vast majority of time when he has modded Maxis originals have been given new IIDs. I simply do not understand why the four props in the BDK weren't.
5. I have never had a poxed city. I have never had a city with a savegame file anywhere near 25MB in size. That does not mean I deny the problem nor that I would not like to find a solution. I feel it is encumbent upon all custom content providers to ensure that their work does not and cannot cause problems - so far as they are able. If problems are found it is then responsible of the provider to correct the problem.
To date once again BSC have been villified and blamed for this whole situation. The original reporting of the problem was by snorelli - not BSC. Others then joined in with their experiences: Fledder, Nardo69, BruceAtkinson - none of them BSC. bap is not BSC. Lord Morpheus is not BSC.
To turn to the people who have been investigating - wouanagaine is a respected member of NHP first and foremost. He works in the computer gaming industry and has programmed a number of useful tools for the SC4 community. He programmed the tool for decyphering savegame files that he has now released to the LEX. Ripplejet is one of the foremost technical modders in the community. He has analysed and posted about the blank lots problem; he discovered how to increase the growth stages from 8 to 15; he discovered how to have upgradeable custom airports and seaports without CTDs. As for me, I have just been testing in accordance with bap's instructions and also testing other combinations of custom content. I am not a number cruncher but can do tests as requested so that the number crunchers can look at them.
It is time that certain people stopped blaming BSC for the woes of the world and co-operated with the community. We don't do this for money or for any other reason than trying to make sure a game which should have been consigned to the rubbish bin long ago is kept fresh, alive and stable to use. Problems reported should be dealt with - as with the Mayor Mode ploppables that are based on cycledogg's template but not corrected to only plop in Mayor Mode.
To reply to tahill69, you suggest "Demolish the building and put something else there."
That does not make any difference as if a savegame is corrutped there is nothing you can do about it execpt use a back up. Please go back and read again through this thread. The reason this community is trying to deal with it is because bap did so much meticulous testing and after being rudely told it was rubbish by Pegasus posted his findings here.
The unpoxed Helmstedt's prop subfile contains 187,896 prop records.
Out of these records, not a single one is marked as disabled or deleted.
This is the point at which the poxed Helmstedt's prop subfile becomes corrupted:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi232.photobucket.com%2Falbums%2Fee198%2FRippleJet%2FHelmstedtpoxedoffset.jpg&hash=194c469b86709cefce5ce4f63d0fbb166355707d)
The last record that the savegame can read starts at offset 0xE87914.
The next record starts 0x58 bytes later, at offset 0xE8796C.
However, that record is severely truncated, as the next record starts only 4 bytes later, at 0xE87970.
All records that appear after this point are flagged as "disabled/deleted" (the encircled 04).
However, there are also no less than 2,160 records above this point that are marked "04".
In total, the poxed city's prop subfile contains 170,367 healthy prop records. Quite a reduction from 187,896.
EDIT:
Lord_Morpheus, unless you already have tested it...
Could you to test the unpoxed Helmstedt with an empty plugins folder (nothing from OWW2)?
Delete the beaches, and try to trigger the prop pox, in the same way as you did when triggering it including the OWW2.
It is not just a matter of Peg to correct his file, which he will never do unfortunatly because that will lead to him recognize he was wrong, something he definitly can't stand with. Even if he and any one else had the knowledge to know it was wrong by the time it was done.
The matter is to teach any other custom content creator to not repeat the error of changing an already existing prop like Bap described without affecting it a new TGI.
The matter is also to find other props that cause the Prop Pox, as it was pointing a lot of time Peg 4 props are not the only cause of Prop pox.
It is pretty clear by now that people at Peg site don't care of the problem, even Lord_morpheus was called a BSC ( like it is obviously an insult to be BSC overthere ). I even didn't know Lord_morpheus 4 days ago.
So what can we expect from now ?
Just that no one else will release baddly modded props
That we ( I mean us the community ) find the others baddly modded props
That anyone who will get the prop pox in the future, will know who to blame if they have the 4 knowns props in their folder
Without OWW2 in my plugin folder I can bulldoze the beaches without any problems.
If I bulldoze enough buildings the city changes back to compressed network file without any problems. No Prop Pox! Retested several times ;)
Pegasus statement is nonsense. He deleted my thread at the moment then there was a 100% sure proof that his OWW2 BDK file is a cause of prop pox. And my files were there so everybody could test it himself. Even Pegasus but instead he refused to do so and deleted the thread. I didn't blame him I just want to protect other players. He is talking about facts but he just deny and delete all facts and just write nonsense. He even stated a fully developed city savegame file on a large map won't be bigger then 5 MByte. As example he came up with the maxis big city tutorial. This file has only 4,6 Mbyte. But well it's on medium map ;D
I would have lost all my big cities to this bug, if I don't read this thread here. This would have been very very frustrating. That's why I did all the testing. I want to ensure that this don't happen to anyone else!
Quote from: Lord_Morpheus on March 28, 2009, 12:43:41 PM
Without OWW2 in my plugin folder I can bulldoze the beaches without any problems.
If I bulldoze enough buildings the city changes back to compressed network file without any problems. No Prop Pox! Retested several times ;)
Excellent, and final confirmation! ;)
Regarding the direction this thread is taking, I think we need to return to the topic of it.
We will probably have to clean out some off-topic content in a while... ::)
Keeping to the topic, I have tested Helmstedt today both with an without custom content. By custom content I mean a prop that I modded without changing the IID and the single umbrella prop from the BDK. Without any custom content and also with only the prop that I modded I was unable to produce a poxed city. I returned to the city and added the single umbrella prop from the BDK and the city poxed immediately.
I cannot explain why at this stage. I can only reconfirm Lord Morpheus' report that this is what happens.
BarbyW, does the prop you modded already exists in that city in its original form ?
The one I modded did exist - it was the trampoline and appeared many times in the R$/R$$ res lots. I made a simple park lot with the trampoline. I went into the city and deleted some lots with the trampoline on. Saved and exited. No pox.
I plopped a couple of my parks and deleted some lots. Saved and exited - no pox.
I deleted the beaches. Saved and exited - no pox.
I removed my modded trampoline. Entered the city rezoned some small zones. Saved and exited - no pox.
I added the umbrella prop. Did some more rezoning. Saved and exited. Poxed.
Now, while we're talking about the umbrellas...
let me post the findings we did on
bap's city Riquelandia 6 a while ago.
It is a city which has only just started to show some signs of having the prop pox.
I am listing the prop subfile (as a hex dump) from the savegame, starting at offset 0xDCDA5D.
This is very close to the end of the file, offset byte Nº 14,473,821 in a file having a size of 14,488,551 bytes.
| Offset | HEX Dump | Explanation |
| DCDA5D | 58 00 00 00 | Size of this prop record = 0x00000058 = 88 bytes |
| DCDA61 | 44 E1 DE D2 | CheckSum |
| DCDA65 | 54 5B 93 20 | Memory Address |
| DCDA69 | 06 00 04 00 | Record Version Number |
| DCDA6D | 00 00 00 05 | Appearance Flag, 05 = normal, visible prop |
| DCDA71 | 1E 82 23 A8 | Identifies this record to be a prop record |
| DCDA75 | 59 71 59 71 | Tract Coordinates |
| DCDA79 | 02 00 02 00 | Tract Size, power of 2 |
| DCDA7D | 00 00 00 00 | Count of SBPROP records = 0 |
| DCDA81 | 36 C5 77 C9 | Group ID = 0xC977C536 |
| DCDA85 | 4A 28 6C 00 | Type ID, should be 4A 28 34 65 |
| DCDA89 | 00 00 AE F5 | Instance ID |
| DCDA8D | 3F 0A 1C 60 | Instance ID |
| DCDA91 | EC 0B 06 00 | Minimum X Coordinate |
| DCDA95 | 04 00 00 00 | Minimum Y Coordinate |
| DCDA99 | 00 04 1E 82 | Minimum Z Coordinate |
| DCDA9D | 23 A8 69 4B | Maximum X Coordinate |
| DCDAA1 | 69 4B 02 00 | Maximum Y Coordinate |
| DCDAA5 | 02 00 01 00 | Maximum Z Coordinate |
| DCDAA9 | 00 00 6C C1 | Orientation, State, Start and Stop Hours |
| DCDAAD | A1 89 6C C1 | Date Timings, Random Chance, Lot Type |
| DCDAB1 | A1 89 00 00 | Object ID and Conditional Flag |
| DCDAB5 | 00 00 03 00 | Size of the next prop record, should be 0x00000058 = 88 bytes |
| DCDAB9 | 00 00 00 00 | CheckSum |
| DCDABD | 00 00 36 C5 | Memory Address |
| DCDAC1 | 77 C9 4A 28 | |
| DCDAC5 | 34 65 00 00 | |
| DCDAC9 | 00 29 00 00 | |
| DCDACD | 00 29 C2 84 | |
| DCDAD1 | 26 45 32 9F | |
| DCDAD5 | 88 43 EB 7F | |
| DCDAD9 | 3A 44 C2 A4 | |
| DCDADD | 26 45 32 9F | |
| DCDAE1 | 89 43 EB 3F | |
| DCDAE5 | 3B 44 02 00 | |
| DCDAE9 | 00 00 00 64 | |
| DCDAED | 02 D6 F9 99 | |
| DCDAF1 | CA 00 6C 00 | |
| DCDAF5 | 00 00 B0 83 | |
I have greyed out the part of this prop record where something goes very much wrong.
After 42 bytes, the remaining 46 bytes are screwed up...
I've highlighted the DWORD where the next record starts (in the middle of the grey part).
As you can see, the size of that record is now erroneously read as 0x00300000 = 196,608 bytes.
Now, let us lift out that part that has been greyed, starting at offset DCDA87:
| Offset | HEX Dump | Explanation |
| DCDA87 | 6C 00 00 00 | Size of this prop record = 0x0000006C = 108 bytes |
| DCDA8B | AE F5 3F 0A | CheckSum |
| DCDA8F | 1C 60 EC 0B | Memory Address |
| DCDA93 | 06 00 04 00 | Record Version Number |
| DCDA97 | 00 00 00 04 | Appearance Flag, 04 = deleted, disabled prop |
| DCDA9B | 1E 82 23 A8 | Identifies this record to be a prop record |
| DCDA9F | 69 4B 69 4B | Tract Coordinates |
| DCDAA3 | 02 00 02 00 | Tract Size, power of 2 |
| DCDAA7 | 01 00 00 00 | Count of SBPROP records = 1 |
| DCDAAB | 6C C1 A1 89 | Property Name Value = 0x89A1C16C |
| DCDAAF | 6C C1 A1 89 | Property Name Value = 0x89A1C16C |
| DCDAB3 | 00 00 00 00 | Always 0 |
| DCDAB7 | 03 00 00 00 | Data Type = UInt32, Rep Count = 0 |
| DCDABB | 00 00 00 00 | Property Value = 0 |
| DCDABF | 36 C5 77 C9 | Group ID = 0xC977C536 |
| DCDAC3 | 4A 28 34 65 | Type ID = 0x6534284A |
| DCDAC7 | 00 00 00 29 | Instance ID = 0x29000000 |
| DCDACB | 00 00 00 29 | Instance ID = 0x29000000 |
| DCDACF | C2 84 26 45 | Minimum X Coordinate = 2664.2974 |
| DCDAD3 | 32 9F 88 43 | Minimum Y Coordinate = 273.2437 |
| DCDAD7 | EB 7F 3A 44 | Minimum Z Coordinate = 745.9987 |
| DCDADB | C2 A4 26 45 | Maximum X Coordinate = 2666.2974 |
| DCDADF | 32 9F 89 43 | Maximum Y Coordinate = 275.2437 |
| DCDAE3 | EB 3F 3B 44 | Maximum Z Coordinate = 748.9987 |
| DCDAE7 | 02 00 00 00 | Orientation = South, State = 0, Start Hour = 0, Stop Hour = 0 |
| DCDAEB | 00 64 02 D6 | Date Timings = 0, Random Chance = 100%, Lot Type = Ordinary Lot |
| DCDAEF | F9 99 CA 00 | ObjectID = 0xCA99F9D6, Conditional Flag = 0 |
| DCDAF3 | 6C 00 00 00 | Size of the next prop record = 0x0000006C = 108 bytes |
I have indicated some important things in red here...
First of all, the Instance ID of this prop record, which has been written at the wrong offset, is 0x29000000.
That is the Beach Umbrella, modded by Pegasus in his Beach Development Kit.
Secondly, you can also see that it has one SGPROP (Save Game Property), 0x89A1C16C.
We still don't know the meaning of this property, but it may have some significance to the cause of the prop pox, as it increases the record size by 20 bytes.
Finally, the last line (at offset DCDAF3) in my HEX dump above shows the first line of the next record.
That is another similar record. In fact, the last
136 records in this prop subfile, all look alike:
The record size is 0x6C (108 bytes)
They all have one SGPROP block, with the property 0x89A1C16C set to 0.
They all have the appearance flag set to 04, indicated they would all have been deleted.
And they all have the Instance ID set to 0x29000000.
The fact that these records in the end are all flagged as disabled/deleted very much corresponds with the way
Lord_Morpheus triggered the prop pox, by deleting the beaches. We are pretty sure
bap did not delete any lots while testing though.
In another test Barby played the unpoxed Riquelandia 4, with only two of Peg's props in place.
As soon as the prop pox hit, she sent me her savegame.
Once again we find a truncated record, starting at offset DD3895:
| Offset | HEX Dump | Description |
| DD3895 | 58 00 00 00 | Size of this record |
| DD3899 | 78 4D C3 E8 | CheckSum |
| DD389D | 64 DF 0C 13 | Memory Address |
| DD38A1 | 06 00 04 00 | Record Version Number |
| DD38A5 | 00 00 00 05 | Appearance flag: 05 = normal, visible prop |
| DD38A9 | 1E 82 23 A8 | Identifies this record to be a prop record |
| DD38AD | 77 4C 77 4C | Tract Coordinates |
| DD38B1 | 02 00 02 00 | Tract Size, power of 2 |
| DD38B5 | 00 00 00 00 | Count of SGPROPs |
| DD38B9 | 36 C5 77 C9 | Group ID |
| DD38BD | 4A 28 34 65 | Type ID |
| DD38C1 | 00 00 F1 28 | Instance ID |
| DD38C5 | 00 00 F1 28 | Instance ID (Purple Flowers) |
| DD38C9 | 8F 71 5F 45 | Min X |
| DD38CD | 9B 09 87 43 | Min Y |
| DD38D1 | A0 5D 47 44 | Min Z |
| DD38D5 | 8F 91 5F 58 | Max X |
| DD38D9 | 00 00 00 2C | Max Y |
| DD38D9 | 26 38 ED 9C | Max Z |
At offset DD38D8 this record has been overwritten with:
| Offset | HEX Dump | Description |
| DD38D8 | 58 00 00 00 | Size of this record |
| DD38DC | 2C 26 38 ED | CheckSum |
| DD38E0 | 9C B3 0E 13 | Memory Address |
| DD38E4 | 06 00 04 00 | Record Version Number |
| DD38E8 | 00 00 00 04 | Appearance flag: 04 = deleted, disabled prop |
| DD38EC | 1E 82 23 A8 | Identifies this record to be a prop record |
| DD38F0 | 74 7B 74 7B | Tract Coordinates |
| DD38F4 | 02 00 02 00 | Tract Size, power of 2 |
| DD38F8 | 00 00 00 00 | Count of SGPROPs |
| DD38FC | 36 C5 77 C9 | Group ID |
| DD3900 | 4A 28 34 65 | Type ID |
| DD3904 | 00 00 B2 29 | Instance ID |
| DD3908 | 00 00 B2 29 | Instance ID (Beach Chair) |
| DD390C | C4 17 50 45 | Min X |
| DD3910 | CE D8 88 43 | Min Y |
| DD3914 | E6 15 6F 45 | Min Z |
| DD3918 | C4 27 50 45 | Max X |
| DD391C | CE D8 89 43 | Max Y |
| DD3920 | E6 25 6F 45 | Max Z |
| DD3924 | 00 01 5A B4 | Orientation: North, State: 1, Timed from 9:00 till 18:00 |
| DD3928 | 00 64 02 4A | Date Timed: No, Appearance Chance: 100%, Lot Type: Normal |
| DD392C | 19 A6 2A 0E | Object ID: 0x2AA6194A, Conditional Flag: 0x0E |
| |
| DD3930 | 58 00 00 00 | Size of this record |
| DD3934 | 32 6B F2 3C | CheckSum |
| DD3938 | 04 B4 0E 13 | Memory Address |
| DD393C | 06 00 04 00 | Record Version Number |
| DD3940 | 00 00 00 04 | Appearance flag: 04 = deleted, disabled prop |
| DD3944 | 1E 82 23 A8 | Identifies this record to be a prop record |
| DD3948 | 74 7B 74 7B | Tract Coordinates |
| DD394C | 02 00 02 00 | Tract Size, power of 2 |
| DD3950 | 00 00 00 00 | Count of SGPROPs |
| DD3954 | 36 C5 77 C9 | Group ID |
| DD3958 | 4A 28 34 65 | Type ID |
| DD395C | 00 00 0D 29 | Instance ID |
| DD3960 | 00 00 0D 29 | Instance ID (Patio Chair) |
| DD3964 | 90 13 50 45 | Min X |
| DD3968 | AF D8 88 43 | Min Y |
| DD396C | 36 43 6F 45 | Min Z |
| DD3970 | 90 23 50 45 | Max X |
| DD3974 | AF 58 8A 43 | Max Y |
| DD3978 | 36 53 6F 45 | Max Z |
| DD397C | 02 01 5A B4 | Orientation: South, State: 1, Timed from 9:00 till 18:00 |
| DD3980 | 00 64 02 5E | Date Timed: No, Appearance Chance: 100%, Lot Type: Normal |
| DD3984 | 19 A6 AA 0E | Object ID: 0xAAA6195E, Conditional Flag: 0x0E |
| |
| DD3988 | 58 00 00 00 | Size of this record |
| DD398C | 03 81 44 2B | CheckSum |
| DD3990 | 6C B4 0E 13 | Memory Address |
| DD3994 | 06 00 04 00 | Record Version Number |
| DD3998 | 00 00 00 04 | Appearance flag: 04 = deleted, disabled prop |
| DD399C | 1E 82 23 A8 | Identifies this record to be a prop record |
| DD39A0 | 74 7B 74 7B | Tract Coordinates |
| DD39A4 | 02 00 02 00 | Tract Size, power of 2 |
| DD39A8 | 00 00 00 00 | Count of SGPROPs |
| DD39AC | 36 C5 77 C9 | Group ID |
| DD39B0 | 4A 28 34 65 | Type ID |
| DD39B4 | 00 00 B2 29 | Instance ID |
| DD39B8 | 00 00 B2 29 | Instance ID (Beach Chair) |
| DD39BC | 3E 1F 50 45 | Min X |
| DD39C0 | AC CF 88 43 | Min Y |
| DD39C4 | 1A DA 6F 45 | Min Z |
| DD39C8 | 3E 2F 50 45 | Max X |
| DD39CC | AC CF 89 43 | Max Y |
| DD39D0 | 1A EA 6F 45 | Max Z |
| DD39D4 | 00 01 5A B4 | Orientation: North, State: 1, Timed from 9:00 till 18:00 |
| DD39D8 | 00 64 02 64 | Date Timed: No, Appearance Chance: 100%, Lot Type: Normal |
| DD39DC | 19 A6 CA 0E | Object ID: 0xCAA61964, Conditional Flag: 0x0E |
That concluded this savegame. Nothing comes after these three disabled props.
Both the beach chair and patio chair are props that Peg has modified,
by making them timed to appear between 9 and 18, without changing the TGI.
In this case we know for sure that Barby did not delete any lots,
unless they became deleted by upgrading into higher stages
(which is quite possible as these props appear on low-stage residential lots).
It's also noteworthy that these have a record size of 0x58, and no SGPROPs.
Just for those people who are unsure, Tage and Steph don't see SC4 like we do. I have managed to get a screen shot of what they see:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi302.photobucket.com%2Falbums%2Fnn110%2FDiggis%2FImages%2FTage.jpg&hash=32893d3c3593d9a03091280b2110b4e9f5818c50)
Diggis, you're clearly poxed.
I can see at least 10 missing props, the first one at offset 0x14.
Quote from: RippleJet on March 30, 2009, 06:45:51 AM
Diggis, you're clearly poxed.
I can see at least 10 missing props, the first one at offset 0x14.
So... He will loose his parts at some moment? %confuso
There are several very important props in the human body ;)
Yes, I am avoiding saving me untill there is a cure for the Pox. I have several very important props I don't want to lose.
Well that is only because you're timed. If you were like me and not timed, you can save yourself anytime anywhere :p
Quote from: Diggis on March 30, 2009, 07:34:11 AM
Yes, I am avoiding saving me untill there is a cure for the Pox. I have several very important props I don't want to lose.
Fortunately, I haven't bothered to save myself in quite some time... but I am still hoping that someone can find a way to replace the finger and left knee props which I lost to the pox back in 06. :D
I'm seeing "04" way too many times there, Diggis. I'm afraid the others are right. Maybe you had better get yourself checked out to see if there's anything that can be done. $%Grinno$% I can confidently say that you're in the best of hands right here, though. Nice work, everyone. :)
Quote from: Diggis on March 30, 2009, 07:34:11 AM
Yes, I am avoiding saving me untill there is a cure for the Pox. I have several very important props I don't want to lose.
Don't worry: some of your props will be missing, but your lot will still be functional. $%Grinno$%
Lmao ::)
Jayson
Sadly some of me is poxed as well. I seem to be losing props on the top of my head slowly.
Quote from: bap on March 30, 2009, 08:00:55 AM
Don't worry: some of your props will be missing, but your lot will still be functional. $%Grinno$%
:D :D :D
Quote from: Diggis on March 30, 2009, 07:34:11 AM
Yes, I am avoiding saving me untill there is a cure for the Pox. I have several very important props I don't want to lose.
You'd better then, remove Daeley's Save Alert Mod from your plugins, so you keep avoiding saving until a cure for the damn umbrella comes out. And don't go to the beach. $%Grinno$%
Finally got a chance to upload the files. Two cities:
http://www.fileden.com/getfile.php?file_path=http://www.fileden.com/files/2009/4/2/2389093/City%20-%20Ciocana.sc4 (http://www.fileden.com/getfile.php?file_path=http://www.fileden.com/files/2009/4/2/2389093/City%20-%20Ciocana.sc4)
http://www.fileden.com/getfile.php?file_path=http://www.fileden.com/files/2009/4/2/2389093/City%20-%20Sarmizegetusa.sc4 (http://www.fileden.com/getfile.php?file_path=http://www.fileden.com/files/2009/4/2/2389093/City%20-%20Sarmizegetusa.sc4)
Unfortunately, I seem to no longer have the pre-pox versions. I believe both of these are heavily poxed.
Also, Stephane, I can't for the life of me get your command line instructions for the plugins list to work. The command works up until >pluginslist.txt. Can you please clarify?
Thanks for the files, I will study them
As for the instructions:
start->run->cmd.exe
this open a console window:
cd "My Documents\Simcity 4\Plugins" or whatever your plugins folder here
dir *.* /B /S >pluginslist.txt
this will create the listing in your plugins folder, then just attach that file to a post here
In case you have some plugins in the maxis folder, reiterate the same operation on that folder
Aha - got it. Brace yourselves (attached)... ::)
You've listed what you've got under plugins_disabled...
Are all these the ones that are loaded with SUM when you're playing your game?
I understood we needed the non-compressed folder. Plugins is datpacked and plugins_disabled is where the loose ones are. I don't use start-up manager.
Quote from: snorrelli on April 03, 2009, 10:34:56 AM
I understood we needed the non-compressed folder. Plugins is datpacked and plugins_disabled is where the loose ones are. I don't use start-up manager.
Okiedokie! :)
You do of course at least have this file...
PEGPROD\CDK3\OWW2\Beach\PEG-OWW2_BDK_RESOURCE.dat
True, but as has been established, the Pox (in my case most notably) existed before the BDK kit... &mmm
Note the dates in the properties of the savegame files. These are from spring 2007...
OK, a few weeks ago I stumbled upon this thread here:
Adding Props to Resized lots (http://sc4devotion.com/forums/index.php?topic=6634.0)
which struck me as interesting. The trick outlined in that thread appeared to force the game to reload the props on a file from the lot files, not the prop subfile (where the Pox apparently lies).
This got me thinking, if we can rebuild the sub file we might be able to remove the Pox. After a few failed attempts which left my cities still poxed I have found a technique that at first checks appears to remove the Pox and restore props to poxed lots.
1. Back up the poxed city
2. obliterate the city (using the mayor mode tool with the dynamite that removes the city, but not the terrain)
3. open the backup in the reader and delete the prop subfile
4. open the obliterated copy in the reader and copy the prop subfile into the backup
5. restore the back up and open the game
6. set the city display level to minimum, save and exit
7. set the city display level to high and save and exit.
8. send the file to Tage for testing :P
It would be very helpful if people with an affected city would be able to have a go at this and see if they can also restore their cities to a working state.
Edited by Barby to correct spelling errors ;D
Edited by Callagrafx to correct even more spelling errors ;D
Quote from: Diggis on July 20, 2009, 03:04:28 AM
8. send the file to Tage for testing :P
The city is indeed prop pox free! :thumbsup:
All those props that were deleted when you obliterated the city are still in the prop subfile, but all the info is zeroed out. Thus, when regenerating the prop subfile, when setting the City Details to low and back to high, the size of the prop subfile in this case increases from 16 MB to some 26 MB.
Quote from: Diggis on July 20, 2009, 03:04:28 AM
Edited by Barby to correct spelling errors ;D
Time to obloterate the Kiwi... ::)
...Hey dudes! and Dudettes!......
It's Bruce.....haven't posted for a long while, however have faithfully been playing and building up my regions. Now, for the first time in months, I went back into Wesley, and lo! and behold...I still had the pox in that city, and only that city. So, prior to updating myself with info from this thread, I decided to subject Wesley with disasters....so I let loose with tornados, lightning, and earthquakes.....wiping out 70,000 Sims....saved the city and the next day, went back in to see the damage and start to rebuild. I know, very mean hearted of me...however I was frustrated! Anyway, when I went back in and started to bulldoze the rubble and start to rebuild, I noticed something very odd....most of the lots that had missing props all of a sudden did not!....although a few did....so I replaced those and saved the city, and exited. Now, the next day I went back in to Wesley, and absolutely everything was fine....no sign of the pox! I couldn't believe it...I wanted to post my good fortune straight away, however thought better of it....so I played Wesley for two more days and the same thing, all was well...and anything I restored from the disasters stayed intact as well. I figured, wow!.....and that was yesterday, when I decided to update myself with all the info from this thread. Some great research by the way! Sadly, though, this evening when I went in to Wesley, the pox was starting to appear again....just in a small area, residential with a couple of park areas. The bus stop is only half way there, and the tennis court is poxed as well...so it is coming back, but slowly this time, almost like it is creeping.
I thought this odd and worth sharing with the group,, the odd thing being that after the disasters, the city appeared normal again, even if only for a short while...so there you go!
Cheers
Bruce
Yes, this is known to happen. It's not that hard to get the Prop Pox to go away... for a while.
Which reminds me... I should really fix up the Near West Side of Chicago according to Diggis' instructions and ship it off to RippleJet for checking. The Sims living there will be so happy.
Yeah, it's a funny one. I can repeat it on the city, but if I repox the city at a later date I haven't been able too. Bap can't get it to work on his so maybe there is a point you need to be at to do it. It's possible I was doing it on a city that will get the Pox but doesn't have it yet and thats the reason. I'm going to look into it more this weekend hopefully.
So, what would happen, if you had a prop-pox-inducing item. and just before the prop pox starts, you delete the offender?
Joe
You get the pox. If it is in your plugins at anytime you have saved the city you will almost certainly get the Pox. :'(
Quote from: Diggis on July 20, 2009, 03:04:28 AM
I have found a technique that at first checks appears to remove the Pox and restore props to poxed lots.
It works! &hlp It works! &hlp All the props have been restored to the Near West Side of Chicago! &dance And that's a lot of props. You have earned the undying gratitude of all the Sims living in the Near West Side, Shaun. ()flower() The subfile has almost doubled in size to almost 31 MB, though - does anyone know why that happened? That might also explain why things seem to be moving a little slowly there. Or maybe everyone's just dazed at having everything back. In any case, the total file size of this city is now a little over 100 MB, which just happens to be the size limit for most of the free file services. Does anyone know how to get a file that size to Tage? Is it acceptable to use the DevEx temporarily in such a case? If so, which section should I use?
Zip it, it should shrink a fair amount. Additionally, try playing for a while and checking that the Pox remains gone. Thanks for testing BTW!
I've run the city for an additional fifteen years, and everything appears completely normal. My testing included a thorough check of all the game's data graphs. And after fifteen years, there's still no sign of the prop pox anywhere.
Once again, congratulations and thanks to all those who worked so hard to understand and fix this bug. &apls
(BTW, zipping the city file reduced its size by more than 80%! Definitely the way to go. :thumbsup:)
&dance &dance &dance &dance
Quote from: Diggis on July 20, 2009, 03:04:28 AM
...I have found a technique that at first checks appears to remove the Pox and restore props to poxed lots....
Quote from: z on August 12, 2009, 03:21:29 AM
It works! &hlp It works! &hlp
Yippee!
Congrats Diggis on that flash of insight.. I'm keeping my fingers crossed that this turns out to be a permanent solution... I have a city very close to the 16G size and I'm fairly sure it has the precursors to the pox, so I'll be very happy to find that there is a confirmed solution.. Be a great end result of some clever work by several key people. Its such an ignominious end to be poxed after so many invested hours!
Once its confirmed, it would be sweet if you made this into a tutorial with a bit more expansion of your steps.. perhaps some pics, etc..
Pretty exciting!
Yes, that would indeed be very useful.
Also it would be nice to have a list of certain pox causes: files, props, lots, whatever.... Of course as far as they are found. I guess it will never be certain that we have found all causes of pox.
At least, as far as I understand this thread, there is no such list. Sorry if I overlooked something obvious...
The reason no list is done is the only thing we have found so far that defininetly causes the Pox is the 2 props identified by Bap. We know there must be more as the Pox is older than those props, but to date we have been unable to find any more.
As for a tutorial, sure, when I get home from Croatia next week I'll look into it.
I have just now arrived home after having a vacation in France...
and this was the first thing (and the only thing for tonight) that I had to check...
Quote from: z on August 12, 2009, 03:21:29 AM
It works! &hlp It works! &hlp All the props have been restored to the Near West Side of Chicago! &dance And that's a lot of props.
Thanks for sending me the city file, Steve!
Unfortunately the city is not prop pox free though... &mmm
However, only three props appear after the point of corruption in the prop subfile.
These three props are all marked as "deleted" and have lost their TGI addresses.
Was this the state your city had immediately after "curing" it, or was it after playing for another 15 years?
If it was immediately after curing it, then I would appreciate if you could send me your latest version, so that I could see if the pox is contained or spreading.
Quote from: z on August 12, 2009, 03:21:29 AM
The subfile has almost doubled in size to almost 31 MB, though - does anyone know why that happened?
Just as the case was with Shaun's testing, there are a huge number of props marked as disabled.
In your case you have 182,315 disabled prop records (out of a total of 358,732 prop records).
Quote from: RippleJet on August 14, 2009, 04:32:25 PM
Thanks for sending me the city file, Steve!
Unfortunately the city is not prop pox free though... &mmm
Unfortunately, I just discovered this too - the hard way. Although my city was pox free (at least in terms of visible symptoms) after 15 years, I ran it for an additional 25 years, and the pox started to come back. It is now spreading rapidly. :(
Quote
However, only three props appear after the point of corruption in the prop subfile.
These three props are all marked as "deleted" and have lost their TGI addresses.
Was this the state your city had immediately after "curing" it, or was it after playing for another 15 years?
If it was immediately after curing it, then I would appreciate if you could send me your latest version, so that I could see if the pox is contained or spreading.
The file I sent you was saved immediately after the fix was applied and appeared to work, but before I ran the city for 15 years. With the information I've provided here, do you still want a more recent copy of the city? If so, I can give you a copy after the 15 year period, or the current version 25 years after that, or both.
Quote from: z on August 14, 2009, 05:32:07 PM
The file I sent you was saved immediately after the fix was applied and appeared to work, but before I ran the city for 15 years. With the information I've provided here, do you still want a more recent copy of the city? If so, I can give you a copy after the 15 year period, or the current version 25 years after that, or both.
Since you've already discovered the result the hard way, there isn't really anything for me to look at. &mmm
You know, I have a wild question that pertains to both "Prop Pox" and Growing empty lots. Seeing that blank lots have been set for the most part with a Maxis building family , and the Prop pox deals with props that are referencing Maxis props...and the blank lots were released back in 2003 along with a lot of other "radical" mods, could there possibly be any connection between these or any other mod released around that time, or even the bldgprop.dats?
Since the empty growables grow almost everywhere and the prop pox does the opposite by removing almost everything , its would be interesting to know if those who are affected un-willingly know they have these in there folder.Its a stretch, I know...just wondering if there could be a connection?
Forgive me if some of this was already brought up...just thinking out loud!
Jayson
Nae, I can't really see a connection between landmarks growing on empty lots and the prop pox.
The landmarks growing on emtpy lots are building exemplars (having an invisible model or no model) erroneously belonging to an in-game family of growable buildings. Buildings and props are not saved in the same subfile in the savegame, and the prop pox only appears when the prop subfile becomes corrupted.
Like I said...it was a stretch ;D
Jayson
It seems to me that we are really close to fixing this problem, so I don't want to give up yet. I gather that Diggis' fix replaces the prop subfile with a completely clean version, so it seems to me that the only way the pox can come back is if the bad props still exist in the city. Does this make sense? If so, it should be possible to track them down and find them, which in itself would be an accomplishment. Then, of course, removing them and reapplying Diggis' fix should get rid of the pox for good. Any suggestions on how to proceed here would be welcome, and I am happy to do any testing required and ship off further files as necessary. I have snapshots of my city at all stages, starting from before I applied Diggis' fix.
Quote from: z on August 15, 2009, 03:07:35 PM
It seems to me that we are really close to fixing this problem, so I don't want to give up yet. I gather that Diggis' fix replaces the prop subfile with a completely clean version, so it seems to me that the only way the pox can come back is if the bad props still exist in the city. Does this make sense?
It certainly does, as
Shaun once was free of the pox, but did get it back if he had the Beach Development Kit in his plugins.
The prop subfile in the city you sent me did not have any records with the Beach Umbrellas or Recliners though.
I think we need to get Shaun to take part in these discussions as well... once he's back from wherever he is... ::)
It seems that there's a rather straightforward (if tiresome) way of identifying the bad prop(s), then. I would just need to go through the following series of steps:
- Save the current city in a safe place.
- Bulldoze exactly half of the (remaining) city.
- Apply Shaun's fix to what's left.
- Reload the city, run it for a month and save it.
- Examine the prop subfile for corruption.
- If the pox is gone, restore the saved city and bulldoze the other half.
- Rinse and repeat.
For a large tile with 64K squares, this procedure would need to be done a maximum of eight times before just the bad prop was left. All I need to know is how to examine the subfile. I don't think this was mentioned in this thread, which is why I needed to send the city to Tage before. So if someone can tell me this, I can follow this procedure and find the bad prop. If there's more than one bad prop, it's a little messier, but not by much. And I doubt that there's more than one, as all my other cities are fine.
I am somewhat confused about the prop pox and I am sure this has been answered in the 17 pages but at 17 pages, material in between is hard to track down. One identified problem is PEG_OWW2_BDK_RESOURCE.DAT and I just wanted to make sure that is the exact file name. I have some of the OWW2 collection and am pretty for sure that I am up-to-date with the dependencies but could not find this anywhere on my system.
In addition, I do not know how many of you have been following my new city but all I have been placing so far is the road tiles. If I would happen to have this file, from reading everything I believe that these tiles already have the prop pox? I get confused at the part where it states that even if you do not use the lots, if you have the file in your plugins you will get the prop pox. I think I am missing something here though because if this were the case, what good would modifying the files do since your city would already have the prop pox?
Like I said, this has probably been addressed but after reading a couple of pages of this thread I could not find this addressed and I am also guessing that I am slightly confused on the matter and missing something that connects the dots.
Thanks for any clarification.
Quote from: projectadam on August 22, 2009, 10:52:22 AM
In addition, I do not know how many of you have been following my new city but all I have been placing so far is the road tiles. If I would happen to have this file, from reading everything I believe that these tiles already have the prop pox? I get confused at the part where it states that even if you do not use the lots, if you have the file in your plugins you will get the prop pox. I think I am missing something here though because if this were the case, what good would modifying the files do since your city would already have the prop pox?
It's pretty difficult to tell if any of those modified props have already appeared on any of the lots that might already have grown in your city. Since those props appear on several in-game low-stage R§§ lots, the risk is considerable that you already have them there though. That's the reason for the conclusion, that if you've had the BDK in your plugins, you most probably are at risk...
On the other hand, it seems as if the prop pox appears only if (at least) one of those lots having an offending prop would become deleted (mostly due to being upgraded to a higher stage lot) just at the right moment, when the prop subfile surpasses 16 MB in size.
If you've only built some roads in a newly started city, then that city probably is not affected though.
Quote from: RippleJet on August 23, 2009, 07:03:14 AM
It's pretty difficult to tell if any of those modified props have already appeared on any of the lots that might already have grown in your city. Since those props appear on several in-game low-stage R§§ lots, the risk is considerable that you already have them there though. That's the reason for the conclusion, that if you've had the BDK in your plugins, you most probably are at risk...
On the other hand, it seems as if the prop pox appears only if (at least) one of those lots having an offending prop would become deleted (mostly due to being upgraded to a higher stage lot) just at the right moment, when the prop subfile surpasses 16 MB in size.
If you've only built some roads in a newly started city, then that city probably is not affected though.
RippleJet,
You take such good care of me in SC4; I hope I meet you someday to treat you to lunch for all of the questions of mine you have answered :thumbsup:
After your response, I am lead to believe that as long as the props never appear in your city you are okay, which since I have just placed roads I believe I am in the clear for at least now. I also wanted to just make sure that this is the file name that I need to be on the lookout for: PEG_OWW2_BDK_RESOURCE.DAT
Thanks for everyone checking this out and for continuing to answer my questions.
Quote from: projectadam on August 23, 2009, 11:37:36 AM
RippleJet,
You take such good care of me in SC4; I hope I meet you someday to treat you to lunch for all of the questions of mine you have answered :thumbsup:
I think that RippleJet has done enough for all of us to be treated to free lunches for the rest of his life. :)
But I do have a question, and it's one that I asked above, and seems to have gotten lost in the shuffle. I'm all set to find the offending prop in my city, but the one thing I need to know is how to tell when my prop subfile is corrupted. Could someone please tell me that? Thanks!
You'll need wou's savegame explorer off the LEX to check it, You'll need to open your city tile with it, and it will tell you whether it's infected or not
Quote from: z on August 23, 2009, 02:57:01 PM
But I do have a question, and it's one that I asked above, and seems to have gotten lost in the shuffle. I'm all set to find the offending prop in my city, but the one thing I need to know is how to tell when my prop subfile is corrupted. Could someone please tell me that? Thanks!
In addition to WC_EEND's reply I have also sent you a PM... ::)
Quote from: Diggis on July 20, 2009, 03:04:28 AM
This got me thinking, if we can rebuild the sub file we might be able to remove the Pox. After a few failed attempts which left my cities still poxed I have found a technique that at first checks appears to remove the Pox and restore props to poxed lots.
1. Back up the poxed city
2. obliterate the city (using the mayor mode tool with the dynamite that removes the city, but not the terrain)
3. open the backup in the reader and delete the prop subfile
4. open the obliterated copy in the reader and copy the prop subfile into the backup
5. restore the back up and open the game
6. set the city display level to minimum, save and exit
7. set the city display level to high and save and exit.
Its been a while since I read this but I decided to actually try it today.. the reason is that I had a city tile that would CTD when I did certain kinds of terraforming. I had learned on that region that for whatever reason I could remove the plugins, load the city, edit the terrain (it would not crash in this instance), then I could reload the plugins and continue with the city.. of course many of the custom lots would loose their "looks".. like the prop pox. Anyways, I figured that instead of reploping (or regrowing for growable customs :( ) that I might try this method for "refreshing" the missing stuff. Well I didn't get far. I am inexperienced in the use of the reader so came up against a wall. I am perfectly willing to do the above, but I feel there is needed a BRIEF tutorial with a few pics to show how to do this.. For example in the READER the "props" file (along with many other entries) seem to be shown as "Unknown". I assume its the big fat file there, but I am very uncertain and it seems foolish for me to charge in until I get a bit more expansion on this method..
If anyone can provide such a brief "tutorial" I, and I'm sure others not so "reader-wise", would be able to tackle this. How to tell which file, which technique or window to use to open the file, where to use the menu to delete & copy, proper save and exit method, etc.. Thanks :)
The props file has a Type ID of 0x2977aa47.
SC4Boy, for what you are doing you can skip steps one to 5. They are Pox specific. That was written for people who were testing for the Pox and understood the relevant files. From the limited testing we have had some minor success but no real breakthrough.
Thanks Barby.. duly noted. I'll see if that helps me out.. :)
Quote from: Diggis on October 14, 2009, 12:55:50 AM
SC4Boy, for what you are doing you can skip steps one to 5.
I have already tested a similar case (and also on this case) .. the simple setting and saving in MIN, then loading, setting to MAX, saving and re-loading does not seem to correct the issue.. unless you have some tip I'm missing
Here is the thread for the case (http://sc4devotion.com/forums/index.php?topic=8951.msg278333#msg278333) I spoke of (though my recent discussion relates to a different city in the region
I read your post there, sounds weird to me. I have no problems doing steps 5 and 6 on their own, and the settings ARE retained within my save file.
hmm.. well i went through the cycle again.. and you're right they did save..don't know what I got confused before.. anyways.. here's the story
The city after I had loaded the city without plugins as it looked reloaded.. the settings are those I normally play on before changing settings
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg70.imageshack.us%2Fimg70%2F4209%2Fminmaxsav1.jpg&hash=924e1cda8fdbd85274030c6e3975679ffcca4af4)
The settings I put in to save the city right before saving at min values
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg390.imageshack.us%2Fimg390%2F4823%2Fminmaxsav2.jpg&hash=e97b517ab6a913fc1d3f505bbaa0534370168a5e)
The city settings after loading at min values showing the max settings
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg389.imageshack.us%2Fimg389%2F9016%2Fminmaxsav3.jpg&hash=8d8c7d7e13289e73132a78b7b99d6cc15a0a317a)
The final city after the max save, reloading and set back to my normal settings. As can be seen, whatever did or didn't happen during the process, nothing was resolved with respect to the missing elements
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg389.imageshack.us%2Fimg389%2F7951%2Fminmaxsav4.jpg&hash=f9560ad116b699aeb24fc0a0a821902e0f183943)
If you have suggestions, I'm certainly willing to listen.
Going through all that was what lead me to conclude the full steps procedure would likely be all that would help... Its not only that the visuals are bad, but by looking at the RCI graph, many of those elements lost during the load without plugins also lost the values of the missing buildings population.. there is a MASSIVE drop in the population resulting from the empty plugins load.
Since I have all the game states backed up I may fool with it to see what good running the city for some time would do.. if the conditions are set, SC4 often quickly recovers from wiping out sections of a city, but I don't know if this may be so massive that it would take many years for it to recover.
Ingame lots seem to appear correctly... e.g. the stock exchange. &mmm
This would actually renounce that you are suffering from the prop pox...
SC4BOY, just to confirm that you're not missing any prop packs...
Could you query a couple of those lots where everything is missing?
Then use BuildingPlop in Buggi's Extra Cheats and plop those same lots.
Be sure "City Details" are set to high when doing this...
If the props are showing up correctly on those newly plopped lots,
then we at least know you're not lacking any prop packs.
Quote from: RippleJet on October 16, 2009, 05:57:56 AM
Ingame lots seem to appear correctly... e.g. the stock exchange. &mmm
This would actually renounce that you are suffering from the prop pox...
yes I definitely don't have prop pox (yet anyways.. haha.. *crosses fingers*)
QuoteSC4BOY, just to confirm that you're not missing any prop packs...
Could you query a couple of those lots where everything is missing?
Then use BuildingPlop in Buggi's Extra Cheats and plop those same lots.
Be sure "City Details" are set to high when doing this...
If the props are showing up correctly on those newly plopped lots,
then we at least know you're not lacking any prop packs.
Sure.. I have moved past the issue by using SC4TF to correct the "crashing terraforming" issue, but I did save copies of the "missing stuff" city.. After I put the "old" city back in (before I did the "empty plugins" changes) all the things that were there showed up again properly.
I do recall casually clicking around a few of the lots, but I had no intent in mind so really didn't attempt to organize what I was seeing. When I did it, there was no result at all.. in fact I could not even find a spot using "cntrl-alt-shift ?" which would give any data at all.
Just as an added note, I played around with the plugins folder trying to isolate EXACTLY what set of plugins were causing the "crash to desktop on terraform" situation, but it is unconclusive so far.. I got tired of trying things and restarting after a while.. but I probably will take it up again in a moment of boredom.. :) I thought it would be obvious like a slope mod or the NAM but I tried quite a few things before giving up temporarily. At this point the only thing I can do that allows "crashless terraforming" on this old city is to take all plugins out.
Quote from: SC4BOY on October 17, 2009, 08:40:36 AM
yes I definitely don't have prop pox (yet anyways.. haha.. *crosses fingers*)
Sure.. I have moved past the issue by using SC4TF to correct the "crashing terraforming" issue, but I did save copies of the "missing stuff" city.. After I put the "old" city back in (before I did the "empty plugins" changes) all the things that were there showed up again properly.
So you removed stuff from your plugins and couldn't figure out why it wasn't showing up properly.... ???
Quote from: Diggis on October 17, 2009, 08:56:18 AM
So you removed stuff from your plugins and couldn't figure out why it wasn't showing up properly.... ???
I thought you said you read the thread..... ??? The short answer is yes I did take stuff out, and no I was neither surprised nor puzzled in the least that things didn't show properly
The whole series of posts both here and there had nothing to do with that point
You're post with the pictures indicates that you were trying to figure out why the props on the lots weren't showing up... and the one below indicates that they did show up when you put the plugins back in. I know this stems from another problem but thats the way it read in here. Apologies if I am missing something.
While on the other linked thread, RJ requested that I try out elements of your "step recovery" from the prop pox thread.
The reason I posted this was that I was not familiar enough with the tool to do the full steps that you outlined.. I did try it, but as I was using the tool it was clear to me that I didn't know what I was doing and that there was little to be accomplished from fumbling around with it when I didn't have the knowledge to do so.
Then it was asked that I do the last two steps, which I did. It did not recover the missing items. Others thought that doing this might recover the missing items (or "reload" them)
So at this point, I am saying simply that, given my current knowledge, I've done what I know how, and can contribute no further. A step-by-step "tutorial" would be nice, but I realize everyone is tight on time. Given my current lack of experience with it, I'll have to give up on that part for now.
With respect to my city itself, as I've mentioned I corrected the issues from a former save and moved on.. Since it crashes on terraforming certain sections of the map, I have to use SC4Terraformer to do terraforming in areas that cause CTD's, then reload it into the region and go from there. This works fine, but is sort of a round about method.
I was trying these items to hope to contribute to the subject.
Well it does appear that my largest city has gone into "prop pox" territory.. I expected this to happen sooner or later as soon as the file became big enough. This is the picture of the very beginning of it. Note that this is the northeast corner of the city and "propagating" to the south as it was suggested it would be...
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg189.imageshack.us%2Fimg189%2F7977%2Fpoxe.jpg&hash=1cdb312bb5dd483657aba883feefb1aae8443432)
SC4BOY: can you put your city into a zip file and upload to a file sharing site like fileden, please? Post the link here; We can then have a look at the file to see if it truly is the prop pox.
Of course.. will post and give link in a few minutes.. actually had just popped back on to edit my post and mention that the uncompressed prop file had dropped from "pre-pox" size of 15.6+Mb a few game months before to 14.4-ish Mb immediately after .. :) Since I saved the "pre-pox" size (of course as we seem to have learned, "pre-pox" is just a convenience as the file's "pox future" has been sealed long ago) I'll post both files.. You can look to your heart's content and if you want other info, just let me know.
Ok, fileden links: (PS: sorry.. forgot to zip them, only ~30% reduction anyway)
Pre-pox (http://www.fileden.com/getfile.php?file_path=http://www.fileden.com/files/2010/1/11/2721637/City%20-%20Centralia10-137.sc4)
Post-pox (http://www.fileden.com/getfile.php?file_path=http://www.fileden.com/files/2010/1/11/2721637/City%20-%20CentraliaPOX.sc4)
As you have correctly surmised your city is poxed. Could you possibly get a list of all the plugins in use for this city? You can email a text file to me.
Quote from: BarbyW on January 12, 2010, 09:29:23 AM
list of all the plugins
As other's also may wish to see it, I've also put it zip'ed on fileden CURRENT PLUGINS LIST (http://www.fileden.com/getfile.php?file_path=http://www.fileden.com/files/2010/1/11/2721637/list.zip). Recall however that one of the peculiarities of the SC4 savefile system is that it uses not only any plugin CURRENT, but ALSO ALL PREVIOUS plugins, even if deleted now .. hopefully this will be useful to you however.. I don't know what I may have deleted as this was started before CAM 1.0 came out. As I use fairly "standard" plugins, I expect you will simply find something that you have seen before. Good luck!
hmm.. added note is that many of those plugins have never been used.. for example no airport mod was ever used.. I'm sure there are others too.
I didn't have to look far to find the problem. I can see you have PEG-OWW2_BDK_RESOURCE.dat in your plugins folder. If you read the initial report by Bap and also other reports by those of us who have been testing you will see that this file will trigger Prop Pox every time.
Sounds good on paper, but as you will note above, this region has been in construction far longer than this total thread :) So the knowledge (which I have followed fairly closely from the beginning) couldn't help me on my region... Perhaps next time :)
Nice to know it was only one lot however! I expected several.
Well, that may have been the only one you had. As I understand there are several plugins that contain the necessary features to trigger the issue. This is one known file that has not yet been amended. If the problem arises again, it may be you have another one in there somewhere, but from what I understand of the trigger, it would be unlikely.
In fact that is the only file that so far we have positively identified as causing the problem. I have investigated many others but still not found another that causes the true Prop Pox.
The knowledge in this thread may be newer than your region but you could have identified that file yourself as the problem. Please note that this is not an anti-anyone situation but merely another confirmation that file is a problem.
To date I have never had Prop Pox in a city. I just checked my largest city in GRVII which is a medium tile with a population of over 250K. I have a plugins of custom content of 3.5GB plus terrain mods etc. I checked the savegame file in SC4Save and it found a total of 52985 props in the city. This is made up of 35089 props on lots, 17885 T21 props and 11 props not on lots - neighbour connections etc. I use the BSC Maxis Blockers although I have some modified Maxis R$ lots to fill the custom content gap.
The problem is caused by modified Maxis props with no change of IID especially the beach umbrella which is used in many Maxis R$ lots. In SC4PIM I checked the lots that used that prop either alone or as part of the prop family and found that there are 19 Maxis lots in families using this prop. The likeliehood of it being in a city, therefore, is high. If you have the modified props that have Maxis IIDs then the lots will be affected whether you have used the beach lots or not. Deleting the dat and returning to a pre-poxed city will not have any effect either as any erroneous props will have been saved in the savegame file already.
Quote from: BarbyW on January 13, 2010, 03:38:08 AM
To date I have never had Prop Pox in a city. I just checked ......
As far as I know the ONLY number that matters as to whether you have the pox or not is if the PROP FILE exceeds 16MB... I've never seen nor heard of any instance showing up below that number. After your prop file exceeds that number THEN you know if you have a pox'd city or not. :)
I never had any visual indication of the pox until that picture above which happened just after the prop subfile exceeded the limit and the overflow caused the disappearance of the props and subsequent apparent decrease in the props subfile size.
I don't mean to bash on anyone's obviously painstaking research, but, Barby, I've had large city tiles with over 500k population, with the PEG file you mentioned installed (unmodified), and Prop Pox has never been an issue for me.
I'm not saying you are wrong; under the correct circumstances, PEG-OWW2_BDK_RESOURCE.dat most likely does contain a trigger for Pop Pox. I just feel that the underlying cause of Prop Pox may go deeper than a incorrectly modified Maxis prop.
*DISCLAIMER: This is what I have found to work best for me and is an opinion. I apologize for any lack of clarity that may have caused anyone to take this as a statement of fact.*
I have found that the easiest way of preventing Prop Pox is to not only take care of the files with known Maxis props that have been modified incorrectly, but also to take steps preventing those files which have Prop Pox triggers that have not been discovered. Those steps are as simple as:
Never build on a completely flat tile, of whatever size.
While completely flat tiles contain the largest amount of room for city building, they also allow for the largest number of potentially Poxy files to have an effect. Make sure not only that your city contains hills, but that there are areas where you cannot build or where it would not make sense to build. One map that I feel hits all this right on the nose is the Invermere Valley map.
My $0.02
DS, I have had a large, flat tile, less that 1/3 developed, that got the Pox. Pretty sure I could manage to get the Pox on a small tile if I tried, definetly on a medium one. This is likely due to my play style as I don't build a final layout from the start, but rather prefer to watch my city grown from small farming village to megatropolis. This involves lots of rezoning and relaying of roads and lots.
As has been pointed out before, number of residents bears no relationship on the Pox, it's number of Props. Generally larger capacity buildings contain less props as the buildings take up most of the lot. It has been noted that urban sprawl is more to blame. South Lester (my Poxed city mentioned above) was mostly low and med density residential and medium density industrial. Heavy on props.
Why should I have to change my play style because there are files out there that cause the Pox. While slightly masochistic, I would prefer to find them by trial and error, and get them fixed.
right ok, i have read this thread and there seems to be very little i can do to monimise the chances of developing POX if i want high fill low density large tiles. So i put it to you, what re the golden no no's to minismise my risk, before i even start developing a region.
Quote from: mightygoose on January 18, 2010, 08:35:44 AM
right ok, i have read this thread and there seems to be very little i can do to monimise the chances of developing POX if i want high fill low density large tiles. So i put it to you, what re the golden no no's to minismise my risk, before i even start developing a region.
At the moment, avoid the file listed above, and be careful with what you download. Short of checking every single upload individually there is little more you can do until more information (on causes and on triggers) comes to light.
PEG-OWW2_BDK_RESOURCE.dat, so is this the only file known to definitely affect prop pox. Are you suggesting i individually check my entire plugins for duplicate props with different IID's?
Unfortunately yes, this is the only file we have found to date. We know it can't be the only one, because there are incidents of the Pox from before that was released. However, before Bap's discovery, records weren't kept so closely so we aren't able to track down which of the files were the culprits.
Checking your entire plugins would be one way of doing it... however not a really efficient one. The stuff on the LEX should be safe as Barby and Tage have checked it pretty thoroughly. Other that that you just have to be careful what you download.
Diggis-
I never said you had to change your play style, I was simply stating what has worked for me in preventing Prop Pox, and that it might work for others as well. Obviously my play style is different from yours; mine gravitates toward small, high-density city areas with a low amount of sprawl and plenty of unused, unpropped space, while yours gravitates towards large, low-density areas. Both are viable play styles, and I would never presume to tell you to play a certain way simply because it is what works best for me.
I apologize if I have caused any offense.
Quote from: dragonshardz on January 18, 2010, 08:09:03 AM
I don't mean to bash on anyone's obviously painstaking research, but, Barby, I've had large city tiles with over 500k population, with the PEG file you mentioned installed (unmodified), and Prop Pox has never been an issue for me.
I'm not saying you are wrong; under the correct circumstances, PEG-OWW2_BDK_RESOURCE.dat most likely does contain a trigger for Pop Pox. I just feel that the underlying cause of Prop Pox may go deeper than a incorrectly modified Maxis prop.
Regardless, I have found that the easiest way of preventing Prop Pox is to not only take care of the files with known Maxis props that have been modified incorrectly, but also to take steps preventing those files which have Prop Pox triggers that have not been discovered. Those steps are as simple as:
Never build on a completely flat tile, of whatever size.
While completely flat tiles contain the largest amount of room for city building, they also allow for the largest number of potentially Poxy files to have an effect. Make sure not only that your city contains hills, but that there are areas where you cannot build or where it would not make sense to build. One map that I feel hits all this right on the nose is the Invermere Valley map.
My $0.02
I don't think you have understood, dragonshardz, and it would be appreciated if you would not make statements that are not based on fact or research.
1. Population is not an issue. I have had cities of 1 million on perfectly flat tiles and have never had Prop Pox. In fact the Riquelandia files that bap posted for testing have less population than the majority of my old cities.
2. Size/type of tile has no bearing on the problem. Prop Pox has been reported in various terrains and various size tiles.
3. To date, I repeat once more, we have only identified one file but know that there must be others that can cause this problem. I have been searching for other files for months but have not yet been able to find one although I do not have all the old lots from the STEX or other exchanges. bap positively identified the file by binary search and tested his theory over many months before publishing his findings. People who have suffered from this problem prior to the release of the BDK file have offered their cities for examination together with lists of their plugins. We cannot, however, know if there have been any changes in their plugins as many had abandoned the affected cities a long time ago.
4. Custom content per se has no effect on Prop Pox as the Riquelandia tile was developed with none at all - and how I learned to detest vanilla Maxis while testing ::).
5. Although it seems that a sprawling suburban style may be the problem, many will change the density of zones as the city develops so promoting the building of higher rise buildings. The problem occurs, so far as we know, when a Maxis prop is modded without changing the IID of the exemplar. My research has involved taking each of the four Maxis props involved in the BDK file and testing each individually. The only prop that constantly caused Prop Pox was the beach umbrella which had been modded but retained the Maxis IID. I tested also by taking the beach umbrella and modding it the same way but I changed the IID. No Prop Pox. The beach umbrella, as I stated previously, is widely used on Maxis R$ lots. All cities start out with R$ whatever they may eventually end up as so
IF you have the BDK file in plugins
AND do not block Maxis R$ lots
THEN you are likely to get Prop Pox even though it may not occur for a long time. Until the prop file of the Savegame file exceeds 16MB, in fact, and that may take years to develop.
Anyone who would care to join in the hunt for other possible files that may cause Prop Pox are very welcome to join in but if you have not done any research or made any positive contributions to this discussion please do not make erroneous statements. We have tried to emphasise the need for research from anyone especially those who may hold older files - those from 2003/2004/2005. The more people hunting and testing, the quicker we can identify and deal with any suspect files.
Quote from: dragonshardz on January 18, 2010, 08:09:03 AM
I'm not saying you are wrong; under the correct circumstances, PEG-OWW2_BDK_RESOURCE.dat most likely does contain a trigger for Pop Pox. I just feel that the underlying cause of Prop Pox may go deeper than a incorrectly modified Maxis prop.
As evidenced by
Lord_Morpheus'es tests (page 12 of this thread and onwards), and also confirmed by every prop poxed city that has been examined ever since, it seems obvious enough that the prop pox appears if at least one lot including at least one of those modified props included in said resource file, is "deleted" (either manually or, most likely, by being replaced in the game by an upgrading lot) during the process at which the prop subfile in the savegame is changed from a compressed one (when the uncompressed size is beneath 16 MB) to an uncompressed one (when its size exceeds these 16 MB).
Quote from: BarbyW on January 18, 2010, 12:02:41 PM
Until the prop file of the Savegame file exceeds 16MB, in fact, and that may take years to develop.
Indeed! And as has been said here and elsewhere, there are cases where the prop file has been "infected", but still hasn't developed the pox when surpassing that 16 MB threshold.
The difference may very well be in the question, whether any of those modified props have been deleted during that crucial step of the prop subfile's layout in the savegame.
As I said, that is what as worked for me so far.
...Perhaps I should go and change that post so that is more clear.
dragonshardz: have you ever had Prop Pox? If not, how can you say that you have the solution? I have never had Prop Pox but at this moment in time would not dream of suggesting a solution as we do not have one.
I would suggest you would be better "employed" researching the problem yourself or check though any old files from 2003/2004/2005 that may have modded Maxis props with unchanged IIDs. There must be some but the more people that look the easier it will be to identify any other problem files.
The best way to avoid prop pox is to not play at all
ok, I'll go and hide
:D :D :D
Quote from: wouanagaine on January 23, 2010, 02:13:26 PM
The best way to avoid prop pox is to not play at all
ok, I'll go and hide
works for me :D :D :D
Barby: I did not say I had a solution, I said that I had found a way of building cities that has helped prevent Prop Pox from affecting me so far. I have changed any posts since my post this past week to reflect that.
Whether my play style actually does help prevent Prop Pox or is just a placebo effect is a moot point, unless I get Prop Pox.
On a less...confrontational...note, Wou, that does work! :D :D :D
I just heard/learned about Prop Pox last night when reading a fellow Mayor's MD whose region has recently become infected. He included a link to this thred and I read all of pages 1-6 before going to bed. This morning I'm back and skipped ahead to this page to see if the topic was still current and I see that it is, so now I have a couple of questions.
I have a brand new region in which no cities have yet been created. I have built nothing anywhere, only planted a few scattered God Mode trees in a few of the 140 large city tiles that comprise the region. I do, however, have a messy and overstuffed plug-ins file that I know for a fact has a number of PEG products in it. I have not yet gone through my plug-ins to see if I have the one file that is known to create this problem nor have I done any housecleaning to check and see if other files may have borrowed from the known file. I think the chances are fairly good that I do have the file in my plug-ins folder.
Given that I have been playing ONLY in God Mode in this region so far, if I tidy up my plug-ins folder NOW, before I enter into Mayor Mode play and start building stuff, will my region escape unscathed? Or, having saved the region many times while in Gode Mode and with a possibly infected plug-ins folder, am I already doomed?
I have full back-ups of the region all the way back to greyscale maps and could recreate the entire region in a couple of hours, so if I have to toss the whole thing out now to prevent possible Prop Pox in the future, I won't hesitate to do that (after cleaning my plug-ins folder, obviously). Just trying to figure out if I actually need to do that or not.
On another note...it's inconceivable to me that any creator of custom content would not only refuse to fix this issue in the face of the overwhelming evidence his/her work is ONE of what may be many problematic files, but would even deny the problem exists at all. I'm glad there are folks "out there" who take our devotion to our game and creations seriously enough to invest the tremendous time and effort that has been expended here to help us all reduce or eliminate the threat to our regions and cities. You guys are all heroes!
Lora/LD
I am the one who recently got hit by the Prop Pox. I am doing some research at the moment. Could anyone provide me with an unpoxed city tile with uncompressed prop subfile? One that survived the jump from compressed to uncompressed?
Just the .sc4 file would be sufficient at the moment. Lord Morpheus' links a few pages back are dead already.
Quote from: ldvger on March 22, 2010, 11:59:53 AM
Given that I have been playing ONLY in God Mode in this region so far, if I tidy up my plug-ins folder NOW, before I enter into Mayor Mode play and start building stuff, will my region escape unscathed? Or, having saved the region many times while in Gode Mode and with a possibly infected plug-ins folder, am I already doomed?
Hi
Lora. The answers are YES and NO, respectively for the first and second questions.
Even if you have an infecting prop in your plugins folder, provided that no actual lot has been plopped or grown, you are free from getting prop pox. In the specific case of the modified beach unbrella inside the PEG BDK package, as soon as no low-density residential lot has grown or no BDK beach lot containing that particular prop is plopped, you are also on the safe side.
Quote from: ldvger on March 22, 2010, 11:59:53 AM
I have full back-ups of the region all the way back to greyscale maps and could recreate the entire region in a couple of hours, so if I have to toss the whole thing out now to prevent possible Prop Pox in the future, I won't hesitate to do that (after cleaning my plug-ins folder, obviously). Just trying to figure out if I actually need to do that or not.
Since you are just starting a brand new region, may I suggest you make frequent & regular backup copies of the full region. In my case this was crucial to help me get rid of the problem. I replaced infected & doomed city tyles by their backup copies at epochs before I had installed the offending prop package. This would not prevent you from having to redevelop the affected cities all over again, but it is certainly better than loosing them for good (or having to start from scratch in an empty tyle).
Good luck with your new region!
Bap
Quote from: RickD on March 22, 2010, 01:26:48 PM
I am the one who recently got hit by the Prop Pox.
Hi
RickD, I regret to know that (this might be one of a few threads at SC4D in which a newby receives this kind of message instead of a "Welcome to our thread!") &ops
Quote from: RickD on March 22, 2010, 01:26:48 PM
I am doing some research at the moment. Could anyone provide me with an unpoxed city tile with uncompressed prop subfile? One that survived the jump from compressed to uncompressed?
If you send me a PM with your email I will send you a savegame file of an unpoxed city with a prop subfile larger than 16Mby.
Bap
Well hello gang!......it is Bruce Atkinson.....
Recently I have had some bad luck with one of my computers, and had to prepare transferring everything of SimCity over to a newer computer with Windows 7 Professional. Prior to doing this, and as most of you know, I'm one of the original sufferers' of Prop Pox. Just recently I applied one of the solutions documented here, regarding using ILive Reader in changing some of the lots....and just recently, again prior to transferring SimCity from one computer to another, I was building in a non-poxed city called QueensBridge. I admit, I was pushing the envelope on this one, as I used a lot of Landmarks and Special lots, and lo and behold on the last opening of the city, Prop-pox appeared! I have saved the offending city and put it in storage and have replaced it with a back-up, and so far no Prop-pox.
Secondly, as mentioned, I'm running SimCity in an Acer computer with Windows 7 Professional. Everything intalled fine and the game seems to be running fine. I'm also using Nvidia GeForce GT 220, and it is updated with their latest driver. Does anyone know if there is any issues with this one, or some tweaking with the Display controls....the only glitch that seems to happen is that my monitor will go black for a few moments, with the hour glass appearing, and then snap back to the city.....
Best Regards:
Bruce
The latest nVidia drivers are known to have a number of problems with SC4 running under Windows 7. Some people have gotten the earlier drivers to work OK, though. I'm afraid I don't recall the thread where I saw the detailed information; maybe someone else could help there.
Here's one I found helpful: {Link} (http://sc4devotion.com/forums/index.php?topic=9657.0). I've no idea if it has anything to do with prop pox. The 192 driver is notorious for causing graphic-display problems, though.
Later...
Joan.
hmm, this is interesting
I have been developing one region for about 4-5 years now and never had prop pox. Then yesterday my most developed, and large-sized, city came down with it. After finding out about what it was and how it was incurable I restored a 3 year old back up of it just today. Then within a few hrs of developing the city so it came closer to its current state (played for about 8 years, but there was massive demand as you'd expect), prop pox was back. I don't get how in a few hours of development I could reach something that took me 3 years earlier to do.
Does that mean there's something new I may have installed causing it, or what? I have had that PEG BDK thing installed for aaaages and never had any issues until now, and I don't think I even used his stuff so far.
Quote from: Duvad on April 06, 2010, 05:27:53 AM
I have had that PEG BDK thing installed for aaaages and never had any issues until now, and I don't think I even used his stuff so far.
Whether you've used anything from that pack or not, is irrelevent.
The relevant thing is that certain Maxis props are included, and edited so that their timing is changed.
Since their TGI addresses are unchanged, they replace all such props in your game.
Those ingame props appear on dozens of ingame lots.
Thus, it's almost certain that you've got lots of those props in your city.
Quote from: Duvad on April 06, 2010, 05:27:53 AM
I don't get how in a few hours of development I could reach something that took me 3 years earlier to do.
This has been reviewed in this thread several times, but again.. the lots that generate prop pox are like seeds or time bombs (should be renamed "compression bombs" in this case.. hehe).
ONLY when you exceed the "compress" size.. approx 16Mb for the file to be "compressed" (the point where the lot size issue ends in "memory overrun" of a sort) does the "bomb" explode into "prop pox".. As long as that point is not reached you can happily play the city and never notice any symptoms.. then once you get to that size and save/reopen the city there it is in all it's glory (starting in one corner, NE as I recall, and working its way south and through the whole city as you continue).
Would be cool if we could figure out how to get the game not to compress the file. In today's computers the file size is pretty much irrelevant since HD storage is so cheap $/Gb. If it never compressed it would never show "prop pox"
I'm so confused! I've gone through the thread but I feel I've missed something. Is there a way to rescue a city that's been struck by Prop Pox? I've gotten rid of the offending plugins, but there's more I need to do, yes? Sorry for being so thick...
Quote from: ElPhantasmo69 on April 06, 2010, 12:26:09 PM
Is there a way to rescue a city that's been struck by Prop Pox?
No
Cheers for those answers. Although my city seems doomed if I do much development on its 3-year old back up I still want to be able to develop it so it properly supports the CO/CS needs of the region.
This might be a stupid question, but if I get rid of prop-intensive lots/plops (e.g. I have tonnes and tonnes of ploppable trees/forests/water), will it reduce the size of the uncompressed file (and thus extending the time I can develop the city before going over the limit)?
Quote from: Duvad on April 06, 2010, 05:56:28 PM
...if I get rid of prop-intensive lots/plops (e.g. I have tonnes and tonnes of ploppable trees/forests/water), will it reduce the size of the uncompressed file (and thus extending the time I can develop the city before going over the limit)?
I won't swear to it, but my recall is that when you remove things, there still are "placeholders" in the save file. You could of course just test for yourself by downloading the tool SC4Save (http://sc4devotion.com/csxlex/lex_filedesc.php?lotGET=2021) and look at the prop subfile of the save (and since you have a backup) do whatever you think you want to do to props lots, save it then look at it again with SC4Save and see for yourself if you have made a significant difference in the file size. As long as you can keep it below the compress size, you'll not see the pox
You can completely get rid of the pox any time you want... temporarily. Here's how:
1. Open your saved city in Ilive's Reader.
2. Sort the left pane based on file size, with the highest at the top.
3. Near the top, there will be a subfile of type 2977AA47. This is the prop subfile. Delete it.
4. Also delete the subfiles of type 6A0F82B2 and 6990C1AA, which are also near the top. These subfiles are regenerated as needed. If you don't delete them, this process will still work, but your city size will increase greatly each time you repeat this process.
5. Save the city file.
6. Start up the game, but don't open the city file.
7. Open the Graphic Options, and make sure the City Detail is set to Low.
8. Open your city and save it immediately.
9. Exit to the region without saving.
10. Open the Graphic Options, and change your city detail to High.
11. Open your city. All your props should be restored.
12. Save your city. Your props will all be there... for a while.
Quote from: Duvad on April 06, 2010, 05:56:28 PM
This might be a stupid question, but if I get rid of prop-intensive lots/plops (e.g. I have tonnes and tonnes of ploppable trees/forests/water), will it reduce the size of the uncompressed file (and thus extending the time I can develop the city before going over the limit)?
The most common size of a prop record is 88 bytes, and the next common one (for timed props) is 108 bytes.
To get the prop subfile up to the size of 16 MB, would require some 190,000 props in a single city.
It might be difficult to find tens of thousands of props to delete, just by bulldozing some ploppable lots though...
And mayor mode ploppable trees aren't even saved in the prop subfile, they're in the flora subfile (0xA9C05C85).
On a large city, 256×256 tiles = 65,536 tiles, 190,000 props would mean almost 3 props per tile. Doesn't sound too much...
However, it's worth noting that low-density growable lots usually have a lot more props per tile than large skyscrapers.
Quote from: bap on February 24, 2009, 08:37:13 AM
[...]
6) It seems a memory overflow somewhere is leading to the corruption of the network subfile and the city save file ( see here (http://sc4devotion.com/forums/index.php?topic=1201.msg164798#msg164798)). There was a suspicion that the EP1 update program could be the cause of Prop Pox. Another possible culprit would be a plugins folder infected by multiple definitions of a same prop.
EP1 doesn't seem to cause it; it happened to the first city I built when I started playing again last year, at which point I didn't have any update installed, just the base version of Deluxe. I also had less than 500mb of plugins at that point. If multiple definitions of the same prop were the culprit, my memory isn't exactly clear but I don't think I removed anything from my plugins folder after that, and have built many more much larger cities (the city this happened to was only 20-30% development on a large tile) and the problem has not re-emerged, and I'll admit I'm sloppy with things like Cleanitols so there's gotta be dupes somewhere. The low level of development on the city this happened to, and some of my current unaffected cities that are large tiles covered top to bottom in plopped custom content from a 4.5GB plugins folder, makes me wonder about the size of the subfile theory. Might there be something different about this in regards to growable lots? The problem never happening after that coincided with a good deal of my cities being custom plopped.
Now I make regular backups.
Edit: Further, my largest city, built as described above, uses every single OWW2 lot including the file given as a cause, and somewhere between the backups it jumped from 13,844KB to 29,762KB. Interestingly enough, that was between Feb 28 and Mar 07 of this year. *If* I made any changes to that particular city (region backup) in that time period, it was small. Still no prop pox. The network subfile is 5,076,314; but I can't imagine a city with only a third of the land developed with a comparatively small amount of custom content could have had a network subfile above 6. There's got to be some interaction...
Quote from: fafalone on April 26, 2010, 05:52:46 PM
Edit: Further, my largest city, built as described above, uses every single OWW2 lot including the file given as a cause, and somewhere between the backups it jumped from 13,844KB to 29,762KB. Interestingly enough, that was between Feb 28 and Mar 07 of this year. *If* I made any changes to that particular city (region backup) in that time period, it was small. Still no prop pox.
Thanks,
fafalone!
That's certainly a confirmation of the fact that the prop pox does not strike every time the prop subfile goes beyond 16 MB and from compressed to uncompressed.
This in turn gives confirmation to what we've suspected...
that one of the lots containing the mentioned props needs to be bulldozed or upgraded during that process.
The fact that few changes were made to the city between the saves would also indicate,
that you managed to get the 16 MB size to be surpassed at the right moment. :)
It would be interesting to see the prop subfile's size and number of records within it before and after it surpassed those 16 MB.
Backup from Feb28 (13,844KB)
Prop subfile size: 5105613
Prop pox free city
149311 props found in city
Some infos about the props:
-0 disabled props found in city
-3898 tracking props found in city
-4570 timed over year props found in city
-22763 dayly timed props found in city
-27427 conditional props found in city
-From what kind of data :
--25 props alone
--129248 props from lot
--20038 props from T21
Backup from 3/7 (29762KB)
Prop subfile size: 5076314
Prop pox free city
148919 props found in city
Some infos about the props:
-0 disabled props found in city
-3904 tracking props found in city
-4566 timed over year props found in city
-22708 dayly timed props found in city
-27368 conditional props found in city
-From what kind of data :
--39 props alone
--128876 props from lot
--20004 props from T21
I really don't know where the difference in size comes from; all of the subfiles listed in savegame explorer are similar in size. If you want the files to analyze them, let me know. Or tell me what else to look for.
The prop subfile is far from being 16 MB in size...
Thus, you wouldn't even have to fear the the prop pox in the first place for quite some time. :)
I went back through some old files and identified the city I was talking about that was only covering 1/3rd of a large tile with a fraction of the custom content.
Filesize: 3.2MB
Prop subfile size:895,727
Prop pox free city
26010 props found in city
Some infos about the props:
-1 disabled props found in city
-763 tracking props found in city
-10 timed over year props found in city
-5778 dayly timed props found in city
-5808 conditional props found in city
-From what kind of data :
--13 props alone
--23252 props from lot
--2745 props from T21
Now it says it's prop pox free, but what happened in the city is absolutely identical to what's called the prop pox. I'll post a screen shot to confirm later.
Quote from: RippleJet on May 01, 2010, 12:00:05 PM
Thanks, fafalone!
That's certainly a confirmation of the fact that the prop pox does not strike every time the prop subfile goes beyond 16 MB and from compressed to uncompressed.
This in turn gives confirmation to what we've suspected...
that one of the lots containing the mentioned props needs to be bulldozed or upgraded during that process.
Sorry, I don't quite understand this. My poxed city develops the pox in pause mode. I have the city on pause with compressed file, force the file to uncompress -> pox. Nothing is bulldozed or upgraded.
Quote from: RickD on May 03, 2010, 02:20:55 AM
I have the city on pause with compressed file, force the file to uncompress -> pox. Nothing is bulldozed or upgraded.
How do you get the prop subfile to increase beyond 16 MB while the game is paused? ()what()
I delete the subfile (which is close to the limit but still compressed) in the reader, load the city with low graphics settings, save and exit, switch to high, save and exit, reload, save and exit Then I end up with an uncompressed, poxed subfile.
That sounds correct. But did you get your props back?
I get many of the props back for the one session after switching the graphics setting to high. After reloading the city they are gone again. Each time I reload the city, more props vanish.
That's my first post and topic on SC4D, but not because of a good thing, hehe &cry2
I had a CAM I downloaded by torrent, but as I saw that there were an original version - and I could get support in case of trouble - here at SC4D, I started to update my SC4, downloading the original CAM and also downloading CAMelots, brand new props and mega packs I had never seen.
That was ok until I experienced prop pox. It happened with some lots but I just noticed when I built a seaport with PEG Seaports. They became completely empty, but they had always functioned perfectly. At first I thought it was some kind of duplicate prop pack or model file, or even some files conflict, but I did some research and discovered that.
I saw there's no turning back and it'll remain the same, and I'm kind confused about what to do, as I saw that prop pox it's not so common. May I look for the 'cause of the problem, delete it and start a brand new region ?
I appreciate any kind of help, 'cause this region is amazing, and I've been planning a CJ... &mmm
:thumbsup:
I've moved this to the correct forum. I would suggest you read through this thread, especially the first posts by Bap. Unfortunatly, if you really do have the POX there is currently nothing we know of that will fix it. I would suggest checking if you have the BDK file from Pegs, and if so post a bug report at his site because he doesn't post here. I would also suggest removing that file from your folder (and probably any others that rely on it) so you don't get the pox again, until a fixed file is forthcoming.
Quoteif you really do have the POX
Diggis makes a good point ... "if" ...
QuoteThey became completely empty, but they had always functioned perfectly. At first I thought it was some kind of duplicate prop pack or model file, or even some files conflict, but I did some research and discovered that.
I would not necessarily jump to conclusions. Do you have your detail set to max? Do you have other lots affected - such as residential?
Diggis : Thanks for replying (and moving it to the right topic) ! ;D
Well, the description of POX it's exactly what happened with my game, but I might check it.
I do have BDK. I'll delete it and see what happens.
jmyers2043 : I had some problems with slow game and crashing, so all my configuration is set to low or medium. I'll check that anyway.
In fact, the most part of my lots had missing props. But even new lots that grew with props, lose them when restarting SC4 or even reloading the city.
Anyway, BDK may be the problem. I'll delete it, read the entire topic, see what I can do. I'll tell you later.
Thanks for helping!
I deleted BDK file and now props aren't vanishing (I think so...). I tested it with a 350,000 pop. city, but I'll test with other big cities btw... Thanks guys ! :thumbsup:
Hi all,
I really don't know where to start. Okay, maybe I'll start with a little problem that I have faced.
It has been around 4 years since I last played SimCity 4, and recently a long summer vacation motivated me that I should do something to rekindle my love for this game. I dug through the attic and found the installation CD (yea, that's so Jumanji), installed it on Windows 7 and everything has been fine so far.
It wasn't until recently, around a week after I have started a new region, that I realized props are systematically missing from my cities. Each save only further propagates the problem and nothing seemed to have stopped it:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg180.imageshack.us%2Fimg180%2F4971%2Fcanarypoxed.jpg&hash=12964c69dcb36933546ec1dfab06770d9f4ff09a)
One thing I realized was that when the prop pox first reared it's ugly head, the most recently grown/plopped lots were the first to be affected. However subsequent saves also reveal missing props in other parts of the city, propagating each time a save is made.
I googled for the issue and landed on this thread. In fact, I was lurking around SC4D for a very long time but didn't muster the effort to register a proper account.
It took me an entire night to go through all 21 pages of the forum, and I have to say that you guys (everyone that has helped to diagnose the issue in any way) have gone beyond your personal moral obligations and responsibility to make prop pox a recognized bug and more importantly, proposed ways to diagnose the problem and fix it, if there's anyway possible.
On behalf of every single person who have came along this thread's way and left with a better idea of what prop pox is and how to prevent it from recurring in the future, I salute every single one of you. Despite a famous BATer's bogus claims of a witch hunt turned onto him and his defiant insistance that we were out there to frame him, you guys treated insults and taunts with a pinch and salt and continued working as hard as ever to help every single one who came here seeking for advice and solutions.
Thank you, thank you, thank you. Just so much.
Although my region couldn't really be saved (I'm more of a perfectionist and would do anything, including starting all over, to make my cities perfect), I just want to let you guys that I have learned a very important lesson - not only about how the game works and the numerous flaws in Maxis' propriety game saving system, but also about human nature.
You guys just saved my ass, in short. At least I didn't have to continue building the infected region with a false hope that nothing is wrong (as claimed by a certain someone, hah). I have removed the problematic file and will be more than confident then ever that I'll build a better region ;)
Thank you, guys *bows* &apls
(Edit)
Anyway, perhaps it was the stubbornness in me, I found a backup copy of my region that was made several days back. I forgot that when I backed up the SimCity 4 folder in My Documents I backed up the Regions folder too :D
The backup was done before I installed the certain someone's problematic file, so I'm very sure that any of the cities are prop pox-free to start off. And to make things a little sunnier, I always have DuskTrooper's mod that blocks all Maxis buildings on (but I only installed the R$, R$$ and R$$$ block files). Since the problematic prop modified by the certain someone is perhaps limited to residential lots (correct me if I'm wrong), my cities should by right be unaffected by the prop pox.
My assumptions turned out to be real. I played a few cities, and constructed massive suburban sprawls and plopped the Maxis gazebo like a madman (it has one of the highest prop count per grid unit, at around 20+ props per square). I let the game run for around 50 years because sleepiness got the better of me. I saved the city and I loaded it after exiting to region.
It's prop pox free. $%Grinno$%
I double-checked using wouanagaine's SC4Save tool, and by investigating the props subfile (which is at 18421848 bytes, or approximately 18.4mb) shows that the city if pox-free (no buffer overflow or whatsoever).
But I might be wrong, I'll continue testing my city and see how it goes, maybe let it run for 200 years or something.
Looks like it's for real. The umbrella prop only appears on Maxis residential lots. If you have disabled their growth completely, your city should be prop pox free (i.e. salvageable) if you can find a backup of it before you plopped the certain someone's lot.
* * *
My conclusion is that if you have DT's maxis building blocking mod installed at the start of the game, and have backed up your cities before you plopped any of the certain someone's problematic lots, then your backup should not be affected by the prop pox in the future too.
(/Edit)
So, that's where we stand.
There is one file recognised as a cause of Prop Pox. So we are not going to use that file anymore.
But what if you have a region that never contained that file but even so shows signs of infection? I happen to have such a region. I uploaded already the first city from this region that was affected to RippleJet. I hope he is able to find my cause of Prop Pox.
But in fact it should be nice to know what kind of props could be the reasons and then find a way to identify them.
My pluginsfolder contains 2GB of lots, props, buildings and textures. And I'd like to start a hunt for the prop pox virus. Who can give me hints? What files or kinds of files are definitely not the reason, so that I can count them out?
Hello guys,
I'm a little bit confused. I tried to get the pox in a test city.
This is what I've done:
- I made a lot with many props on it and plopped it massively in a completely empty test city. I found a threshold:
2862 of those lots and the subfile 2977aa47 of the saved game had a size of 4,102,010 bytes, 2868 let the size grow to 16,007,843 bytes.
So there, the game switched the way of saving the game.
- I made a time controlled prop and gave it the TGI of a static Maxis Prop, so I had a replacement mod. I put this Prop on a lot.
- I put this lot without the replacement mod in the test city which had a small subfile and saved it. With this lot inside, the subfile was still small.
- I restarted the game with the replacement mod in my plugin folder. On the lot with the Maxis prop, there was now my prop. I saved the game.
- I restarted the game and plopped some more of the lots with many props on it and saved the game, it made the subfile grow to 16,208,667 bytes.
- Now I expected to have the pox. I restarted the game and loaded the city again, but every prop was where it should be.
Is there anything I did wrong?
Quote from: Fluggi on October 14, 2010, 02:41:04 PM
Is there anything I did wrong?
Its been a while since I read the Prop Pox topic, but from memory ... its also how many LOTs are affected as well, in the case of the know affected props they are beach props, but maxis also used them in low wealth (R$) houses as garden furniture so they can appear hundreds of times in your city.
hope that's right
:)
Quote from: Fluggi on October 14, 2010, 02:41:04 PM
- I restarted the game and plopped some more of the lots with many props on it and saved the game, it made the subfile grow to 16,208,667 bytes.
- Now I expected to have the pox. I restarted the game and loaded the city again, but every prop was where it should be.
We've had a few pretty strong indications that, for the prop pox to appear,
some of those props that have been modded need to be deleted during the process where the prop subfile surpasses 16 MB in size.
(btw, 16 MB = 16,777,216 bytes).
All savegames of poxed cities that I've inspected have a number of deleted props
(indicated by the flag saying it's an active prop having been reset to 0) in the end,
and it's among these that the subfile becomes corrupted.
Deletion of a prop would normally occur when a growable lot upgrades in the game.
Plopping new lots in empty space would never lead to the deletion of existing props.
This in turn would also explain why the prop pox doesn't strike every time,
and that you do have a chance of getting past those 16 MB without being poxed.
Quote from: FrankU on October 14, 2010, 03:18:20 AM
I uploaded already the first city from this region that was affected to RippleJet. I hope he is able to find my cause of Prop Pox.
I just realized I never posted anything about it after I checked your savegame, Frank... &ops
The main reason was that there was very little to report...
The corrupted occurred very late in the prop subfile, with only half a deleted prop record following after the point of corruption.
That prop was all zeroed out though, with no information about which prop it could have been.
Since the prop pox clearly has affected a huge number of props along the eastern edge of that city,
it is clear that the prop subfile has become very much truncated at some stage.
Hi RippleJet,
Sorry, but I don't understand.... Do you have any clue what might be wrong or not? Is there anything I can do? Do you want me to send you the second poxed city in that same region?
Quote from: FrankU on October 15, 2010, 03:27:30 AM
Sorry, but I don't understand.... Do you have any clue what might be wrong or not? Is there anything I can do?
To be honest, we've kind of run out of options in the whole prop pox matter...
The more I look at different poxed cities, the less I know about why it became poxed.
The only thing common for all of them is that a corruption occurs in the end of the prop subfile,
and that all records that follow after that point (and have an invalid starting point) are marked as deleted.
Some times those deleted props still have their TGI addresses intact, but mostly not.
And often the whole prop subfile is truncated, so that most deleted prop records are in fact deleted (I hope that makes sense...). ::)
I believe the only certain way of finding additional pox causing props,
would be to go through the same lengthly and tedious process that
bap used when identifying those four we now know of.
Quote from: FrankU on October 15, 2010, 03:27:30 AM
Do you want me to send you the second poxed city in that same region?
Sure, I can take a look at it, but don't expect too much out of it... ;)
I will be travelling most of next week though, so I won't be able to look at it until next weekend.
One way to check out using bap's method needs to concentrate on original files from before the release of the file that has been identified as causing the problem. It should be done with as few files dated after that as possible and from what we have already noted needs to concentrate on props used on Maxis R$ and R$$ early stage lots.
Hi RippleJet and BarbyW,
If I interpret your posts correctly there is not much development on the Prop Pox matter.
Also, it seems that the only thing that is sure is that there are four props by Peg that will corrupt the prop subfile. And that the prop subfiles of poxed cities are corrupted.
But does that mean that all other causes of Prop Pox need to be props also?
Might it be that there are other causes of Prop Pox? Maybe there are other ways of corrupting the prop subfile? Like CTD's caused by very different reasons such as unstable operating systems, inappropriately modded files of different kinds, etc?
The reason why I offer you my corrupted city is not because I think you are bored and like to dig around in someone elses digital crap ;D .... I offered it because I hope it could shed light on the Prop Pox matter. If you think you won't be able to learn something from it, you better spend your time on something difrerent.
But if you think it's useful I gladly send you a yousendit link.
Thanks!
Quote from: FrankU on October 18, 2010, 02:50:56 AM
But does that mean that all other causes of Prop Pox need to be props also?
Yes, we know for sure that the prop pox is related to the corruption that occurs in the prop subfile, when it becomes more than 16 MB in size. And that file, surprise, surprise, contains only props.
The fact that we know how to identify whether the prop pox has struck in a savegame, is also the reason for wouanagaine's SaveGame Explorer program being 100% correct each time it finds and reports a poxed city.
Yes, I understand, but I was thinking of a possibility of corruption occurring when the game crashes during saving. I once had such a crash. My city looked OK after a new startup, but who knows?. Or something completely different. Just guessing....
All right folks,
I found out last night I've been hit by prop pox. For the second time in the three occasions I've had to develop a large city tile to around 100k inhabitants. Past the urge to throw my computer out of the window, I come here to report and offer my save game if anyone wants to have a look at it.
Here is a screenshot showing I'm not mistaking. I should also mention that the 1st time it happened, I did have the PEG beach original file in my plugins folder and some of its lots plopped. I've since modified the said file following the procedure detailed by bap, and none of it have been plopped in my new region so far anyway.
At that point, I might just obliterate the city and start over. I'll do some cleaning in my plugins, but I don't expect wonders down the road.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg210.imageshack.us%2Fimg210%2F7229%2Fscreengl.th.jpg&hash=e10d515f4429b8423d1ecef3ae95c16b31ecf700) (http://img210.imageshack.us/i/screengl.jpg/)
Click for full size.
Quote from: TiFlo on November 09, 2010, 08:01:50 AM
I found out last night I've been hit by prop pox. For the second time in the three occasions I've had to develop a large city tile to around 100k inhabitants. Past the urge to throw my computer out of the window, I come here to report and offer my save game if anyone wants to have a look at it.
Here is a screenshot showing I'm not mistaking. I should also mention that the 1st time it happened, I did have the PEG beach original file in my plugins folder and some of its lots plopped. I've since modified the said file following the procedure detailed by bap, and none of it have been plopped in my new region so far anyway.
At that point, I might just obliterate the city and start over. I'll do some cleaning in my plugins, but I don't expect wonders down the road.
Hi TiFlo.
Just to make it clear, did you started this new region -- struck by Prop Pox -- after of before modifying the BDK_resource file? Please remember that those props appear in Maxis low density R$ and R$$ lots even if no BDK lots where plopped in your cities. It would be good to be sure your most recent case of the pox is definitively not related to those props already identified as causing the problem.
If you upload a copy of your infected city to a file server and post the address here, I might find some time to have a close look at it this next weekend. From your picture, I gather that the affected city has about 19.000 disabled props, almost 10 per cent of all props in the city. The larger the number of disabled props, the most spread is the pox. I hope the corruption is not so profound that we might be able to recover the TGI info of the disabled props. These are the ones who lead to the Prop Pox afterall.
Cheers,
Bap
Hi bap, thanks for the quick reply.
To address your first concern, This new region was started with the already modified PEG file (I modified the file early this summer, and started the current region about a month ago). Also, as far as maxis R are concerned, I believe I have none of them since I use a maxis blocker for R, CS and I (the BSC one that's compatible with CAM). I'm pretty sure it works, as all the low R I can see are either mattb325's or CP's Early 19th Century.
As for the already big amount of missing props, my mistake was two days ago when working on the South-West corner of the city and having the game run at fast speed several times without going around to check things up. Then yesterday I opened the city, went working on the North-Eastern side of it and discovered the mess....
Link to my savegame file (http://www.megaupload.com/?d=I8MOP4DM). Let me know if I can do anything else.
Thanks again!
Florian
TiFlo, I studied the Prop Poxed version of your city with SC4Savegame. As I was afraid, the degree of corruption of the prop subfile was already so high that no useful information could be extracted from the disabled props. There is no way to discover which prop(s) specifically caused the pox in that city.
Before we proceed, let me introduce a couple of expressions:
1) A "Prop Pox free" city is one for which there is no disabled prop;
2) An "infected" city is one for which there are disabled props (stored at the end of the props subfile);
3) A "Prop Poxed" city is one in which the props subfile has been corrupted. This occurs when the prop subfile contains disabled props and has reached the 16Mby limit size.
As RippleJet already explained, a city becomes infected when lots with problematic props are destroyed or replaced by other lots (for example, when an R$ lot with the problematic beach umbrella in its backyard is upgraded to a R$$ lot). In this case, the program does not delete the offending prop, but stores is at the end of the prop subfile and marks it as 'disabled'. The first attached figure shows a prop pox free city, with no disabled prop. The second figure shows an infected city, with 127 disabled props stored at the end of the file. It is not prop poxed yet (but it will be when the prop subfile reaches the 16Mby limit). In the Prop Record View panel (lower right) one can see that they are marked as disabled (appearanceFlag with no 'visible' flag set) and all have the same IID 0x29000000 (the IID of the beach umbrella prop). Their record size (0x6C) is also different from the usual 0x58 record size of most (non-timed) props.
The third figure shows your prop poxed city. Of the 19515 disabled props in the non-corrupted section of the file, 65 are from T21 (instead of from lots). For all the others the TGI information is deleted. The Prop Record View shows the beginning of the sequence of disabled props. The appearanceFlag has no 'visible' flat set and the IIDs are all set to zero. In fact, the TGI addresses are all zeroed (inside lower right side red box). These deleted props were probably 'healthy' props which became deleted as a consequence of the spreading corruption.
From what was said above, the best chance we have to identify the prop(s) causing the pox in your city would be to recover a backup of that same city not long
before is got prop poxed. The offending props should be at the end of the prop subfile, marked as disabled props.
Hope this helps.
Bap
EDIT1: I got another idea. Instead of looking for a backup of the proppoxed city, you could load all other developed cities of your new region into SC4savegame and see if there are disabled props in any of these cities. One might expect that the one approaching the 16Mby prop subfile size would already be infected with disabled props at the end of their respective prop subfile.
EDIT2:
Quote from: FrankU on October 15, 2010, 03:27:30 AM
Sorry, but I don't understand.... Do you have any clue what might be wrong or not? Is there anything I can do? Do you want me to send you the second poxed city in that same region?
FrankU, the same idea of the EDIT1 above applies to your case. Maybe the answer to your questions is laying as a group of disabled props at the end of the props subfile in one of the developed (but not yet prop poxed) cities in the same region. If you do have the SC4Savegame tool, I would suggest you scan other large city tiles in that region in search for cities with reported disabled props. If you don't have that program and you do wish to help, you might consider uploading your most developed unpoxed city of that region in a file server, and I may have a look at it.
I just find this thread (at the top of the page... I need new glasses) So I copy my post here too from 'The Prop Pox' topic.
I have several questions
I'm working on a realistic nightlight mod based on Light Replacement Mod v3 by mrtnrln. See thread http://sc4devotion.com/forums/index.php?topic=12101.0
During thinking on how to insert light poles and cones into stoplights I found it probably will cause prop pox. It would require changing the stoplight prop from ResKeyType1 to 4, which means different prop length. If I understand well, that can cause prop pox. Can somebody confirm it?
Furthermore. I read through this thread and what I understand about prop pox, any change in the prop length can cause prop pox. This means, that the LRM v3 already can cause prop pox, because it directly replaces maxis streetlights with new models, and the new props many time have different amount of data in ResKeyType4 line.
Am I right, that any replacement type mod is a potential source of prop pox? What should I do, if I know, that my mod will inherit prop pox from LRM v3?
Quote from: kodlovag on December 03, 2010, 07:48:46 AM
During thinking on how to insert light poles and cones into stoplights I found it probably will cause prop pox. It would require changing the stoplight prop from ResKeyType1 to 4, which means different prop length. If I understand well, that can cause prop pox. Can somebody confirm it?
Changing it from RKT1 to RKT4 is not a risk. It becomes a risk only if you're adding or changing the type of timing for the props.
Quote from: kodlovag on December 03, 2010, 07:48:46 AM
Furthermore. I read through this thread and what I understand about prop pox, any change in the prop length can cause prop pox. This means, that the LRM v3 already can cause prop pox, because it directly replaces maxis streetlights with new models, and the new props many time have different amount of data in ResKeyType4 line.
Am I right, that any replacement type mod is a potential source of prop pox? What should I do, if I know, that my mod will inherit prop pox from LRM v3?
The difference of length is not the length in the prop exemplar (that's a mistake I think
bap also made in the beginning, and is probably still mentioned in his posts), it's the difference in length once it's saved in the savedgame (*.SC4) file. Only differently timed props lead to these differences in record lengths.
Quote from: RippleJet on December 04, 2010, 06:06:03 AM
The difference of length is not the length in the prop exemplar (that's a mistake I think bap also made in the beginning, and is probably still mentioned in his posts), it's the difference in length once it's saved in the savedgame (*.SC4) file. Only differently timed props lead to these differences in record lengths.
Thanks RippleJet for the quick reply. I must take some time of my vacations to reorganize this thread (maybe combining the 4 initial messages into one explanatory message that would show up at the top of every page). That would be a good time to remove some old ideas that we later learned are not correct (i.e., about the size of the prop exemplar being relevant for prop pox).
On the other hand, my last experience with poxed cities suggest that the problem may not be with the size of the prop registry at the savegame itself. I closely followed the development of an infected city until it was finally poxed. I though that one would have been cleared because (i) I recovered a backup copy of the city in which all records of the 4 offending props were of normal size and (ii) it was being developed after I corrected the BDK file that leads to prop pox. In that backed up copy of the city, all beach umbrella had 0x6C size records and all recliner, beach chair and patio chair had 0x58 size records. However, there were 41 records of recliner+beach+patio props left in the savegame file with the conditional appearance flag set to 'HourTimedProp', indicating these were remaining modded versions of the props. As their lots were progressively replaced in game, these modded props all became 'disabled props', dumped at the end of the prop subfile. When the prop subfile reached the 16Mby size, the city became prop poxed. At that point 38 of the 41 modded props were already disabled (with a normal 0x58 record size). That was enough to cause the problem. (I realized I had to go even farther in the past to find a really non-infected version of that city; I fortunately had a previous backup which is indeed free from the props which cause the pox ;); the city is doing fine now :D)
Thus, just underscoring what RippleJet said above, if one wishes to avoid creating a cause of prop pox, please do not change the type of timing of an existing prop. Maxis code doesn't like that. And every time a lot containing one of these modded props is deleted (or a piece of a road is destroyed, if the modded prop is a T21 prop), the offending prop will become disabled and will be dumped at the end of the prop subfile, leading to prop pox when that file reaches the 16 Mb size.
Thanks for the info.
I have been hit by what I assume is the "pox" and following a very long read of this thread. My region is showing all the symptoms and it just breaks my heart knowing that I have lost a region that I have been working on for the last 6 months try to create a city metropolis; but then that is just the way it is.
Now before I go off and start something new could I please ask the knowledgeable folk here a few questions;
- Is it only limited to large cities - the poxed one was a 3x4 large city region
- Must the lots with the dodgy props be plopped or is it enough that they are just in the plugins folder - reason I ask is that the first city to be hit with the pox was land-locked and none of those props would have been in use and much the same with the second and third.
Thanks in advance.
Quote from: TownMaster2005 on December 25, 2010, 12:52:11 PM
- Is it only limited to large cities
Yes, you could say so.
The most common size of a prop record is 88 bytes, and the next common one (for timed props) is 108 bytes.
To get the prop subfile up to the size of 16 MB, would require some 190,000 props in a single city.
In a large city, 256×256 tiles = 65,536 tiles, 190,000 props would mean almost 3 props per tile. Fully achievable...
It's also worth noting that low-density growable lots usually have a lot more props per tile than large skyscrapers.
In a medium city, 128×128 tiles = 16,384 tiles, 190,000 props would mean almost 12 props per tile.
That's on an average... and very few lots would have that many props.
Thus, the chances of getting prop pox in a medium sized city are close to none.
In a small city, 64×64 = 4,096 tiles, you'd need 46 props per tile in order to being at risk of getting the pox.
That risk is negligible! ;)
Quote from: TownMaster2005 on December 25, 2010, 12:52:11 PM
- Must the lots with the dodgy props be plopped or is it enough that they are just in the plugins folder
It's enough to have them in your plugins folder, since those props are modified Maxis props, and Maxis did use those props on a lot of their own lots.
There are lots of ingame low-stage residential lots with pools, and thus, recliner chairs and beach umbrellas in their backyards.
RippleJet, thank you very much for your prompt reply and it explains why inland cities are nailed as well.
I suppose this mean that we all need to seriously think about how we design our regions and cities.
Well, as they say in the trenches; "onwards and forward". I am going to make the changes suggested and with using only the large city for the big lots I will see how it all plays out.
Keep up the brilliant work you guys.
All the best for 2011.
Quote from: z on April 06, 2010, 10:12:27 PM
You can completely get rid of the pox any time you want... temporarily. Here's how:
1. Open your saved city in Ilive's Reader.
2. Sort the left pane based on file size, with the highest at the top.
3. Near the top, there will be a subfile of type 2977AA47. This is the prop subfile. Delete it.
4. Also delete the subfiles of type 6A0F82B2 and 6990C1AA, which are also near the top. These subfiles are regenerated as needed. If you don't delete them, this process will still work, but your city size will increase greatly each time you repeat this process.
5. Save the city file.
6. Start up the game, but don't open the city file.
7. Open the Graphic Options, and make sure the City Detail is set to Low.
8. Open your city and save it immediately.
9. Exit to the region without saving.
10. Open the Graphic Options, and change your city detail to High.
11. Open your city. All your props should be restored.
12. Save your city. Your props will all be there... for a while.
I just tried this, and it worked, but for one thing I immediately noticed: all the automata from my city (except the police helicopter) were gone. I checked the route query for a few avenues that were previously heavily used, and found that they had absolutely no traffic on them. I then checked the traffic volume graph and found that all traffic in my city was at zero (although residences that did not previously have a "no job" zot over them remained in working order, no abandonment due to commute time for them). I waited a few game-months, and found that traffic was returning to my city, but only in the form of cars and pedestrians; no mass transit usage. Then I saved and exited to region and then reloaded in hopes that traffic would be back to normal, but found that the prop pox was back, not in the northwestern corner of my city, but rather in the southeastern area.
So here is my question: will z's method that I quoted allow one to perform the method, correct/remove problem props in iLive Reader, and then run the city without the prop pox if the cause in one's plugins has indeed been fixed? Or does the city file remain "infected" after performing z's method, as in it will still eventually get poxed?
I just recently got the prop pox in this city (I deleted it the last time it got the pox); I thought (or rather hoped) that after I re-started the prop pox wouldn't affect it anymore, since I edited the BDK resource file like Bap said to do in the original post and removed the bad prop exemplars. Apparently, though, I have another cause of the prop pox in my plugins folder, so after getting it in this city earlier today I removed a bunch of prop exemplars from PEG_TrailPark-Engine_305a.dat which were modified versions of the maxis originals with the same ID, having more properties added to the exemplars and thus increasing the file size.
Quote from: Moonraker0 on January 05, 2011, 07:11:18 PMOr does the city file remain "infected" after performing z's method, as in it will still eventually get poxed?
This is correct. Unless someone finds a way to edit the save files and preserve their integrity, you cannot "undo" the infection of prop pox. The quoted method simply removes the effect temporarily, but it will return when the compress/expansion condition recurs. This is why there is considerable emphasis on finding all causes where possible. Unfortunately the event is fairly uncommon and when it does occur it is rare that there is enough data to make further conclusive investigations. The only way you can "recover" is if you have a save file which is from before the first instance of the infected save/delete event.
Quote from: Moonraker0 on January 05, 2011, 07:11:18 PM
I just recently got the prop pox in this city (I deleted it the last time it got the pox); I thought (or rather hoped) that after I re-started the prop pox wouldn't affect it anymore, since I edited the BDK resource file like Bap said to do in the original post and removed the bad prop exemplars. Apparently, though, I have another cause of the prop pox in my plugins folder, so after getting it in this city earlier today I removed a bunch of prop exemplars from PEG_TrailPark-Engine_305a.dat which were modified versions of the maxis originals with the same ID, having more properties added to the exemplars and thus increasing the file size.
Moonraker0, if you wish to help, you might consider uploading your most developed unpoxed city of that region in a file server, and I may have a look at it. If this city is also infected by the pox, the culprits should be laying at the end of the savegame prop subfile as disabled props and we should be able to identify them using Wouanagaine's SC4Savegame program.
@bap: I think that I have solved the prop pox in this city. There were corrupted IIDs of props at the end of the file when I looked at the poxed version of the city. The only backup I have of that city was from before it was infected at all, which led me to believe that the source of the prop pox was very recently added to my plugins, although as there were no disabled props in the uninfected file I can't be sure. My belief is that the pox virus may have appeared when (during that time period between the uninfected backup and the poxed city file) I upgraded the Hong Kong Peninsula Hotel to the new version that was released then; as the description didn't say anything about bulldozing, I kept the lots of that building in that city when I upgraded it, but the buildings (which are timed-over-year props) on the lots disappeared and I couldn't query the lots. I think that it's possible that this incorrect method of upgrading may have caused the prop pox. I routinely check that city file in SC4Save and there are still 0 disabled props in it as of now.
Unfortunately, I just got the prop pox in another city in a different region. I knew I would eventually, as the bad BDK props were in the city file as disabled props when I checked, and I had no earlier backup to go back to. I have made backups of that city about every other day for the past week or so, and when it got the prop pox I checked the city file in the backup I made yesterday. It had 62 disabled props, all of which are the four bad PEG-BDK props. I checked the first backup I had of the city and saw that it had only 6 disabled props, which were also only the BDK ones. The thing is, after I made that first backup, the BDK props were deleted from the BDK Resource file, following the instructions in one of your early posts in this thread. I thought that this would cause the 6 disabled props to stay in the save file, but no further ones should appear. Is it normal for the number of disabled props to increase after the cause has been fixed?
In any case, I have created a folder at MediaFire containing the save files in question here (http://www.mediafire.com/?vogc3mq5bklja). The Ternes files are the only ones that will probably be of any use to you. The file City - Ternes.sc4 is the infected one with the 62 disabled BDK props. The file City - Ternes.sc4.poxed is the version where the prop pox appeared. The file Ternes.sc4.bak is the earliest backup I have, the one with the 6 disabled props.
Moonraker0, if you read carefully through this thread, you will find that the appearance of "prop pox" and whether or not you have "the infection" are two totally different events. The thread will explain what appears to cause it, why it seems to cause it, and more importantly when it shows up.. your description above would suggest to me that you have not read through these issues. It is likely that you have had the infection for a very long time even though it only shows up very "late in the game" in terms of what shows up in your city(ies).. in many cities it will never show up, even though they "have the pox" .. the save file size has to get quite large.,.. many if not most players rarely play a city to that size, so they never even notice it.
Hello All,
Thank you for all of your efforts. I recently reinstalled SC4 and started to rebuild my plug-ins. Luckily the dependencies I needed from SG and other hrer had no links to the file in question.
I thought I had backed up my old plug-in zips somewhere. I had downloaded every full reference CAM (the original reference downloads not just models) and anything I found interestting. If I can find the dvd, is there anyway to know if I have found an old enough file that you might want to search?
EDIT:
Question, In the search for other causes, is it believed to be limited to an old dependency pack of some sort or a BAT or Lot? If an old pack, is it possible the offending pack has already been updated? I would think STEX would be a primary place to start. I would hate to start a new region and find an old lot still available on the STEX or other places that I had backed up or find an old one now that I liked without knowing if it might possibly screw it up later.
Thanks again,
Flash
@SC4BOY: Yes, I know that they are different events, as described in bap's post on the previous page. I believe I described the stages of prop pox accurately in my previous post according to bap's definitions. I spent this evening reading the remainder of the thread, though (I had about half of it down before today). I thought I wouldn't get the prop pox anymore, but once again I have been proven wrong about that, as I have just today experienced it in another city in a recently started region. I seem to have a knack for making cities with enough props to get the pox. This city is almost all high density, but only about half of the tile is covered with development. When I first noticed the prop pox, I immediately exited without saving and looked at the prop subfile in SC4Save. The strange thing was that even in this poxed city, SC4Save reported 0 disabled props and "prop pox free city". I loaded the city again in the game and, after making a backup of the first poxed version, I saved the city again. This new version has 35845 disabled props, although it is still reported as "prop pox free". I looked at a few of the IIDs for the disabled props at the end of the list, and they just appear to be random Maxis props (upon examination in Reader of those IIDs), and not anything that any single mod I know of would be modifying. Bap did say a few posts back that it was bad if the IIDs in the poxed save file were corrupt, so is this a good thing that they're apparently intact here? Or are these seemingly random props just misleading IIDs because they are actually corrupt? If this save file is useful to bap or anyone else, I did upload it to my Mediafire folder (http://www.mediafire.com/?vogc3mq5bklja) with the poxed city files. The file "City - Kowloon.sc4" is the newest one, when I saved it again after getting the prop pox and SC4Save first reported all those disabled props. The file "City - Kowloon (Poxed).sc4" is from right when I started seeing the prop pox, even though no disabled props or prop pox were reported in SC4Save.
I just checked out the links bap made to Riquelandia (to try testing for prop pox myself), but they all seem to have been broken by Fileden changing its link structure; they all redirect me to http://www.fileden.com, with seemingly no way to get to the file I am looking for.
Quote from: Moonraker0 on January 29, 2011, 08:59:34 AM
I just checked out the links bap made to Riquelandia (to try testing for prop pox myself), but they all seem to
have been broken by Fileden changing its link structure; they all redirect me to http://www.fileden.com, with
seemingly no way to get to the file I am looking for.
I just tried to login at fileden withou success. I get this message at their homepage, though:
"We are currently experiencing a technical problem with a portion of our storage cloud, some files cannot be
accessed. We expect this issue to be resolved in the next few hours, your files are safe. Apologies for any
inconvenience caused!'
So, in principle, it is a temporary problem with no loss of data &mmm . If they don't solve it in the next
couple of days you may send me a PM and I will send you the proper files by email (12 Mby after
compression with rar).
Quote from: Moonraker0 on January 15, 2011, 06:30:03 PM
Unfortunately, I just got the prop pox in another city in a different region. I knew I would eventually, as the
bad BDK props were in the city file as disabled props when I checked, and I had no earlier backup to go
back to. I have made backups of that city about every other day for the past week or so, and when it got the
prop pox I checked the city file in the backup I made yesterday. It had 62 disabled props, all of which are the
four bad PEG-BDK props. I checked the first backup I had of the city and saw that it had only 6 disabled
props, which were also only the BDK ones. The thing is, after I made that first backup, the BDK props were
deleted from the BDK Resource file, following the instructions in one of your early posts in this thread. I
thought that this would cause the 6 disabled props to stay in the save file, but no further ones should appear.
Is it normal for the number of disabled props to increase after the cause has been fixed?
This procedure will only prevent you from getting Prox Pox in
new cities started
after correcting the
BDK resource file. Since the city you mention was a developed one, it might well have already been infected
(although the appearance of the Pox might occur much later on). Every Maxis low density residential lot with
a beach chair, umbrella, recliner or patio chair in their backyard that grew in your city while the problematic
props were in your plugins file infected it with the Pox 'virus' -- hundreds of them can grow in a few simyears
of enthusiastic mayor zoning :( . Once they are there, it is usually a matter of time for the lots they are part
of to be destroyed/upgraded for them to become disabled -- even if the problematic props are no longer in
your plugins folder ...
[ At this point, a palliative measurement could be to identify all lots containing the suspicious props and mark
them as historical, so none would be further destroyed/replaced. I attached a small virus-detect dat file at the
end of this message that helps with this approach. It simply turns all occurrences of the 4 suspicious props
into brown boxes, so the mayor can easily recognize them in game. After you mark all infected lots as
'historical', the virus-detect file can be removed from the plugins folder (and sims will stop complaining 'what
the hell this mayor did to my backyard beach chair?'). But even this may be useless if some of these props
already became disabled. ()sad(). Alternatively, this file helps you gauge the size of your problem. If a few
brown boxes appear in the city it may be that none of the props became yet disabled and you may get around
by 'historicalyzing' all few infected lots. On the other hand, if you see a forest of brown boxes &ops ... better
go off for a bier. ]
I will have a look at the Kowloon savegame files and will report back soon.
EDIT: I login at Fileden and updated the new url addresses for the Riquilandia files. However, the links still do not work. Will wait a couple of days to see if the site goes back to normal.
I solved, (fingers crossed) my prop pox problem long ago by removing PEG-OWW2_BDK. I understand that there are other known culprits. Is there a list somewhere? Should this list be included in the "How to Avoid the Problem" section at the beginning of this thread?
Quote from: dahemac on February 04, 2011, 05:15:59 PM
I solved, (fingers crossed) my prop pox problem long ago by removing PEG-OWW2_BDK. I understand that there are other known culprits. Is there a list somewhere? Should this list be included in the "How to Avoid the Problem" section at the beginning of this thread?
dahemac, unfortunately there is no such list yet. The only confirmed source of Prop Pox still is the BDK-resource file. The conclusion that there must be at least one other source comes from the fact that the first players infected by Prop Pox report the problem in cities build before the release of the above culprit package. However, we were not yet successful in finding these other specific props, mostly because the first infected players were not aware of the problem until their cities became irremediably corrupted, at a stage where it is no longer possible to recover the IDs of the offending, culprit prop(s).
On the other hand, the fact that all recent cases of Prop Pox can be associated to the BDK-resource file suggests that the older cause(s) of the problem may no longer be in use by players, perhaps because the associated files may have either been superseeded, retired or upgraded. (I hope this also answers the questions raised earlier by
Flash).
My only city to get infected with the pox (at the time I didn't realize that's what I had) was after I had downloaded Pegasus's Beach replacement lot, this was years ago and I no longer have the zip file, but from memory it was a replacement to the Maxis beach and had a lot of timed props (which is why I downloaded it as I was doing an Island at the time and it looked a lot nicer than the Maxis beach).
I would have downloaded it from the STEX and I have just gone thru all of Pegasus's stuff on the STEX and its gone, there is just his BDK files now.
Quote from: catty on February 05, 2011, 01:54:59 PM
My only city to get infected with the pox (at the time I didn't realize that's what I had) was after I had downloaded Pegasus's Beach replacement lot, this was years ago and I no longer have the zip file, but from memory it was a replacement to the Maxis beach and had a lot of timed props (which is why I downloaded it as I was doing an Island at the time and it looked a lot nicer than the Maxis beach).
I would have downloaded it from the STEX and I have just gone thru all of Pegasus's stuff on the STEX and its gone, there is just his BDK files now.
Peg now has the entire catalog at Simpeg productions. You will have to register for the PLEX though. (and BTW I love Terry Pratchett, great sig!)
Quote from: Kcrimsonsim on February 05, 2011, 07:07:51 PM
Peg now has the entire catalog at Simpeg productions. You will have to register for the PLEX though. (and BTW I love Terry Pratchett, great sig!)
Its not on the PLEX either, but I did find the old support topic for it started in January 2004
http://www.simpeg.com/forum/index.php?topic=230.0
QuoteChanges From Previous Version:
1. This new beach now replaces the original beach in the Parks Menu.
2. This new beach is easier to place than the original beach.
Lot Description:
----------------
Although this replacement for the beach has some visual enhancements over the existing beach, its primary purpose is to eliminate the existing beach which uses a horrendous amount of system resources. If you are experiencing notable performance problems on a fairly adequate or better computer, then the cause is most likely the use of beaches in your cities.
Removing all the beaches will solve your performance problem. Replacing them with this new beach will keep your cities looking spiffy... and give the area a slightly improved YIMBY as well.
This new beach is easier to place than the original beach. It will tolerate a slightly greater degree of slope and is more flexible concerning its placement along the shore. This new feature should make replacing existing beaches easier as they where prone to alter the terrain when placed, prohibiting replacement..
Plop costs and monthly maintenance fees have been increased slightly... as has the park effect. The beach also now draws a bit of electricity to power the lights. All these modifications are very minimal.
Special Things to look for:
1. A film crew may occasionally show up to film their lead story for the five o'clock news.
and this from May 2004
QuoteMy material is currently unavailable as it is being updated for release on the new exchange. Older lots are being transit enabled, props and textures updated, etc... I have been working on the beaches attempting to rid them of the water graphic bug... with little success so far I'm afraid.
I can't find any information on when it was released after this date and what changes were made to it, but it must have been as I know I downloaded it from the STEX sometime in 2007
:)
Guess what: my most populated city I've ever made is now affected by the Prop Pox, just when I decided to make an update for my MD :(. I used Z's method to restore the city's props (which actually didn't restore my T21s), and all traffic suddenly drops to zero (I believe other people have ran into this problem too), reducing my city's population from 675K to only 389K. Fortunately I have backed-up my Poxed city, in case something went wrong, like this...
The oddest thing is I have at least two cities with filesizes larger than 30 MB that don't have the Prop Pox. It's the first time it occured to me and I hope it will be the last time...
EDIT: I might have an idea which prop caused the prop pox to appear, since I didn't used it in my city before. Before it occured, my city save-file was way over 16MB without any problems. Now it suddenly appears. This may be the only way to un-infect the city...
Best,
Maarten
Sorry for the double-post, but I have some great news: I've succeed to completely UNDO the Prop Pox! What did I do:
- I opened the city affected by the Prop Pox while having the city details set to low.
- I demolished the LOTs with the props causing the Prop Pox to appear initially. (This is the most important step). In my case, it was one set of my experimental ploppable median lights that caused the problem.
- I saved the city and exit to region.
- I changed the city detail settings to high again.
- And guess what: the Prop Pox vanished! And I'm happy again :)
Best,
Maarten
Quote from: mrtnrln on February 26, 2011, 07:04:37 AM
EDIT: I might have an idea which prop caused the prop pox to appear, since I didn't used it in my city before. Before it occured, my city save-file was way over 16MB without any problems. Now it suddenly appears. This may be the only way to un-infect the city...
It's not the city save file that needs to be over 16 MB, it's the prop subfile within that file.
And that file you can only see by Reader or
Wouanagaine's
SC4 Savegame Explorer (http://sc4devotion.com/csxlex/lex_filedesc.php?lotGET=2021).
Quote from: mrtnrln on February 26, 2011, 08:40:48 AM
- I demolished the LOTs with the props causing the Prop Pox to appear initially. (This is the most important step). In my case, it was one set of my experimental ploppable median lights that caused the problem.
What did you do in those experimental lights?
Quote from: mrtnrln on February 26, 2011, 08:40:48 AM
- And guess what: the Prop Pox vanished! And I'm happy again :)
I certainly hope so, Maarten. Let us know what happens in he future when you keep playing that city.
Quote from: RippleJet on February 26, 2011, 01:51:21 PM
It's not the city save file that needs to be over 16 MB, it's the prop subfile within that file.
And that file you can only see by Reader or Wouanagaine's SC4 Savegame Explorer (http://sc4devotion.com/csxlex/lex_filedesc.php?lotGET=2021).
Well, when your file size drops from 60MB to only 15MB, then there must be something wrong.
By the way, there may be something about the 16MB filesize 'limit'. 16MB is exactly 2
24 bytes, and therefore 2
32 bits. Since most current systems are 32 bit, it may have to do with allocation. But this is just a wild guess ;)
Quote from: RippleJet on February 26, 2011, 01:51:21 PM
What did you do in those experimental lights?
Nothing out of the ordinary to me. But maybe I did something wrong, because all other 13 sets don't cause any problems. I'll check the prop descriptiors again for error...
Quote from: RippleJet on February 26, 2011, 01:51:21 PM
I certainly hope so, Maarten. Let us know what happens in he future when you keep playing that city.
I'll sure do. At the moment, it seems that my problem's solved, and all my props (a significant ammount, since it affected about
1/
6 of all my props on the map) are back.
Best,
Maarten
I got the Prop Pox again.
Infected city:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg820.imageshack.us%2Fimg820%2F3223%2Fpox2.jpg&hash=d9570bc6749c44693b595e39984ccc298e8d8d64)
Pox-free backup from a month ago:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg684.imageshack.us%2Fimg684%2F4765%2Fbackupunpoxed.jpg&hash=d4a7e11a2ae4a64e5084739870accac0155e0dfa)
Isn't there something odd?
A month ago: not compressed, Pox free
now: compressed, poxed
()what()
Quote from: RickD on February 28, 2011, 03:01:15 PM
Isn't there something odd?
A month ago: not compressed, Pox free
now: compressed, poxed
Not really anything odd with that... (unfortunately) :(
When your city grows, lower stage lots are replaced by higher stage lots.
Lower stage lots are those which contain the largest number of props (per tile).
Thus, when you city grows upwards (and not horizontally), the number of props actually drops.
And, as you can see, the uncompressed size of the prop subfile is now just under 16 MB.
Any time the size of the prop subfile is under 16 MB, it will be compressed.
And, as we've seen the prop pox may appear whenever that limits is crossed
(probably regardless whether the size goes from below to above 16 MB or v/v).
All depending on whether one of the known props was erased during that crossing of the limit.
That makes sense. But does that also mean that my city (the backup) will be safe as long as I keep the number of props high?
I retraced what I did to my plugin folder in the past weeks and the only big thing I did was removing some street mods (Jeronij's or SFBT street side mod, Peg's Avenue Mod, the Light Replacement Mod). When I run the city without doing anything it will be pox free (at least for a few years). But as soon as I use the road tools and click on existing roads (thus probably deleting the props of the removed mods?) the pox break out.
When I put the mods back in and click on the roads: no pox. But I have not done any long term testing yet. Only let the city run for a few game years.
I am sure I removed the known props when I started this tile from scratch. Maybe one of them got back in somehow.
Quote from: mrtnrln on February 26, 2011, 08:40:48 AM
Sorry for the double-post, but I have some great news: I've succeed to completely UNDO the Prop Pox! What did I do:
- I opened the city affected by the Prop Pox while having the city details set to low.
- I demolished the LOTs with the props causing the Prop Pox to appear initially. (This is the most important step). In my case, it was one set of my experimental ploppable median lights that caused the problem.
- I saved the city and exit to region.
- I changed the city detail settings to high again.
- And guess what: the Prop Pox vanished! And I'm happy again :)
Best,
Maarten
So you found the cure? Congrats!! &apls &apls &apls &apls &apls
QuoteI demolished the LOTs with the props causing the Prop Pox to appear initially.
Good for you, but personally for others, it seems like anyone figuring what the Lots are that initially cause this seems challenging. However though, I must &apls you for defeating the deadly pox.
Quote from: mrtnrln on February 26, 2011, 08:40:48 AM
- I demolished the LOTs with the props causing the Prop Pox to appear initially. (This is the most important step). In my case, it was one set of my experimental ploppable median lights that caused the problem.
Quote from: RickD on February 28, 2011, 11:48:39 PM
I retraced what I did to my plugin folder in the past weeks and the only big thing I did was removing some street mods (Jeronij's or SFBT street side mod, Peg's Avenue Mod, the Light Replacement Mod). When I run the city without doing anything it will be pox free (at least for a few years). But as soon as I use the road tools and click on existing roads (thus probably deleting the props of the removed mods?) the pox break out.
When I put the mods back in and click on the roads: no pox. But I have not done any long term testing yet. Only let the city run for a few game years.
Is there a connection here, or am I just trying to make one? :-\
I was just about to ask.. Just downloaded the LRM a few minutes ago and there is a bunch of changed rkt4 exemplars with old Maxis IDs in there... &Thk/(
Hi all!
I have a question :
Several of my cities from my old region are infected. I am ready to rebuild a few of them from scratch but I would like to keep the terraforming I did on the tiles. Would using the "Obliterate city" function clean the save files and prevent reappearance of the prop pox provided that I cleaned my pluggins of any problematic files?
Joel
^ "Obliterate city" would do the job, at least in my experience.
Quote from: vil on March 07, 2011, 02:43:17 AM
I was just about to ask.. Just downloaded the LRM a few minutes ago and there is a bunch of changed rkt4 exemplars with old Maxis IDs in there... &Thk/(
Only one particular set caused problems, but the other sets don't cause any problems.
I have to say that my solution only solves one quite easy to track problem. There probalbly multiple, complex causes for the Prop Pox. I just got the luck that mine was very easy to solve...
so since new posts popped up since I started editing my previous post, I deleted it and post anew here.
disregard the previous post of mine.
looks like I was a little too fast at reading this thread.
now, I stand corrected, posting my "newer" thoughts.
from 95 more or less developed city tiles all under the same plugin setup (as I sort them by necessity for the used region), 1 is infected and 2 others are poxed. everything else is pox free per bap's definition a few pages back. Development is suburban sprawl style with LOADS of low density buildings, about 90% the huston style medium wealth to precisize it, needless to say I am literally splattered with props so crossing the 16mb threshold is mandatory rather than optional in many cases.
curious tho, the region was started prior to my findings of what prop pox is, thus prior to what bap does suggest to alter in terms of peg's files, but definitely they were on board. A rough estimation is this region is 3-4 years old, my learning of bap's findings occured much later.
so basically this would mean that I am bound to be poxed sooner rather than later.
As I learned from the previous pages, sc4 save is considered a sureshot in terms of identifying the 3 states of pox free, infected and poxed, that's why I ran all cities through it, one by one.
What lead me even further into confusion, as one of the poxed cities is available in a backup file which is according to sc4save, not poxed and not infected (namely 0 disabled props, no poxed warning). the prop file is well beyond 16mb in this "clean" version.
So both the infection and the outbreak must have happened later on. Only changes to it tho are as recent as within the last fortnight, when I demolished quite some parts and the prop file dropped well below 16mb. I guess same accounts for the other poxed city, I did some minor changes but have lots of midrise buildings, many of which are grown C$$, so there was in fact a growth circle as explained earlier. As the prop file is just below 16mb, I guess once more the reason is in crossing the threshold backwards, keeping in mind that other cities positively crossed the threshold and stand unaffected according to sc4 save.
Cross searching the web led my to simforum.de where diggis is cited with a probable solution similar to the one Z named here.
I tried this and the prop files in both poxed cities doubled in uncompressed size, thus positively crossing the 16mb threshold again. Still poxed according to sc4 save tho, but at least for one saving process, all props remained visible.
This got me back at the beginning of not knowing anything as it pretty much contradicts my previous findings, albeit they are not wrong either.
a quick resumé wont hurt here, stating the relevant points:
- according to bap's findings, my beloved region WILL attract the pox, since editing out his findings happened after starting the region.
- one poxed city is available in a completely clean state beyond the 16mb threshold
- same city became both infected and poxed within the last fortnight, allegedly by negatively crossing the 16mb threshold
I did some further investigating, leading me even further into confusion, as I gave the virus detector thingy a shot and came up with my entire region being splattered with the affected props (no big deal testing, know the state of one, know the state of all as all the same tilesets, thus same buildings all over the place... like I said, suburban sprawl). Now keeping in mind previous findings, once more I wonder why most cities, holding the named props, being beyond 16mb prop file, and old enough to be started prior to editing peg's files are technically clean. I bet, once I negatively cross the threshold, they'll be affected aswell.
What I did now was creating a new region, same plugin setup, fired up a large city, zoned it entirely in sprawltype manner just like my main region, let it develop till it crossed the critical threshold and checked the save file. No corruption.
Then I bulldozed to drop below the critical value, checked the new save... and to my surprise, I was not able to reproduce my previous observation of the pox striking me on negative crossing of the threshold. Not even on multiple attempts I wasn't (luckily the game can run on it's own most of the time so I could do other things, took quite some time to test this).
So, applying this finding to my above mentioned city, it wasn't the threshold crossing either that triggered the pox.
Now all that seems to be left to think about is what I did to the city in between the uncorrupted backup and the corrupted current state. If it wasn't for the deleting work, it must be for the plopping work.
But also here, testing of the relevant files (luckily it was just 2 sets of puzzlepieces) I used turned out to be no factor to the pox either.
So, long story short, I have a clue of being poxed due to peg's - despite the malicious outturn still considerably good - creations, but the outcome is rather random than predictable. For me at least.
Now I think of making a bunch of screenshots and restarting the 2 poxed and 1 infected city tiles from scratch... or abandon years of work completely as there's no definity cure to the disease, just a work-around to surpress the symptoms. That said, can I actually, thinking of my above mentioned testing phase and it's apparent results, consider an obliterated and then rebuild city tile as more or less safe from pox, or would it be in vain to try it?
Another point, aiming at really getting rid, some of the earlier pages suggest to extract several prop files from the games root data and making them zzzz thingy plugins so they load after probably affected lots.
Did anyone actually follow this idea already? From my logic, the game loads it's basic content, then the plugins, overruling the games content if necessary by simply being loaded afterwards. Now if someone would go ahead and, again, overrule the relevant props by a zzzz plugin with the maxis standard values, shouldn't this mean that at least for altered maxis content, the cause of prop pox would be eliminated? If I had the time, I would give this a shot myself as I did something similar for a modd related to grass textures which I presented over at the Simtropolis so I do at least hold the basic knowledge fiddling around with the reader to do so, but unfortunately I'm in the hot phase of ATPL exam preperations so if there's one thing I have even less than money, it's time :(
Another, totally head-in-the-clouds idea that crossed my mind, but I guess this wont be possible both for legal and coding issues, is to force the game to stop messing around with compression. From what I learned until now, there seems to be a strong correlation between the outbreak of the pox and the game's urge to fiddle around with compressed data. I don't get the point of compressing small files but not compressing large files anyway.
GMT, thanks for your detailed post and testings.
Quote from: GMT on March 12, 2011, 12:47:14 PM
from 95 more or less developed city tiles all under the same plugin setup ... 1 is infected and 2 others are poxed. everything else is pox free per bap's definition a few pages back. Development is suburban sprawl style with LOADS of low density buildings ... needless to say I am literally splattered with props so crossing the 16mb threshold is mandatory rather than optional in many cases.
curious tho, the region was started prior to my findings of what prop pox is, thus prior to what bap does suggest to alter in terms of peg's files, but definitely they were on board ... so basically this would mean that I am bound to be poxed sooner rather than later.
As I learned from the previous pages, sc4 save is considered a sureshot in terms of identifying the 3 states of pox free, infected and poxed, that's why I ran all cities through it, one by one.
What lead me even further into confusion, as one of the poxed cities is available in a backup file which is according to sc4save, not poxed and not infected (namely 0 disabled props, no poxed warning). the prop file is well beyond 16mb in this "clean" version.
So both the infection and the outbreak must have happened later on. Only changes to it tho are as recent as within the last fortnight, when I demolished quite some parts and the prop file dropped well below 16mb. I guess same accounts for the other poxed city, I did some minor changes but have lots of midrise buildings, many of which are grown C$$, so there was in fact a growth circle as explained earlier. As the prop file is just below 16mb, I guess once more the reason is in crossing the threshold backwards, keeping in mind that other cities positively crossed the threshold and stand unaffected according to sc4 save.
For the following discussion I will assume the cause of your Prop Pox are the 4 props defined in Peg's BDK-resource file. Given that, in order to get Prop Pox
your city needs to meet all three following conditions:
1) low-density R$ or R$$ residential lots
must grow in your city
while the (unmodified) BDK-resource file is in your plugins folder. It does not matter if you remove the BDK-resource file after a while. All such lots grown while the BDK-resource file were in your plugins folder might lead to Prop Pox at some point in the future; (As you figured out by using the virus detector file, it seems you have loads of residential lots with possibly affected props)
2) at least
some of your affected lots must be replaced (upgraded by the game simulator with a higher wealth lot, or directly demolished by the Mayor). When a lot with an affected prop gets replaced, the offending prop becomes disabled (at this point we call the city 'infected');
3) the props subfile must
reach the 16Mby limit from below, i.e., it must fill the 16 Mby buffer set for compression for Prop Pox to finally appear.
By demolishing a sizeable fraction of your city you probably deleted several lots with affected props (all of which became disabled) and you also reduced the prop buffer below the 16 Mby limit. Any further development which brings this buffer again above the 16 Mby limit leads to Prop Pox as now it contains disabled props. So, it is not crossing the limit backwards which drives Prop Pox, but it is crossing it again forward when it contains disabled props.
It is possible to go beyond the 16 Mby limit without getting Prop Pox. All you need is no disabled props. And this can be achieved by preserving the offending lots from being replaced. This sets up an interesting way around of being infected: set all offending lots as historical. (you need to find them all, and you must do it
before any of them gets replaced). Now, if your development is such that old lots do not get replaced (for example, no increase in population EQ to drive upgrading of R$ to R$$ residences), you have a chance of going beyond the 16 Mby limit without getting the pox,
even if affected lots grew in your city. This is possibly what happened with most of your grown unpoxed cities.
Quote
Cross searching the web led my to simforum.de where diggis is cited with a probable solution similar to the one Z named here. I tried this and the prop files in both poxed cities doubled in uncompressed size, thus positively crossing the 16mb threshold again. Still poxed according to sc4 save tho, but at least for one saving process, all props remained visible.
Diggis and Z procedures are attempts to restore an already poxed city, and are essentially the same procedure. Unfortunately it seems it just postpones the problem. If you keep playing the city, it will become poxed again. &ops
Quote
What I did now was creating a new region, same plugin setup, fired up a large city, zoned it entirely in sprawltype manner just like my main region, let it develop till it crossed the critical threshold and checked the save file. No corruption. Then I bulldozed to drop below the critical value, checked the new save... and to my surprise, I was not able to reproduce my previous observation of the pox striking me on negative crossing of the threshold. Not even on multiple attempts I wasn't (luckily the game can run on it's own most of the time so I could do other things, took quite some time to test this).
May I suggest you (i) use the virus detector to figure out which lots might be affected, (ii) check whether these lots are being destroyed when you bulldoze parts of the city (and if they consistently generate one disabled prop per lot), (iii) let your city develop further, in order for the 16 Mby prop subfile limit to be crossed upwards again.
Quote
Now I think of making a bunch of screenshots and restarting the 2 poxed and 1 infected city tiles from scratch... or abandon years of work completely as there's no definity cure to the disease, just a work-around to surpress the symptoms. That said, can I actually, thinking of my above mentioned testing phase and it's apparent results, consider an obliterated and then rebuild city tile as more or less safe from pox, or would it be in vain to try it?
Again assuming that your Prop Pox is caused by the BDK-resource props, if you correct the aforementioned props, obliterate the Poxed cities and start again, you should be free from Prop Pox in these new cities. I restored all cities in my region which were either poxed or infected with backups from before I installed the BDK-resource file, modified the offending props, and continued developing these cities from that point without any further symptom of Prop Pox. The two larger ones have now gone beyond the 16 Mby limit without problems. Thus, yes, it is worth rebuilding.
A tip for the city rebuilding task: If you have two computers that you can run SC4 side by side, you can start the game with the old (poxed or infected) city in one computer, move the CD to the other computer, start the game in the other computer with the new (pox-free) version of your city, and use the old one to guide you rebuilding the new version. If you are up to preserving details, this allows you to reproduce exactly the same transportation, water, energy and city zone design as before.
Quote
Another point, aiming at really getting rid, some of the earlier pages suggest to extract several prop files from the games root data and making them zzzz thingy plugins so they load after probably affected lots.
Did anyone actually follow this idea already? From my logic, the game loads it's basic content, then the plugins, overruling the games content if necessary by simply being loaded afterwards. Now if someone would go ahead and, again, overrule the relevant props by a zzzz plugin with the maxis standard values, shouldn't this mean that at least for altered maxis content, the cause of prop pox would be eliminated?
It does not work ()sad(). This is equivalent of editing/correcting the offending props with the Reader. It corrects all new occurrences of that prop growing in your city from that time onwards, but it cannot change the offending props in already grown lots, as these are already stored in the savegame file. And we cannot modify the records already stored in the prop subfile unless one deciphers the checksum algorithm used to build the props buffer. If/when this is done, it will be possible to restore infected/poxed cities. (although
Mrtnrln may have found a way around this.)
Quote
Another, totally head-in-the-clouds idea that crossed my mind, but I guess this wont be possible both for legal and coding issues, is to force the game to stop messing around with compression. From what I learned until now, there seems to be a strong correlation between the outbreak of the pox and the game's urge to fiddle around with compressed data. I don't get the point of compressing small files but not compressing large files anyway.
Yep, the fixed size of the props buffer required by the compression scheme is crucial in leading to Prop Pox. But modifying the game's compression scheme requires access to the .exe source -- which seems out of question. Several things Maxis did (or did not do) might sound meaningless from todays point of view, but just remember that this game is from 2003, when cpu power, ram memory and HD disk space were considerably lower than what is now available (just as an example, the whole original Maxis game files are no more than 600 Mby because it has to fit into cd-roms, while most users nowadays list the size of their plugins folders in terms of several Gbys, just of custom content).
Quote from: bap on March 13, 2011, 08:58:51 PM
By demolishing a sizeable fraction of your city you probably deleted several lots with affected props (all of which became disabled) and you also reduced the prop buffer below the 16 Mby limit. Any further development which brings this buffer again above the 16 Mby limit leads to Prop Pox as now it contains disabled props. So, it is not crossing the limit backwards which drives Prop Pox, but it is crossing it again forward when it contains disabled props.
It is possible to go beyond the 16 Mby limit without getting Prop Pox. All you need is no disabled props. And this can be achieved by preserving the offending lots from being replaced. This sets up an interesting way around of being infected: set all offending lots as historical. (you need to find them all, and you must do it before any of them gets replaced). Now, if your development is such that old lots do not get replaced (for example, no increase in population EQ to drive upgrading of R$ to R$$ residences), you have a chance of going beyond the 16 Mby limit without getting the pox, even if affected lots grew in your city. This is possibly what happened with most of your grown unpoxed cities.
although this explanation does what it's supposed to be - explain - I find some contradictions to what I witnessed. The "oiriginal" state (as in prior to reworking started) was 0 disabled props, at 25mb prop file. then I bulldozed considerable parts of low dens. R$$ thus dropping below 16mb and then I visually discovered the pox across town already, no need for a positive crossing in this particular case.
QuoteMay I suggest you (i) use the virus detector to figure out which lots might be affected, (ii) check whether these lots are being destroyed when you bulldoze parts of the city (and if they consistently generate one disabled prop per lot), (iii) let your city develop further, in order for the 16 Mby prop subfile limit to be crossed upwards again.
hm...
as for top1: well, as it is mainly the same buildings, I don't think I need to run the virus detector again in this one, be assured affected lots are present. a wide majority of the development is huston tileset low dens. R$$ in both the original region and the testing grounds and by checking the original region, I found plenty of the respective props, so logic asures me that it's a waste of time to run the check again, albeit a small one, since the variation in maxis' lotting is a neglectible factor on fully developped large tiles.
as for top2: for similar reasons I am pretty sure that also affected lots are bulldozed. I did bulldoze about half the tile each time to definitely get below 16mb, like I said no disabled props whatsoever.
as for top3: that's what my testing was all about, crossing the 16mb threshold multiple times to prove my theory, or to falsify it.
QuoteAgain assuming that your Prop Pox is caused by the BDK-resource props, if you correct the aforementioned props, obliterate the Poxed cities and start again, you should be free from Prop Pox in these new cities. I restored all cities in my region which were either poxed or infected with backups from before I installed the BDK-resource file, modified the offending props, and continued developing these cities from that point without any further symptom of Prop Pox. The two larger ones have now gone beyond the 16 Mby limit without problems. Thus, yes, it is worth rebuilding.
since I edited out any instance of the 4 affected props you initially determined that I came across digging through peg's resource files on my system and thereafter haven't come across an instance of pox, no matter if forced attempt or by chance, I assume these 4 props to be the only cause so far. My guess was that obliterating and rebuilding it would help, just wanted another thought on this one.
QuoteA tip for the city rebuilding task: If you have two computers that you can run SC4 side by side, you can start the game with the old (poxed or infected) city in one computer, move the CD to the other computer, start the game in the other computer with the new (pox-free) version of your city, and use the old one to guide you rebuilding the new version. If you are up to preserving details, this allows you to reproduce exactly the same transportation, water, energy and city zone design as before.
Why haven't I thought of this?? seriously, working on 2 systems parallel is something I do quite often, it should have come to my mind aswell. duh.
QuoteIt does not work ()sad(). This is equivalent of editing/correcting the offending props with the Reader. It corrects all new occurrences of that prop growing in your city from that time onwards, but it cannot change the offending props in already grown lots, as these are already stored in the savegame file.
I didn't think of it as a cure, but more like a jab to at least give a chance to prevent future occasions. It would also come handy for those that have no experience with the reader.
QuoteYep, the fixed size of the props buffer required by the compression scheme is crucial in leading to Prop Pox. But modifying the game's compression scheme requires access to the .exe source -- which seems out of question. Several things Maxis did (or did not do) might sound meaningless from todays point of view, but just remember that this game is from 2003, when cpu power, ram memory and HD disk space were considerably lower than what is now available (just as an example, the whole original Maxis game files are no more than 600 Mby because it has to fit into cd-roms, while most users nowadays list the size of their plugins folders in terms of several Gbys, just of custom content).
see that's exactly why I dont get the logic in compressing small (sub)file sizes and not compressing large ones, instead of the other way around or even compressing both. the only reasonable explanation I could make up is that the devs thought that such large subfiles have a very remote chance to occure.
Hi all,
QuoteMay I suggest you (i) use the virus detector to figure out which lots might be affected, (ii) check whether these lots are being destroyed when you bulldoze parts of the city (and if they consistently generate one disabled prop per lot), (iii) let your city develop further, in order for the 16 Mby prop subfile limit to be crossed upwards again.
A few questions. Is there a way to guarantee a prop will become disabled? Are disabled props the only cause of prop pox?
Quotesee that's exactly why I dont get the logic in compressing small (sub)file sizes and not compressing large ones, instead of the other way around or even compressing both. the only reasonable explanation I could make up is that the devs thought that such large subfiles have a very remote chance to occure.
This happens because there is a limit to the data the game can compress (0xFFFFFFFF bits I believe).
Quote from: Lowkee33 on March 15, 2011, 11:09:21 AM
This happens because there is a limit to the data the game can compress (0xFFFFFFFF bits I believe).
Actually just 0xFFFFFF ;)
The algorithm to decompress these files goes like this:
Read the 9 byte header, which is formatted like so:
Offset 00 - Compressed Size of file
Offset 04 - Compression ID (0x10FB) (QFS Compression.)
Offset 06 - Uncompressed Size of file
At offset 09 starts the compressed data itself.
For some really strange (and stupid) idea, the formatting reserves
32 bits (4 bytes, offsets 00, 01, 02 and 03) for the compressed size of the file,
but only 24 bits (3 bytes, offsets 06, 07 and 08) for the uncompressed size of he file.
Thus, as soon as the size of the uncompressed file exceeds 0xFFFFFF (16,777,215) bytes (or 16 MB),
it becomes too big for the compression format... &sly
Quote from: Lowkee33 on March 15, 2011, 11:09:21 AM
This happens because there is a limit to the data the game can compress (0xFFFFFFFF bits I believe).
The "Mod the Sims" goes into more detail on DBPF Compression and how it works
see links
http://www.modthesims.info/wiki.php?title=DBPF_Compression
http://www.modthesims.info/wiki.php?title=Sims_3:DBPF/Compression
http://www.modthesims.info/wiki.php?title=DBPF
:)
can't even obliterate one of the 2 poxed cities. the game keeps crashing on me on both systems... &Thk/(
Try doing a large delete on various sections of the city. That might get around the problem enough so that you can eventually do an obliterate.
1 bulldozing and 2081903 simoleons later (god I love full hd resolution, gets almost an entire large city tile in zoom 1 on the screen) it still does crash upon obliterating.
wierd if you'd ask me.
well, I guess I just pull out the afore mentioned unpoxed backup copy of this file (luckily it's this city tile and not the one that's already poxed in my backups) and start from scratch here. hope I can obliterate this copy.
EDIT: oh lucky me, just moving the city out of the region folder and re-importing it ingame did help already to be able to obliterate it.
I had the prop pox in one of my older cities, caused by the BDK, but I deleted the bad prop from the prop pack and used mrtnrln's solution which worked visually.
Like he said, T21s didn't put themselves back, and there were some LOTs that didn't get their props back but it mostly worked.
SC4Savegame explorer still reports it as poxed though.
this approach would be working for me aswell I guess. My problem is tho, I can live with the occasional prop missing unless it's vivid (like missing fountains on a fountain plaza, missing lake on the large park and stuff) but what I can't stand at all is missing T21s. nothing worse than an ave interchange w/o traffic lights or even worse, no catenaries over railways. And since I'm prone to murphy's law, I guess I do the safe approach here ;)
And as a bonus, I could do some minor changes I had in mind that hesitated to do cuz I was to lazy to rebuild relevant parts of a finished city tile. Now that I have to anyways, I can do it ;)
EDIT: witnessing the following, I got a question: what relationship to the matter at hand do have disabled props actually?
I am asking because I am developping the first recreated city tile of the 2 poxed city tiles. while growing, I did frequent quicksaves and checked them in sc4save. at a certain point slightly prior to crossing the haunted threshold, I had 1 disabled prop in town, now I crossed the 16mb and sc4save does find 0 disabled props. this made me curious...
EDIT2: AND NOW TO THE FUN PART IN THIS MY VERY STORY (sry for caps): Just now, just a few seconds ago, the unbelievable happened:
I am still letting the city grow (albeit it's almost fully developped, I wait for some higher growthstage). Still quicksaving every few minutes and analyzing the savefile. And what do my little eyes spy? "Your city is poxed".
Funny. But that's not the end to the story yet. I let development run further, saved again, and guess what? "Your city is pox free".
Now... what the frack? I did tripple check to make sure I didn't click the wrong file in sc4 and qadruplechecked the reading. ???
Bad news: the Pox has returned in my city :( This time I have no idea what's causing it...
The odd thing however is that the file size stays around 25 MB and not 16 MB...
EDIT: after some demolishing it went up to 35 MB again. I hope its solved now...
Well, I used my backup of my Poxed city of where the Prop Pox occured for the first time, which I thought I solved the problem for the first time. But guess what, it did not. While the problem may seem to be solved, it's only fighting the symptoms. The Prop Pox is still present, but does help to limit the effect for a while.
If you set your game to low detail, demolish some lots (try to demolish fillers with lots of props) and then build them up again, save the city and then turn details to high seems to mask and limit the effect.
Best,
Maarten
Still having trouble making disabled props... &mmm
If a lot with pox inducing props is burnt down, do the props become disabled, or destroyed? Could this prevent prop pox while making the compressed/non-compressed switch?
Quote from: Lowkee33 on March 15, 2011, 11:09:21 AM
A few questions. Is there a way to guarantee a prop will become disabled? Are disabled props the only cause of prop pox?
Props that lead to Prop Pox become disabled when their lots are demolished or upgraded.
It is correct and safe to say that disabled props cause Prop Pox. However, since there is presently only one know group of props that drive the pox, one cannot say for sure if disabled props are the
only cause of the pox or not. I would feel more confortable to say that if we find another cause of the pox that works the same way as the modified BDK props: by becoming disabled props (instead of being deleted from the buffer) when their lots are demolished/upgraded.
Quote from: Lowkee33 on March 31, 2011, 02:18:38 PM
If a lot with pox inducing props is burnt down, do the props become disabled, or destroyed? Could this prevent prop pox while making the compressed/non-compressed switch?
This is worth testing. What I know is that demolishing a lot with a pox-driving prop is equal to letting the lot being upgraded: the pox-driving prop becomes disabled (I made the virus_detect mod with the hope that by identifying & demolishing all suspected lots I could get rid of the pox before it manifested itseft -- it didn't work; I just increased the number of disabled props).
I had prop pox in 2009. I was directed to this thread. I found out that the cause was PEG-OWW2_BDK_RESOURCE.DAT and removed it from my plugins. I started a new region late last year. Just now I realized that one of the cities has props disappearing. PEG-OWW2_BDK_RESOURCE.DAT cannot be the cause because I never had it installed while working on this... What do you think?
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fwww.davemckay.ca%2F_Temp%2FProp_Pox-2011-04-02-at-02.07.14.jpg&hash=6bf45cf550be14d163a943e5f8a48d0c9fbec27f)
It is known historically that prop pox has occured for many years, and well before the Peg lot.. it is clear that there are other problems.. it might be useful for you to place your city save on some file host location (there are a number that allow free use and large files .. I use fileden (http://www.fileden.com/)) and perhaps someone can zero in on the file(s) that may have caused your specific problem..
I think that I have figured out when the pox turned up. The city on March 27th looks fine to me while the city on March 28 has begun to lose props. On the 28th I did a thing that might have caused it. Let me know what you think.
On March 20th I updated the RTMT to V3.60. It includes model files; SG_BusStop01.dat through SG_BusStop20.dat and SG_BusStopLg.dat dated 2009/10/23. These 21 DATs had more current dates on them than the versions I had been using with simgoober/Transport/Bus Stops dated 2009/02/25. So, thinking I only wanted the more current files in my plugins I removed the older ones. After that I noticed that when I plopped SG Bus Stops they had no shelter on them. So I thought that I needed both the old and new versions in my plugins and put the older ones back. And indeed, SG Bus Stops plopped after that had shelters, but, all subsequent saves have swaths of props missing.
I notice now that while all the other 2009/10/25 DATs are the same size as the older ones, SG_BusStop16.dat from 2009/10/23 is 66 KB while the older version from 2009/02/25 is 70 KB. I understand that changes to prop size can contribute to prop pox, could this be significant?
I can't be sure of the exact timing however and this may be coincidence. I have also been editing traffic capacities of lots to match the rules set down by Z, so, I could have screwed something up there too.
The unpoxed and poxed versions of the city are at the links below. If you know what you are looking for, as I certainly do not, you may want to examine them. I have not had the PEG-OWW2_BDK_RESOURCE.DAT in my plugins since 2009. This region was started 2010/12/21 so it is for sure a new case of pox not caused by PEG-OWW2_BDK_RESOURCE.DAT. As such it may be helpful in figuring prop pox out.
Unpoxed: http://www.davemckay.ca/_Temp/110327_21-25_unpoxed.zip (http://www.davemckay.ca/_Temp/110327_21-25_unpoxed.zip)
Poxed: http://www.davemckay.ca/_Temp/110328_01-07_poxed.zip (http://www.davemckay.ca/_Temp/110328_01-07_poxed.zip)
Thanks in advance.
This is certainly a reasonably question, and one that I asked myself at one point. However, it has been investigated thoroughly, and the consensus is that a simple change in prop size could not cause the prop pox. Apparently, the pox requires the use of timed props and their untimed version in the same city.
Furthermore, in your particular situation, the IDs of the RTMT prop exemplars are different from SimGoober's IDs - only the models are the same. This automatically disqualifies this situation as a possible cause for the pox.
Also, just editing traffic capacities cannot set off the pox, regardless of what numbers you put in.
So, I can keep 2 sets of SG_BusStopXX.dat in my plugins?
Definitely. You can use both the RTMT and the standalone versions of the bus stops in the same city; many people do that without any problems at all. The game doesn't care about file names; the key is that the IDs are different.
Thanks Z.
Well, if it is not that, then I have no idea. If anyone has any thoughts or think it would be useful to look at the save-games then:
Unpoxed: http://www.davemckay.ca/_Temp/110327_21-25_unpoxed.zip (http://www.davemckay.ca/_Temp/110327_21-25_unpoxed.zip)
Poxed: http://www.davemckay.ca/_Temp/110328_01-07_poxed.zip (http://www.davemckay.ca/_Temp/110328_01-07_poxed.zip)
I have just spent the last two hours going through this thread. Prop Pox is messed up man. Sucks that there are even issues like this. It's to bad SC4D can't just come out with their own SC4 game with all problems fixed! It would be more than Maxis ever wanted to do with it, I.M.O.
Question?
So I'm starting fresh with SC4/RushHour. I got the LEX DVD and I was wondering. Is there a list of anything that maybe I shouldn't install, that might cause Prop Pox?
@Bap: Thanks for the info. Start to do a fair amount of modding to props, so having a city that can quickly be tested will be helpful.
@Final Table: Nothing on the LEX DVD is known to cause prop pox. When the RKT1 to RKT4 issue was found, the BSCers went through all their stuff looking for cases (not sure if they found any). Also, I believe that if you start a new region and never change your plugins, then you will never get prop pox, even if you started the region with the Peg BDK. (could be wrong though).
Quote from: Lowkee33 on April 03, 2011, 07:58:16 AM
Also, I believe that if you start a new region and never change your plugins, then you will never get prop pox, even if you started the region with the Peg BDK. (could be wrong though).
Unfortunately, this is not true. If you have a lot grow with the beach umbrella, and then the lot automatically upgrades into a bigger lot, the beach umbrella will end up as a disabled prop, and it is then possible for you to get the pox.
@ Lowkee33, yea I'm still confused after reading this entire thread, but I guess what I was hinting at, was you have all these great minds here at SC4D. It would be nice if a group of people from here, could get together, and get the rights to produce their own SC game with! I think it would be something that would take sometime to make, but in the end result, you could weed out all problems and have a TON of things to go with the game.
I mean with purchasing SC4/RushHour, compared to what add ons that are on this site. It is still pretty basic. So why don't the head mods put together their own game? A challenge in and of its self, but worthy cause no?
You would have to ways going about it as I see it. Getting the rights from EA or starting off fresh. Maybe I'm just dreaming up a wild idea here. ::)
But the support, and friendliness of this site alone, goes beyond anything else. There is a reason why it's called sc4"D"!
@ z back to my original question. If I'm doing a fresh install, what should I be taking out of the folders? Where is this umbrella you speak of?
I have had my LEX disk for almost 2 weeks now and have been picking and choosing what to install. I haven't even fired up the game yet! I'm taking it slow to get all things in order before firing it up for the first time.
Quote from: finaltable on April 03, 2011, 01:06:18 PMI think it would be something that would take sometime to make, but in the end result, you could weed out all problems and have a TON of things to go with the game. I mean with purchasing SC4/RushHour, compared to what add ons that are on this site. It is still pretty basic. So why don't the head mods put together their own game? A challenge in and of its self, but worthy cause no? You would have to ways going about it as I see it. Getting the rights from EA or starting off fresh. Maybe I'm just dreaming up a wild idea here. ::) But the support, and friendliness of this site alone, goes beyond anything else. There is a reason why it's called sc4"D"!
@Final T: Oh, believe me when I say we, the rest of the SC4 community here and there have previously tried. The reason EA recently started to sell SC4 as a DLC game, is they know we, the people that truly do work on the game, we; the international modding community, are the people that did better work, despite they get paid, and did not really return the favor. The only thing that worked out was the original RHW, because they left an unfinished road network ship with the game. (however missing/unfinished Maxis civic buildings like a DMV, and various others did not ship with the game)
There have been times the community tried to talk to EA before, regarding the SC4 Source code, or getting an SDK (source developer kit), not a bunch of head mods, but there were plans to make almost a duplicated SC4 by rewriting the program from the ground up! What you said was basically the intention of the goal, and to still use SC4 custom content, as well as new 3D content that would have not made it into regular SC4, but that too ended up only being a dream. These days, game engines are more involved, as you know SC4 is restricted from full 3D with the locked camera angles. In the end, that turned out to be pretty hard. But, it seems that great minds think alike after all.
Unfortunately some problem with SG Bus Stops and the RTMT is causing my pox.
Step 1 below shows the unpoxed city with one of the SG Bus Stops that is missing its shelter.
Step 2 shows that I have bulldozed the defective lot.
Then I saved, closed and reopened the city.
Step 3 shows that there is no change.
Step 4 shows that I plopped a new SG Bus Stop. It has its shelter.
Then I saved, closed and reopened the city.
Step 5 shows that the city is poxed.
I can repeat this over and over. If I plop a new SG Bus Stop, save close and open then the city is poxed.
Step 1
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fwww.davemckay.ca%2F_Temp%2F_SG_BusStop_Prop-Pox%2FStep_1.jpg&hash=321df8224769822b0b37eef4a156ba9166fc9995)
Step 2
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fwww.davemckay.ca%2F_Temp%2F_SG_BusStop_Prop-Pox%2FStep_2.jpg&hash=8375e08e0a30a889b8bc682282f640ef4a1483e9)
Step 3
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fwww.davemckay.ca%2F_Temp%2F_SG_BusStop_Prop-Pox%2FStep_3.jpg&hash=b61482cc3a12241d66acbd1dcaacdc2dbafbfc6b)
Step 4
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fwww.davemckay.ca%2F_Temp%2F_SG_BusStop_Prop-Pox%2FStep_4.jpg&hash=321102086ca7a3126005ec61d07c48e04ee63bf2)
Step 5
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fwww.davemckay.ca%2F_Temp%2F_SG_BusStop_Prop-Pox%2FStep_5.jpg&hash=540b615becaed08ab5c30e763afd128c0094b3ab)
Can anyone come up with a list of know files that could possibly cause the Pox effect to happen? I have seen many people refer to the umbrella. What umbrella and what file?
If we had a list to go by, it would in turn be, (maybe) easier to avoid. It seems to me that maybe you could start a list like.
1.) Umbrella (file name/location)
2.) SG bus stop (file name/location)
This is just an example.
Or maybe it is just not that easy. ()what()
@ J-dub, yea so it seems that EA just wasn't willing to work with anyone in this international community. That really blows. I could think of 2 reasons. First being EA doesn't want to deal with a group of different people and pay any $$ to anyone for making their game better. Second EA just doesn't care! I'm going with the latter. Being that EA gets most of it $$$ from sports games.
After doing some research though, you would think that Will Wright would care more about his work of art that he created than to let it fall by the waste side. I guess if you have an international community that can help improve the game at no cost to you, and it increases the sale of your game. Why would you even bother?
Quote from: dahemac on April 03, 2011, 03:25:07 PM
Unfortunately some problem with SG Bus Stops and the RTMT is causing my pox.
Step 1 below shows the unpoxed city with one of the SG Bus Stops that is missing its shelter.
Step 2 shows that I have bulldozed the defective lot.
Then I saved, closed and reopened the city.
Step 3 shows that there is no change.
Step 4 shows that I plopped a new SG Bus Stop. It has its shelter.
Then I saved, closed and reopened the city.
Step 5 shows that the city is poxed.
Again, based on our present understanding, there is no way that the combination of props you described can be causing the pox. The steps you followed did not ensure that the pox was ever removed from the city - simply that some of its symptoms were. The pox was undoubtedly still present in the savegame file. In order to verify that a city is pox free, you need to use the
SC4 Savegame Explorer (http://sc4devotion.com/csxlex/lex_filedesc.php?lotGET=2021), whose use is explained elsewhere in this thread.
Quote from: finaltable on April 03, 2011, 04:14:44 PM
Can anyone come up with a list of know files that could possibly cause the Pox effect to happen? I have seen many people refer to the umbrella. What umbrella and what file?
It's the beach umbrella in the file PEG_OWW2_BDK_RESOURCE.DAT. This is the only known cause of the pox. There are other causes, but no one has been able to isolate any of them yet.
It's the beach umbrella in the file PEG_OWW2_BDK_RESOURCE.DAT. This is the only known cause of the pox. There are other causes, but no one has been able to isolate any of them yet.
[/quote]
Thanks z for the information. So should I go in and delete the umbrella file in the file PEG_OWW2_BDK_RESOURCE.DAT.? Would that help and is deleting it what I should do?
Also I looked in both of my PEG files in my plug ins folder and couldn't find the above mentioned folder/file? ()what()
Quote from: finaltable on April 03, 2011, 05:40:03 PM
Thanks z for the information. So should I go in and delete the umbrella file in the file PEG_OWW2_BDK_RESOURCE.DAT.? Would that help and is deleting it what I should do?
Most of the currently asked questions have already been answered in this thread. I'm just searching through it to pull them out:
Quote from: bap on February 24, 2009, 08:53:46 AM
How to avoid the problem
If you want to avoid the above described cause of Prop Pox, you have the following choices:
1- Refraining from using Pegasus CDK3-OWW2 lots (the beach resource file contains a couple of SSH files used by the other OWW2 lots). Wait for Pegasus to release a patch to his package correcting the problem props.
2- Open the PEG_OWW2_BDK_RESOURCE.DAT file with the ilive Reader, delete the items 11, 12, 13 and 14 (exemplar names R1x1x2_BeachChair_29B2, R1x1x3_PatioChair_290D, R1x2x2_Recliner_2911, and R2x3x2_$$Beachumbrella_2900), and save the file again. The three first props will no longer be time-dependent (the umbrella will still be time-dependent, appearing only during day time). But the lots will work fine. With no Prop Pox.
3- Open the PEG_OWW2_BDK_RESOURCE.DAT file with the ilive Reader, change the exemplar name (p.ex., add a PEG_ before each name) and the instance of the items 11, 12, 13 and 14 (mark each one and select "generate new instance"), and save the file. Load each of the beach lots into LotEditor and replace each occurrence of these props by the corresponding new PEG_* prop and save the lots. Replace the original lots by the modified ones. They will work exactly as designed, but will no longer lead to Prop Pox.
QuoteAlso I looked in both of my PEG files in my plug ins folder and couldn't find the above mentioned folder/file? ()what()
In this case, either that file has been deleted in the past, or the pox in your city is being caused by something else.
FWIW, I am one of those who have a poxed city where the pox was not caused by the beach umbrella. I had also never used SG's bus stops at the time the pox appeared.
Thanks z for the reply. I remember reading the "How to avoid the problem" part. So sorry to be repetitive. Your reply is very helpful me so thanks again.
The only problem is that I read and re-read the "How to avoid the problem" and I don't know what to do.
I'm more lost with this...
3- Open the PEG_OWW2_BDK_RESOURCE.DAT file with the ilive Reader, change the exemplar name (p.ex., add a PEG_ before each name) and the instance of the items 11, 12, 13 and 14 (mark each one and select "generate new instance"), and save the file. Load each of the beach lots into LotEditor and replace each occurrence of these props by the corresponding new PEG_* prop and save the lots. Replace the original lots by the modified ones. They will work exactly as designed, but will no longer lead to Prop Pox.
Just way over my head here with all of this...
Edit....I just did a search across my computer and couldn't find said file. PEG_OWW2_BDK_RESOURCE.DAT Is it or was it in one of the dependencies? Or is it possibly in a file that I have gotten to yet on the LEX disk or on the LEX site?
Thanks z for the advice re "Save Game Explorer." I have it open right now.
Please note the really interesting thing. The poxed city has no disabled props. Please note also that the poxed city below is not the one from Step 5 of the earlier post. If you want to investigate this further I will make you a fresh new poxed city later today.
It says the the city in Step 1 is unpoxed.
QuoteProp pox free city
252135 props found in city
Some infos about the props:
-0 disabled props found in city
-1337 tracking props found in city
-33682 timed over year props found in city
-16046 dayly timed props found in city
-49729 conditional props found in city
-From what kind of data :
--9 props alone
--241649 props from lot
--10458 props from T21
It does show that the poxed city from 110328 is poxed. This is the oldest version of the city I have archived that has corruption.
QuoteProp poxed city !!!
Buffer corruption occurs around offset 0x01667FFC
259288 props found in city
Some infos about the props:
-0 disabled props found in city
-1399 tracking props found in city
-40583 timed over year props found in city
-14542 dayly timed props found in city
-55126 conditional props found in city
-From what kind of data :
--5 props alone
--249415 props from lot
--9852 props from T21
The procedure I took to cause the prop pox works every time. I tested it three times. I am not saying that there is anything wrong with the RTMT or the SG Bus Stops. I have used them for years. However when I updated the RTMT I replaced the SG DATs with the RTMT DATs of the same name. Then because the shelters disappeared on the SG stops I put the older DATs back. Since then I have removed the newer DATs. It no longer seems to make a difference however. Messing with SG Bus Stops now cause Prop pox in this city.
This is very interesting indeed! Note the following recent quote by Dr. Propper himself:
Quote from: bap on March 31, 2011, 04:50:39 PM
Props that lead to Prop Pox become disabled when their lots are demolished or upgraded.
It is correct and safe to say that disabled props cause Prop Pox. However, since there is presently only one know group of props that drive the pox, one cannot say for sure if disabled props are the only cause of the pox or not. I would feel more confortable to say that if we find another cause of the pox that works the same way as the modified BDK props: by becoming disabled props (instead of being deleted from the buffer) when their lots are demolished/upgraded.
I have also worked with poxed cities quite a bit, and they have always contained disabled props. I have never seen an output from Save Game Explorer that shows a poxed city with no disabled props, as yours does.
It is probably not a coincidence that SimGoober's bus stops (at least many of them) are timed props.
At this point, I think that people more expert than I at this need to take a look at what you've got, which appears to be a type of pox that's never been seen before. I'll post a little note where some of them will see it, just in case they miss these posts.
Thanks Z.
Another test to show that a problem involving the SG Bus Stops and the RTMT 3.6 update and the DATs with the same names in these has become a cause of Prop Pox in this city. It seems like I can make other changes to the city without causing pox. For instance, I installed and replaced a lot of Avenue GLR and FLUPs without causing pox. However if I mess with any SG Bus Stop, since the RTMT 3.6 update was installed, then BOOM! Prop pox explosion.
The Unpoxed City with a SG Bus Stop without its shelter. The missing shelter was caused when SG_BusStopXX.dats were replaced.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fwww.davemckay.ca%2F_Temp%2F_SG_BusStop_Prop-Pox%2FOriginal_Unpoxed.jpg&hash=b2068cd0317d574f8be3a07e705889443b7bfb74)
QuoteProp pox free city
252135 props found in city
Some infos about the props:
-0 disabled props found in city
-1337 tracking props found in city
-33682 timed over year props found in city
-16046 dayly timed props found in city
-49729 conditional props found in city
-From what kind of data :
--9 props alone
--241649 props from lot
--10458 props from T21
I opened the unpoxed city bulldozed one SG Bus Stop then saved. This caused pox.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fwww.davemckay.ca%2F_Temp%2F_SG_BusStop_Prop-Pox%2FDelete_SG_Bus-Stop_Poxed.jpg&hash=6c27845a94047a25cd213b86365c2cd7f91836b9)
QuoteProp poxed city !!!
Buffer corruption occurs around offset 0x01412AC8
233903 props found in city
Some infos about the props:
-0 disabled props found in city
-1280 tracking props found in city
-27434 timed over year props found in city
-14380 dayly timed props found in city
-41815 conditional props found in city
-From what kind of data :
--5 props alone
--223883 props from lot
--9996 props from T21
I then reopened the original unpoxed city and then resaved it without making any deliberate changes. This caused no pox.
QuoteProp pox free city
252137 props found in city
Some infos about the props:
-0 disabled props found in city
-1338 tracking props found in city
-33682 timed over year props found in city
-16046 dayly timed props found in city
-49729 conditional props found in city
-From what kind of data :
--9 props alone
--241650 props from lot
--10458 props from T21
Before we forget Finaltable, here's some answer.
The Peg-etc.dat file is part of Pegasus beach set. It is not on the LEX nor on the LEX-disk. You can find it on his own site (simpeg.com) or on the STEX (simtropolis.com). I advise you to just not use the beach set and this file. It is a dependency file belonging to the beach set.
Sorry, I forgot the exact name of the set, but it is a set with beachside lots. You can perfectly do without.
Pityfully Peg saw the identification of solely his file as a cause of prop pox as a personal attack. Which was not the case. Anyway, he is not working together with the BSC people and the people from SC4Devotion.
For his work, which is undoubtedly excellent, you best visit his own site. But keep your hands off the beach set file!
Quote from: dahemac on April 04, 2011, 04:06:28 PM
Another test to show that a problem involving the SG Bus Stops and the RTMT 3.6 update and the DATs with the same names in these has become a cause of Prop Pox in this city.
I recall that the first release of RTMT v3.60 had a problem when you used SG's bus stops in the same city as the RTMT version of them, although this did not result in the prop pox. This problem was fixed fairly quickly, though. Is your version of RTMT v3.60 up to date?
I downloaded the RTMT from of the LEX 2011/03/20. I have been using RTMT 3.5 with SG Busstops for a long time with no problem.
Below is a screen shot of the RTMT folder in my plugins. Red files are ones I was not sure about after I went through the installation.
At the moment I have only one set of SG_BusStopXX.dat in my simgoober folder.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fwww.davemckay.ca%2F_Temp%2FRTMT_3-6_installed.gif&hash=93be27a8cd8d34ccc6430b9ce0616a0103a3ac4b)
Quote from: FrankU on April 06, 2011, 12:51:01 PM
Before we forget Finaltable, here's some answer.
The Peg-etc.dat file is part of Pegasus beach set. It is not on the LEX nor on the LEX-disk. You can find it on his own site (simpeg.com) or on the STEX (simtropolis.com). I advise you to just not use the beach set and this file. It is a dependency file belonging to the beach set.
Sorry, I forgot the exact name of the set, but it is a set with beachside lots. You can perfectly do without.
Pityfully Peg saw the identification of solely his file as a cause of prop pox as a personal attack. Which was not the case. Anyway, he is not working together with the BSC people and the people from SC4Devotion.
For his work, which is undoubtedly excellent, you best visit his own site. But keep your hands off the beach set file!
Thanks Frank! You answered every question I had, perfect. Great answer and perfect explanation. It's to bad the way things ended.
Maybe PEG will feel better knowing that I have Prop Pox without his PEG_OWW2_BDK_RESOURCE.DAT.
I'm sure PEG would feel better, however I doubt it would do anything to mend old wounds. Your case seems special in a sense you have no idea what is causing it. Also from what I gather, it is doing something that people haven't seen it do before? No?
What is RTMT????
RTMT is the Road Top Mass Transit. It is the best thing since the invention of, well, transit.
Do you have a link to this RTMT? I tried on the LEX but it could be endless searching. Also we don't know if it is the RTMT, SimGoobers bus stop, or either one of the two causing the POX problem?
If you search for RTMT in the search field on the left of the page it will take you to the RTMT. You could also use advanced search and look for things created by z.
My pox was not caused by any particular fault in either RTMT or SG BusStops. I think it is a version control problem with the model files and a confused installation. As far as I know, anything you get of the LEX will NOT inherently cause Prop Pox.
My hope is that looking at this instance of Prop Pox which does not conform to the current understanding, might help solve the problem.
Dahemac, thank you very much for your detailed explanation, pictures, and file listings. They make absolutely clear what the problem is, and also how to fix it.
Specifically, the problem is the following:
Quote from: dahemac on April 04, 2011, 04:06:28 PM
The Unpoxed City with a SG Bus Stop without its shelter. The missing shelter was caused when SG_BusStopXX.dats were replaced.
The RTMT v3.60 instructions do not state anywhere that you should replace the original SG bus stop files. In fact, replacing them can be deadly, as you have discovered. Here's what happened:
Before your installation of RTMT v3.60, everything was running fine. But then when you installed RTMT v3.60, instead of just adding the SG .dat files to the RTMT Models folder, as the directions instruct, you used them to replace the existing SG .dat files. This is where the problem arose. The original RTMT versions of these files were identical to SimGoober's; hence the identical name. But this turned out to cause problems for people who used both versions of the bus stops. The problem was that once RTMT v3.60 was installed, you no longer got just the standalone SG bus stops that you had loaded, but you could get any of them. This was happening because the .dat files contained not only the models, but also the prop exemplars for the standalone bus stops, which were constructed by SimGoober so as to put all the props in the same group.
To fix this problem, I removed the prop exemplars from the RTMT version of these files. I left the names the same for compatibility with the original v3.60, so that people updating v3.60 would automatically have those files overwritten.
When you replaced SG's original .dat files with the RTMT ones, though, you effectively removed all his prop exemplars. That's why his bus stops suddenly had no props. And then when you bulldozed one of these bus stops, the game tried to remove a timed prop that had a prop ID pointing to it, and which existed at one time, but which now no longer existed in the Plugins folder anywhere. The game apparently got confused enough by this that during the deletion process, the prop subfile got corrupted. The saved game had no disabled props because when the lot was bulldozed, there were no props to disable.
This has the larger implication that the pox has to do with deleting timed props, but is not necessarily connected with disabled props. The only reason we thought that disabled props were involved is that generally, when you delete a prop, it exists, and therefore becomes disabled. But your example has shown that this is not necessary.
So to fix everything, here are the steps you should take. Your RTMT v3.60 appears to have a number of installation errors, and I'll point these out along the way.
- First, make a copy of both your city and your entire Plugins folder so that those who want to explore this more fully can do so.
- Next, remove and reinstall the original SG_BusStop*.dat files that you were using from SimGoober's standalone distribution.
- Reinstall RTMT v3.60 over your existing installation, following the instructions in the Readme very carefully. (BTW, none of the files you highlighted in red are a problem.)
- I notice that your Signs subfolder has only two files in it. There should be dozens here - almost one for every possible RTMT station. Are these files somewhere else? Without them, I would expect you to be getting brown boxes on essentially all your RTMT stations.
- Be sure to overwrite existing files when duplicates exist.
Once you do all this, everything should work fine.
Quote from: dahemac on April 06, 2011, 07:03:00 PM
If you search for RTMT in the search field on the left of the page it will take you to the RTMT. You could also use advanced search and look for things created by z.
For most of the RTMT downloads, this is correct, but you need to get the original
RTMT v3.50 (http://sc4devotion.com/csxlex/lex_filedesc.php?lotGET=1057), which is still necessary at this point, and which needs to be installed first.
Great Job z! &apls Way to track down the problem, man this forum really has some great people in it.
Well, I may have sorted out my plugins folder. I will go through the installation again I think to see if I have missed anything obvious. However it looks like in any version of the city if I bulldoze an SG Bus Stop I will get pox. I will investigate further, however I think that in the existing city any old version of the SG Bus Stops is a prop pox land mine.
Quote from: z on April 06, 2011, 07:58:06 PMThis has the larger implication that the pox has to do with deleting timed props, but is not necessarily connected with disabled props.
Takes my theoretical angle away.
@Dahemac: What happens if you burn the lots down?
Quote from: dahemac on April 11, 2011, 01:36:59 PM
Well, I may have sorted out my plugins folder. I will go through the installation again I think to see if I have missed anything obvious. However it looks like in any version of the city if I bulldoze an SG Bus Stop I will get pox. I will investigate further, however I think that in the existing city any old version of the SG Bus Stops is a prop pox land mine.
This implies that your Plugins folder still has problems. I would suggest first going through it and removing all SG_BusStop*.dat files, wherever they reside. Next, completely remove the standalone SG bus stops, and then reinstall them, following their installation instructions exactly. This should completely remove the cause of the pox in your cities.
Bwa ha ha ha ha. As it turns out the problem had it roots in an update I did to the SG Bus Stops on March 17. The version on the LEX is more current than the one I was using up to that point.
I have sorted out the plugins, however I needed to go back to a city save file from before that update for the problem to vanish.
I have not as yet tried burning a lot down.
Well thought out approach, a great public service message to all SC4 players. A well-earned Karma Point from me! &apls
I'm testing my city tile that keeps getting the Pox...Every backup I've gone to is already over 16mb in the network file and they show no signs of the Pox until I put a lot of work into the tile, then it pops up...I'm testing an earlier backup which was already over 16mb, but nothing is happening. I feel like when I test the pox hides, but when I actually play and work on a tile for real the pox will manifest. Here's to more testing :(
How to minimize the effect of the Prop Pox?
Currently I have three cities that show signs of the Prop Pox. Although this is very annoying, I've found three tips to minimize the effect of the Prop Pox:
1. Play in Low Detail settings!
Yeah, I know, the game looks ugly when you set your stettings low, but it has its advantages. Not only does it improve peformance, but also it makes CTDs due to camera movement to occur less frequently and it also helps against the Prop Pox. You see, the Prop Pox occurs when a certain file reaches a certain size, and when it reaches it, it begins to shrink. However, when you set your city detail level to low, a lot of props become disabled, and from my experience the game doesn't save disabled props, so the Prop Pox will occur later. And when it does occur, no need to worry. When you set your city detail settings to high again (for an MD update for instance), all props will appear, as if there were no Prop Pox at all.
2. Save in Zoom 1.
Just like the above, when you're in Zoom 1 with low detail settings, lots of props get disabled and will not be saved, limiting the effect of the Prop Pox.
3. Planted trees are not props.
Trees planted in God Mode or Mayor Mode will not dissappear due to the Prop Pox. Try to avoid tree filler lots and plant God/Mayor Mode trees instead.
I hope this information might be usefull to you ;)
Best,
Maarten
Quote from: mrtnrln on June 04, 2011, 06:33:19 AM
3. Planted trees are not props.
Trees planted in God Mode or Mayor Mode will not dissappear due to the Prop Pox. Try to avoid tree filler lots and plant God/Mayor Mode trees instead.
(...)I hope this information might be usefull to you ;)
Maarten
That's a neat one, I had no idea about it. Thanks a lot Maarten!
I've decided to start my infected tile fresh. Can I just obliterate the city? Or do I need to rerender the region and import a fresh tile. Any ideas? I've tried the little workaround that replaces props, but it would be too much work to keep replopping trees onto tiles, etc, and the enjoyment is lost working on my core city tile, so I want to restart the tile.
It is safe to rebuild in the space where the old infected city was, but I am just going to tell you my experience with redoing in the same spot.
My experience when I redid a city tile, is I used the same name, and for whatever reason, using the same city name, eventually it did crash, but when I used a different name, only altering it slightly, where it would crash before, it would not. This was a little too suspicious to crash from a different issue.
Instead of obliterating in the city I used the trash can icon in region view. The first time, I used obliterate when inside. The second time I had to be safe and used the icon in region view. Hopefully this will not happen, but no pox, yet after redoing the city tile in that spot. I have had to redo two large cities in the same reason. One of them, was not so much pox, but I just was not satisfied with it. I hate reoccurring air pollution.
On a different note, I bulldozed a Maxis airport, and so far in a large city tile, with large development, the saved city seems to be acting like normal after reloading.
I think I will rerender the entire region and import a fresh tile....I've tested other large tiles for the pox and nothing seems to be happening, so I'm hopeful the pox cause is gone, so a fresh start will end well.
Hey Maarten,
That's interesting information.
Now stays for me the question: when the props are not saved, how does the game know what props are needed in high detail settings? Does the game read the original lots and places the props anew? This would mean that lots with prop families could look different after saving in low detail setting and then going back to high detail settings.
Does anyone know how this works?
Quote from: FrankU on June 08, 2011, 02:34:11 AM
Now stays for me the question: when the props are not saved, how does the game know what props are needed in high detail settings? Does the game read the original lots and places the props anew? This would mean that lots with prop families could look different after saving in low detail setting and then going back to high detail settings.
I think that's how it works. There is another trick involving this procedure, and that's for overhanging LOTs. Don't know where I can find it now, but it does have the same effect. For instance, if you add/remove anything from a LOT, it will only be shown on new LOTs. However, if you set detail settings to low, save the city, set detail settings to high again and load the city again, then the old LOTs are changed too.
Hm, maybe I should do some testing with my Farm lots... It would show soon enough.
Quote from: FrankU on June 08, 2011, 02:34:11 AM
Now stays for me the question: when the props are not saved, how does the game know what props are needed in high detail settings? Does the game read the original lots and places the props anew? This would mean that lots with prop families could look different after saving in low detail setting and then going back to high detail settings.
This is done by changing the 7th digit in the 2nd rep of the LotConfigProperties in the Lot Exemplar. By default (in PIMX at least), this rep is 0x00000000 and means it will appear in all detail levels; 0x00000010 means medium; 0x00000020 means high only. Changing the last digit of this rep to "1" activates the prop requesters, meaning that you can successfully have prop families with different wealth/crime/trash models appear at the correct time (though I haven't got crime/trash to work, it does with the Maxis families).
For Maarten's suggestion, it would probably be best to set these reps to 0x00000020.
Perhaps through Maarten's last post it would be possible to "fix" the pox. Change the detail to low, save and quit. Then change the last digit in the 2nd rep to 0x00000001 and add a prop with the correct wealth level to the family (or perhaps even change the last rep). Upon re-loading and changing to high detail, if the new prop is displayed, it might make the game forget it ever used the poxxed prop. Of course, I have no idea about this.
Well hello everyone...it has been so long since I've talked with anyone here...so first, how are you all? I trust very good and living life to the fullest &apls
......As you know, I'm one of the first sufferers of the Prop-pox....even to the point of naming it such....and I'm still suffering! I use 'z's method...this one:
1. Open your saved city in Ilive's Reader.
2. Sort the left pane based on file size, with the highest at the top.
3. Near the top, there will be a subfile of type 2977AA47. This is the prop subfile. Delete it.
4. Also delete the subfiles of type 6A0F82B2 and 6990C1AA, which are also near the top. These subfiles are regenerated as needed. If you don't delete them, this process will still work, but your city size will increase greatly each time you repeat this process.
5. Save the city file.
6. Start up the game, but don't open the city file.
7. Open the Graphic Options, and make sure the City Detail is set to Low.
8. Open your city and save it immediately.
9. Exit to the region without saving.
10. Open the Graphic Options, and change your city detail to High.
11. Open your city. All your props should be restored.
12. Save your city. Your props will all be there... for a while.
....So now I have the traffic automata problem, in which there is no usage being indicated on the bus stops, subway or elevated rail. Now I know back a few months someone also posted this issue...but I cannot find a reply...is their a solution to this, other than replacing all of the bus stops and what have you?
Any help would be gratly appreciated:
Bruce (BEJA)
^^ I don't use Z's method. I actually skip step 1 to 6 and start with step 7. Works like charm! And the best part is that traffic doesn't become corrrupt.
Thanks mrtnrln ....works like a charm!!
BEJA
Hello everybody every of you masters of developing fun...
my pox case have began yesterday... no images needed isnt it??
after reading about a lot today (what a headache), i think i can resume my case in this...
POXED CITY:
Name Terraxons(2):
weight of SC4 file: 16,8 and goes to 16,6 after working a lot in it (seems to have the symtoms...)
weight of network subfile (2977aa47): 4,85 mb (<6mb limit bap has reported on page 1!!!)
analysis with savegame explorer: positive in pox:
Report:
Prop poxed city !!!
Buffer corruption occurs around offset 0x00DCA95F
163248 props found in city
Some infos about the props:
-11488 disabled props found in city
-2264 tracking props found in city
-3118 timed over year props found in city
-14583 dayly timed props found in city
-17634 conditional props found in city
-From what kind of data :
--41 props alone
--138276 props from lot
--13437 props from T21
In the map that shows... the grid appears with not the complete extension... in the four edges! but pox occurs also inside the correctly showed grid
NO POXED CITY:
Terraxons:
weight: 26 mb and not less
weight of network subfile (2977aa47): 17,9 mb
analysis with savegame explorer: negative in pox:
I have beaches, but i think i have no PEG beach pack (i´ve searched for the infamous file in my plugins folder with no results... any hidden location i should know????)
Recent upgrades:
I´ve installed several plugins and upgrades... one of them, the great RTMT upgrade (RTMTv3.60)
I´ve follow the instructions the best i can, my english is not the better, and make some mess with the instructions...
but for what i´m reading here, bus stops could be a problem, so i´ve decided to report my case.
it is not the same as dahemac cause i´ve been alerted by savegame explorer as prop disabled!!
i´m going to try to test what happens if in the non poxed city i´ve also reported, i do the following:
- run it now (i´ve not opened since the last upgrade but, the SC4 file is changed in 200 kb)
- then save
- then re-enter and pray and see if pox has arrived to the city
- if not, or if yes, test it with savegame explorer.
- Then i will change the actual one, for the backup just before doing the upgrade
- run it with the upgrade and repeat...
- if pox dont appear in any case, should be related to new plugins installed
- as i´m reading about RTMT, im going to bulldoze the new bus stops i´ve put in the poxed city
- then delete RTMT files and better put the older ones and try to open the poxed city
- lets see what happens (maybe the city is not poxed anymore?, maybe still poxed even without new RTMT, i remember to read someone says that once poxed... impossible to recover)
What do u think could happen???
Any further step you, seniors, recommend me to do, to do instead of one i´ve mentioned, or to include in some position???
If nothing good occurs, i´m going to try to go back to the last backup, and reinstall all the stuff i´ve recently upgraded, all but not RTMT and lets see... notice that my network subfile in poxed city is under 6 mbs and the one from non poxed, over 17...
one more... should the skipping 1 to 6 z´s method steps solve my problem even with RTMT3.60 as now?? this is forever? have to repeat sometimes when pox attacks? how it works in this way??
i remember, my understanding of 26 post pages of english is limitated, be good with me
At last, thank u very very much for all the tests, the plugs, the props, the... all in SC4devotion... you´re crazy, men!!! :)
I had been playing with an old city of mine... and noticed that there were many missing props... I chanced upon this forum and did a little investigating myself... when I opened the city Greenville.sc4 .. i looked at section 2977aa47 and noticed that its a LOT larger than any of the files that others were finding... mine is 75,617,388. what the heck does that mean !!!!!!
since í´ve written my post reply some weeks ago, i´ve decided to investigate myself and i´ve done an exhaustive test to my poxed city.
(the test is reported in a Word document, to be able to go back and see the steps i´ve follow to get some solutions, which is able to anybody to see it if wants, only have to ask for it)
I have no time since august to play nothing, so i´ve not been able to continue with the test, even not able to write here... but i´m completely at your disposal if someone wants the city, its bacukps and the document to see and test somemore.
in some case of study... i´ve been able to avoid pox in a 99% of its effects, still there... but are good news.
The backup i have of the poxed city (only few weeks ago the pox strikes for the first time) show (with SC4save) no sign of pox in the results. But have 5 disabled props.
With the map that SC4save is able to show, with the localisation of all props, i´ve been able to see where the disabled props are exactly (appearing in glowing white) in the backup version with the "Prop pox free city" message.
These props all correspond to "April´s seafood shack" location. ("Newman Inc Wooden Waterfront Commercial" if i remember good)
I´m not saying that this Newman creation causes pox, i say that my disabled props are in that location (the five)
I´m not going to be able to see if in this location, some years ago, were other stuff, at least now, i´m going to see if i have more backups, but i think no other stuff never there...
Do you think, is something to do with the backup, to recover the missed props in the not poxed city, to avoid pox striking???? someone has proof reinstalling stuff in a similar case???
THANKS A LOT FOR YOUR ANSWERS!!!! (and like always, sorry if my english is not the best...)
Related to "sneekypetepuma" as i know, 2977aa47 over 16 mbs let pox to strike but, have you tested the city with SC4save? get the pox free or poxed city message?
i have other cities with elevated weights of 2977aa47 files and no pox, cause no missed props. As I know, once poxed, impossible to recover (i´m lucky to have a not poxed backup, you?)
kind regards.
Question: Will obliterating or deleting an affected city fix Prop Pox?
Quote from: Wiimeiser on June 19, 2012, 09:42:09 PM
Question: Will obliterating or deleting an affected city fix Prop Pox?
Hi Wiimeiser. Yes, obliterating or deleting the affected city will fix its Prop Pox occurrence. But this means you loose all development you have done in that city. Before starting to build it again, be sure to check if you have the PEG BDK resource file in your plugins (and if you find it, you may either remove that package or modify it according to one of my earliest posts in this thread in order for it to become harmless). It is also advisable to read the last 4-6 pages of this thread to be aware of more recent possible causes of Prop Pox. Good luck!
It's statistically difficult to prove this point, but I realize that when I blocked the growth of Maxis residential lots (all wealth), the prop pox does not surface. I used to play a region with the aforementioned problematic plugin, and only the first largest tile city was affected - and that city was constructed prior to blocking off Maxis building growth. And since it is known that the problematic timed prop appears on Maxis residential lots, the region I played provides (somewhat) circumstantial evidence that as long as Maxis residential lots don't grow, the prop pox does not manifest itself (since the props will not appear in the city tile whatsoever).
Most people never get the prop pox - it's quite rare - so I think the sample of a single player here is really not enough to show anything in these circumstances.
For purposes of Prop Pox and the network subfile, do MMPs count as props or something else? I don't have any experience with the Pox but that could be because I've never had a city's network subfile go over the critical size. All of my cities so far were begun with the known problem file PEG CDK resource installed, though I don't know that those props ever appeared on a lot in Siilijoki (no CDK lots in my towns though it's possible a different plugin used that dependency). Does that mean that my cities are potentially "ticking time bombs", susceptible to the Pox if they reach a certain size? As an adaption to my last computer's slow speed all my cities have significant areas covered by water where lots will never be placed (large tiles still played excruciatingly slow) so hopefully I never reach the critical network subfile size.
Thanks in advance for clarifying the issue here :thumbsup:
Quote from: noahclem on November 20, 2012, 12:07:18 AM
For purposes of Prop Pox and the network subfile, do MMPs count as props or something else?
Technically MMPs are counted as flora and as far as I know flora isn't stored in the network subfile.
Quote from: noahclem on November 20, 2012, 12:07:18 AM
All of my cities so far were begun with the known problem file PEG CDK resource installed, though I don't know that those props ever appeared on a lot in Siilijoki (no CDK lots in my towns though it's possible a different plugin used that dependency). Does that mean that my cities are potentially "ticking time bombs", susceptible to the Pox if they reach a certain size?
Since the issue is improperly modded Maxis props, it's certainly possible other lots use a poxed prop - so to speak - so yes, your cities could become affected if the network subfile grows large enough. You could depox the CDK file fairly simple though, just delete the simulator properties from the exampler files. Or delete the exampler files alltogther since they're Maxis props to begin with, so there won't be any brown boxes or anything.
Doesn't SC4Save tell you if your city is poxed at any time? Or only when you go over the file size?
Cheers
Willy
Only after you've gone over the filesize and the game has corrupted the network subfile.
Well, Noah, then you could always run a test on your cities: turn the water into land, and build something prop-heavy on it (like seasonal forest lots or something) to push it over the size. Then see if it's poxed.
Cheers
Willy
I've just spent two days reading this thread (and gosh there is a lot of great info in here &apls &apls &apls :thumbsup:)
I have the BDK file and I have the RTMT and SG bus stops, so what is my course of action?
I would very much like to use both of these in the game (without the pox issue) if this is possible.
Sorry, but my head is spinning with all this info so I'm not entirely sure what to do now. I think for the BDK i'll have to go for either the 2nd or 3rd option, but what about the busses, were those confirmed as a prop pox cause? I have the 3.6 RTMT installed.
Edit: Oh and forgot to mention that I have the pox at the moment in several cities, so the "don't worry if you build small cities" part doesn't apply to me in some cases :D
Quote from: asser on December 05, 2012, 03:28:50 PM
I have the RTMT and SG bus stops, so what is my course of action?
I would very much like to use both of these in the game (without the pox issue) if this is possible.
Sorry, but my head is spinning with all this info so I'm not entirely sure what to do now. I think for the BDK i'll have to go for either the 2nd or 3rd option, but what about the busses, were those confirmed as a prop pox cause? I have the 3.6 RTMT installed.
As far as RTMT goes, as long as you follow the installation directions, you should definitely have no problems with the prop pox. And if you follow the instructions properly, you can use RTMT with SG's bus shelters along with SG's standalone bus stops with no problems. Many people do.
Great news on the RTMT/SG
I'm trying to replace the props on the lots, but when I try to save I get the error saying "lots must have a base texture for each lot" I should have all dependencies installed. Is there some trick I'm missing?
The lot looks like this in LE
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fstatic.nihei.dk%2Fsc4devotion%2Fforum%2FlotEditorPegNoBaseTexture.PNG&hash=416a89073685b0dda5824d1159ac5f3608169cf7)
As far as I recall there shouldn't be a texture for the sand?
Every tile in LE needs a base texture, yes. You can remove it afterwards in Reader. Open your LOT file, and find the LotConfigPropertyLotObject line starting with 0x00000002 and ending with the texture's IID. Delete that line, right-click and Reindex Lotconfig. Done.
Cheers
Willy
I have a question for the Prop Pox experts. It's quite clear that replacing an untimed prop with a timed version of the same prop using the same TGI can trigger the Prop Pox. I'm currently working with a situation where a Maxis timed prop is overwritten by a timed prop with the same TGI. However, the newer prop is larger, because it has a second RKT4 - in this case an RKT4 xm, which allows the prop to be mirrored. So there's a second timed RKT4 in the second prop. Is this a possible cause of the Prop Pox? This prop has been around for years, apparently with no problems, but instances of something that at least resembles the Prop Pox (and may very well be the Prop Pox) have arisen recently.
While I'm no expert on the subject I'd reckon it could be reason for concern indeed. As I understand it the pox is caused when there're two exemplars with the same TGI which differ in size, i.e. the amount of information each hold.
Quote from: bap on February 24, 2009, 08:51:00 AM
Now, when SC4 game reads its vanilla files, it sets a buffer of Ni bytes to store the info of prop i in memory. When it later reads again the info of that prop in the custom prop file it find 73 extra bytes of information to store and it keeps writing beyond the expected final memory position of that prop. Thus, it overwrites other things and messes up the program buffer. This is memory overflow, an easy way of loosing track of how many props you have installed and where in memory the corresponding info starts/ends.
The 73 bytes mentioned pertains to the specific example
bap gives but it's easy to see how the same memory overflow applies in this case. To see if a city is affected, check the size of the network subfile. (http://sc4devotion.com/forums/index.php?topic=7066.msg225648#msg225648)
I got Prop Pox in my main city. Fortunately, thanks to the information contained here and following z's steps (http://sc4devotion.com/forums/index.php?topic=7066.msg385144#msg385144), the Prop Pox is solved.
There is only one thing I could not fix: the MMP that I put over some Lots disappear once I have solved the PropPox. When the city got Prop Pox the MMP over the Lots remains, but when Prop Pox is solved the MMP disappear &ops.
So now I got MMP_over_Lot Pox $%Grinno$%
Someone has any idea how to keep MMP on the Lots? There is a file that contains MMP information in the city file? If so, I could copy the file from the poxed city file to the healthy city file... &Thk/(
PD: No problem with the MMP over the "normal" terrain.
According to our hypothesis about the prop pox, the problem isn't related to the exemplar or its size (ie the "definition" of a prop), instead it is related to the different (wrong) size of the prop instance (or "reference", if you prefer) in the savegame. It's not the exemplar itself that is saved in the savegame, but instead a much stripped-down reference, which contains information like the IID, along with the "positioning" stuff, like coordinates, orientation etc (these are not contained into the exemplar of course). Everything else (model's TGI, name, LTEXT, behaviour on slopes etc) are properties that are read from the exemplar (and that's why we can change a prop's model, for example, without problems). Timed props are different, in that they need to store additional information in the savegame, like state, days since last activation etc, resulting in a different length of the record to be written in the savegame. It seems that the game doesn't check the length of the record saved in the savegame (it may actually not even precede the record with a "length" field - to save space), instead it seems to determine the record size by checking the prop exemplar (a timed prop creates a longer "prop reference record"), so if the prop reference was created with a different timed/untimed definition (and then this definition is changed by installing/uninstalling a plugin that overrides the prop, redifining it from simple to timed or vice versa), the program is "lost", and the prop pox occurs.
So the answer to your question is find the record lengths of the two props. The exemplar size makes no difference, the key is the size of the prop reference records generated in each case. If the record lenghts are equal, there will be no pox, although the prop's activation state may be wrong when it is first loaded (and it will remain wrong until reset, eg in a game-year).
Please note that a prop that contains a RKT4 property isn't necessarily timed. The RKT4 may simply display multiple models (through a single exemplar), or just shift a model's position, or even display different models during the day and nighttime (using the NightTimeChange property). Such a prop is NOT timed and no additional information is saved in the savegame, as the game does not need to keep track of it; it just displays different models during the day and the night. As for the RKT4xm, I have only seen this property (defining additional, "mirrored" models) in network props, where a network tile may be defined as a mirrored version of another one. I believe such props aren't "timed" either.
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.
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.
Quote from: Magneto on May 06, 2013, 10:37:14 AM
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.
vortext, I had not seen your reply. Thanks for the explanation :thumbsup:
Cogeo: slight confusion here... I don't want to interfere with flora, I just want to replace the maxis props trees.
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.
Quote from: cogeo on October 14, 2010, 10:21:54 AM...
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*
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.
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).
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.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi.imgur.com%2Ft429bRQ.jpg&hash=52ff62e94406d34465dd2e67dddd1344db4beb4e)
Note the stadium without seats in the southeast end, underneath a cloud. This was the first instance I noticed props disappearing from the city.
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)
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?
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).
So then, what size should I keep it at?
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...
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.
Wait, so deleting the props as advised on the first page actually worsens the problem?
Quote from: Kuewr665 on November 29, 2013, 10:09:53 AM
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.
Quote from: z on November 29, 2013, 02:01:55 PM
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.
So maybe it's clearing the wrong amount of data, which leads to the whole thing becoming horribly misaligned?
Quote from: Wiimeiser on November 30, 2013, 04:30:13 AM
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.
There's a reference to modded Maxis props in the file PEG_CDK--IND_205.dat of an early post. Which are the modded props?
The beach umbrella. It may show up in many places besides the beach, such as on lawn tables.
To be on the safe side, it is better to assume that the suspicious props are:
R1x1x2_BeachChair_29B2,
R1x1x3_PatioChair_290D,
R1x2x2_Recliner_2911, and
R2x3x2_$$Beachumbrella_2900
I did not find them in PEG_CDK--IND_205.dat.
This (http://sc4devotion.com/forums/index.php?topic=7066.msg225117#msg225117) is the post I am referencing that mentions modded Maxis props in the file.
Kuewr665, the modded versions of these props are not in PEG_CDK--IND_205.dat,
but in PEG-OWW2_BDK_RESOURCE.DAT file.
Can someone confirm or debunk what Haljackey said on his "Building a City from Scratch" series on Youtube that there is also an item (or several items) within PEG's Mountain Theme Pack (MTP) series that causes Prop Pox?
https://www.youtube.com/watch?v=k4i4UudLzcQ
There is an item in a very old version of an MTP resource pack that is confirmed to cause Prop Pox. That prop is not used in modern (The ones you can download) versions of the MTP and is no longer available for download. At the time of diagnosis, the only way to obtain it was to obtain a discontinued donation CD from Pegasus that contains the original versions of the MTP and CDK.
So I would say no, there is no evidence to support the notion that the Modern version of the MTP causes Prop Pox. However, the Coastal Development Kit's Beach Development Kit module on the other hand has a publicly downloadable prop that does cause Prop Pox.
@jdenm8: Thanks for the clarification :thumbsup:
So I guess Haljackey just had a lot of really old stuff in his stash then eh?
Hello Guys,
first of all a big "Thank You" for this Thread an the whole Community.
But i'm not (exclusively ;)) here for Praise.
To clarify...i have PropPox in my biggest and most beautiful City (large City Tile, 750.000 Residents, over 4 gigs of plugins...i know too much but i can't help it).
I started the City some Months ago and have been adding mods ever since including the mentioned Beach Kit from Pegasus.
As i was occupied with building other stuff, i got around testing the beach last week (and realized my City was infected with PropPox on Sunday).
So now i have a save with the infected City and a save without Infection (2 Weeks old, SC4Save says so) but both had that Beach Kit installed (deleted the Props yesterday).
If i use the older Save, will my City get PropPox again (Beach Kit was installed but never plopped)?
Sorry if this question was answered before. I read the whole Thread but it is still unclear to me (and SC4Save says my City is fine)!
I've got a weird case of what I thought was PropPox. In many of my cities, the trees and lot details disappear no matter the zoom level, and the city appears all but pox'd entirely. However, on inspection with the SC4Save utility, there are no missing props, and none of my cities are infected. I'm wondering if these might be corrupt save files or a graphics card issue (I don't have it installed on a second computer to test)?
Quote from: Stargazer2893 on April 01, 2014, 04:39:07 AM
I started the City some Months ago and have been adding mods ever since including the mentioned Beach Kit from Pegasus.
As i was occupied with building other stuff, i got around testing the beach last week (and realized my City was infected with PropPox on Sunday).
So now i have a save with the infected City and a save without Infection (2 Weeks old, SC4Save says so) but both had that Beach Kit installed (deleted the Props yesterday).
If i use the older Save, will my City get PropPox again (Beach Kit was installed but never plopped)?
Sorry if this question was answered before. I read the whole Thread but it is still unclear to me (and SC4Save says my City is fine)!
Stargazer2893, please have a look here http://sc4devotion.com/forums/index.php?topic=7066.msg353628#msg353628 (http://sc4devotion.com/forums/index.php?topic=7066.msg353628#msg353628) for an answer to part of your question. Prop pox is not produced directly by any BDK beach ploppable lots, but by a modified prop included in that file, the beach umbrela, that appear frequently in the backyard of several Maxis low-density R$ grow lots. When one of these lots grow with that modified prop, you are in your way to Prop Pox. Your city will be "infected" if/when one of these lots gets destroyed/replaced by another lot; at that point the offending prop becomes 'disabled'. Several disabled props mess us the savegame file when the 'props' subfile goes beyond the (compressed) 16 Mby limit. Therefore, even if a city is not marked as "Prop Poxed" in SC4Save, it might already be infected. I suggest you load your 2 weeks old saved city in SC4Save and look for
disabled props. If there are some, it means your city is already infected although not yet "poxed". It there are no disabled props, there is a reasonable chance that this saved version is indeed free from Prop Pox, meaning that no Maxis low-density R$ lots with the offendind prop (beach umbrela) had time to grow in your city before you saved it.
Quote from: Floydian on April 01, 2014, 02:46:12 PM
I've got a weird case of what I thought was PropPox. In many of my cities, the trees and lot details disappear no matter the zoom level, and the city appears all but pox'd entirely. However, on inspection with the SC4Save utility, there are no missing props, and none of my cities are infected. I'm wondering if these might be corrupt save files or a graphics card issue (I don't have it installed on a second computer to test)?
Floydian, this may indeed be a graphical problem. When one runs one of Maxis updates (EP1 or BAT), the graphics settings are reset to low, making most of lots props to apparently disappear. Please check whether your graphics are set to 'low'. If this is the case, your props will came back if you set graphics to 'high' or if you choose hardware rendering mode.
Lucky me still has a backup save from 5th of March without any disabled props.
So now i have 3 Saves, one with no disabled props, one with 952 disabled props and one with Prop Pox.
Trying to comprehend your post (http://sc4devotion.com/forums/index.php?topic=7066.msg353628#msg353628) i compared my 3 Saves and found something which doesn't quite match your post.
The PropRecordView from the Save/City with 952 dis. Props shows some Entries with Appearance Flag 0x04 but not the IID 0X29000000 but 0x00000000 instead (i didn't find any with 0x2900000). The Size of those Entries is 0x00000058.
As far as i understood your Post it should not look like this until the PPox visualizes. Right?
The City with PPox has nearly exactly those entries (looks like your Screenshot).
And the oldest one has of course none of those 0x04 Appearance Flag Entries.
In the neighbouring City i have 1 disabled Prop which fits your description to the letter.
I'll switch to a backup there as well but im curious why i can't find the Entries you mention, in my biggest City. Just want to make sure that i don't have another Mod installled which uses Maxis-Props the way Pegs BDK uses them...
Oh and just for information. I never zoned Low Density Res Zones.
The Query says i have 3419 High and 3 Medium Density Tiles in my City (don't ask why 3 Medium...i just can't find them).
And regarding Pegs way to handle this Situation...
I bet my Props-Subfile is this large because of Pegs Seasonal Woods (yes...i do plop them wherever it fits. I'm sick of plopping Trees in Mayor Mode...takes ages and looks ugly).
He arguments nobody will ever get this but releases Mods which bloat the Props-File like hell (if i'm right of course) and then ignores hints given to him by fellow users, who invested so much time finding the cause of PropPox.
Thinking about how many users will stumble upon his (truly beautiful) CDK and then eventually get PropPox-Infection, makes me angry.
Anyway...thanks for your help. :)
Quote from: bap on April 01, 2014, 07:25:46 PM
Quote from: Floydian on April 01, 2014, 02:46:12 PM
I've got a weird case of what I thought was PropPox. In many of my cities, the trees and lot details disappear no matter the zoom level, and the city appears all but pox'd entirely. However, on inspection with the SC4Save utility, there are no missing props, and none of my cities are infected. I'm wondering if these might be corrupt save files or a graphics card issue (I don't have it installed on a second computer to test)?
Floydian, this may indeed be a graphical problem. When one runs one of Maxis updates (EP1 or BAT), the graphics settings are reset to low, making most of lots props to apparently disappear. Please check whether your graphics are set to 'low'. If this is the case, your props will came back if you set graphics to 'high' or if you choose hardware rendering mode.
Yeah, the same thing happened to me, too. You just have to have the "city detail" set on high. Even if you have it on medium (which I did before), not all your props show up, apparently. At least it doesn't really affect my game performance having this on high.
Just to summarize, if you're like me who doesn't dabble in any form of modding, to avoid Prop Pox all one must keep in mind is/are to:
1. Avoid Custom Content which have been identified to cause Prop Pox like PEG's BDK.
And,
2. Avoid playing on large City Tiles.
Is that correct?
If I understand it correctly #1 is paramount, #2 is a precaution if you already have the pox inducing content in use so the savegame doesn't reach critical size as quickly.
Quote from: vortext on May 01, 2014, 07:16:52 AM
#2 is a precaution if you already have the pox inducing content in use so the savegame doesn't reach critical size as quickly.
So does that mean if you never had nor used the Custom content in question to begin with, say you're new to the game and just started growing your Plugins folder, you can play with large city tiles with no worries of ever getting Poxed?
Yes. If you're (re)building your plugins folder without the custom content in question and start in a new region, you have nothing to worry about regarding large tiles.
Quote from: vortext on May 02, 2014, 02:19:20 AM
Yes. If you're (re)building your plugins folder without the custom content in question and start in a new region, you have nothing to worry about regarding large tiles.
Thanks for the confirmation :thumbsup:
I haven't played on large city tiles since I started playing SC4 again this January after I bought it from steam, whilst rebuilding my Plugins folder & having read this thread some time ago.
I was so worried about playing on large city tiles even if I do not use any of the CC in question but now you've put my mind at ease &apls
So in the end, it was Pegasus' plugin that causes prop poxing. He quite defended himself well though.
Quote from: jmsepe on May 02, 2014, 05:31:22 AM
So in the end, it was Pegasus' plugin that causes prop poxing. He quite defended himself well though.
It's a real shame really as his BDK set was a good item to have. And to this day I have yet to find a newer Beach set CC that took the same path Pegasus took with his BDK, that is making the Beach lots have no base textures.
Well, not so fast. Not all poxed cities have Pegasus' plugin. For example, I have one poxed city that doesn't. Other sources of the pox do exist; they just haven't been identified.
Nevertheless, your chances of getting the pox in a big city are extremely small, and I wouldn't worry about it. Only a relatively small number of truly poxed cities have ever surfaced.
Quote from: z on May 02, 2014, 08:16:40 AM
Well, not so fast. Not all poxed cities have Pegasus' plugin. For example, I have one poxed city that doesn't. Other sources of the pox do exist; they just haven't been identified.
Hope you guys will eventually narrow down which other mods causes Prop Pox so Pegasus will no longer feel singled out.
Tropod is currently making a tool that scans plugins and reports conflicts (and I hope overrides as well). It wouldn't be a big deal to add a check for the prop-pox condition. The check is simple, find simple props overridden as timed or vice versa. As props are referenced by the Instance ID only, the Group ID should be ignored, ie two pop exemplars that have the same IID but different GID should be considered conflicting/overriding, not unrelated. I was planning to make such a tool myself, but then Tropod started making his own, so I backed out. Maybe someone could just tell him.
Another setting that could cause prop-pox is uninstalling a timed prop (custom content) for which there is at least one reference (instance) in the city file (eg a prop instance in a grown or plopped lot). Making a tool that can detect this is much harder though, as it requires checking both the plugins and the city files.
Speaking of Timed Props as the real culprit, could you guys check if this "Game Clock" Park lot from Rivit is safe to have or not?
http://community.simtropolis.com/files/file/29328-game-clock/
Rivit is one of the safest developers in the community. His experience in computers and extensive examination of the SC4 Data files leads one to consider his files as usually on the level provided you follow the directions.
That being said, the clock should be safe as it uses new props and new exemplars. Prop Pox is typically caused by replacing non-timed props with rotating/timed ones. Since the clock doesn't replace any, it should be fine. Also, it should be noted that the plagued files by PEG can be used if one installs them before any other development, or if you use a Maxis blocker to prevent the non-timed instances from appearing.
Quote from: APSMS on May 04, 2014, 01:01:47 AM
Also, it should be noted that the plagued files by PEG can be used if one installs them before any other development, or if you use a Maxis blocker to prevent the non-timed instances from appearing.
About the part I highlighted, is that true? If so then that truly is some great news as I do have Maxis Blockers in my Plugins folder :thumbsup: &apls
Well, I wouldn't say it if I didn't believe it to be so.
If I were you I'd read up through this forum thread and elsewhere to verify, though I did read it somewhere reliable. The main issue with that sort of fix is that you can't have any Maxis buildings built that have this modified prop instance anywhere in your cities (if you plan on adapting it to existing cities). The other catch, of course, is that you have to have enough plugins to compensate. The Maxis stuff may not be the world's greatest, but it is plentiful and varied, so be prepared to deal with the medicine required for the cure.
I think the problem may also be rectified if Maxis buildings are only built after the replacement is installed so that they only reference the timed instance, but I think that is a more risky solution. A lot of this stuff has been tested by others more patient and knowledgeable than me, so some searching of the forums seems like a good use of your time if you're experiencing problems. I think I've experienced mild prop pox before, but haven't ever had anything quite as severe and some of the painful examples mentioned in this thread; I've had PEG's seaports and CDK installed ever since I discovered CC, so that might have something to do with it. I can't really be sure, though.
Hm, I'm not quite sure if a Maxis blocker would suffice to prevent the pox from surfacing since there'd still be duplicate exemplar files with the same IID floating around. So the game would still read/write both exemplars one after another and as they differ in size, the savegame could still become corrupted after a while. That's what I understand to be the main issue at least.
That said, Rivits clock is safe to use. As APSMS said, Rivit is an incredibly knowledgeable member of the community. If there was any problem with the clock to begin with (which I highly doubt anyway) it would've been corrected by now.
The problem with the prop pox happens only when the conflicting props are deleted. This, of course, happens automatically as new buildings grow and replace older ones. If done correctly, a prop blocker would work, because there would not be multiple IIDs of the prop in the game - there would only be the IID of the prop blocker. However, such a prop blocker would have to be in your Plugins folder before you started building your city, as the first time a conflicting plugin was deleted, the groundwork for the later appearance of the Prop Pox would be set.
Hi Sim-Folks,
I've been away for soooooome time now but decided to return to SC4. Unfortunately I discovered a problem with my last city I develeoped. I do have several zoned areas where the buidlings decided to disappear:
(https://www.mediafire.com/convkey/8b3f/oaxm4j3b6x8iibx6g.jpg)
As you can see, there are some things on this residential zone like cars, .. but the building itself is missing. I also can bulldog the zone, then a new building will appear - so the zone clearly isn't empty itself. My question now is: is this what is called prop pox? Or am I encountering a different problem here?
It appears to be a different issue as the lot is also missing textures, which are unaffected by the pox. My best guess is you're simply missing some dependencies.
Well the funny thing is I cannot bring up the descriptopn of the lot/building, so I cannot find out what might be missing. ()sad()
Quote from: Rady on July 11, 2014, 10:42:26 AM
Well the funny thing is I cannot bring up the descriptopn of the lot/building, so I cannot find out what might be missing. ()sad()
I have had this problem before to. I agree this is not Prop Pox. The way I fixed this was to either delete the building again or use the unzone and unzone the lot. Also, as much as you don't want to, sometimes using the Tera Form tools and try lowering that lot down to sea and leveling it back up. If the dependency (cies) are still there, it may be possible to plop a new building right on top to hide them. FINALLY, one last ditch effort is to prop a single street in each square may also get rid of the cies that are there.
dyoungyn
Quote from: Rady on July 11, 2014, 10:42:26 AM
Well the funny thing is I cannot bring up the descriptopn of the lot/building, so I cannot find out what might be missing. ()sad()
This is either caused by an "immortal lot" or the information needed for the game to reference it (especially in the case of Custom UIs) is part of a dependency that you are missing, probably the same one containing the building. This is in no way indicative of prop pox.
Try removing it with
this (http://sc4devotion.com/csxlex/lex_filedesc.php?lotGET=2356) tool.
If things grow like that then you simply need to know what you installed, check the readme and then install whatever dependenc(y/ies) you are missing.
Installing content without checking you've the right dependencies installed first leads to these problems. So unless you test content as you go, if you've no idea what this is it's probably going to take you a while to go through your plug-ins and find it, there is no quicker solution, sorry.
Quote from: mgb204 on July 13, 2014, 08:05:31 AM
Quote from: Rady on July 11, 2014, 10:42:26 AM
Well the funny thing is I cannot bring up the descriptopn of the lot/building, so I cannot find out what might be missing. ()sad()
This is either caused by an "immortal lot" or the information needed for the game to reference it (especially in the case of Custom UIs) is part of a dependency that you are missing, probably the same one containing the building. This is in no way indicative of prop pox.
Try removing it with this (http://sc4devotion.com/csxlex/lex_filedesc.php?lotGET=2356) tool.
If things grow like that then you simply need to know what you installed, check the readme and then install whatever dependenc(y/ies) you are missing.
Installing content without checking you've the right dependencies installed first leads to these problems. So unless you test content as you go, if you've no idea what this is it's probably going to take you a while to go through your plug-ins and find it, there is no quicker solution, sorry.
Well, first, I'm happy to hear tthat this is not the Prop Pox :) As for the missing dependencies, the main problem is that I bought a new PC a year ago and transferred SC to this one one, ans that I paused SC4 for some years. Both facts add - well, let's say ... some difficulty to the situation :)
I already spent some months cleaning up & checking the plugins folder, re-creating the DAMN menue and so on.
o, it seems some works lies ahead still :)
Thank you folks!
So I finally managed to get my own poxed city. I did something stupid though, so not too much of a loss, as I backed up everything before I did it. Removing SPAM screwed up the overall industrial and commercial demand anyway, so it was a failed experiment all over. But that's a given for demand mods.
I should probably have removed all farms and let the cities run for a while before removing the mod. So, as I said, my own fault.
Hi guys... i didn't write so often here but i'm a SC4 devotion friend since 2008
I was affected few years ago by prop pox and rage quit with simcity 4 for a while...now i'm back and have a question about p.pox:
I started a new region, with only NAM and few girafe's trees..i just have built highways and rails and developed a tiny village of 3k people
Now..my question is...if i install custom content(except the PEG's one with timed props) they will conflict with maxis's one and start the pox?
What I have discovered by experiment after experiment, is that when one starts a map (Large map), develop then use many lots. As one is backing up and loses the lot files for some reason and re-downloads and the the creator changed something, then go back into the map and presto, prop plox. Lesson learned is that I deal with what I have and hope and pray that I do not have to re-download the same lots risking prop plox or just not re-download.
dyoungyn
Ciro,
in my experience simply replacing maxis props with other static props is fine. In fact, though I use the timed PEG props I've yet to see a serious case of the pox in any of my cities, in part because I'm probably not 100% aware of how it looks, but also because it's just never been that bad (knock on wood).
I believe that even the timed replacement props won't cause prop pox as long as you install the props before you begin building, so that you aren't replacing the instance improperly and causing a read error in the file sizes.
Quote from: APSMS on August 29, 2014, 04:57:26 PM
Ciro,
in my experience simply replacing maxis props with other static props is fine. In fact, though I use the timed PEG props I've yet to see a serious case of the pox in any of my cities, in part because I'm probably not 100% aware of how it looks, but also because it's just never been that bad (knock on wood).
I believe that even the timed replacement props won't cause prop pox as long as you install the props before you begin building, so that you aren't replacing the instance improperly and causing a read error in the file sizes.
So it should be ok if I install custom contents over Maxis's one,even if i already begin with few contents...If i get it correctly,the prop pox will occurs if you modify those maxis timed props...So if i install and then uninstall custom content with maxis timed props p.pox will occur..thank you
Sorry for the bump in this thread, but I have spent today reading through most of it. Anyway I have experienced prop pox once in one of my cities, but I managed to minimize it and stop it spreading by rebuilding prop poxxed areas, saving and retaining saves where the prop pox reduced in size. I wasn't using Peg's BDK nor did I have it in my plugins but I still managed to get the prop pox anyway.
Anyway, from reading this thread I see comments that Pegasus never altered the BDK file and the four infamous props. But I checked the BDK development thread in Simpeg4 and in the last post Pegasus added this edit;
EDIT: Attached is a patch file for the BDK.
This patch file returns 4 modified props used in the BDK back to their default values. Although this patch will do nothing except detract from the appearance of the BDK lots... it was created in anticipation of panic stemming from a soon to be
annouced prop issue.
If you have experienced any issues with the props on these lots or worry that you might, just copy the DAT into the BDK folder. No need to redownload any BDK material or bulldoze any lots.
« Last Edit: February 24, 2009, 03:45:42 PM by Pegasus »
If these four props are restored to their original values does that mean they are safe to use, and thus the BDK mod can be used without causing prop pox? Have people downloaded the patched file and experienced prop pox because of it?
I just want to make sure that Pegasus hasn't been slandered here, because if some people are saying he never fixed this particular file when he had, then maybe that's why Pegasus feels hacked off?
QuoteI just want to make sure that Pegasus hasn't been slandered here, because if some people are saying he never fixed this particular file when he had, then maybe that's why Pegasus feels hacked off?
It's nice that he finally decided to release a fix for that (five years ago), even if he continued to deny any responsibility. His answer to the (alleged) problem was quiet enough that it would never have had a chance of fixing things for any significant fraction of the people that downloaded the files in question. And from my experience all these old bitter conflicts that seem stupid or silly are rooted in some legitimate disputes that we should mostly just be happy aren't relevant anymore.
The prop pox issue isn't black and white. You'd probably be safe with the fixed files but I really don't know. I
am pretty sure prop-pox-style problems can also be caused by other problems with plugin management, as has happened to me, but if I were you I don't think I'd take the chance of messing with those files. Have you seen the historic harbor release on the stex and plex? As nice as those BDK files looked back in the day I think they're more or less superseded.
Quote from: Vizoria on October 27, 2014, 12:19:39 PM
Anyway, from reading this thread I see comments that Pegasus never altered the BDK file and the four infamous props. But I checked the BDK development thread in Simpeg4 and in the last post Pegasus added this edit;
EDIT: Attached is a patch file for the BDK.
This patch file returns 4 modified props used in the BDK back to their default values. Although this patch will do nothing except detract from the appearance of the BDK lots... it was created in anticipation of panic stemming from a soon to be
annouced prop issue.
If you have experienced any issues with the props on these lots or worry that you might, just copy the DAT into the BDK folder. No need to redownload any BDK material or bulldoze any lots.
« Last Edit: February 24, 2009, 03:45:42 PM by Pegasus »
If these four props are restored to their original values does that mean they are safe to use, and thus the BDK mod can be used without causing prop pox? Have people downloaded the patched file and experienced prop pox because of it?
I just want to make sure that Pegasus hasn't been slandered here, because if some people are saying he never fixed this particular file when he had, then maybe that's why Pegasus feels hacked off?
I sent Pegasus a PM the day before starting this thread (1) to let him know in advance of the prop pox findings, (2) to let him be aware that I was opening a thread here to let people know about those findings, and (3) to ask him if he would consider releasing an updated version of the BDK file with the needed corrections. In his answer he denied the problem and did not mention any intention to correct the file. I never got any other message from Pegasus.
I just checked at Simpeg. The message you quote is an edit to a 2007 December 13 message, that goes unnoticed in the before-last page of the BDK development thread. And the patch file is not attached to that message. Nor does the main BDK release in the PLEX has been updated. The BDK beach development kit page says "Uploaded: Dec 11 2007 - 12:01pm, Updated: Never". So, no patch available, no update to the affected file at PLEX. It seems the file have not been fixed after all. But the solution is simple and the affected props can be easily corrected in ilive's Reader (as explained in reply #3). :)
this is my first post in this forum and im not sure im the right place ...
my city was struck by prop pox in the past, i searched the internet and found this topic...and i would like to thank bap for his tests...it was caused by the bdk file...i edit the file (deleting the said exemplars using ilives as instructed) and never get prop pox ever since... :)
i did add more files to my plugins folder...making backups and testing it with sc4save as i add them...i downloaded the props needed for uki agricultural http://uki-sim.seesaa.net/ (this particular files doesn't cause prop pox however)...
when i tested two of my downloads from http://hide-inoki.com/bbs/phpbb2/viewtopic.php?p=3187#3187
- jim parking pack (quite a few files from here)
- jim carprop pack 1.2 (Jim CarProp v1.2 SC4Desc & Jim CarProp v1.2 SC4Model )
i got prop poxes, at least thats what the sc4save tells me...im not sure wether it is true, can anyone confirm about what i just found out...
*note:
-i didn't notify the author of the prop packs as im not registered to that site
-sorry for my bad english.
My largest city just yesterday came down with pox after which I of course read this clear and very informative thread.
No need to discuss all of the details as they have already been explained here.
Couple of important notes for future reference.
I did have the BDK file in question in my plugins for over three years. Have also had the Maxis residential blocker in my plugins for just as long.
I recently removed the Maxis blocker in an attempt to grow some late stage Maxis Euro Modern Apt's I have noticed in some CJ's.
The prop pox did not occur until I removed the Maxis Blocker. Thus confirming an observation that someone else noted regarding the Maxis blocker in a previous post.
I have since removed the BDK file, obliterated my city and will soon embark on a static landmark and park creating binge.
ahh!! just got infected with prop pox!!!
I'm not tech savvy at ALL, so the only thing I can really add is in my case I was on a large tile, LOTS of maxis low density housing, and lots of PEG random woods v206 (which is basically a square filled with maxis trees). I know I was reading somewhere that there might be correlation with all these maxis props showing up on low dense housing, and from what I imagine my random woods parks.
I did what some people suggested and put graphics to low, saved, then back to high, and played. Is this something I can do over and over? Or is there a limit to how many times I can do this?
Also, I play different cities, each has its own separate plugins folder. I just swap plugins folders whenever I want to change cities. Are my other cities and other separate plugins folder for those cities at risk for the same thing here??
Any answers appreciated, thanks
Are you really, really sure you have got prop pox, because the reality of this problem is that it is very unlikely. Why don't you start by telling us exactly what is wrong with your city, when it happened (were any changes to your plugins made for example) and any other useful information. If you have prop pox you can pretty much delete that city because it's toast.
Well, let's see, this city I basically didn't play for maybe a year, but last week I started playing it again since I got my new computer. What I do is every city I make, I save the plugins folder, so that way if I want to start playing it again, I just put that plugins folder in and walaa, I got everything I need.
So I first noticed this last year when playing, one of my huge subway stations, the entire model was missing and it was just the tile there. When I query it all the stats were normal, and it was functioning normal. I didn't think much of it, I thought it was just the plugin itself that was tripping out, so I was like eventually I'll just get a diff station. One wierd thing tho, at that time, I demolished it and put a new one there, and it was still missing model. So wether this is actually prop pox or not I can't say for sure. But thinking back, I also noticed my city seemed a lot more empty compared to the amount of trees I thought I plopped (I have PEG random woods, which is basically a 1x1 square with a bunch of trees on it as props I'm assuming).
So I started to play again, and then I noticed for sure something was wrong. Some recently added tree parks had the trees missing, as seen here. You can see the base texture there for many of the parks I plopped, but the trees are missing. Some of the parks still have the trees.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi9.photobucket.com%2Falbums%2Fa55%2Fnasarawan%2FDowntown-Aug231451422592972.png&hash=9b3043e8234a2a301d8822ba3a3bcd4f7648550d)
I also noticed that the university was missing some buildings. Also the parking lot to the right, it is supposed to have cars and light poles sticking out. Sometimes the cars disappear, but the light poles don't, and they never look as empty as it does in this pic.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi9.photobucket.com%2Falbums%2Fa55%2Fnasarawan%2FDowntown-Aug231451422592542.png&hash=078e8697185cdf81478fd26413165cf3c30a5b07)
And here's a shot of the entire city, as you can see A LOT of low density residential, and those tree parks are used A LOT. The extreme amount of trees may be a contributing factor.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi9.photobucket.com%2Falbums%2Fa55%2Fnasarawan%2FDowntown-Aug231451422592618.png&hash=7253c16877919c5d277c9882a9974a584db827e9)
At this point I knew something was definitely wrong so I started searching the internet to see if I can figure out what's going on, and I came across this thread and a few others. I did what I read in this thread, I put the graphics city detail to low, saved, then high, then played and all of a sudden everything was back. However, I've noticed since then a few of the parks lost their trees again. Its nowhere near as bad as before, but I wouldn't be surprised if its heading back down that path.
I know there's some other stuff people were saying to do, but honestly, all that stuff went over my head. I have no clue what livereader (is that what its called, I forget..) is, or if I even have it. So I haven't verified through anything except for my gameplay experience which certainly seems to mimick prop pox.
What do you think? It def sounds like prop pox, I don't know.
I was pretty bummed out as it seemed I had to delete the city, and it was hard for me to make the highway, I didn't want to have to do that all over again. But I saw that the graphic setting trick temporarily fixed it, and honestly it doesn't bother me to have prop pox as long as I know I have the option that whenever I DO want to be able to see the props, I just have to mess with the settings. Lots of times when I'm in build mode, it doesn't bother me if some props are jacked up. Like for example, I'm bout to build a huge GLR network, as long as the lots are working its ok if the props are missing. So if this is something I can just keep doing over and over, and whenever I want to take pictures, or just see the city in full detail, I'm completely ok with doing that.
Well for sure something looks wrong, I would say if features that will not display properly in this particular city tile are appearing correctly in others in the same region running the same plugins folder (so the university is an easy way to check this) then prop pox is the most likely reason. If other city tiles have problems then that would point to errors in your plugins folder itself.
As for how it was caused, that's really a very difficult thing to answer, the fix with the Reader outlined is only for a very specific plugin. If you don't have the BDK from PEG in your plugins (assuming you never did also) then it could be quite difficult to track down the actual cause. As for saving the city, to my knowledge this is like a disease with no cure, it can only get worse as the save files are corrupted and there is no way to fix them.
It's worth going through the first few pages of this thread, as it might help you to avoid running into problems in the future, but it's also worth noting if this has happened that somewhere in your plugins this time-bomb must be lurking, and your other cities are likely infected to, however it is not certain that they will also develop the problem, certain other conditions must also be met for it to come to the surface, related to the size of the save file.
It is possible to use Datanode and check every single overwrite that exists within your plugins folder.
Somewhere in that list of possibly 20,000 plus items will be whatever Rep 4 prop is overwriting a Rep 1 prop.
Of course, this course of action is only needed if your cause of Prop Pox is currently unknown.
I remember a while back when Haljackey did his "Starting a City from the Ground up" series on Youtube, there was one episode where he did mention one of his city tiles on the same region where he was filming his video series suffered from Prop Pox and he did say the cause was the PEG MTP Trees. And I asked about that on here as well...
Quote from: CahosRahneVeloza on March 07, 2014, 12:15:43 PM
Can someone confirm or debunk what Haljackey said on his "Building a City from Scratch" series on Youtube that there is also an item (or several items) within PEG's Mountain Theme Pack (MTP) series that causes Prop Pox?
https://www.youtube.com/watch?v=k4i4UudLzcQ
...to which jdenm8 then replied with...
Quote from: jdenm8 on March 07, 2014, 07:30:07 PM
There is an item in a very old version of an MTP resource pack that is confirmed to cause Prop Pox. That prop is not used in modern (The ones you can download) versions of the MTP and is no longer available for download. At the time of diagnosis, the only way to obtain it was to obtain a discontinued donation CD from Pegasus that contains the original versions of the MTP and CDK.
So I would say no, there is no evidence to support the notion that the Modern version of the MTP causes Prop Pox. However, the Coastal Development Kit's Beach Development Kit module on the other hand has a publicly downloadable prop that does cause Prop Pox.
So yeah, nas786 if your copy of the PEG Tree parks are from that older, unsupported version then there is your culprit right there.
Quote from: mgb204 on January 31, 2015, 01:52:08 PM
Well for sure something looks wrong, I would say if features that will not display properly in this particular city tile are appearing correctly in others in the same region running the same plugins folder (so the university is an easy way to check this) then prop pox is the most likely reason. If other city tiles have problems then that would point to errors in your plugins folder itself.
As for how it was caused, that's really a very difficult thing to answer, the fix with the Reader outlined is only for a very specific plugin. If you don't have the BDK from PEG in your plugins (assuming you never did also) then it could be quite difficult to track down the actual cause. As for saving the city, to my knowledge this is like a disease with no cure, it can only get worse as the save files are corrupted and there is no way to fix them.
It's worth going through the first few pages of this thread, as it might help you to avoid running into problems in the future, but it's also worth noting if this has happened that somewhere in your plugins this time-bomb must be lurking, and your other cities are likely infected to, however it is not certain that they will also develop the problem, certain other conditions must also be met for it to come to the surface, related to the size of the save file.
Ok, I'll build a university somewhere else and run it a few times and see what happened. No other cities are nearly as filled up as this one though, so it might not show due to smaller size. Worth a try either way, thanks for the pointer
Also just to mention, after I put the graphics detail to low, then high, the university's been fine. I've probably played a few hours and saved a half dozen times since then, so far the university is fine. I just noticed a few trees from those tree parks mentioned earlier missing.
Quote from: HappyDays on January 31, 2015, 07:33:29 PM
It is possible to use Datanode and check every single overwrite that exists within your plugins folder.
Somewhere in that list of possibly 20,000 plus items will be whatever Rep 4 prop is overwriting a Rep 1 prop.
Of course, this course of action is only needed if your cause of Prop Pox is currently unknown.
At the moment, I don't know if I'll do this. I have no idea what Datanode is, where to get it, or how to use it. Like I said, I'm real bad with software. I'll try a couple things already mentioned and if that doesn't help or points toward doing this as a next step, then I'll try and do it.
**altho if this is something which will help the community at large, then I will go ahead and do this. Let me know
Quote from: CahosRahneVeloza on January 31, 2015, 07:50:05 PM
I remember a while back when Haljackey did his "Starting a City from the Ground up" series on Youtube, there was one episode where he did mention one of his city tiles on the same region where he was filming his video series suffered from Prop Pox and he did say the cause was the PEG MTP Trees. And I asked about that on here as well...
Quote from: CahosRahneVeloza on March 07, 2014, 12:15:43 PM
Can someone confirm or debunk what Haljackey said on his "Building a City from Scratch" series on Youtube that there is also an item (or several items) within PEG's Mountain Theme Pack (MTP) series that causes Prop Pox?
https://www.youtube.com/watch?v=k4i4UudLzcQ
...to which jdenm8 then replied with...
Quote from: jdenm8 on March 07, 2014, 07:30:07 PM
There is an item in a very old version of an MTP resource pack that is confirmed to cause Prop Pox. That prop is not used in modern (The ones you can download) versions of the MTP and is no longer available for download. At the time of diagnosis, the only way to obtain it was to obtain a discontinued donation CD from Pegasus that contains the original versions of the MTP and CDK.
So I would say no, there is no evidence to support the notion that the Modern version of the MTP causes Prop Pox. However, the Coastal Development Kit's Beach Development Kit module on the other hand has a publicly downloadable prop that does cause Prop Pox.
So yeah, nas786 if your copy of the PEG Tree parks are from that older, unsupported version then there is your culprit right there.
hmm, so the exact plugin I'm using is this here
http://community.simtropolis.com/files/file/4526-peg-random-woods-v206/
It seems as the PEG MTP woods came after, as stated in the description, that was the one which supposedly replaced this one that I'm using. Not sure if there is any connection or what. I don't have the PEG MTP resource pack tho. This one seems to just use the default maxis trees.
@nas786: Well there you go, as the download page you posted even states up at the very top of the page that the download is already "discontinued" meaning it is both outdated and unsupported. You should have used this one instead...
http://www.simpeg.com/forum/index.php?action=downloads;sa=view;down=9
...incidentally you should update all of your PEG plugins you have downloaded on the STEX for the ones hosted on Simpeg just to be sure.
Quote from: nas786 on January 31, 2015, 11:01:36 PM
Quote from: HappyDays on January 31, 2015, 07:33:29 PM
It is possible to use Datanode and check every single overwrite that exists within your plugins folder.
Somewhere in that list of possibly 20,000 plus items will be whatever Rep 4 prop is overwriting a Rep 1 prop.
Of course, this course of action is only needed if your cause of Prop Pox is currently unknown.
At the moment, I don't know if I'll do this. I have no idea what Datanode is, where to get it, or how to use it. Like I said, I'm real bad with software. I'll try a couple things already mentioned and if that doesn't help or points toward doing this as a next step, then I'll try and do it.
**altho if this is something which will help the community at large, then I will go ahead and do this. Let me know
Finding more sources of the Prop Pox is always beneficial.
http://community.simtropolis.com/files/file/27675-sc4datanode/
It comes with a manual that explains each function in detail. Don't worry if it seems overwhelming, as it is at first. It's just an informational tool, however, so it's impossible to break anything.
Hey guys.
Ok, so personally, I'm just riding it out. Basically playing my city, and every now n then do the low detail back to high detail graphics thing, so everything reappears, and slowly disappears again. I just love my city too much, I don't wanna see my baby go ()sad()
But as mentioned, the more we know about this whole prop pox business, the better it is for the simcity community, so I went ahead and install that datanode thing, I ran it (I scanned by plugins folder, I'm assuming that this is what I was supposed to do?). So now the thing is, how do I convey whatever information it is that the datanode gave me to all you guys? What should I look for, and what info should I post?
Its basically like a list, which has different columns, columns being -
Seq#, Entries, Dead, DIRs, Bytes, File
I was just gonna take a pic and post it here, but the list is way too long, it'd take like 50 pics just to get the whole thing up (1197 rows). I would just copy paste this beast, but doesn't seem to give me that option. So yea, anyone that knows about this program, please let me know how to show my findings. Or if I should just manually go through it and look for something and let you know, what is it?
Even if you provided pictures, it would do nothing. The problem is located within the plugins themselves. No, this is going to be a pain. I apologize.
When you've loaded your plugins, you'll a list of filters on the right side of the program's window. First click on "TGI View" and then "Overrides". You'll see a very, agonizingly long list appear on the left. I suggest you do this on a nice, quiet weekend where you have plenty of time.
There are multiple columns. The column you want to pay attention to is "Entry". The only thing you're looking for are Props. Every entry that isn't a prop can be ignored. No, these lists cannot be sorted much to your chagrin.
The column next to "Entry" is "IID". Items that share the same IID that are right next to each other on the list is the prop being overridden and the prop(s) that overrides it. Clicking on an item in the list brings up its information in a window to the right. At the top of this information window will be a mention of whether the item is overriding and what it's overriding, or if it is being overridden and by what.
Your goal is to check the "Resource Key Type" property in each prop's information listing. The prop pox occurs when a Resource Key Type 0 prop is overridden by a Resource Key Type 4 prop. Ideally, you'll eventually find this occurrence somewhere in your plugins.
Once identified, you can remove it using Reader. Datanode tells you what file the prop is from and its TGI, so this process will be quite easy. Finally, tell us the name of the affected plugin so that others can avoid your pain in the future.
ok, so this seems pretty hardcore. I've gone through some of the files, it'll probably take me a while cuz I got a few thousand. All I've seen so far is the ones that have a resource key type (this line isn't there for EVERY file, some say something else like lot resource key, which seems a completely diff thing) they will say resource key type 0 or 1, if its being overridden by a type 4 it will say so on that same line?
I'm just ignoring anything that doesn't state "resource key type 0". When I DO see that, I guess i'm just checking the entire line to see if it says anything about being overriden by type 4....
Datanode will not mention what portions of an overridden file are different. Lot resource key is something else, yes.
You want to focus on finding props with a Resource Key Type 4, not Resource Key Type 0/1.
Quote from: nas786 on February 04, 2015, 07:07:02 PM
I'm just ignoring anything that doesn't state "resource key type 0". When I DO see that, I guess i'm just checking the entire line to see if it says anything about being overriden by type 4....
As my father always said, "if the job is worth doing, it is worth doing right."
You are wasting your time looking only for type 0. It is the type 1 being overwritten by type 4 that was the problem with the Peg files.
The issue is not one type being overwritten by another, the issue is a type being overwritten by a longer type.
I went ahead and downloaded the BDK file from the STEX and loaded it up into an empty plugins folder
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi179.photobucket.com%2Falbums%2Fw298%2Fjoshua43214%2FPeg_prop1.jpg&hash=f547ecaf48158f36c140ee92e1322b9ccc8b5494)
Notice in the top I have the Maxis patio chair highlighted and it shows as a Resource Key Type 1 with 3 numbers (5AD0E817-BADB57F1-290D0000). In the bottom I have the Peg patio chair highlighted that is overwriting the Maxis chair, and it is a Resource Key Type 4 that has 16 numbers. This is a cause of prop pox.
It also illustrates what I have been saying for years, avoid the STEX when ever possible. Even reputable authors like Pegasus have stuff there that should be removed or locked. If I remember correctly, Barbyw uploaded some bats here on the LEX that had this same issue, these bats are all now either updated or locked (sorry Barbyw if I have this confused).
I might write a bit of code for checking this. I already wrote some code a while back for scanning dat files, if I expand it to scan all files it should be a simple matter to simply make sure that all props with the same TGI have the same resource key type, and generate a list of bats that have issues.
I did just install some lots that require JimCarPark Packs or whatever...urgh...there must be a way to check files before-hand to PREVENT this sort of thing....and we need a clear tutorial on HOW to do it. Here's to hoping I can save at least a 3-month old backup of my SECOND plagued tile...ugh...
I'm doing a search through SC4DataNode for overriding props, specifically a Resource Key Type 4 override either a Type 1 or 0. (Tip: Start from the bottom if you haven't had problems with any of your completely developed cities until now, likely the culprit is going to be towards the bottom and not the top). I started from the bottom and found one culprit (I think rather quickly - It is from xannepan's Seine Riverfront series JENXPARIS_QS1.dat. Now this is strange, since I've had this in my folder forever and present when I've saved a number of my big cities (have I corrupted ALL my big cities? If this is so, I give...and I guess I'm starting another new region...it is just to painful to rebuild so much). What is strange is that the prop being overridden is contained in the SAME .dat file. I'll keep you posted on any more findings.
Quote from: packersfan on February 05, 2015, 05:30:47 AM
...found one culprit (I think rather quickly - It is from xannepan's Seine Riverfront series JENXPARIS_QS1.dat.
Are you sure you're interpreting the data correctly? When I compare Xannepann's files against my entire plugins folder it does not show any prop overrides for them. Also, as one of the most experienced modders around you might want to tred carefully before making the suggestion they could be faulty. Looking at the latest release, all props have unique IDs, therefore these files are fine even if they are modified Maxis props, you must overwrite the Maxis props with the same IID and change the RTK property for this problem to occur.
---
As for the Jim Car Props, the original Maxis props are overwritten with a file (Delete Default CarProp v1.0.DAT) that overrides them with a null key (i.e. it makes them disappear). It simply doesn't have any properties pertaining to RTKs (or anything else for that matter). The new props have unique IDs and were made in such a way that they do not in fact overwrite anything, they are unique props with unique IDs that take the space the Maxis props still use, only the Maxis ones re-direct to a model that doesn't exist and so they don't appear at the same time. Long and short, there is nothing wrong with this file.
Once again the fear of prop pox is way out of proportion with reality, whatever the facts (honestly, it's not really clear) there is for 99% + of users about sod all chance of this happening. More people think they have the dreaded pox than actually understand what it is and what the best guess so far as to it's cause is. In fact if you take everything explained in this thread as fact, the simple answer is don't install the BDK and you should be fine.
I personally resent the opinion that somehow because a creators work is on the STEX it is inferior or of a poorer quality. The reality is that most content (regardless of where it was hosted) is made by people with a passion for this game and whilst errors can occur (this is some complex stuff you know), most creators take every care to ensure they do not. I think with a little bit of reading everyone can work out why PEG didn't update the BDK, come to think of it you don't see any new stuff either, just food for thought, perhaps this hysteria isn't beneficial or proportionate?
Hey, all I know is that I've caught the Prop Pox twice. First in 2012, when after I removed the BDK things ran fine on my large tiles. Now it has popped up again.
I don't know if I'm interpreting the data correctly. I admit I could be wrong. I don't wish to slander anyone. This problem is very real, though. Yeah, WE all know that it will strike only a tiny percentage of people (well it has happened to me twice and I'm looking for answers again.) This time it has affected so much in my region that I might just abandon it because it will take forever just to determine how much is messed up, much less rebuild.
When I went through all the props overrides in DataNode this came up as a RTK 1 and then the overriding one was an RTK 4. However, both prop instances were from the same file...so I don't know what that means.
I don't know why everyone is getting bent out of shape about highlighting what MAY be a problem file. If I just kept my mouth shut you wouldn't have checked the file to make sure. I LOVE the modders here and at the STEX. I know there is a risk to modding the game. When I have a pretty catastrophic problem like this which renders a large tile basically a ticking time bomb as you add more and more props to the land building a great city, I want to find the problem so it can be fixed, others can avoid/fix the problem, and I can go back to enjoying a clean game.
I'm not out to get PEG or Xannepan. I LOVE there files...I hate even thinking that Xannepann's files could have caused this because I WANT those lots in my cities!
So if it is not prop-pox, what is it? Changing the graphics setting to low and back to high does nothing. Checking in SC4Save shows that it indeed is Prop Pox'd as we define it.
Can you explain to me better what to look for when searching DataNode? I clicked on TGI and then Prop List and clicked on every two props that had the same instance code and checked that the RTKs were the same for both...and found only this ONE prop pair with a "problem"...RTK 1 overridden by an RTK 4.
I don't know if that is the problem...I'm going to do the binary test to see what happens.
Is it possible you have the now locked version of the Quais de Seine?: http://sc4devotion.com/csxlex/lex_filedesc.php?lotGET=2774
That is quite possible...I've moved on to starting a new fresh region, but it is good to have a hint that perhaps this file was bad and that I might have had a locked file. I'll have to pick up the NEW version of it!!!
When I responded to your post, I ended the response and switched to a more general comment, noting this with three hyphens. As a player I genuinely feel for you, almost every other type of problem can be resolved with an archived backup, but not this, I fully understand what that means.
Quote from: packersfan on February 05, 2015, 06:40:36 PM
Hey, all I know is that I've caught the Prop Pox twice. First in 2012, when after I removed the BDK things ran fine on my large tiles. Now it has popped up again.
If you had prop pox then your files would have been corrupted the first time, are you saying you managed to continue the region thereafter? In which case perhaps you should know those affected save files were always doomed, there is no cure, only prevention. That would suggest that the problems have been there all along and that you may not have any other "faulty" content.
In fact the mere suggestion that you can play with prop-poxed cities for 2 years without problems is far more suggestive of the fact that you don't actually have prop pox, if you did there is no magical fix, certainly not removing a single mod. I would need more information about what changes were made and things were done and specifics on how well it was working during the interim period before I could state anything as fact though.
Quote
This time it has affected so much in my region that I might just abandon it because it will take forever just to determine how much is messed up, much less rebuild.
There is simply no fix or rebuilding here, ditch the region and move on, even your backups (if you have them) will likely be corrupted too.
Quote
When I went through all the props overrides in DataNode this came up as a RTK 1 and then the overriding one was an RTK 4. However, both prop instances were from the same file...so I don't know what that means.
So you have a prop being overridden by another with a new RTK 4 exemplar, which may sound like the problem, but due to the complexity of the problem it kinda is/isn't. Yes this type of prop change is to be avoided, but unless one displays in your city, is subsequently saved and then at some point it disappears (for example you delete the content, bulldoze the lot or it upgrades in-game), the bug will not be triggered in the savefiles. Even when it is, as a user you'd have no way of knowing without checking the save files, but even then you may never actually see the problem occur.
Without looking into this in-depth I can't really comment if these files are broken or otherwise, if they are the "old, locked ones" I don't have any way to get them, so I can't help you with this.
Quote
I don't know why everyone is getting bent out of shape about highlighting what MAY be a problem file. If I just kept my mouth shut you wouldn't have checked the file to make sure. I LOVE the modders here and at the STEX. I know there is a risk to modding the game. When I have a pretty catastrophic problem like this which renders a large tile basically a ticking time bomb as you add more and more props to the land building a great city, I want to find the problem so it can be fixed, others can avoid/fix the problem, and I can go back to enjoying a clean game.
I'm not out to get PEG or Xannepan. I LOVE there files...I hate even thinking that Xannepann's files could have caused this because I WANT those lots in my cities!
Well I was a little offended by the comments of joshua43214, it's a slur on the reputation of creators, that comes across with a whiff of elitism and totally disproportionate (picking up a theme here?). I am not bent out of shape to my knowledge, the simple truth is that most content does work and won't break your game. So to suggest the only way to be safe is to ignore the vast vaults of every other file exchange as somehow prudent is frankly ridiculous.
The simple fact is, since this problem was discovered no new instances of faulty props have been found, not a single one. Look through these pages, by comparison how many have been linked as potential "prop pox" suspects. Then look at user comments with regards to those files. Users are steering clear or worried about content that simply should never have been publicly named or should have been rebutted. Many users won't spend the time it takes to go through every post here, but reading it is a cacophony of misinformed folks and needless paranoia.
I'll use the Jim Car Props as an example. I could check them very quickly and see that the file contained nothing that could possibly cause this problem because I know what I'm looking at. Yet the idea that they might cause the pox has been stated here (more than once) and you can see the evidence of the resulting paranoia on these very pages. Once a file is linked to the prop pox, for many simple guilt by association kicks in, this is sadly human nature.
Given the stigma generated I'd want to be pretty sure I was right before I'd publicly mention any file. If I seriously thought a creators file was problematic I would contact them privately before going public with the merest suggestion it might be, especially if I didn't even understand what I was looking at.
Of course if you have prop pox, telling you not to worry about it is not really helpful, but this part was not really directed at you.
Quote
So if it is not prop-pox, what is it? Changing the graphics setting to low and back to high does nothing. Checking in SC4Save shows that it indeed is Prop Pox'd as we define it.
I would have said before this sounds like what is defined here are prop pox, I was not disputing that, although given the new information I now have some doubts. Then again if SC4Save says otherwise, who am I to argue.
Quote
Can you explain to me better what to look for when searching DataNode? I clicked on TGI and then Prop List and clicked on every two props that had the same instance code and checked that the RTKs were the same for both...and found only this ONE prop pair with a "problem"...RTK 1 overridden by an RTK 4.
Yes and no, I can tell you how to search or what to look for, but as you are unable to interpret the data, I can see it getting out of hand quickly. If I could sit in front of your PC, I'd be happy to spend whatever time it takes to look into it. But I can't and from afar this becomes a vastly more difficult task.
Quote
don't know if that is the problem...I'm going to do the binary test to see what happens.
I don't understand your motivations here, if I'm not mistaken that won't help you in any way to find a problem.
If your files are corrupted now (or were before, assuming you have the pox), they can not be uncorrupted by removing plugins or anything else. Corrupted save files can not be fixed by any currently known means, primarily since there is a system in place to recognise any modified save files and reject them built into SC4. I suggest you try to read up some more on the problem, because you seem to have mis-understood what Prop Pox does to your savefiles.
What if you don't have any files that cause prop pox as defined here? You are searching for a needle in a haystack, if you are confident that the only overriding props are from one DAT (there is no QS1.DAT in the latest release FYI) then the best I can do is suggest you update to the latest version of this mod and move on. This brings us full circle, because so many people are looking for a problem that doesn't exist (that's not to say Prop Pox doesn't), however, If there is no needle in your haystacks, all the time spent searching for one is futile. Hypothetically, what if you did once have such a faulty file in your plugins, but it's long gone so the problem could exist, but you have no way of tracking it down?
This is the reality of prop pox for most people, known cases must number less than 50, confirmed cases are much lower. Here's the rub; if I told people that they had a 0.0000001% chance of something bad happening, they wouldn't think about it and just get on with life. And that's the reality of prop pox, the odds are so infinitesimally small of this problem, that by and large it's simply not worth worrying about.
On the other side what are the chances you are going to find a potential file that no one else has yet found, I would say approximately 0%, because as of now, that's the exact odds as defined by this very thread. Whilst it's heart-breaking to loose your region and I understand you want to do all you can to avoid a repeat of this, there is only so much you can do or that is worth doing when you put all the facts into perspective. I know it seems crass to simply sum up with "I know it sucks, but it shouldn't happen again so just move on" but sometimes the truth is not what people like to hear?
Just thinking aloud, if you want to be totally sure this problem won't cause such havoc again you could do the following:
- Make a regular backup of your SC4 Savefiles, keep at least 2 or 3 previous versions of the backup archived.
- When performing the backup, check the files with SC4Save to make sure they are fine.
In the event a backup showed corrupted save data, the archive should contain uncorrupted versions to restore. Worst case you'd loose the work done in the interval period between backups.
Quote from: mgb204 on February 06, 2015, 10:12:21 AM
When I responded to your post, I ended the response and switched to a more general comment, noting this with three hyphens. As a player I genuinely feel for you, almost every other type of problem can be resolved with an archived backup, but not this, I fully understand what that means.
Okay, no problem, I was just a little frustrated.
QuoteIf you had prop pox then your files would have been corrupted the first time, are you saying you managed to continue the region thereafter? In which case perhaps you should know those affected save files were always doomed, there is no cure, only prevention. That would suggest that the problems have been there all along and that you may not have any other "faulty" content.
In fact the mere suggestion that you can play with prop-poxed cities for 2 years without problems is far more suggestive of the fact that you don't actually have prop pox, if you did there is no magical fix, certainly not removing a single mod. I would need more information about what changes were made and things were done and specifics on how well it was working during the interim period before I could state anything as fact though.
Let me just talk this out. I get what you are saying. The first city that DISPLAYED Prop Pox was merely the first of my large tiles to reach the point where Prop Pox manifests itself (when the save file jumps from 13-14 MB to 23-24 MB). So I see what you are saying...any other large tile I saved with the BDK file in my plugins was infected. I'll have to check, though, because I have two or three other large tiles that have passed the danger threshold and they haven't displayed any problems...and I have to think that I played and saved those tile while infected, too. This is where the confusion comes in...really the only "clean" save would be the rebooted prop poxed city.
I was able to play the region for FOUR more years because none of the other large tiles reached that "prop pox" threshold (though three other large tiles did surpass it with seemingly no problems) until now.
So in fact, I never played with "Prop Pox'd" cities...(they were corrupted, but there was no way to no that (SC4Save doesn't tell you a city is prop pox'd until AFTER it passes the threshold to where the corruption actually manifests).
QuoteThere is simply no fix or rebuilding here, ditch the region and move on, even your backups (if you have them) will likely be corrupted too.
Yeah, this is a sad realization...Again, I can keep playing the region as this problem almost has no possibility of occurring on what are probably infected MEDIUM or SMALL tiles since those save files never reach 13 or more MB. However, I just can't take rebuilding all those large tiles...
Four years of this region post discovering Prop Pox and I guess not FULLY realizing what that meant for ALL the other large city tiles.
QuoteSo you have a prop being overridden by another with a new RTK 4 exemplar, which may sound like the problem, but due to the complexity of the problem it kinda is/isn't. Yes this type of prop change is to be avoided, but unless one displays in your city, is subsequently saved and then at some point it disappears (for example you delete the content, bulldoze the lot or it upgrades in-game), the bug will not be triggered in the savefiles. Even when it is, as a user you'd have no way of knowing without checking the save files, but even then you may never actually see the problem occur.
Without looking into this in-depth I can't really comment if these files are broken or otherwise, if they are the "old, locked ones" I don't have any way to get them, so I can't help you with this.
I just wanted to make sure. Now that I see it is a locked file, I feel very comfortable picking up the updated version. I really like the river embankments.
QuoteWell I was a little offended by the comments of joshua43214, it's a slur on the reputation of creators, that comes across with a whiff of elitism and totally disproportionate (picking up a theme here?). I am not bent out of shape to my knowledge, the simple truth is that most content does work and won't break your game. So to suggest the only way to be safe is to ignore the vast vaults of every other file exchange as somehow prudent is frankly ridiculous.
The simple fact is, since this problem was discovered no new instances of faulty props have been found, not a single one. Look through these pages, by comparison how many have been linked as potential "prop pox" suspects. Then look at user comments with regards to those files. Users are steering clear or worried about content that simply should never have been publicly named or should have been rebutted. Many users won't spend the time it takes to go through every post here, but reading it is a cacophony of misinformed folks and needless paranoia.
I'll use the Jim Car Props as an example. I could check them very quickly and see that the file contained nothing that could possibly cause this problem because I know what I'm looking at. Yet the idea that they might cause the pox has been stated here (more than once) and you can see the evidence of the resulting paranoia on these very pages. Once a file is linked to the prop pox, for many simple guilt by association kicks in, this is sadly human nature.
Given the stigma generated I'd want to be pretty sure I was right before I'd publicly mention any file. If I seriously thought a creators file was problematic I would contact them privately before going public with the merest suggestion it might be, especially if I didn't even understand what I was looking at.
Of course if you have prop pox, telling you not to worry about it is not really helpful, but this part was not really directed at you.
Yeah, I can understand the stigma attached. I guess I was counting on everyone to work together and weed out problems. JimCar Props for example. I didn't find any issues when going through the plugins, so then I just chalked that up as a false lead.
I wouldn't avoid a whole Exchange. That is paranoia. Just be diligent and if you want and know how, check things out under the hood.
QuoteI would have said before this sounds like what is defined here are prop pox, I was not disputing that, although given the new information I now have some doubts. Then again if SC4Save says otherwise, who am I to argue.
I still think it is Prop Pox. Your explanation really makes sense. Any city tile I saved while having that file in my plugins is infected...they just don't show the PROP POX until the save file reaches a certain size...which most of them hadn't ...and still haven't...until this point.
QuoteYes and no, I can tell you how to search or what to look for, but as you are unable to interpret the data, I can see it getting out of hand quickly. If I could sit in front of your PC, I'd be happy to spend whatever time it takes to look into it. But I can't and from afar this becomes a vastly more difficult task.
Yeah, I wish I could interpret the data. Easier to start over at this point anyway.
QuoteI don't understand your motivations here, if I'm not mistaken that won't help you in any way to find a problem.
If your files are corrupted now (or were before, assuming you have the pox), they can not be uncorrupted by removing plugins or anything else. Corrupted save files can not be fixed by any currently known means, primarily since there is a system in place to recognise any modified save files and reject them built into SC4. I suggest you try to read up some more on the problem, because you seem to have mis-understood what Prop Pox does to your savefiles.
What if you don't have any files that cause prop pox as defined here? You are searching for a needle in a haystack, if you are confident that the only overriding props are from one DAT (there is no QS1.DAT in the latest release FYI) then the best I can do is suggest you update to the latest version of this mod and move on. This brings us full circle, because so many people are looking for a problem that doesn't exist (that's not to say Prop Pox doesn't), however, If there is no needle in your haystacks, all the time spent searching for one is futile. Hypothetically, what if you did once have such a faulty file in your plugins, but it's long gone so the problem could exist, but you have no way of tracking it down?
This is the reality of prop pox for most people, known cases must number less than 50, confirmed cases are much lower. Here's the rub; if I told people that they had a 0.0000001% chance of something bad happening, they wouldn't think about it and just get on with life. And that's the reality of prop pox, the odds are so infinitesimally small of this problem, that by and large it's simply not worth worrying about.
On the other side what are the chances you are going to find a potential file that no one else has yet found, I would say approximately 0%, because as of now, that's the exact odds as defined by this very thread. Whilst it's heart-breaking to loose your region and I understand you want to do all you can to avoid a repeat of this, there is only so much you can do or that is worth doing when you put all the facts into perspective. I know it seems crass to simply sum up with "I know it sucks, but it shouldn't happen again so just move on" but sometimes the truth is not what people like to hear?
First I started a clean region with an empty plugin folder. Then built a city up to nearly 13 MB before the jump to 20+. Then save this (this city SHOULD be clean)...continue building to get the leap...save and check (yep, clean). Go back and grab the archived file of the near 13 MB clean city and now add in the entire plugin folder. Theoretically I then build to get the jump and save. Now check the file (no Prop Pox? then the offending file must have been the BDK way back 4 years ago - --- - If Prop Pox'd? = remove half the plugins, relaunched the archived clean city and build past the jump again and then check if infected. This is how they found the BDK file.) However, when I tried this after I returned all the plugins, my game froze on the save and I just gave up. I was fully expecting to get a return of no prop pox anyway, which sounds like the case.
QuoteJust thinking aloud, if you want to be totally sure this problem won't cause such havoc again you could do the following:
- Make a regular backup of your SC4 Savefiles, keep at least 2 or 3 previous versions of the backup archived.
- When performing the backup, check the files with SC4Save to make sure they are fine.
In the event a backup showed corrupted save data, the archive should contain uncorrupted versions to restore. Worst case you'd loose the work done in the interval period between backups.
Yeah, now I'm armed with a few more tools I didn't know about. Does SC4Save have information about corrupted save files? I know it can tell if a city is PROP POX'd, but only after the jump...so an archive of that city even dating back 4 years could be infected and I'd never know...basically, I'd need to have a clean test city always available to test my plugin folder at any given time.
With my new region, I've sworn off 4x4km tiles. They aren't really necessary for my gameplay and they've cause more trouble than good. Thanks for your comments.
There is another option if you don't want to abandon the region, though it's not particularly appealing and I would make a backup before you do it.
IIRC, deleting the Prop Subfile in the City File will make the game rebuild the file from scratch as it places new props. Provided the bad mod file has been removed, the issue should not present itself again. Keep in mind that this will remove all of the props in your city.
Set detail settings to low, then high, and the city will be returned to its former glory after the process. Some saving and exiting may be involved.
Ok guys. lemme reiterate, this is all a completely new language to me, so bear with me. So what I did is open the sc4datanode, opened my plugins file. On the right column I clicked "TGI view" and I also clicked "Lots - props", and scrolled through the entire list, clicking on all the files written in red/orange text, as it seems that these were the ones which were being overridden.
I did not see any type 4 props overriding any type 0 or type 1 props, so I don't know what's going on.
The only thing that kinda stuck out to me is in the rtmt folder, there was a file with type 4 props overriding other files, however none of those prop files had the "resource type key" line in it, so I don't know what's up.
I attached a screen shot of what I'm talking about, on there I am clicked on the overriding file, which shows it as resource key type 4. The bunch of files above it which it over writes, none of them have a "resource key type".
I don't know, did I do something wrong here? Thought?
I was also expecting to come across the PEG random woods, given that I have an outdated version of it, however I never saw it highlighted as an overriding files. Or at least nothing stuck out to me mentioning trees or anything like that.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi9.photobucket.com%2Falbums%2Fa55%2Fnasarawan%2Fsc4datanodertmt3131.png&hash=e147cc6a75ed8f846153a3805c33ea2c662dc73d)
Quote from: HappyDays on February 07, 2015, 01:45:44 PM
Set detail settings to low, then high, and the city will be returned to its former glory after the process. Some saving and exiting may be involved.
yup, this is basically what I'm doing. I did that, got all my props back, and as they slowly disappear with each save, every now n then I just do that again, lol. Its pretty bootleg, but it don't bother me. Seems the easiest way to deal with it.
Quote from: packersfan on February 07, 2015, 03:57:00 AM
Yeah, now I'm armed with a few more tools I didn't know about. Does SC4Save have information about corrupted save files? I know it can tell if a city is PROP POX'd, but only after the jump...so an archive of that city even dating back 4 years could be infected and I'd never know...basically, I'd need to have a clean test city always available to test my plugin folder at any given time.
Now I've read your last post, it occurs to me that it probably won't help, my thinking was that since it could tell you a city was poxed (which is ultimately a form of file corruption) that this tool could tell if a file was damaged. Of course before the Network Subfile expands the corruption doesn't occur, so actually my idea wouldn't work at all.
Ultimately it would seem to me that this problem occurred a long time ago and has been waiting in the wings since then, so in reality you have only been poxed once. Given the sheer number of users of most mods/downloads, if something deadly were out there, you can be pretty confident someone would have found it by now. With that in mind I think you should be safe if you steer clear of the BDK or fix it, in all likelihood this kind of thing should not happen again. As for the tile, the decision of writing it off or limping onwards is really more about what you can live with. Personally I would just kill it knowing that ultimately it may be doomed and putting more work into it doesn't make sense.
@NAS786
Plenty of props (and other things) get overriden, there is nothing inherently wrong with doing this. If the files in PEG Random Woods do not override other game-exemplars then again they too can not cause prop pox. Many files have been listed in this thread as "potential suspects" I will repeat than in all the years this thread has been going not one single new file with this problem has been found, not one, don't worry about it, enjoy your game, you could get hit by a bus, but you probably won't - I'm sure you don't spend much time contemplating how to avoid it either way.
There is NO WAY to fix a prop pox'd city ... or as I've learned now, any city that was saved while the offending file (BDK...) was in the plugin folder.
I believe I tried the prop subfile route back in 2011 and it didn't do anything.
I tried doing the graphic trick to limp forward...but it must require saving and exiting, etc...and that would just exasperate the problem.
You may as well kill the tile...and any other large tiles you played and saved while the BDK file was in your plugins.
Now I'm quite confident that the only BAD file that causes the Prop Pox is that BDK file. I agree with mgb204. Given the amount of users of most mods/downloads, if something else were causing this issue, it would have affected many people and been found by now.
So, some advice from someone who has just learned the hard truth. If you discover you have prop pox and you have the BDK file in your plugins OR it was in your plugins at ANY point, you should just assume ALL your large tiles are corrupted (though I'm not sure if this hurts those that make the leap to 23+ MB).
I've cut out one part of the equation by relying solely on medium/small tiles in my new region. Prop Pox isn't the ONLY reason for this...performance issues also tend to plague 4x4 tiles more often than medium and small tiles.
Quote from: mgb204 on February 06, 2015, 10:12:21 AMThis is the reality of prop pox for most people, known cases must number less than 50, confirmed cases are much lower. Here's the rub; if I told people that they had a 0.0000001% chance of something bad happening, they wouldn't think about it and just get on with life. And that's the reality of prop pox, the odds are so infinitesimally small of this problem, that by and large it's simply not worth worrying about.
I'm not sure that this is so. I guess the problem is vastly underreported. Or you are right, and given the play style of many people who just plop skyscrapers in their downtowns, they may never experience this, as skyscraper lots are unlikely candidates to cause this issue.
My cities that reach the necessary file size to show the problems are of the partially rural type, with lots of tree and agricultural props. The image of the university from last page looks familiar. I could have posted the same. I definitely never used the BDK in that region.
At the moment, I'm thinking of backing out from using seasonal trees. Not in the tree controller - that one doesn't touch the original Maxis trees - but in tree replacers. I have absolutely no idea what caused the prop pox in my case, but I may look at that mod that replaced trees on Maxis lots with random seasonal trees. I'm not calling it out, as I have no idea whether this mod is related to my issues (Edit: Proven not to be the issue. Sorry for that). In any case, given the number of mods used, it's like looking for a needle in a haystack.
And the latter means that the number of confirmed cases tends to be low by default, given the difficulties of nailing down the reason for sure. But that's a methodological problem, and I don't think the low number truly reflects the number of cases. Most people will just conclude the city is bugged and throw it aside. Even if they investigate the matter, they will find that there is no cure, so the reaction would be to move on. But sure, it's mostly a problem of people who play the "decorator" style of the game.
Just to show that I'm sure about this being a prop poxed city:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FS5zQqg9.jpg&hash=57dbed486e80155ff5f1e6c00ebbcef4d74cd96a)
Well it would seem to me that anyone who'd taken a city/region to where it needs to be for this problem to materialise is probably the kind of person who's initial response is how do I fix it, ultimately this problem is well known about and I would expect a good percentage of those people to subsequently find this thread.
You can't replace Maxis tree props with seasonal versions, but many mods for seasonal trees don't work this way. Again a quick check through this thread brings up many examples of people who have prop pox but also didn't use the BDK. In fact a large chunk of the cases originate from before the release date of the BDK. We know a couple of files on the LEX which were subsequently fixed had this problem too. Still no one has confirmed anything since as causing prop pox. One of the biggest problems is that the trigger can happen and years later you might find out. I've not been playing the game for more than 2 years, my plugins are an ever-evolving and expanding entity, what are the odds that the file is still there or hasn't been updated?
If you want to check your entire plugins folder, I'd take a copy to one side, deleting files as you find they are OK, this way you'll have an ever-dwindling set of potentials.
Begin by doing a search for SC4Lot, SC4Model and SC4LooseDesc files, delete them all, these files should not contain prop exemplars. Add to that most of your prop packs, BSC packs and others with many tens of thousand users + are not realistically going to be where the problem lies. Of course many files are packed into DATs, so here's where the legwork is needed. To begin with separate all the files left into two "piles", one which you are sure have nothing to do with props (if you don't find it in the remainder, you may want to come back to them later), and the remainder. For these files you simply need to know if they are using unique ID's or not. There are not so many Maxis props, but cross-referencing them can be tedious, SC4 Data Node should help, but it's not exactly for novices either. Anything that comes up here will then need to be checked manually, that means opening it in the reader, going through the props to check the RTK value, and then cross referencing it against the Maxis DATs to ensure the same TGI was not used. At the point where someone genuinely finds evidence to suggest a Maxis prop is being overridden with an RKT4 prop, I'm certain they'd find a willing volunteer to step in and verify it.
The problem for me is when someone calls out a file because of a lack of understanding of either how to interpret what they are seeing or the prop pox problem. I don't think it's fair to do this in a public forum because you are frustrated, however, provided with the evidence to back it up (rather than a misinformed guess) then things change somewhat. Most creators are very nice friendly people, a simple PM would be enough for someone who understands how things work to provide an explanation to you. If that fails and the creator has moved on, well then I guess you may need to post and ask for help here. What I'm seeing (and I am reading between the lines a bit) are people naming files because something it does sounds vaguely like it could cause prop pox. Every time these files are checked by someone, nothing is wrong, after all this time I just think it's time for people to stop panicking over it, more people naming files have never even suffered from the pox, presumably they are motivated by paranoia? Certain files are always coming back around as rumoured to be a cause of the dreaded pox. There are for example users who are steering clear of or removing the Jim Car Props because they've simply been mentioned by someone, these files are totally fine, so theres a real world example of how a disproportionate response is negatively affecting innocent creators. Some mods take fantastical amounts of time, releasing your work always adds to this, because you have to do things differently and properly. If having made such efforts to give something away someone was to name one of my files without a shread of evidence to back it up, I'd be pretty mad. None of this detracts in any way from the catastrophic tolls this bug causes and the amount of work lost. I just think if you don't know what you are doing, you are unlikely to bring anything new to the table here.
Quote from: mgb204 on February 08, 2015, 06:55:58 AM
Well it would seem to me that anyone who'd taken a city/region to where it needs to be for this problem to materialise is probably the kind of person who's initial response is how do I fix it, ultimately this problem is well known about and I would expect a good percentage of those people to subsequently find this thread. [...]
The problem for me is when someone calls out a file because of a lack of understanding of either how to interpret what they are seeing or the prop pox problem. I don't think it's fair to do this in a public forum [...] I just think if you don't know what you are doing, you are unlikely to bring anything new to the table here.
First of all, in any online community only about 10% of the userbase are active posters. So even when people have the issue, go online and find this thread, the majority will not report it. In other words it's safe to assume the problem is, in fact, underreported.
Now secondly you expect a good percentage of cases being reported - which I firmly believe is not the case - however simultaneously you seem to dismiss those who do report it if they 'don't bring anything new to the table'. This poses somewhat of a paradox. Do you want people to report it or not? While I agree it's not a good idea to start pointing fingers, you have to keep in mind not everyone is sufficiently versed into the technical intricacies to make a proper assessment. Moreover it's completely understandable human nature to start looking for a cause when faced with a very frustrating problem.
Quote from: mgb204 on February 08, 2015, 06:55:58 AM
At the point where someone genuinely finds evidence to suggest a Maxis prop is being overridden with an RKT4 prop, I'm certain they'd find a willing volunteer to step in and verify it.
Nitpicking but the issue is not just Maxis props, the issue arises whenever any RKT1 prop is overridden by a RKT4 prop with the same ID and subsequently gets disabled. So say for example someone starts modding custom content, however by lack of oversight also has the duplicate, unmodded file in their plugins. They'd unknowingly and inadvertently run into the pox - and this is not a unrealistic scenario as I've done just so when I started out. ::)
Moreover the pox only manifests whenever the prop subfile goes over a certain threshold. So all in all it's not easy to verify by any means. Besides, for all we know the pox, i.e. memory corruption might have multiple causes which I for one believe is very much a possibility. Haphazardly shuffling content in and out the plugins might be a cause in and of itself, especially if it were overrides for maxis content like rewards replacements. Not to mention there're quite a number of torrents out there which contain conflicting content.
Quote from: vortext on February 08, 2015, 08:04:38 AM
Now secondly you presume a good percentage of cases being reported - which I think is not the case - however simultaneously you seem to dismiss those who do report it if they 'don't bring anything new to the table'. This poses somewhat of a paradox. Do you want people to report it or not? While I agree it's not a good idea to start pointing fingers, you have to keep in mind not everyone is sufficiently versed into the technical intricacies to make a proper assessment. Moreover it's completely understandable human nature to start looking for a cause when faced with a very frustrating issue.
That's the gist of it. I saw this as data point. The image is just there to prove that I'm talking about a poxed city, not anything else. I have the problem. I never debated it much (I actually mentioned this already in this thread some pages ago), and I don't point fingers. Edit: The trees on Maxis lots are fine by the way. Those are relots, and the trees are still there even after removal of the mod, as I still have the dependencies for many other mods loaded.
In my first post on this issue I was also very clear on this:
Quote from: vortext on February 08, 2015, 08:04:38 AMHaphazardly shuffling content in and out the plugins might be a cause in and of itself...
That's exactly what happened here, which is the reason why I am not really heartbroken over this issue. I knew I was doing something risky (or you may call it stupid), but you know how it is if it goes well numerous times: it becomes a habit. I made a backup copy of the region before I did it. The biggy was more or less that I removed the SPAM from the city tile without deleting all fields before the act. That's not a good idea anyway, as it's breaks the demand calculations. However, in the prop poxed city, the tile is full of disabled seasonal props on the field tiles. The city went south as soon as I zoned over a deleted field. A different tile with an even bigger save file with even more props and even more SPAM fields, but where I never tried to delete or zone over the remaining fields, the tile checks out clear, with zero disabled props. My biggest city with only Maxis fields checks out clear, too, with 2 disabled props, but it's still below the risk threshold regarding file size.
Nevertheless, in this case, it's not a real loss and the result of something I did myself and of which everyone will tell you that it's not a good idea. It obviously wasn't. No idea whether any Maxis props are involved at all. So no, no blame meant to be given at all.
Quote from: vortext on February 08, 2015, 08:04:38 AM
Moreover the pox only manifests whenever the prop subfile goes over a certain threshold. So all in all it's not easy to verify by any means. And in fact for all we know the pox, i.e. memory corruption might have multiple causes which I for one believe is very much a possibility. Haphazardly shuffling content in and out the plugins might be a cause in and of itself, especially if it were overrides for maxis content like rewards replacements. Not to mention there're quite a number of torrents out there which contain conflicting content.
Indeed, I think the way we are pushing the game makes such a likelihood highly probable, I don't think prop pox is a myth, but I do think that the reactions of many are causing harm. You know I'm always up for helping someone out if I can, there is no intention to bury heads in the sand, but as a guy who works on the basis of probability I just can't ignore the one nagging fact, no-one in 6 years has found an instance of this problem that could be tracked down. Again I'm not suggesting people stop trying, but the reality is that most users simply have little to no chance of finding it, even if they do have the skills to seriously get into the problem.
I also believe that most content is made with great care and dedication, if such a file/(s) exists somewhere, then it would be very much a statistical anomaly. But this issue has had a lot of exposure, perhaps I was presumptive to think that most users would report it though, my rational simply being that it takes a certain type of hardcore player to get a 6MB subfile. In my mind that sort of player would be more likely to seek out an explanation and ask questions but I accept your point of view here.
Quote from: mgb204 on February 08, 2015, 08:57:56 AM
I just can't ignore the one nagging fact, no-one in 6 years has found an instance of this problem that could be tracked down.
So, you don't believe the first four posts in this thread are correct, or do you mean anyone except that case?
Normally i don't comment on this subject, but i feel the need to point something out here for everyone.
Quote from: Turjan on February 08, 2015, 03:42:25 AM
At the moment, I'm thinking of backing out from using seasonal trees. Not in the tree controller - that one doesn't touch the original Maxis trees - but in tree replacers. I have absolutely no idea what caused the prop pox in my case, but I may look at that mod that replaced trees on Maxis lots with random seasonal trees. I'm not calling it out, as I have no idea whether this mod is related to my issues. In any case, given the number of mods used, it's like looking for a needle in a haystack.
Tree models can be placed into the game in 2 ways: as a
flora exemplar or a
prop exemplar. Tree controllers and tree replacers use
flora exemplars, which
DO NOT write to the network subfile; instead they write to a subfile with Type ID a9c05c85 (not 2990c1bc). So while it is possible for flora to bloat the city's filesize, it does not bloat the network subfile which everyone worries about. I tested this thoroughly when making my last tree controller because with using HD flora on tight spacings it is possible to create absurdly large filesizes in some situations. At no point in my testing did such cities contract "prop pox", and that was with exaggerated cases that in no way would be possible to recreate with currently available controllers. The only way a tree or bush or flower gets put into the game as a prop is when someone adds it as a prop to a lot.
(*sidenote: Tree controllers actually DO contain copies of maxis flora such as the maxis pines, oak, and scrub brush, but we don't bother touching the RKTs. We need to overwrite the "Flora Table" in the maxis files so the game engine doesn't try to place them with the God Mode tool)
AFA the seasonal trees on maxis lots mod: If it's the one i'm thinking of, that mod contains relots of all the maxis files with the old trees deleted from lots and new trees manually placed on them, it is not a mod that that overwrites maxis tree RKTs with new RKTs. A quick look inside the mod reveals only .sc4lot files, no .dats with RKT overwrites. I've used it myself since its release with no problems.
---
I also want to point out that i think there are quite a few mis-diagnoses of custom content causing "prop pox". The only time any of my cities contracted the pox, it was actually file corruption because the client CTD'ed mid-save thanks to my antivirus starting a scheduled scan (and it was a skyscraper city; no RKT4 overwrites there. RIP Stormwatch, Kaui). When people's props start disappearing they jump around hell bent on finding a plugin to blame. But i wonder: is it a plugin or is there file corruption from this rickety old .exe trying to write to the hard drive while the user has too much crap running in the background (or, gods-forbid, someone tried to alt-tab durring a save).
Yes, I hoped to make clear that the tree controller wasn't to blame. I learned my lesson and did not remove any trees that I used, ever. That region went through 3 tree controllers, and all trees are still there as I made sure to keep MMPs of them (even the Maxis ones).
I also addressed the relots with seasonal trees in my third post. Removing that mod is definitely not the issue in my case, as I looked, and the props are still there after removal of the mod. I should probably edit my second post.
Quote from: epicblunder on February 08, 2015, 10:01:16 AM
I also want to point out that i think there are quite a few mis-diagnoses of custom content causing "prop pox". The only time any of my cities contracted the pox, it was actually file corruption because the client CTD'ed mid-save thanks to my antivirus starting a scheduled scan (and it was a skyscraper city; no RKT4 overwrites there. RIP Stormwatch, Kaui).
This may well be the case here. I hope it was clear that I did not blame the SPAM in any way or form. First, I removed this content without deleting all instances first (a big no-no). And still, the other tile with even more SPAM fields managed to get rid of all disabled props, somehow. The poxed city didn't, for whatever reason. I should probably try my luck and see whether I can ruin the other tile ;).
Edit: Test was "positive". City got prop poxed. Still with 0 disabled props.
Quote from: mgb204 on February 06, 2015, 10:12:21 AM
Well I was a little offended by the comments of joshua43214, it's a slur on the reputation of creators, that comes across with a whiff of elitism and totally disproportionate (picking up a theme here?). I am not bent out of shape to my knowledge, the simple truth is that most content does work and won't break your game. So to suggest the only way to be safe is to ignore the vast vaults of every other file exchange as somehow prudent is frankly ridiculous.
I stand by my words in this matter, and the BDK file is the perfect example. Peg updated the file on his own site, but did not bother to update the file on the STEX. So there it sits, waiting to ruin regions. The biggest strength of the STEX is also it's greatest weakness. I learned long ago to always closely examine STEX downloads before I let them loose in my game. I have read this entire thread in the past. As a research scientist, I accept the method used by the OP to determine the file that was causing prop pox on his machine. I accept the change from an RKT 1 to an RKT 4 as a good theory for what causes the pox. The game clearly re-examines the savegame when it reaches a certain size threshold, and during this process the pox strikes.
My intent was not to slur the creator that upload to the STEX, I have many STEX bats and stuff. My intent is always to warn, never get something from the STEX, if you can get it from the creators own website, and when you do get something, look it over closely.
Anyway...
I modified a piece of code that I wrote for opening and scanning dat files.
It first scans the SimCity_1.dat file and creates a dictionary of all props and their RKT's. It then scans all the other .dat and .sc4desc files, when it finds a new TGI, it adds it to the dictionary. When it encounters a TGI already in use, it compares the RKT's between the two files. If the RKT's are different, it adds both files to a new dictionary of potentially bad dats. Lastly, it writes tab delimited .txt files for the SimCity_1 props list, the complete prop list for all dats, and lastly a bad dat file that has the the names of the files in question and their respective RKT's.
The nice thing about the script, is that it compares every TGI to the others, not just to the SimCity_1.dat on the assumption that creators might be overwriting each other (which I did find).
['0x6534284a', '0x8fb08a82', '0x10d16eb7', 'RKT4', 'bsc mega props - misc vol02.dat', '"rtprop_snm_paratrooper"', 'RKT1', 'bscbatprops rt snm vol01.dat', '"rtprop_snm_paratrooper"']
['0x6534284a', '0xc977c536', '0x29110000', 'RKT1', 'SimCity_1.dat', 'R1x2x2_Recliner_2911', 'RKT4', 'peg-oww2_bdk_resource.dat', '0x20\tr1x2x2_recliner_2911']
['0x6534284a', '0xc8dbccba', '0x0c9db0fe', 'RKT0', 'pmct_lots.dat', '"pmc_prop_centrepole"', 'RKT3', 'pmct_namv061705.dat', '"pmc_prop_centrepole"']
['0x6534284a', '0xc8dbccba', '0x0c9db0fd', 'RKT0', 'pmct_lots.dat', '"pmc_prop_sandstone"', 'RKT3', 'pmct_namv061705.dat', '"pmc_prop_sandstone"']
['0x6534284a', '0xc8dbccba', '0x0c9db0fa', 'RKT0', 'pmct_lots.dat', '"pmc_prop_openpaved"', 'RKT3', 'pmct_namv061705.dat', '"pmc_prop_openpaved"']
['0x6534284a', '0xc977c536', '0x29b20000', 'RKT1', 'SimCity_1.dat', 'R1x1x2_BeachChair_29B2', 'RKT4', 'peg-oww2_bdk_resource.dat', '0x20\tr1x1x2_beachchair_29b2']
['0x6534284a', '0xc8dbccba', '0x0c9db0fc', 'RKT0', 'pmct_lots.dat', '"pmc_prop_pavement"', 'RKT3', 'pmct_namv061705.dat', '"pmc_prop_pavement"']
['0x6534284a', '0xc8dbccba', '0x0c9db0fb', 'RKT0', 'pmct_lots.dat', '"pmc_prop_cobblestone"', 'RKT3', 'pmct_namv061705.dat', '"pmc_prop_cobblestone"']
['0x6534284a', '0xc977c536', '0x290d0000', 'RKT1', 'SimCity_1.dat', 'R1x1x3_PatioChair_290D', 'RKT4', 'peg-oww2_bdk_resource.dat', '0x20\tr1x1x3_patiochair_290d']
The first three entries are the TGI
The next three entries are the file being over ridden
The last three entries are the over-ridding file
The BDK file is there as a control
Note the BSC files being changed from 1 to 4. I have no idea if this is a problem or not, but snm or the pmct might be a cause of unexplained prop pox. pmct is the PedMallCompatibleTransit pack (from the STEX &mmm )
I need a bit of time to wrap the script in a GUI (I kinda suck at GUI), and convert it to an .exe.
If any one is interested in testing the tool, send me a PM and I will give you a copy of it. Once I feel like it will run ok on other machines, I will upload it to the STEX :bnn: for everyone to enjoy.
Out of 17471 props scanned, it is impressive that this is all the files that are potentially bad in my plugins folder.
That's a very promising tool, nice job. &apls
As for the issues you found, that'd need to be determined by closer inspection; i.e. does the RKT4 file actually have timing properties. As I recall changing from RKT1 to RKT4 in and of itself doesn't matter. What matters is whether or not the RKT4 prop is timed since it's the additional info pertaining to timing that gets stored in the savegame and later on causes the discrepancy, i.e. corruption when it gets disabled. Instead RKT4 may have been used to offset the prop, since apparently it's a paratrooper, which afaik isn't an issue.
Not sure about the RKT0 & RKT3, both typically use the same kind of model (a single S3D used for all rotations & zooms) and iirc RKT3 is only ever used for transit exemplars (overhanging models and such) so I suspect it's not saved in the prop subfile to begin with.
Quote from: packersfan on February 08, 2015, 03:07:47 AM
I tried doing the graphic trick to limp forward...but it must require saving and exiting, etc...and that would just exasperate the problem.
You may as well kill the tile...and any other large tiles you played and saved while the BDK file was in your plugins.
Hey, so I'm doing the graphic trick currently, what happened exactly as you kept moving forward with that? Because as I said, I don't mind playing w/ missing props vast majority of the time, as I stay busy building stuff rather than enjoying the scenery. And then every now n then I wanna enjoy the scenery, I do that trick. Is this going to lead to anything worse down the road?
Also I should point out, I don't have the BDK file, I have actually never downloaded it ever, so it def doesn't exist anywhere on my computer, or hard drives, or diff plugin folders.
Quote from: mgb204 on February 07, 2015, 04:51:11 PM
@NAS786
Plenty of props (and other things) get overriden, there is nothing inherently wrong with doing this. If the files in PEG Random Woods do not override other game-exemplars then again they too can not cause prop pox. Many files have been listed in this thread as "potential suspects" I will repeat than in all the years this thread has been going not one single new file with this problem has been found, not one, don't worry about it, enjoy your game, you could get hit by a bus, but you probably won't - I'm sure you don't spend much time contemplating how to avoid it either way.
Yea, I get what you saying bro, I just been moving forward with the graphic trick, and I'm good with it. To be honest, I was going through all that stuff more for the sake of our community at large, know what I mean. for the cause, homie. Figured if I could identify something, it may help others avoid it. But as far as myself, I'm a lazy bastard, soon as I found the graphics trick I was good to go! lol
Quote from: Turjan on February 08, 2015, 09:34:00 AM
So, you don't believe the first four posts in this thread are correct, or do you mean anyone except that case?
I think that anybody spending 10 minutes of their time to check back through a couple pages could answer that question for themselves?
---
However the law of probability is against you here from every angle. The chances of getting prop pox, the chances of finding what caused it, the probability of all these things is so close to zero that beyond taking a few precautions to protect yourself, there really isn't anything you can do about it. That is my entire point here, if you want to spend time tracking the problem down, by all means do that. However I think taking all the facts into consideration that it wouldn't be in someones best interest to advise them to invest a lot of time tracking it down, especially if you don't really have the knowledge of the game to understand what you are looking at it whilst doing so.
So in short, my advice (opinion) would be to accept the files are toast and simply move on. You may choose to limp on with the region using various tricks to keep your cities going, but the results of that are played out here too, eventually it will be too broken to continue. If sometimes I come across as trying too hard to find a diagnosis that is not prop pox, that's simply because many cases are not prox pox and misdiagnoses here has some pretty catastrophic effects. So when I ask "are you sure it's prop pox" my intentions are to be certain in my mind that you have correctly diagnosed the problem, because if you haven't then almost certainly the people on these forums would be able to help you to get your cities back and running. The last thing I'd want to do is be cavalier in my assessment of a problem like this, that'd be like a vet looking for excuses to put your pets down, rather than trying everything possible first to avoid such a scenario.
Quote from: Turjan on February 08, 2015, 11:28:08 AM
Yes, I hoped to make clear that the tree controller wasn't to blame...
Aye. But as mgb said, once even a hint of suspicion comes up people tend to shy away from things just to be safe. I wanted to clarify for everyone (not just you) that these type of files absolutely don't act in the way that people suspect is the cause of prop pox.
Quote from: mgb204 on February 09, 2015, 07:58:22 AM
So in short, my advice (opinion) would be to accept the files are toast and simply move on. You may choose to limp on with the region using various tricks to keep your cities going, but the results of that are played out here too, eventually it will be too broken to continue. If sometimes I come across as trying too hard to find a diagnosis that is not prop pox, that's simply because many cases are not prox pox and misdiagnoses here has some pretty catastrophic effects. So when I ask "are you sure it's prop pox" my intentions are to be certain in my mind that you have correctly diagnosed the problem, because if you haven't then almost certainly the people on these forums would be able to help you to get your cities back and running.
Well, SC4 Save claims it's prop pox, and it definitely looks like it. Regarding the rest, no worries. I had made a backup of the whole region and the whole plugin configuration I used in that region before I moved the files out. The prop pox struck immediately after I had moved the plugins out, on my second play session after this (when I got to a tile with the necessary file size). Which means I just lost a few hours of meddling around, which is nothing. I can just revert to the state from before.
Quote from: epicblunder on February 09, 2015, 09:57:44 AM
Aye. But as mgb said, once even a hint of suspicion comes up people tend to shy away from things just to be safe. I wanted to clarify for everyone (not just you) that these type of files absolutely don't act in the way that people suspect is the cause of prop pox.
That's probably a good thing to do. I never had any problems with tree controllers, except the occasional CTD when I didn't keep MMPs from the controller that wasn't used anymore in the very beginning (there were some ghost Maxis trees left) when I didn't know any better.
Hi all,
Joshua asked me per PM about the prop-pox and my PMCT (Pedmall-compatible Transit Pack), obviously because of the RKT0 to RKT3 overrides reported above. My answer here is that there should be no problem, as both prop exemplars are simple (ie not timed or seasonal). The RKTx properties are not saved in the city file, instead they are referenced (in the effective exemplar). Besides, the RKT3 version here overrides the RKT0 one fully, that is all props will be recorded using either version of the exemplar, and then red having the same effective definition; it's an intra-package override, not an Original-by-Plugin one. The RKT3 version is for the newer versions of NAM.
Not sure if it has become clear of what really causes the prop-pox. My understanding is that it is caused by redefining a simple prop exemplar (usually in SimCity_1.dat) as a timed or seasonal one (or the opposite), because for the latter a longer record is written in the city file for each prop instance (it is a little longer because it stores a little more information, like state or days-elapsed-since-activation or who knows what). So if the length of the record stored in the city file does not match the one implied by the exemplar (based on the presence or absence of seasonal or timed properties) the program is somehow "lost" and cannot read the props' data correctly (this is my understanding). Props using the NightTimeChange property (in combination with RKT4) are NOT really timed, as there is no prop "state" (simply a different model is displayed during nighttime). And as mentioned above I'm quite sure that the RKTx properties are not saved in the city file, so you are free to override them with no problem. Accordingly, the program should rather be modified, so as to check whether a simple prop was redefined as a seasonal/timed one (or the reverse), instead of comparing whether the RKTx property was changed to another one, or even removed completely (or reversely, added).
All the Best
Quote from: cogeo on February 11, 2015, 12:39:55 PM
Hi all,
Joshua asked me per PM about the prop-pox and my PMCT (Pedmall-compatible Transit Pack), obviously because of the RKT0 to RKT3 overrides reported above. My answer here is that there should be no problem...
Accordingly, the program should rather be modified, so as to check whether a simple prop was redefined as a seasonal/timed one (or the reverse), instead of comparing whether the RKTx property was changed to another one, or even removed completely (or reversely, added).
All the Best
Thank you very much for responding.
My understanding is about exactly the same as what you are saying. The issue is changing a prop with a small memory footprint to one with a larger footprint.
I have debated in my mind your suggestion about modifying the program since I started writing it. On one hand, it could be unfair to folks like you that are on my short list of trusted authors. On the other hand, I hate withholding information that might be valuable. I have no intention of removing the PMCT from my own plugins, I don't want to be responsible for possibly scaring folks away from an excellent mod. The Libertarian in me says "just give folks the information, and let them make a grown up decision."
I finally got the GUI working (except the cancel key), the .exe runs on my system, and I need to prepare a readme. Going to test it on another PC before I send it out for limited testing. I will decide how to handle the issue before it goes public. Ideally, the output would warn the user that a particular RKT change is safe or dangerous. Unfortunately the output goes to a txt file meant for use in Excel or Notpad++, and there is not good method for formatting such a warning. I am definitely open to suggestions on this subject.
This script originally started as a vision for a dependency finder. The idea was to write a program that would create a list of every TGI in a mod file, give the program out to folks with really big plugins folders, and have them send their files back to me. I would then merge the files into a master list, and release the program publicly. Users could then upload their TGI list to a place I could access it, and then I would periodically release an updated master file. I bet that 10 users with a lot of files on their system could cover >90% of the TGI's. Used in conjunction with SC4DataNode, players would be able to find what dat and missing dependency comes from. This could be a really good tool used for getting rid of brown box's and finding missing textures.
Writing the prop checker actually helped me solve a couple of problems I faced with the original concept. I am currently considering holding the tool back and finishing the original concept with the RTK scan as an optional scan. The real issue here is that I am a molecular geneticist and a computational biologist, not a developer. I write very programmatic code that just takes large data files, and make pretty graphs from the stats. I kinda suck at writing GUI's, and I am not even sure where to start with making the program able to auto-update.
-Josh
Quote from: joshua43214 on February 12, 2015, 09:21:29 PM
...The idea was to write a program that would create a list of every TGI in a mod file, give the program out to folks with really big plugins folders, and have them send their files back to me. I would then merge the files into a master list, and release the program publicly....
wouanagaine wrote a program that would go thru all your LOTs and generate a html file file with that kind of information in it, unfortunately it was never released, you used to be able to download it from the first post in this topic
http://sc4devotion.com/forums/index.php?topic=86.0
link no longer works ()sad()
Quote from: catty on February 13, 2015, 12:39:40 AM
Quote from: joshua43214 on February 12, 2015, 09:21:29 PM
...The idea was to write a program that would create a list of every TGI in a mod file, give the program out to folks with really big plugins folders, and have them send their files back to me. I would then merge the files into a master list, and release the program publicly....
wouanagaine wrote a program that would go thru all your LOTs and generate a html file file with that kind of information in it, unfortunately it was never released, you used to be able to download it from the first post in this topic
http://sc4devotion.com/forums/index.php?topic=86.0
link no longer works ()sad()
My idea is a bit closer to what DataNode does. You would be able to scan a file, and it would return all the TGI dependencies. It would then compare the required dependencies against a crowd sourced master list of TGI's, and return what file
contained the missing TGI. You could then Google up the missing file.
A few years ago I used SC4LotInfosGenerator and scanned my plugins, the LEX DVD and CD and the STEX Disks (2, 3 and 4) ending up with a huge number of duplicates records obviously and as I only wanted to know the name of the plugin and its file name I ended up with an Microsoft ACCESS database containing this information
GALLERY File Name
0xEE668F70 SG_Lots_Motels.dat CS$$4_3x3_SG_BrewPubFishTaleAle
0xEE668F70 CS$$3xSG_BrewPubFishTaleAle_ee668f70.SC4Lot CS$$3xSG_BrewPubFishTaleAle
0xEE66901B SG_Lots_Motels.dat CS$$2_2x5_FishTaleInn
0xEE66901B CS$$2xFishTaleInn_ee66901b.SC4Lot CS$$2xFishTaleInn
57215 lines in total, I've exported it out as a text file (its still 4mb in size) and put it "dino's" briefcase over at CB in case anyone wants it.
The Gallery ID is from the plugins TGI, but it also helps me identify the picture of the plugin if I want to check I'm looking at the right item (only 18717 pictures ;D)
I'm attaching a picture from my files
Cathy
0x0C2C1272 Microwave Power Plant_0c2c1272.SC4Lot Microwave Power Plant
To anyone spending their Sunday looking for RTK changes in their plugins folder, don't bother.
I have been doing some further experimentation and I can say categorically, with no reservation, that changing RKT1 to RKT4 as in the BDK file is NOT the cause of prop pox.
The issue lies elsewhere in the exemplar file.
My GF is on her way over for a delayed Valentines Day (weather...), so I do not have time to give a full write up, and I have some further testing to try and narrow the cause down further.
-Josh
Intriguing. We await your analysis.
Sorry for the delay.
This will be a long post. I will try to keep the most important stuff at the beginning.
tldr: changing from RKT1 to RKT4 does not cause the pox.
Something about prop pox had me bothered, especially after reading Cogeo's response above. Something just felt contradictory to me.
If changing the RKT from a short to long on a prop caused it to overwrite good data on a save, then the PMCT would cause prop pox. However, I have faith in Cogeo, and have no real reason to believe that his PMCT caused prop pox.
Also, if changing the RKT caused prop pox, then the BDK umbrella should not cause the pox since it does not change the RKT.
I decided to do some testing of my own to see what I could come up with.
Bap's original cities he uploaded have vanished along with fileden.com, so I decided to create my own test cities.
I found that it is painfully easy to make a city with prop pox.
A city ready to pox, only has about 61,000 sims. all living in LD residential.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi179.photobucket.com%2Falbums%2Fw298%2Fjoshua43214%2FPox1-Jun9291424122592.jpg&hash=15cf2a0dbf31f389fab84f0f488a0c5787fc459f)
The prop file in the save game will toggle from compressed to uncompressed when the new zoning is about 2/3 done.
One of the reasons this issue concerns me so much is that I build a lot of slums arround my dirty industry, and I have been a victim of the pox a number of times even though I stopped using the BKD years ago.
I used a Plugins folder empty of any mod except the extra-cheats dll. I had to install it for the money cheat until the city developed.
For positive and negative controls, I grew the city till it was done developing with and with out the BDK installed.
With out BDK, no pox
With BDK, pox
This indicates my test city works for purposes of testing.
Unless specifically noted, I ran each test until the city finished development, saved the game, and checked the save game in the SC4Savegame Explorer
http://sc4devotion.com/csxlex/lex_filedesc.php?lotGET=2021
Because of the way this city was made, toggling between compressed and uncompressed prop file is as simple as zoning or dezoning.
I reloaded the save from a back up between each test.
I decided to begin with the PMCT, this is the great Ped Mall Compatible Transit pack by Cogeo from the STEX
http://community.simtropolis.com/files/file/13147-pedmall-compatible-transit-pack/
This version is meant for the NAM, which I did not have installed.
To be safe, I plopped 80 of the centerpole plops (lots of brown boxes).
No pox
I plopped 200 more, ran the game for a while
no pox
dezoned until the prop file compressed
no pox
rezoned and ran til prop file un-compressed
no pox
The indication is that the PMCT does not cause the pox.
This also suggests that changing the RKT from 0 to 3 (a small RTK to a big RTK) does not cause the pox.
I next turned my sights on the BDK.
I compared the BDK files for the Umbrella, recliner, beach chair, and patio chair to the game files in SimCity_1.DAT.
The Umbrella had the "Nighttime State Change" (SimCity_1) replaced with "Prop Time of Day." This is the only change to the Umbrella.
The recliner and chairs all had the same changes. The RKT1 was changed to RKT4, and a "Prop Time of Day" property was added.
I began by deleting the Umbrella from the BDK, added the BDK to my Plugins, and ran the city.
it did not pox.
I added some amenities and created a mid-wealth area with some high-wealth residents.
it did not pox.
Puzzled, I wondered if there was none of these props, or possibly not enough to cause a problem. SC4Save does not tell you how many of a prop are in the save, but it does provide a line for each instance of a given prop.
each page on SC4Save displays 32 lines, I counted 141 pages for the beach chair, 129 pages for the patio chair, and 131 pages for the recliner.
I could not verify that the recliner, the beach chair, or the patio chair cause the pox.
I next deleted the chairs and the recliner from a fresh BDK copy (has the umbrella)
It poxed right away.
I then deleted the chairs and recliner from a fresh BDK, and deleted the "time of day" property
it poxed
I took a fresh BDK, and replaced the "time of day" with a "nighttime state change" with no values
it poxed
I took a fresh BDK, and replaced the "time of day" with a "nighttime state change" copied from SimCity_1.DAT
no pox
I changed the "nighttime state of change" from the default 0x01 to 0x00 in the same file, and reloaded the un-poxed master file
it poxed
Then I took a fresh BDK and simply copied the "nighttime state of change" property from SimCity_1 to the BDK
no pox
as a control, I deleted the umbrella from the BDK, and added a "Self illuminated" property to the chairs and recliner
no pox
I added the "self Illuminated" and "nighttime state of change" property to a fresh BDK
no pox
The indication here is
the beach chair, patio chair, and recliner do not cause the pox
changing from RKT1 to RTK 4 do not cause the pox
deleting the "nighttime state of change" property from an RKT4 causes the pox.
Adding a "time of day" property to a RKT4 does not cause the pox
At this point I went back and re-read all 33 pages of this thread to see if anyone had looked at this before.
I did some more "extreme" testing, details are below. I can actually demonstrate that on its own, the BDK umbrella does not cause the pox. My contention is the pox occurs after the prop has been removed or changed like when a property develops or is redeveloped. In a real game, it causes the pox. See the end for details.
I need to vent a bit here.
In my field (genetics and computational biology), people that falsify data or claim to have run experiments that they did not run are considered the lowest of the low. There are examples of this that have caused havoc for years and cost the lives of thousands of people because important treatments did not reach the market, or bad treatments did.
The total amount of time to create my test zone and edit the BDK was well under 1 1/2 hours. I have no compunction about naming a person who claims they "conducted an investigation and found no problem" a bold faced liar. To then turn around an denigrate the extremely hard work of people investigating this problem, and claim that the issue is "invented," "caused by the NAM," "furthering the dark aims of the BSC," or "caused by random chance" is not only a liar, but a detriment to the whole community. All the beautiful work not withstanding, we would be better off never to have this person in our community.
I would once again like to formally tip my hat to Bap, wounagaine, Ripplejet, Barbyw, andreas, z, Cogeo, and all the others that contributed to this thread, and tried to not only find a solution, but tried pave a road to peace with the SimPeg website at the cost of permanent ban.
OK, back on topic.
When performing research. One of the things you never do is change your method of measuring or change the tool used to measure results. Something as simple as using two different microscopes can prevent funding and publication.
Bap did his experiments the "hard" way. He had to use a shrinking un-compressed prop file to indicate prop pox.
The problem with this method is that it is confounded when mid-wealth and high-wealth push out the low wealth. There are fewer props in a high-wealth neighborhood than a low.
I could not find a report of anyone checking just the chairs and the recliner after wou published the SC4Savegame Explorer.
I believe this is the reason that the recliner and chairs were blamed for the pox.
I should be really clear here, negative evidence is not evidence. Just because I did not see the problem, does not mean that it does not exist. There might be another factor here. The most obvious one is that my game save file is no where near as big as Bap's was. It is possible that there is some secondary issue when another file is forced to decompress.
It seems more like to me that Bap's method was confounded, than my method was confounded by a secondary cause.
If anyone has a copy of Bap's test cities, it would be great if you could verify that the chair and recliner do or do not cause the pox.
The key piece of information here is "what exactly is in the savegame?"
The key question here is "what exactly goes wrong with this information when the save is un-compressed?"
There was plenty of speculation, and Ripplejet posted some tentative results from this very query.
I spent some un-happy time with the information on this page
http://www.wiki.sc4devotion.com/index.php?title=Prop_Subfile
trying to write a script to read the prop file so I could monitor changes to it. Sadly the information on the page produces a format that is very different from the format of my savegames. It will take a great deal of trial and error to make it read properly, though I have made some progress.
Being able to read the prop file is critical to demonstrating proof of the cause of prop pox.
Until I can read the file, I have a theory, and some further evidence.
When the game loads, as we all know, it loads all the files in a certain order, it then does whatever the last files loaded says to do.
What the game does not do is go back and "forget" obsolete files, it just holds everything in memory.
The Theory:
When the game saves, it goes through every file in memory in loading order. It creates a field in the SGProp (I believe) for every piece of information required to load the prop. When it reaches the last prop in load order, that information overwrites all the information already entered. In the case of the BDK umbrella, the "nighttime state of change" field is added by SimCity_1 dat, then that field is null in the BDK.
A short explanation of how the DPBF file format works is required to explain how this causes a problem.
The BPBF format is a proprietary database format created by EA for the Sim games. Just about everything in the game from models to images are stored inside a DPBF file. The files we are talking about in this discussion are "exemplar" files (whatever the heck an exemplar is).
After the exemplar has been de-compress, and converted from binary into readable text, it contains a series of lines.
The first three lines always contain the same information in the same order: file code, parent cohort, property count.
After the third line, each line has two entries, the first being its "tag" ("Name value" in the Reader), and the second being the value.
Below is the umbrella from the BDK
EQZB1###
0,0,0
14
0x10 30
0x20 R2x3x2_$$Beachumbrella_2900
0xabfc024 28
0x27812810 ['0x40000000', '0x40000000', '0x40400000']
0x27812824 ['0x0', '0x0', '0x0', '0x0', '0x27812821', '0x5ad0e817', '0xbadb57f1', '0x29000000', '0x1', '0x0', '0x0', '0x0', '0x27812820', '0x5ad0e817', '0xbadb57f1', '0x0']
0x27812870 ['0xa0000001']
0x49a1e05a 1235347861
0x49c9c93c 1
0x4a149631 ['0x41100000', '0x41900000']
0x4a89fcf3 True
0x6a95e503 False
0x8a416a99 ['0x2026960b', '0x6a554afd', '0x6a8c223b']
0x8a5e5db8 True
0xe9a316eb 2
The game reads the exemplar, see that it is a binary that needs to be decoded (EQZB), it has no parent cohort (0,0,0), and has 14 properties. If it has to many or to few properties things go wrong.
the tag 0x27812824 tells the game this has a Resource Key Type 4 (RKT4), and the 16 values on the left are basically the what/when/where information about the prop.
The tag 0x4a149631 is the "time of day" property, the numbers on the left are a hex version of 9am to 6pm.
So in essence, the game reads the file, sees it has 14 properties, goes through each property and does the correct thing. This is a very robust system, the file tells the game what type of information it has, then it tells the game what that information is.
The save game is not so robust.
Rather than a series of ordered pairs (tag,value) it is just a series of values.
below is a partly decoded save file.
The tags on the left are NOT part of the file. I added those so I could read it.
The file is just a series of values.
size 181
CRC û
mem 0x29e201c
maj_v 0x6
min_v 0x4
zot 0x0
unk_1 0x0
ap_flag 0x0
something 0xa823821e
min_tract_x 0x47
min_tract_z 0x47
max_tract_x 0x47
max_tract_z 0x47
x_tract_size 0x2
z_tract_size 0x2
prop_count 0x0
TID 0x6534284a
GID 0xc977c536
IID 0x29110000
instance_ID 0x43fbd3d2
min_x 3.21964677141e-14
min_y 503.654846191
min_z 270.0
max_x 502.793548584
max_y 504.654846191
max_z 272.0
orientation 0x65
state 0xfc
start_time 0x43
stop_time 0x0
count 0x0
It clearly has a decoding error around the Instance ID, since the min_x value is clearly wrong, but it is in frame up to the TGI values (this is the recliner).
I believe that the game creates a field for the Nighttime State Change, and the BDK enters a null value.
When the file is compressed, tags are added giving the compressed and uncompressed size of file.
The game is not able to understand the null value, it looks for x number of properties, but finds x-1. It thinks the Nighttime State Change property is the nth property, but it is missing, so part of the next property is read instead. The error then propagates forward to the end of that property.
The game is not able to compress a null value.
Somewhere during the process of decompression and compression, the game gets confused about the expected file size and number of properties, and the actual file size and number of properties.
If things go wrong, it will write the file forward into space reserved for another prop. This prop is now corrupted, and the process continues.
Since I could not verify this to be the case, it will have to remain a theory until someone can help me out with the save format, or I figure it out myself.
As a further test, I made this.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi179.photobucket.com%2Falbums%2Fw298%2Fjoshua43214%2Fumbrellas.jpg&hash=3e139c0f7973db8fe5e5ca443c6bb796b9be577a)
It is an empty grass lot, covered in about 750 umbrellas.
I plopped about 3 1/2 rows from end to end on a small city tile until the props folder was at is max compressed size.
Sorry, no screenie, it crashes the game to look at them lol.
I then added the BDK file, plopped 5 more of these so the file uncompressed.
no pox
ran it through and entire day night cycle.
no pox.
It seems the pox can only occur during development as properties are created and recreated.
This is only supporting evidence of my theory. We will have to wait until the save file is more fully decoded for proof.
I am brainstorming on how to fix my Pox scanner to deal with this. I am not sure if load order is a factor here or not. It seems to me that if the BDK loaded before the SimCity_1.DAT, that the same problem would occur, only this time SimCity_1 would be the cause of the pox. Checking this level of data means that every exemplar will have to be decompressed, and a rather large check file created and passed over. My current scrip will scan my 3.7Gb test folder, open 1649 files, and compare RTK's on 18,313 props in about a minute, and is written in pure Python. Python can certainly do a deeper search, but this is really moving into something that should be programed in C (which I can't write), especially if load order is important.
-Josh
Edit: I conflated "null" with "0". My post has been corrected. Nighttime State Change is a binary. 0 sets it to "No Change", which is a valid value. SimCity 4 just wipes out the reps entirely for "nulled" properties, it seems.
Fascinating. Concerning, as well. There are many prop packs on this site alone that override props from other prop packs, and add/remove various things. Unless there are more specific limits on what causes prop pox than what you've described, many people could be infected.
One example of many:
BSC Mega Props - JES Vol01. Instance 10A83059 (jes_BN-Line-53_Container) conflicts with the one contained in BSC MEGA Props - Misc Vol02. Same basic prop, different properties.
The BSC Mega Props - JES Vol01 version contains several more properties than the other. These are mostly binary in nature. MaxFireStage and Flammability are also not in the other version.
MEGA Props - Misc Vol02 has fewer properties, but has a family value; something that should never be empty. In addition it has an zero'd text key for the purposes of allowing the prop to properly appear as a ground model. Could this cause issue if this file is loaded first, then overridden by BSC Mega Props - JES Vol01?
If you upload your city somewhere, I can do testing for you following your methodology. I'll need to make my own prop lot, of course.
I wouldn't worry about the programming language, yet. Just having a functional tool will work.
Hi Guys
Had read this post early in the day and have just been doing some update work on the plugins catalog at CB, when this plugin caught my eye
http://community.simtropolis.com/files/file/24165-time-of-day-property/
Had a quick look thru the Catalog and couldn't find any others that are designed to change the time of day.
-catty
A quick update,
I scanned through SimCity_1.dat and made lists of all props that use 9 of the properties that seem like they could cause a problem. Out of the 9, I settled on 5 that made sense. I then made a new dat that was nothing but the prop exemplars from a handful of each type. I then deleted the suspicious property, loaded the game.
So far all I can confirm is that deleting the Nighttime State Change and the Time of Day properties will cause the pox.
It is possible the ones that failed didn't have opportunity to cause the pox. For example, my first test on deleting Nighttime State change failed even though I have found this to be a cause previously. I remade the bat and went from two props in the exemplar to 15 (I made sure to leave out the umbrella on both tries as a control). The second attempt poxed the city.
I then made three grassy parks with one prop each, the recliner, the umbrella, and a bench. I made prop exemplar bats for each one as well. I then loaded each one up and added or deleted properties from the exemplars.
I could then scan the prop save file. a single prop creates a prop save file only 88 bytes long, so it is fairly easy to see changes even if I do not know what the change means.
Near as I can tell, adding or deleting the Nighttime Change State has no effect on the prop save. This property is not saved in what we believe the prop save file to be. It must be saved elsewhere, or there is something entirely different going on. There is a change in bytes 4 - 7, these bytes contain a flag for if the file is compressed or not, and its umcompressed size. I can use the same check for compression and algorithm for decompression that I use on regular files, so I didn't bother to write the code so those 4 bytes are readable. There might be a flag hidden in there though. But like other exemplar files, the reading frame seems to start at byte 9.
The Time of Day property does appear in the save file as a 2 byte flag, and a third 1 byte flag that toggles day/night.
Next step is to dig into the index and look for changes there.
Hopefully something will turn up.
I can post the savegame somewhere I suppose. I had not considered it since all you have to do is make an ugly grid of LD res with some ind and com mixed in.
I will see if I can find a file hosting site that is not about to vanish into the night like the others.
-Josh
Quote from: joshua43214 on February 17, 2015, 11:10:29 AM
...I can post the savegame somewhere I suppose. I had not considered it since all you have to do is make an ugly grid of LD res with some ind and com mixed in.
I will see if I can find a file hosting site that is not about to vanish into the night like the others.
-Josh
As a CB member you have 50mb of storage space available in your CBEX briefcase, you just need to click the add button to access it, the only snag is its for registered users and/or visitors with a social login (facebook, google, twitter) will be able to access it
Quote from: joshua43214 on February 17, 2015, 11:10:29 AM
I can post the savegame somewhere I suppose. I had not considered it since all you have to do is make an ugly grid of LD res with some ind and com mixed in.
I will see if I can find a file hosting site that is not about to vanish into the night like the others.
We can make our own, true, but then we wouldn't be using the same microscope. :P
In addition to knowing the city and what to expect, everyone looking to test will have the same base to work from and there's a smaller number of steps involved as 90% of it's already done.
I recommend DropBox for your sending people stuff needs. It's free, no mess, you get a few gigs of space to start with, and it's unlikely to go anywhere.
Also, just leaving this here: https://xkcd.com/949/
Another long post.
tldr: you should really read it...(at least the end)
Quote from: catty on February 17, 2015, 12:10:41 PM
Quote from: joshua43214 on February 17, 2015, 11:10:29 AM
...I can post the savegame somewhere I suppose. I had not considered it since all you have to do is make an ugly grid of LD res with some ind and com mixed in.
I will see if I can find a file hosting site that is not about to vanish into the night like the others.
-Josh
As a CB member you have 50mb of storage space available in your CBEX briefcase, you just need to click the add button to access it, the only snag is its for registered users and/or visitors with a social login (facebook, google, twitter) will be able to access it
Excellent news!
I have been a member of CB for a while, it is a great resource. Your work on CB is in my mind, one of the most under-appreciated resources the community has.
Sadly, I got to working too quickly when I was too tired, and accidentally over-wrote my un-poxed master save.
I will recreate it and re-do the relevant experiments, then upload the save and maybe some dats for people to play with.
I have made a great deal of progress interpreting save files.
The thing that seems to be missing is a save index.
Does any one know if there is a save index? It would be an index of all the saves inside the '0x2977aa47' prop sub-file.
This is important because the game needs to know the location of each prop file inside the sub-file itself.
There are two ways to find each prop file: use an index (like the way a regular exemplar file full of props is), or use the size of the prop file to know when to start reading the next prop file.
The first piece of info in the prop file is its size. You can start reading the next prop file by simply offsetting by the accumulated sizes of the previous prop files. This is a really ugly way to do things because if the file size is wrong, all the following prop files are read incorrectly.
My script uses the file size to know when to start reading the next file.
I have only found two file sizes for props, 88bytes and 108bytes.
presumably there is more because the pseudo code that Ripplejet created would have other sizes.
see http://www.wiki.sc4devotion.com/index.php?title=Prop_Subfile
This page will need a big overhaul when I get a bit further, there are many discrepancies.
an example of a 88byte prop file. As before, all the clear text on the left is mine, only the hex text on the right is in the file.
This also contains information that is used for decoding such as "key_type" and "data_type."
size 88
CRC Фp
mem 0x28a2634
maj_v 0x6
min_v 0x4
zot 0x0
unk_1 0x0
ap_flag 0x0
something 0xa823821e
min_tract_x 0x40
min_tract_z 0x40
max_tract_x 0x40
max_tract_z 0x40
x_tract_size 0x2
z_tract_size 0x2
prop_count 0x0
name-val NA
name-val_1 NA
something_2 NA
data_type NA
key_type NA
word NA
prop_val NA
TID 0x6534284a
GID 0xc977c536
IID 0x1eda0000
IID_1 0x1eda0000
min_x 2.30816478127e-20
min_y 2.63198852539
min_z 270.0
max_x 43.9499969482
max_y 6.63198852539
max_z 273.0
orientation 0xcc
state 0xcc
start_time 0
stop_time 0
count 0x3f
A 0x42
B 0x2
C 0x0
D 0x0
E 0x64
lot_type 0x2
obj_id 0x8c356905L
cond_ap 0x0
This is an example of a 108byte prop file
size 108
CRC Фp
mem 0x28a2974
maj_v 0x6
min_v 0x4
zot 0x0
unk_1 0x0
ap_flag 0x0
something 0xa823821e
min_tract_x 0x40
min_tract_z 0x47
max_tract_x 0x40
max_tract_z 0x47
x_tract_size 0x2
z_tract_size 0x2
prop_count 0x1
name-val 0xcaa46595
name-val_1 0xcaa46595
something_2 0x0
data_type 0x00000003
key_type 0x00000000
word 0x0
prop_val 0x100
TID 0x6534284a
GID 0xc977c536
IID 0x29f10000
IID_1 0x29f10000
min_x 1.07025499574e-13
min_y 4.0
min_z 270.0
max_x 455.5
max_y 12.0
max_z 273.0
orientation 0x0
state 0x40
start_time 0
stop_time 0
count 0xe4
A 0x43
B 0x3
C 0x0
D 0x0
E 0x64
lot_type 0x1
obj_id 0xffffffffL
cond_ap 0x0
if you look closely, there are some obvious groupings that could be made.
This is a reformatted version that looks an awful lot like what we see in the Reader
size 108
0x28a2974
maj_v 0x6
min_v 0x4
zot 0x0
0x0
ap_flag 0x0
0xa823821e 0x40,0x47,0x40,0x47,0x2,0x2
prop_count 0x1
0xcaa46595 0xcaa46595,0x0,0x0,0x100
TGI 0x6534284a,0xc977c536,0x29f10000
0x29f10000 1.07025499574e-13,4.0,270.0,455.5,12.0,273.0,0x0,0x40,0,0,0xe4,0x43,0x3,0x0,0x0,0x64,0x1
0xffffffffL 0x0There is a certain pattern that always occurs at a few points, importantly, notice that the IID is always given twice in a row
TID 0x6534284a
GID 0xc977c536
IID 0x29f10000
IID_1 0x29f10000notice also the name value is given twice in a row
name-val 0xcaa46595
name-val_1 0xcaa46595I started looking for corrupted files. Because my script offsets to the next prop based on the size of the previous prop, my script would crash when it hit a corrupted file length.
here is an excerpt from the last "readable" file in a poxed city.
size 1154551993
<snip>
zot 0x6400
<snip>
something 0x2a46ee
<snip>
prop_count 0x11569674
<snip>
prop_val corrupted
TID 0x4000000
GID 0x40006
IID 0xa823821e
IID_1 0x615e615eaccording to this record, this prop file is about 1.1Gb. Notice also that the IID does not match the IID_1
The zot is not a valid zot type
the prop_count (property count, not "prop") is to big
If the game does not have an index for prop file locations, then all the following props will be lost not be read, and you will see a poxed city.
This corrupted file however is not the cause of the pox, it is a symptom :)
This is an excerpt from the previous prop file:
size 88
<snip>
zot 0x6
<snip>
prop_count 0x20002
name-val NA
name-val_1 NA
something_2 NA
data_type NA
key_type NA
word NA
prop_val NA
TID 0x89a1c16c
GID 0x1
IID 0x89a1c16c
IID_1 0x0Again the IID does not match the IID_1
again the zot type is invalid.
more importantly, the property count is wrong. It says there are 131074 (0x20002) properties. In all the files I have looked at, the property count is either 0 or 1 (Ripplejet recorded values of 2 and 3 as well).
If the property count is 0, the file is 88bytes long. if the property count is not 0, the file is 88 + the length of the additional properties (in my case this is always 20).
The IID is 4 bytes long.
I modified the script to compare each 4 byte segment to the following 4byte segment. If I could find the offset where there was two segments that were identical, then I could find the proper offset for the rest of the file.
This condition did not exist, the data is corrupted.
I believe that this is supposed to be a prop record greater than 88bytes. If say this was supposed to 108Byte record, the following prop file would start 20 bytes later than it currently does.
offsetting the next (the last "readable" file) file by 20bytes yields this:
size 2770670
CRC yЫ
mem 0x101f2168
maj_v -0x698c
min_v 0x1156
zot 0x6
unk_1 0x4
ap_flag 0x4
something 0x4000000
min_tract_x 0x1e
min_tract_z 0x82
max_tract_x 0x23
max_tract_z 0xa8
x_tract_size 0x615e
z_tract_size 0x615e
prop_count 0x20002
name-val 0x1
name-val_1 0x89a1c16c
something_2 0x89a1c16c
data_type 0x00000000
key_type 0x00000000
word 0x0
prop_val Null
TID 0x36000000
GID 0x0
IID 0x4ac977c5
IID_1 0x653428The property value is Null!
this appears to be another instance of the previous prop (there is a single record for each and every individual prop).
Notice the size is still wrong.
Notice that name_value_1 = something_2. name_value_1 is at offset 20. The bad data that precedes this actually belongs to the previous record. The key_type and data_type are both valid. The property count should be something valid.
Adding a loop right before the TGI value to bump the offset by 1byte until IID = IID_1 (turned out to be offset 6)
yielded this
TID 0x6534284a
GID 0xc977c536
IID 0x29000000
IID_1 0x29000000Does anyone want to guess what prop has this TGI?
This is the TGI for the beach umbrella :)
Offsetting the next record by 112 to compensate for the corrupted previous file yields a perfectly good prop file (yet another umbrella). Offsetting again by 108 (the correct length) yields another umbrella (perfectly good record).
So this adds more support to my theory about a null value corrupting the file, and data reading from or into another file.
The upshot here is that in this case, the data is not being overwritten, just missed.
This means it might (might) be possible to actually cure prop pox :)
Next is to start trying to figure out what the values actually mean in relation to what kind of prop is being recorded
-Josh
Hats off to you Josh! I am by no means a computer programmer, but your post made quite a bit of sense. It seems like you are definitely on to something here :thumbsup:
I thought it was it over-writing the next entry. Turns out it's just the size being recorded wrong. Hats off to you for the in-depth analysis. If we had the CRC algorithm for the network subfile, someone could probably build a program that fixes it.
Quote from: joshua43214 on February 19, 2015, 10:35:18 AM
...I have been a member of CB for a while, it is a great resource. Your work on CB is in my mind, one of the most under-appreciated resources the community has....
&blush
Thanks, as for the CBEX briefcases you can upload (in theory as no one has ever tried it) a file up to 25mb in size, if you need to upload something bigger then I should be able to tweak the CBEX settings to let you, the other thing to be aware of is you cannot delete any files you upload the reason being the CBEX uses group permissions so if I give registered users delete rights to the CBEX then they can delete anything, their stuff ... your stuff ... the official MAXIS files, etc so if you do upload something and you want to delete it then just send me a PM and I'll delete it, I hoping the company that makes the CBEX software will eventually change this from group permissions to individual permissions, but in the meantime its a pain.
If I was still on the SC4D staff I'd give you a karma point for the research you are doing re the prop pox :thumbsup:
That IID_1 column did ring bells with me as something I'd read about in the past, did a bit of search and found it was mentioned by a fellow RTMT team member in a post on traffic signals
http://sc4devotion.com/forums/index.php?topic=5136.msg265392#msg265392
:)
@joshua43214: I just have to say that this is an awesome piece of research. Thank you very much for this. I'm really looking forward to seeing where this goes. Let's hope there will be some more insight at the end of this, in addition to what you already found out.
Quote from: HappyDays on February 16, 2015, 08:54:44 PM
Fascinating. Concerning, as well. There are many prop packs on this site alone that override props from other prop packs, and add/remove various things. Unless there are more specific limits on what causes prop pox than what you've described, many people could be infected.
One example of many:
BSC Mega Props - JES Vol01. Instance 10A83059 (jes_BN-Line-53_Container) conflicts with the one contained in BSC MEGA Props - Misc Vol02. Same basic prop, different properties.
BSC MEGA Props - Misc Vol02 is such a PITA. Unfortunately it was made a dependency for BSC Essentials. It really messes with existing plugins, like adding more props with bigger footprints to existing families in BSC Mega Props - JES Vol01, which makes many lots that use the latter dependency look pretty ugly. I had deleted it from my poxed city, too. (Disclaimer: No, that is no indication it is in any way responsible, as I deleted too much stuff to really pinpoint anything). I was thinking of deleting most of the questionable stuff out of this file for my next region.
Sorry for the tangent, as this is probably not related to prop pox, but this dependency is a bit of a sore spot with me.
Many of the older mega packs, the ones assembled from props made in the pre-SC4devotion days, are a bit messy. BSC MEGA Props - Misc Vol02 is the tip of a very large ice burg.
That said, I am impressed the BSC team did as well as they did sorting things out without the benefit of DataNode. We're talking tens of thousands of props of all levels of quality. That things work as well as they do, that's something to be commended.
My main issue with mega packs is that, generally, you're not using half of what the pack contains, with the rest adding to load times for no benefit. That's a rant for another time, though.
Quote from: HappyDays on February 20, 2015, 05:00:45 PM
That said, I am impressed the BSC team did as well as they did sorting things out without the benefit of DataNode.
Oh, yes, certainly. Just to make sure, I didn't want to denigrate anyone's work here. I'm very happy for all the wonderful content I got the opportunity to use, and I'm thankful for that. In this specific case, I'm just unhappy about these multiple interdependences, which cause stuff like this (http://sc4devotion.com/forums/index.php?topic=327.msg454748#msg454748) to happen, and it's a bit difficult to say "just don't use this" if we talk about a dependency for BSC Essentials.
Regarding Mega Packs, it's a trade-off. I guess they are the result of complaints about "too many dependencies".
Teaser...
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi179.photobucket.com%2Falbums%2Fw298%2Fjoshua43214%2FPropteaser.jpg&hash=4b26ea9bc1a2df77c2127929819234dcc6619afd)
:)
WIP...
I like the title of this :).
Looking good &apls
I have some updates.
I made a pair of new test cities. The first is a large tile with roads, some minor amenities, and fully zoned ready to run. The second is the same city just before the prop file decompresses. I have confirmed that it does not pox on it's own, but will pox when the BDK file is added. I need to double and triple check to make sure it is all kosher, then I will upload it to the CB.
Next, I have successfully removed the corruption from a poxed save game, generated a new save game file that the game loads and runs with no crash dump errors. The new save is "pox free" according to the SC4 Savegame Explorer, and it opens and looks fine in the Reader.
Sadly, it will re-pox after the game has run for a while.
Which leads me to the next part, I think I have tentatively found the actual cause of the pox. I was wrong about the null value messing up decompression, nulls seem to occur when the file corrupts and is an effect, not a cause. The issue seems to be faulty state flags either during a timed state change or during re-development.
Below is a truncated table of experimenting with plopping various props. I used the SC4 Lot Editor to add a bench, an umbrella, patio furniture, and a lotcarcluster (commonly found in commercial lots) to individual grassy parks. These are all un-modded Maxis props, and each has a single timed property different from the others. I would plop the lot, save, wait through a day/night cycle and save at various points during the cycle, and run my script over the save game to parse out the info. I would then delete the city, and create a new city for the next plop test.
| bench | umbrella NSC | | | | | patio furniture PTOD | | | | lotcarcluster ALS | | |
| | day
| night hidden
| night visible
| day 2 visible
| day 2 late hidden
| day
| late day
| night
| day 2 late
| day no power
| day power
| night
|
size
| 88
| 88
| 88
| 88
| 88
| 88
| 88
| 88
| 88
| 88
| 88
| 88
| 88
|
ap_flag
| 0x5
| 0x5
| 0x5
| 0x5
| 0x5
| 0x5
| 0x5
| 0x5
| 0x5
| 0x5
| 0x5
| 0x5
| 0x5
|
prop_count
| 0x0
| 0x0
| 0x0
| 0x0
| 0x0
| 0x0
| 0x0
| 0x0
| 0x0
| 0x0
| 0x0
| 0x0
| 0x0
|
name-val
| NA
| NA
| NA
| NA
| NA
| NA
| NA
| NA
| NA
| NA
| NA
| NA
| NA
|
name-val_1
| NA
| NA
| NA
| NA
| NA
| NA
| NA
| NA
| NA
| NA
| NA
| NA
| NA
|
prop_val
| NA
| NA
| NA
| NA
| NA
| NA
| NA
| NA
| NA
| NA
| NA
| NA
| NA
|
state
| 0x0
| 0x0
| 0x1
| 0x0
| 0x0
| 0x1
| 0x0
| 0x1
| 0x1
| 0x0
| 0x1
| 0x0
| 0x1
|
start_time
| 0
| 90
| 90
| 90
| 90
| 90
| 120
| 120
| 120
| 120
| 70
| 70
| 70
|
stop_time
| 0
| 180
| 180
| 180
| 180
| 180
| 160
| 160
| 160
| 160
| 200
| 200
| 200
|
cond_ap
| 0x0
| 0xf
| 0xe
| 0xe
| 0xf
| 0xe
| 0xf
| 0xe
| 0xe
| 0xf
| 0x7
| 0xf
| 0xe
|
KEY:
NSC = Nighttime State Change, this is the property deleted from the BDK umbrella.
PTOD = Prop Time of Day, this is the property added to the BDK umbrella.
ALS = Active Lot State, just another timed timed prop for comparison.
According the work done by Ripplejet and published here:
http://www.wiki.sc4devotion.com/index.php?title=Prop_Subfile
a conditional appearance flag (cond_ap) of 0xe is a timed prop in state 0x1 (hidden/off). Note that the umbrella (NSC) can have a cond_ap flag of 0xe and yet have a state of 0x0 (visible/on). Both the patio furniture (PTOD) and the carcluster (ALS) follow the rule.
Either this confusion of timing and state flags is the issue, or there is a problem elsewhere in the savefile.
When a new grassy lot with a single prop is plopped, 5 new entries are added to the index (the prop, lot, building, type 10, and an unknown sub file). The unknown file is 91 bytes long. I spent some time trying to figure out what is in it, but nothing obvious came up. The TGI for this file is '0xc97f987c', '0x299b2d1b', '0x00000000' if any one has some ancient records floating around of what this might be. It does not seem to have either the IID or the instance IID for the prop.
Some of the other sub-files in the save game (there are 147 total with one prop) get bigger as well.
If the issue is with conflicting flags, each prop would have to be checked against a library of props and the flags individually corrected. This is not inconceivable, there are only 65 props with NSC and only 521 with PTOD in the vanilla game. The issue is that the other causes of prop pox besides the BDK are not found and eliminated. I suppose there is no reason the plugins folder could not be scanned and a list of all props and their properties could be created. My i7 with 16 Gb of RAM can handle this with no issue, but it could easily crash on a smaller system. I was considering making this script anyway to scan for this issue between modded props. As someone already stated, some of the BSC prop files do a lot of replacing other BSC props. I would really like to pin down the actual cause first.
At this point all we know for sure is that deleting the NSC and adding the PTOD properties to a prop causes the pox. Is the reverse true? The ALS files concern me to, parking lots are a popular item to mod.
-Josh
Quote from: joshua43214 on February 24, 2015, 01:09:42 PM
...The TGI for this file is '0xc97f987c', '0x299b2d1b', '0x00000000' if any one has some ancient records floating around of what this might be....
Can't stop to read as I'm at work, but 0x
c97f987c comes up in the Sims Wiki in the document they were recording the SC4 SAVEGAME details and which bits they had decoded
http://simswiki.info/wiki.php?title=SAVEGAMES
Its just above the "Tire Recycling Ordinance" that document was transferred to that site back in 2005 when the old wiki was shutdown so its really old, I don't know if anyone else has tried decoding any more of the SAVEGAME
%confuso
Quote from: catty on February 13, 2015, 07:06:10 AM
A few years ago I used SC4LotInfosGenerator and scanned my plugins, the LEX DVD and CD and the STEX Disks (2, 3 and 4) ending up with a huge number of duplicates records obviously and as I only wanted to know the name of the plugin and its file name I ended up with an Microsoft ACCESS database containing this information
GALLERY File Name
0xEE668F70 SG_Lots_Motels.dat CS$$4_3x3_SG_BrewPubFishTaleAle
0xEE668F70 CS$$3xSG_BrewPubFishTaleAle_ee668f70.SC4Lot CS$$3xSG_BrewPubFishTaleAle
0xEE66901B SG_Lots_Motels.dat CS$$2_2x5_FishTaleInn
0xEE66901B CS$$2xFishTaleInn_ee66901b.SC4Lot CS$$2xFishTaleInn
57215 lines in total, I've exported it out as a text file (its still 4mb in size) and put it "dino's" briefcase over at CB in case anyone wants it.
I've deleted this from my briefcase, did a much needed tidyup re getting rid of duplicates and have started putting it somewhere everybody can view, it will take a while as you can only have about 500 lines per post
http://city-builders.info/apps/canvas/25-discussions/group/17-simcity-4?customView=item&discussionId=47
:thumbsup:
I'm currently experiencing Prop Pox. I haven't had a chance to read the entire thread, but does that 6MB filesize theory still hold? I ask because the city in which I'm experiencing PP has an overall size of exactly 10MB, but the filesize is 4,133,617 in ilives. Another city has an overall size of 44MB, and it's filesize is 14,134,667, but no PP. ()what() The bigger city is about 800k and the other is around 450k.
Sorry point of order first: are you sure you have prop pox, this must be the #1 misdiagnosis I hear. Please can you state exactly what is happening and when it started happening (if anything changed in your plugins for example). This information helps to make sure you are being given the correct advise.
As for file sizes, these are irrelevant, it's a specific part of the file that is being refereed to not the actual file size itself, such sizes are quite normal for developed tiles.
All,
I post this again as this has fixed my Prop Pox issue. I have studied this ever since the game came out and what I have discovered is the following:
I appears to all be with ones plugins. When one downloads a plugin and builds the city. When the creator makes an update change to the plugin, one re-downloads the same plugin and goes back into the city with the plugin, and wa-la, Prop Plox. I have made the painful decision to NEVER re-download any more updates to ANY plugins and deal with what I have and ROUTINELY back up EVERYTHING even my Regions. By me demolishing an effective map and starting all over again and fixed my Prop Plox issues.
Now, I am no programmer or computer genius, just a die-hard SC4 player whom uses the excuse to demolish and modernize my maps with the latest NAM standards. Now, what I have not concluded is that latest NAM is part of the Plugin Update fiasco or not; thus far, it appears not be a Prop Plox demons.
Just a little food for thought and what have been working for me.
dyoungyn
mgb204, yes I believe so. I did recently update the game from the xx38x to xx40x, but nothing else has been recently downloaded. 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. That's a recent change.
EDIT: I did recently update the Mipro Essentials file and the METMW Prop Pack from 1.2 to 1.3 as a dependency for a new building. I don't think it would have been the mipro because I played with it for some days, but the METMW is within the past few days.
Quote from: dyoungyn on May 17, 2015, 02:19:50 PM
<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.
Quote from: alexr19
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.
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.
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.
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
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.
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
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").
Quote from: joshua43214 on July 28, 2015, 08:57:33 AM
...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
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
Quote from: mgb204 on May 18, 2015, 05:42:04 AM
Quote from: dyoungyn on May 17, 2015, 02:19:50 PM
<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.
Quote from: alexr19
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.
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.
@ 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.
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 :D
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?
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.
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 :D
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).
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.
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...
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.
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.
Quote from: woodb3kmaster on January 26, 2016, 05:14:08 PM
<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)?
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. &Thk/(
Quote from: Wiimeiser on January 26, 2016, 05:51:16 PM
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).
Quote from: APSMS on January 26, 2016, 11:30:58 PM
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! :D
Quote from: APSMS on January 26, 2016, 11:30:58 PM
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).
I usually save with CTRL + ALT + S periodically in-game (this is much faster because it doesn't update the region view and doesn't safe any data for the transportation view). I only use CTRL + S when I want the region view updated for screenshots and stuff. I never save with the button, always with the keyboard, and then exit without saving.
Quote from: woodb3kmaster on January 27, 2016, 02:57:09 AM
Quote from: APSMS on January 26, 2016, 11:30:58 PM
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! :D
I didn't notice in you post that you deleted anything from your plugins file, except for the Quais de Seine trees from a long time ago. Why would those props have the network index/jobs files as part of their exemplars, or am I missing something obvious here (most likely)? Or rather, why would prop pox, which removes props after the prop exemplar file experiences an uncontrollable overflow, affect the network TGI/parameters?
Quote
IINM, that fix is by simmaster07, but yes, it's installed.
Oops, faux pas on my part. Sorry simmaster07. :-[
Quote from: woodb3kmaster on January 27, 2016, 02:57:09 AM
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).
Yes, I have also read somewhere (I believe it was here on SC4D) that saving at zoom 1 and setting details to low speeds up the process of saving and helps to avoid the prop pox. This is probably because fewer props are "visible" in that case.
I have personally tried this in the past and yes, it does re-set the Prop Pox, however, it also removes all the floral as in trees when you re-set it back to the default view.
I saw about this on the dll thread at the other site...
I am not sure what is going on, I didn't read the entire thread (36 pages woot!!!)
Also I never had the issue, maybe because I don't have lots of graphical mods (including new lots), since I tend to focus on gameplay stuff.
Anyway, recently I've been STILL trying to track down the damned commute time bug, and while chasing it I ended stumbling on how the game saves stuff, since it is not related to what I am chasing now, I don't went in details...
But the game basically use something that resemble "save-state" that you see in console emulators, it copies whole chunks of memory, compresses it, and stores it, this includes even completely irrelevant information for when it is decompressed, like memory pointers, and stuff that have to be reset anyway (like the current CPU timestamp, used to know how much time passed since the last simulation update).
The "subfiles" people documented, are frequently a class, many classes in the game (but not all), inherit from a class called "Serializable", the game when saving basically memory dump entire classes on the save file.
The result of this, is that everything, and I mean EVERYTHING affects a safe file, the zoom level, what you were doing, the time of day in real world, the time in-game, the amount of props on screen, the amount of automata on screen, and so on.
Maxis basically was unsure of what to save, and decided to just save everything.
This has some side effects:
anything that was decided only once (for example during city creation), will stay that way, no matter how much you mod the .exe, add .dlls, edit .DATs, install or remove plugins, some stuff will just stay in that save file.
This is why sometimes if your save gets corrupted, you can't fix it, the corruption is saved in it, and will stay in it.
This also makes the general idea of installing and removing mods during play of a city, a bad idea, any mods that add or remove stuff that is saved only once, won't affect it, maybe to no effect, and maybe to causing bugs, since I have no idea what properties of a save file are calculated only once, I cannot advise about what type of mods cause bugs or not.
Another notable thing, is that because the save file is a memory dump, that is affected by almost everything, you must be careful to not save your file in some situations, for example if you are going beyond what the game can do (example: maybe you zoomed out, and there is not enough memory to display all props, or you have a crap GPU that don't have enough vram for all textures), it will save that "culled" information, or even corrupted information.
Also, if you save the game after something corrupting happened, it will save corrupted (example: your computer overheated, and started to glitch all over the place, any random stuff that the overheating changed on the memory, will be saved).
So what I can suggest is: if you care too much, make backups (I personally don't make them). And be careful when you save, if you abused the game in some manner (example, created some bizarre stuff with NAM or other complex mod, or tried all the cheats, or installed some crazy mods to see what they do), it is better to not save.
Well that's interesting.
Quote from: APSMS on January 27, 2016, 03:55:00 AM
I didn't notice in you post that you deleted anything from your plugins file, except for the Quais de Seine trees from a long time ago. Why would those props have the network index/jobs files as part of their exemplars, or am I missing something obvious here (most likely)? Or rather, why would prop pox, which removes props after the prop exemplar file experiences an uncontrollable overflow, affect the network TGI/parameters?
There seems to be some misunderstanding here. I'm not saying that I deleted anything from my
plugins (not even the QS trees; I simply put the old versions in a folder that loads after the new ones). Rather, I deleted three subfiles from
within my savegame, as per z's instructions from page 20 of this thread:
Quote from: z on April 06, 2010, 10:12:27 PM
You can completely get rid of the pox any time you want... temporarily. Here's how:
1. Open your saved city in Ilive's Reader.
2. Sort the left pane based on file size, with the highest at the top.
3. Near the top, there will be a subfile of type 2977AA47. This is the prop subfile. Delete it.
4. Also delete the subfiles of type 6A0F82B2 and 6990C1AA, which are also near the top. These subfiles are regenerated as needed. If you don't delete them, this process will still work, but your city size will increase greatly each time you repeat this process.
5. Save the city file.
6. Start up the game, but don't open the city file.
7. Open the Graphic Options, and make sure the City Detail is set to Low.
8. Open your city and save it immediately.
9. Exit to the region without saving.
10. Open the Graphic Options, and change your city detail to High.
11. Open your city. All your props should be restored.
12. Save your city. Your props will all be there... for a while.
Those two extra subfiles that the instructions say to delete are, as I mentioned, the network index subfile and the sims-to-jobs matching subfile. Prop pox doesn't affect them at all, but deleting them supposedly keeps the savegame from getting bloated (although that wasn't true for me; my edited savegame was over 35MB after I saved it). However, it also has the effects I described in my first post.
I'm really confused and frustrated by the Prop Pox right now; it has occurred in my main region after three years of no instances of the bug. I have been making about bi-weekly backups of the region for the past three years since I started it, at least during periods of time when I was playing SC4. For at least the first year of play, I was rigorously checking all of the city files I'd played in SC4Save to see if there were any disabled props every time before I made a new backup, and there never were any. Eventually, since I already had most of the plugins I wanted for the region, I stopped doing checking the files, and stopped adding new plugins to the game.
About one month ago, though, I noticed the full instantiation of the prop pox bug in one of my main cities in the region. Unfortunately, looking at many of the older backups from previous months shows that many of the cities had positive values for the number of disabled props in the region. The older backups don't have any disabled props. What's strange is that if I load an old backup of the region (without any disabled props) and then load and save the main poxed city (after waiting a few minutes), the city then has around 300 disabled props.
It appeared to me, then, that the plugin which caused the prop pox must have been added after that backup was made, so I tested removing different plugins from my game and loading and saving the city in question. Bizarrely, the same number of disabled props would show up for this city no matter how many plugins I removed—I even removed all the files from the Documents plugins folder AND all the ones from the game's installation directory and still got around 300 disabled props.
I really don't understand how the disabled props can initially appear in a city when there are no plugins installed whatsoever. Perhaps the offending plugin(s) was(were) in the game's folder all along, and I'm only seeing new disabled props now because that mod was removed from the game? The past month's worth of testing to find the source plugin(s) has proven unsuccessful, sadly. I've tested the majority of the backups I'd made individually, mainly by binary testing (removing half of my plugins and testing the city). Even with the oldest one, from early January of 2013, I get disabled props when I remove all of my plugins and test the only city in the region at that time. I get between 100-200 of them if I do this, but if I leave the current set of plugins I've had in the folder (what I've been playing with for a long time), I only get 2 disabled props—but this is more than this city had between the original backup and the subsequent one; both backups showed 0 disabled props originally.
Can anybody help me to explain all of this? I just want to find the cause of the bug in my plugins; if I have to re-start the region, I guess I'll do that, but I just need to find the bad plugin already.
Moonraker,
The only currently available file that is known to definitely cause Prop Pox is PEG-OWW2_BDK_RESOURCE.DAT. There has been much speculation over the years that there have been other files that might have caused the Pox back at the dawn of the SC4 modding movement (primarily because there was evidence of the Pox, or something very similar, that was available before the PEG file was ever published), but if the speculation is correct, none of the these suspect early files are currently available. There has also been speculation that other PEG files have also caused the Pox, but this has never been proved.
The most concise and complete explanation of the Pox is in the the very first post of this topic by BAP. Probably more important that his explanation of what causes the Pox is hisexplanation of how to avoid it (or even fix the PEG file if you really need it),
Also very important to understand is that none of the other content that has been published by Pegasus has been found to cause the Pox. Some of the posters on this topic have suggested that the best way to avoid the Pox is to not use any of the content created by Pegasus, but I have always felt that this is a gross overreaction. Obviously players will do what they want (sometimes regardless of what is suggested by anyone else), but by not using any of the PEG content, these players are denying themselves the use of some very unique content that hasn't been touched by any other content creator (IMHO).
As far as whether you need to restart your region, that is the common wisdom. There have been several people that have suggested "fixes" for a Poxed city, but most if not all of these fixes have proved to be only temporary.
Go back and read through the first couple of posts, and hopefully most or all of your questions will be answered.
Thanks for your reply. I actually have previously read all the posts in this thread, including re-reading the first few recently, but could not come to a solution based on any of it. I thought that the presence of any disabled props at all means that the city is prop pox-infected and will eventually show the bug's symptoms. Also, I didn't mention this in the last post I made, but I'd already corrected the BDK resource pack file based on bap's solution in one of the earlier posts (the one involving deleting the offending props, if I remember correctly). I had corrected the BDK file before I even started this region in 2013, so that's why I thought there must be another cause somewhere in my plugins, but just like you said, it doesn't seem like anyone knows of another plugin that causes Prop Pox. I'll definitely re-start my region, but I have a feeling the Prop Pox will still manage to show up in my cities, unfortunately. It seems like there's just no escaping it when you use a lot of mods like I do ()sad()
Hi,
Sorry to wake this thread but I have come to a dead end and need some advice. I bring pictures:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FZZ4ky1y.jpg&hash=47189e7a67306527b1e954aeaf417e04ed8c1ba7)
maxis country club sans tree cover...
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FOsf7v0S.jpg&hash=68021a7c227dfad1a2a6aae5fff61c703fbc750a)
maxis mayor house missing seemingly quite a lot
These lots are obviously affected by an issue. I have not had the file confirmed as causing prop pox in my plugins folder (or any from the same 'series')
I cannot currently download the savegame explorer from the lex as I am perma-logged in on my work pc and forgot the password - t(he reset goes to a work email and I am not at work) :'(
This city is the first tile in a newly developed region as my last region showed similar issues - maxis country club being the first affected lot I noiced there also.
The save file for the city is currently 34.2 MB, although as mentioned above I can't look more deeply at present.
Basically, I am looking for a confirmation that this (could be) prop pox, in which case there is another guilty file floating around - as I have never created content for myself it must be something I have downloaded and therefore must be worth flagging to the community.
Alternatively, someone offering an alternative explaination - some other kind of save file corruption - would also be helpful.
Typically pox affects a city over huge areas (see Feyss' recent encounter) (http://sc4devotion.com/forums/index.php?topic=14867.msg507834#msg507834), making props disappear in wide strips which run all throughout the city tile. In other words, it rarely affects just one or two lots. If this were pox, I'd expect for instance to see props missing on the avenue, as well as the residential lots. From the looks of it, I'd say it's an issue with the Maxis rewards instead. Perhaps you have recently added reward replacements without bulldozing previous instances of them?
Then again, without confirmation from SC4SavegameExplorer my guess is as good as anybody's, really.
I appreciate the response, I don't have anything which messes with the rewards to my knowledge as this tile has all been developed quite recently. I will get the save game explorer next week and have a better look
Since it only seems to affect Maxis' lots (the large park looks bare as well), and you had this happen previously, maybe the main game files are corrupted somehow. If you're comfortable with the idea you could try reinstalling the game all together, just make sure to back-up the plugins and regions folders beforehand.
Vortext. The re-install seems to have worked. Thank you so much! :thumbsup:
I was wondering if anyone can definitively tell me whether or not having a nonzero value for "disabled props" in a city tile means that it is prop pox-infected and will eventually show the symptoms of prop pox if the necessary conditions are met. After the last run-in I had with the prop pox recently, I re-started my region. Previously, I had just used iLive's Reader to correct the known cause (PEG BDK Resource Pack) to avoid the prop pox (this was years ago), but upon restarting the region, I just went ahead and deleted it, since that seemed to not be working out. Now, in the brand-new region, I have disabled props showing in SC4Save in some of my cities. I re-read the first few posts of the thread, but couldn't figure out if disabled props necessarily mean prop pox or if they have other uses in the game. I guess I'd previously thought that the presence of disabled props meant that the city was infected. Perhaps there is another cause of Prop Pox in my plugins after all.
Yeah I'm afraid disabled props in SC4Save means the city will get prop pox once the file size threshold is met, and as far as I know there's no way to somehow get rid of them, or re-enable the props before it's too late. &mmm
Something I noticed a long time ago: God Mode data doesn't appear to use checksums. Or at the very least, you can corrupt a city so that its tile disappears, open the tile in SC4Terraformer, and, as long as you revert the tile to God Mode it will reappear. Not sure if this is really all that relevant, but we might be able to figure out a lot more, possibly even a fix, by checking out the checksums.
EDIT: On a more on-topic note, what would happen if you obliterated a city with the pox and immediately started a new one without saving or leaving the tile? Would it carry over?
iirc obliterating a city only makes things worse because it marks all props as disabled.
I've got a city tile, that only has layed out with some roads and streets and zoned with some Res and Com areas. I've never played it further, so this city hat no buildings grown or plopped and it has no residents. Curious about the SC4 Save Explorer tool I opened it and found 5 disabled props counted in the tool.
Are street/road tiles counted as props as well? I might have deleted some before I saved this city a while back.
Anyone has an explanation for this? Just curious you know...
Kind regards!
:)
Hello!
I want to thank all the contributors to this topic. I am fairly new to SC4 and even newer at adding custom content, but this topic popped up while I was looking at seasonal tree mods. After reading over 100 pages on a few different threads this topic has my head spinning!
I am curious about a few points...
Is there a list "$Deal"$ of all known files to cause this issue?
Three files that I saw listed in most of the threads:
PEG-OWW2_BDK_RESOURCE.DAT
PEG_TrailPark-Engine_305a.dat
PEG_CDK--IND_205.dat
I see the above files are currently available on the STEX, have they been fixed?
On two of the threads, it was pointed out that as long as suspected Pox files are not removed, then prop-pox should not happen. Is this correct?
Quote from: River.Song on February 12, 2017, 02:16:56 PM
Is there a list "$Deal"$ of all known files to cause this issue?
no, unfortunately not.
Quote from: River.Song on February 12, 2017, 02:16:56 PM
I see the above files are currently available on the STEX, have they been fixed?
afaik they have not been fixed.
Quote from: River.Song on February 12, 2017, 02:16:56 PM
On two of the threads, it was pointed out that as long as suspected Pox files are not removed, then prop-pox should not happen. Is this correct?
No, it doesn't matter if the actual files are removed or not. What matters is whether or not the affected props are being disabled in the savegame file, which for examples happens when a growable lot upgrades.
Maybe we should, you know, stop modifying existing props? If you try to do that in Gmod both versions of the model fail to load altogether and it spams errors like "Error Vertex File for 'Humans\Group03\Female_07.mdl' checksum -1076405403 should be -710229447"* once per frame per model; not 100% sure what happens but it appears to be having two mdl files with the same name, for example, HL2E2's gnome and Rockford's gnome...
*In other words, I think it's expecting something like (1 = 0), which is mathematically impossible
Quote from: bap on February 24, 2009, 08:53:46 AM
How to avoid the problem
3- Open the PEG_OWW2_BDK_RESOURCE.DAT file with the ilive Reader, change the exemplar name (p.ex., add a PEG_ before each name) and the instance of the items 11, 12, 13 and 14 (mark each one and select "generate new instance"), and save the file. Load each of the beach lots into LotEditor and replace each occurrence of these props by the corresponding new PEG_* prop and save the lots. Replace the original lots by the modified ones. They will work exactly as designed, but will no longer lead to Prop Pox.
So playing with the ilive Reader I was able to figure out how to change the exemplar names of the 4 questionable props, but when it comes to generating the new instance of the items, is it just as simple as I am reading it? Or do I need to request an "instance (iid) range" first from y'all?
I don't want to create a new problem.
-R
Quote from: River.Song on February 12, 2017, 02:16:56 PM
Three files that I saw listed in most of the threads:
PEG-OWW2_BDK_RESOURCE.DAT
PEG_TrailPark-Engine_305a.dat
PEG_CDK--IND_205.dat
I see the above files are currently available on the STEX, have they been fixed?
Here's one of the problems re: this thread, people don't generally understand the issue all that well. It should be noted that neither PEG_TrailPark-Engine_305a.dat or PEG_CDK--IND_205.dat have actually been shown to cause prop pox. So many files are "questioned", but the reality is that only the two initial files noted at the beginning of the thread, were ever linked to the problem. Those are the PEG-OWW2_BDK_RESOURCE.DAT (Beach Development Kit) and one file from BSC which was swiftly fixed. A lot of paranoia has sadly been generated by this thread, hence the accusations of problems with other files, none of which have ever turned out to have such problems.
You also need to understand that once you've had the affected files in your plugins folder, if you saved any cities whilst they were there, those cities
*could* develop the problem. Removing the files or fixing them, having previously saved with them present, will not change the chance of problems developing one day. The only way to ensure no problems exist is never to save a city with the "broken" files in the first place. So if you've done this before knowing about the problem, what do you do? Note how the issue is mainly an issue associated with players using large tiles, with large swathes of small 1x1/1x2 houses. If you don't play this way, chances are Prop Pox will never occur. If you do though, perhaps consider how far developed your cities are? If they are in their infancy, perhaps it's safer to start over now you've fixed the cause, rather than risk finding your cities are doomed later on? If the problem does occur, even having backups will not help you to resolve the problem.
As for what ID to use for the new props, just right click the exemplar and click on Generate New Group and Instance. A random ID is the best to use for props, there is no need to have one issued for props. With billions of possibilities, the chances of conflicts are mathematically insignificant..
Quote from: Wiimeiser on February 12, 2017, 05:56:40 PM
Maybe we should, you know, stop modifying existing props?
As a user, you are never forced to install such modifications. Again, that viewpoint is a classic example of the over-hyped paranoia the words prop pox bring about.
Fact: One file and 4-5 props have been altered in a way that seems to cause problems, without being "fixed". I'm sure anyone who's read a little of this thread doesn't need it explained why that is. So based on one tiny blip, however catastrophic it might be
IF it happens, we should stop doing a thing that is standard practise and has many benefits? No, I'm sorry, but I couldn't disagree with you more in this case.
Hello,
So, I edited the 4 props in "PEG-OWW2_BDK_RESOURCE.DAT". Then edited the three beach lots that had the modified Maxis props, switching them for the newly named Peg_ props. When I save the lots, they save separately from the original DAT file. Do I need to edit the other Lots too, just to remove them from the DAT file?
-R
If you are comfortable with using Reader, I'd remove the original lots from the DAT file. Then copy over the lots with those modifications back into the DAT file. Then you can discard the lots and just use the updated DAT from here.
Depending on how you saved them in the LE (did you use Save or Save As), the former will have the same ID, i.e. override the originals. But the later will give your new lots a unique ID. Ideally you'd have used Save. In which case you can also load the lots after the DAT file and it will all work.
Also, in case you didn't know, PIM-X (https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjgmv7xnI_SAhVhKpoKHR6rBYcQFggaMAA&url=http%3A%2F%2Fsc4devotion.com%2Fcsxlex%2Flex_filedesc.php%3FlotGET%3D2260&usg=AFQjCNHmHGq4zqpR8_SLPPDIvcN3XatEsA&bvm=bv.146786187,d.bGg) is an improved tool for replacing both the PIM and LE from Maxis. One of it's benefits is that you can save files/modifications inside the original DAT, without having to create new lots, you should check that out.
This conversation has no end. A man who knows IliveReader, Gmax and Phototoshop can create all and do it all. Why everyone needs a beach from PEGASUS?. Maybe we can insert another beach and will not torment PEGASUS... He's a great artist with dozens of lovely files for SC4. We know the dangers of PROP POX is not the first year. Maybe it is not necessary to remake the original from PEGASUS but use another? Maybe put this in the SC4Devotion's "New Member Area" line?
Hello,
@mgb204 - Thanks for the info. I will checkout the PIM-X tool. Since it's only a few lots, and I have a copy of Pegasus' original, I will just edit them again in the new program.
@Silur - I am still at the crawl stage. I have only been playing for about a month and this is my first endeavour into editing. Looking through some of my father's files he had a lovely island resort, with a great looking beach. Much of his island was with Pegasus' creations, so I wanted to replicate it in my region.
As for the other stuff, I plan to get there... Eventually. However, I will need to get proficient at a more basic task before I can head down that road.
-R
Good luck with Your work. My advice - don't climb on the MAXIS beaches by PEGASUS. These things are very ambiguous... Why are you doing this in the beginning... There are many other beaches ... Good Luck once more! We have thousands of files for SC4, but somehow always come back to Pegasus's Beach ...
I am really sorry for bothering you. I have read this thread but there's so much information in there, it's hard for me to sort for the relevant.
After I got totally confused I decided to remove the BDK plugin since I didn't use it at all and got it in the first place for the sake of completing my CDK3 collection.
A) I have checked my region with the savegame explorer. Some of my tiles have nonzero disabled props, some don't. - I guess that means some tile are affected and some don't? (all affected are big tiles intended to be suburban and have quite some 1x2 low dens residentials... any advice here?)
Quote from: mgb204 on February 13, 2017, 01:16:34 AM
If you do though, perhaps consider how far developed your cities are? If they are in their infancy, perhaps it's safer to start over now you've fixed the cause, rather than risk finding your cities are doomed later on?
B) When you say "start over" do you mean completely restart the region? Or is there a way to restart single city tiles without taking over the infection? I've read that you should not "obliterate" your city.
This topic has no end... :thumbsup:
Quote from: Seaman on February 28, 2017, 11:10:42 AM
B) When you say "start over" do you mean completely restart the region? Or is there a way to restart single city tiles without taking over the infection? I've read that you should not "obliterate" your city.
One solution would be to move the non affected tiles to a blank region. In essence what you need to do is ensure a new savefile for each city is generated, which using "obliterate" won't do. That process would work something like this:
Make a copy of your previous map/region, giving it a different name. Use the "Import City" feature to import all the unaffected city tiles from your old save file/region, in the correct locations of the new region. When that's done, you'll be left with blank cities with new savefiles in those locations that were affected by the problem. But they should conform to the topology of the map. You can then archive the old region or delete is as desired.
As always, make a backup of the entire region before you start, just in case something goes wrong. Import = Move, NOT copy BTW.
Also, an option to preserve the geography of a corrupted city tile (in case of any corruption, not only the pox) is to use some mapping program (sc4 mapper, sc4terraformer, etc) to create an empty region. Then you import the clean cities to your old region without having to manually terraform them back.
thx for the help!
Quote from: Silur on February 28, 2017, 11:57:08 AM
This topic has no end... :thumbsup:
I know, I wonder why!? I guess the type of SC4 player who cares about the pox puts a lot of effort into his/her region. It's like building your model railroad with a glue that is likely to fail after some years. You need a certain "c'est la vie"-type of character to enjoy building with that glue... ;)
one last question (hopefully) from my side:
SC4 savegame explorer found disabled props in some of my cities but says it's pox free (didn't see the green tag in the tool immediatly (https://en.wikipedia.org/wiki/Color_blindness#Red.E2.80.93green_color_blindness)). Am I correct in my assumption, that those cities are infected and will likely show symptoms after reaching the critical filesize, although they are currently without symptoms, hence pox free at the moment?
If I understand th phenomenon correctly, that's precisely the case. And indeed, it is fairly difficult to reach the critical file size on anything but a big city tile, so you would be relatively safe with pre-poxed medium and small cities. For that and other reasons it is recommendable to reserve big tiles for mostly untouched environments, with as few props as possible (but hey! MMPs aren't props!)
I have prop pox in a city... swaths of tiles lose their props at once, it gets worse every save. Yes, the city is a large tile full of 1x2 custom residentials and T21s.
Uncompressed size of type 0x2977AA47 file is 15411379 bytes.
A quick search of my plugins folder found no less than 7 files which contain props in group 0xC977C536. I need to now cross-check IDs to see which ones share ID with the Maxis exemplars.
Quote from: CT14 on May 06, 2017, 09:11:44 AM
I have prop pox in a city... swaths of tiles lose their props at once, it gets worse every save. Yes, the city is a large tile full of 1x2 custom residentials and T21s.
Uncompressed size of type 0x2977AA47 file is 15411379 bytes.
A quick search of my plugins folder found no less than 7 files which contain props in group 0xC977C536. I need to now cross-check IDs to see which ones share ID with the Maxis exemplars.
I'm so sorry, it's always a big downer to see so much work spoilt for a few props.
It would be very useful though that you make the list available, to check our own plugins and resolve the problem before it appears.
There were over 100 000 players in SC4 - and only units were the problem... They called this "Prop Pox" - this is very convenient. Check your files in the Plugin and read the "ReadMe" text. Who of us reading the "ReadMe" - zero. Some of us have heard about "Prop Pox" - and all their problems blamed on it. This is not a problem!!! There is no such problem - the problem in our facilities in our PLUGINS !!! ;D
If we have a legal option SC4 and barely know how to work with Ilive Reader - no problem. In 14 years of playing with SC4 (more than 10 years here and on Simtropolis) - I see that problem very often occur in people with illegal versions of SC4 or garbage in Plugins.
Play SC4 like about 2000 people in this world - and we are reminded of the "Prop Pox" $%Grinno$% $%Grinno$% $%Grinno$%
Thank you for your attention.
It's cool, I look at those cities (this is the second one now) as practice.
I got a bunch of good screens before it started and I'll post some in the Show Us... threads.
I will also post the list of files I modify, but not until after I've verified that it actually solved the problem.
Per the method near the beginning of the thread, building a city/growing the prop file size to the ~6MB point where pox would occur, if prop exemplars sharing Maxis group and instance ID values but differing in filesize were still present.
I'm not sure why there still seem to be unlocked pox sources downloadable, but then I have content from 6 or 7 different places.
I also haven't read all 37 pages here, just the first 10-12 and last few, so it's possible such a list of pox sources already got posted sometime in the last 8 years...
Currently scanning all TGIs in my plugins for conflicts, using SC4Reader: http://sc4devotion.com/forums/index.php?topic=16386.0
I've already confirmed a couple of cases that would cause pox, but I want to make sure I have them all...
Oh, man! It's a shame you're going through this with all the good work you're doing, CT14. Unfortunately, reading the part about the 1x2 residentials scares me since I tend to have a lot of them. If I ever do have this happen to a large tile (which I tend to build on a lot), the plan is to rebuild that area on medium tiles.
CT14 and all others:
Despite the efforts of mgb204 and other long-time players to dispel the myths surrounding "Prop Pox", these myths still continue.
To try to be clear once again (and this is all spelled out in the initial post on this topic):
1. Prop Pox occurs under very narrowly defined circumstances:
a) A prop of a certain type (in the only KNOWN cause of Prop Pox - an untimed Maxis prop) is modded to be a different type of prop (in the only KNOWN cause of Prop Pox - a timed prop), and keeps the same IID as the original prop.
b) The group ID has nothing to do with the problem. The relative sizes of the actual prop exemplar files is not the direct cause of the problem. The problem is when the savegame file is created, a certain amount of space is reserved for different types of exemplars. Because the Maxis exemplar is saved first, x amount of space is reserved. When the modded exemplar with the same IID, but with additional information is saved, the savegame file tries to overwrite the original information. The additional information causes corruption because of trying to write x + .5 amount of information in a space reserved for x amount of information.
c) This has been found to occur in only one specific file created by Pegasus, and in only a specific subset of the prop exemplars included in that file. No other Pegasus content has ever been proven to cause problems (and there has been a plethora of testing accomplished over the years). No other content by other authors has ever been proven to cause the Prop Pox. Note that the existence of the Prop Pox does predate the known problem Pegasus file. So there WERE other files that likely caused the Pox available at one time. But none of these potential trouble makers has ever been identified, and are not likely to be still available anywhere.
d) Even if you have never used any of the affected Pegasus props, if you have ever started a large city (I will not go into the esoterica of why only a large city - again, this is spelled out in the original post(s)) with a non-modified copy of the affected Pegasus file in your plugins folder (even if you later removed it), then that city is already essentially "infected", and its only a matter of time if you continue to develop that city.
e) Modifying a Maxis prop will not in and of itself cause Prop Pox. Even doing so and keeping the same IID will not in and of itself cause Prop Pox, even though this is a bad practice.
So, in summary:
1. There is no list of files known to cause Prop Pox because there is only the one known file spelled out in the original post.
2. There are no other files by Pegasus or any other author that are known to cause Prop Pox currently available.
3. The Prop Pox will not occur outside of a narrowly defined set of circumstances (spelled out in the original posts).
4. You will need to address why the only file known to cause Prop Pox has not been locked, with the Administrators at the only known location it can currently be downloaded (STEX).
5. This conversation could be ended if people would just go back and read the original posts, and base any questions off of those posts. None of the other 36-37 pages of posts that have occurred since then have brought to light any new information about any new PROVEN problem files.
So every city I've started since circa 2010 is corrupt from frame 0, for having a file I rarely use... In that case it genuinely surprises me that the file still hasn't been locked yet. I can't find it on the STEX at all, so something might've been done about it regardless.
Sidenote, I now have evidence that the game save props on an individual basis (http://imgur.com/a/QJhji); I was missing the prop file for that bridge, installed it, reloaded the city and replopped the top lot.
EDIT: This (http://community.simtropolis.com/files/file/19111-peg-oww2-bdk-beach-development-kit/) is the offending download, correct?
So every city that you've created since 2010 has the potential to develop the Prop Pox. It doesn't matter whether you have ever used anything from the problem file. If you have ever saved the game with the problem file in your Plugins folder, it overwrote the Maxis exemplar having the same IID in the savegame file, hence providing the "seed" for the Prop Pox. However, the fact that you have the potential to develop the Prop Pox, doesn't mean you will ever see it. A city still needs to meet a limited set of circumstances before Prop Pox is more or less guaranteed. For example, I don't recall anyone reporting a verified case of Prop Pox in a city that is not a large city square.
If you've got cities that you've been developing for 10 years and haven't yet experienced Prop Pox, that means they don't meet the limited set of circumstance for Prop Pox to actually occur. If you don't continue to develop them (assuming the large city square size factor), the Prop Pox is not likely to occur.
Please go back and read (or re-read) the first 3 posts where bap explains in detail what causes Prop Pox and what conditions must exist in a city before it will appear.
Check reply #36 to this topic. Ripplejet provides a quick tutorial on how to check if a particular city meets the circumstance necessary for Prop Pox to appear. Also read any replies in this topic that reference SC4Savegame Explorer (created by wouanagaine), which is a tool that will scan your savegame files and tell you whether the files have been corrupted by Prop Pox. Also check the topic for this tool under Third-Party Tool Discussion.
Sorry, the link in your edit didn't come through properly.
The problem file can be found in this download: http://community.simtropolis.com/files/file/19111-peg-oww2-bdk-beach-development-kit/
It's not as huge a deal as it is for most people, since I have a habit of just abandoning my regions and starting over every so often. I've been gone for a while, and a fresh start on regions after some practice might do it.
I've removed the exemplars in question, but I could potentially still get it through missing props, like the Venetian canals, at least in theory, if the way props are saved and my screenshot of the two bridges may suggest.
Is it odd that the modified file is 399kb on my internal hard drive but 400kb on my external one?
Quote from: twalsh102 on May 06, 2017, 10:35:43 PM
e) Modifying a Maxis prop will not in and of itself cause Prop Pox. Even doing so and keeping the same IID will not in and of itself cause Prop Pox, even though this is a bad practice.
For the most part you have summed up the problem very nicely. Although I must disagree that overriding Maxis props or other items with the same Id is bad practice. It's the exact opposite, a very useful and frequently used modding technique. As you point out, it's only a problem when you use an override and change the properties to a different RTK type. Although the latest information points to the problem being a result of the night-time state change property.
If prop pox concerns you - DON'T install the Beach Development Kit (BDK) by Pegasus. Or, fix the files as outlined in the first page of this thread.
If you don't have the BDK file in your plugins folder and never did have it at any time during the creation of your region, you should not fall victim to this issue. There is a caveat though, people seem to be having the problem anyway. My conclusion is there is more to the problem than explained in this thread. I think many people incorrectly identify Prop Pox as the source of their problems. But it also seems probable that either some other files exist that cause it, or that such file corruption is possible through other means we don't yet have proof of.
Yes the original files (BDK) are still on the STEX. They can not be patched without the explicit consent of Pegasus (I tried), so that's pretty much not going to happen IMO. At the same time, would we prefer these wonderful items were simply locked and never made available ever again? I know that's not what I'd want to see either. So I'm glad they are available on the STEX. The frank reality is that even with these files, most users are unlikely to ever see problems. But it depends upon how you build your cities as much as having the file installed.
@twalsh102 Indeed I do have the dependencies for that beach lot installed, so there's probably nothing more to it as the city seems to meet all conditions for the classic pox case. I'll check with the Savegame Explorer.
I appreciate your summary of the pages I didn't read.
Edit: here's the Savegame Explorer view... I will remove the beach lot's dependencies, and do some "split testing" to make sure the next city with a prop file size past the threshold does not trigger pox.
(https://i.imgur.com/AuOxWFq.png)
Edit 2: Unfortunately, in those first few posts, bap was not precise about which files he removed to cure his pox. He says it was the BDK resource file and "associated lots", so presumably means the other BDK file "PEG-OWW2_BDK_Beaches_110.dat".
Here's the thing - I don't have the BDK installed and never have on this city...but I do have its listed dependencies installed. If bap actually removed those files too to cure his pox, things would make more sense. I do see that he's referring to specific exemplars in the BDK resource file.
I finished the SC4Reader run, checking Plugins TGIs against SimCity_1.dat's group ID c977c536 exemplars, and it found a number of shared TGIs, but of course they will need to be examined closely for the types of changes in properties that might cause the buffer overflow problem. And I also need to check against *all* group IDs... From the sound of it and all the testing that has been done in the past, most will be false positives. I also need to re run it with a few DAT packs unpacked, to narrow down some hits.
Edit 3: temporarily installing the beach mod, then running the SC4Reader scanner for the exemplar mentioned by OP shows just these four overlapping instance IDs in the beach resource file, which is less than expected: 29b20000, 290d0000, 29000000, 29110000. There are others in related files, so I suppose split testing should start with remaining TGI overlaps from the same source.
And: side by side examination of the properties differing from Maxis in the confirmed pox source (for example Beach Umbrella prop 29000000), with the properties differing in other exemplars from that group (for example Effect Small Fountain 2a7ccda1 from the Seaport Village Resources dat), shows the exact same characteristics which are said to lead to the buffer overflow: a change from Nighttime State Change property to Prop Time of Day property, and corresponding property type change from Uint8 to Float32.
Now that I've done that sanity check, I'll split test and narrow the source down.
I got one tile that has prop pox - the content in it is in every other tile in the region at the moment. The tiles that SC4save can open have 0 disabled props, however there are a couple where it runs out of memory (and the files themself are around 55mb in size). The tile in question is 63.9mb at the moment., and was doing fine until I built a road connection. Is it possible for file size itself to cause the issue?
A few questions might help:
Can we get a few screenshots of the tile?
Can we also get the size of your plugins folder?
Is this (https://community.simtropolis.com/files/file/31956-llama-reserve-nature-park/) lot in that particular tile?
Does starting new cities pox them too?
From what I've heard, if a plugin causes the pox it will cause it by simply being installed, so if only the one city is affected, then yes, there is a size limit.
Quote from: CT14 on May 07, 2017, 10:01:57 AM
Edit: here's the Savegame Explorer view... I will remove the beach lot's dependencies, and do some "split testing" to make sure the next city with a prop file size past the threshold does not trigger pox.
You misunderstand how this works. If you have ever had the file (and
ONLY this file), PEG-OWW2_BDK_RESOURCE.dat installed, then your save files are already affected.
- Even if you do not see any symptoms, once a city has been saved with this file in your plugins, it is sufficient to trigger a series of events which CAN lead to Prop Pox.
- Prop Pox will only ever occur IF the network subfile is converted, as it reaches the limits outlined in this thread.
In short, so long as those other cities do not have the Network Subfile convert to the second format, you should not see Prop Pox in them. But, the underlying trigger will exist in the save files and any older backups of them, once there, it's always there.
QuoteEdit 2: Unfortunately, in those first few posts, bap was not precise about which files he removed to cure his pox. He says it was the BDK resource file and "associated lots", so presumably means the other BDK file "PEG-OWW2_BDK_Beaches_110.dat".
No. ONLY the main resource file (RED) listed can cause problems. The other related items simply use these props on the included lots, which is very different. In the event the BDK Resource file isn't there, they will use the Maxis default versions of these props. However, if the BDK resource was removed entirely, then you'd probably see brown boxes and missing items on these lots too. So in reality, why keep the beaches if you are deleting the dependency for them? Or put another way, if you do decide to delete the BDK resource, you should also delete/remove any content that lists that file as a dependency for it.
QuoteHere's the thing - I don't have the BDK installed and never have on this city...but I do have its listed dependencies installed.
Either you have the BDK resource file or you don't, that's the only question here? Sorry but this statement seems to contradict itself. Do you mean you never used the content, but the files were in your plugins folder?
QuoteAnd: side by side examination of the properties differing from Maxis in the confirmed pox source (for example Beach Umbrella prop 29000000), with the properties differing in other exemplars from that group (for example Effect Small Fountain 2a7ccda1 from the Seaport Village Resources dat), shows the exact same characteristics which are said to lead to the buffer overflow: a change from Nighttime State Change property to Prop Time of Day property, and corresponding property type change from Uint8 to Float32.
Not really, there has never been anything more than the suggestion that changing the Nighttime State Change property might be the real cause. Not to mention, that was by one user only and never really got verified. The problem being that all these years on, everyone just accepts the answer outlined in the first post of this thread as gospel, when the evidence points to a wider problem. However, since no definitive data exists to give us a clearer understanding of the problem, it's very hard to protect yourself against this issue. Given the community activity levels and general lack of assistance/user participation for testing anything, the odds of progressing on this are very low indeed.
The elephant in the room is, we don't really know much about the problem.
As mentioned previously to others, unless you are an expert with a completely thorough understanding of the ins and outs of SC4/modding, realistically these are your options:
- Remove the file PEG-OWW2_BDK_RESOURCE.dat and never use it again.
- Remove or Fix the props as mentioned in this post (http://sc4devotion.com/forums/index.php?topic=7066.msg224892#msg224892), from the file PEG-OWW2_BDK_RESOURCE.dat.
If you don't understand the instructions in point 2, you are wasting your time going any further with this. You might as well remove the file (step 1) and be done with it. If you can't properly interpret the data you see, how can you reasonably expect to find something no one else has in the last 10+ years? Of course if you want to spend your time checking into it, knock yourself out, I won't stop you. Just trying to inject a dose of reality into the picture. Which is that the odds of you finding something others haven't is very small, rather than worrying about it, accept the worst has happened, protect yourself as best you can and move on with a new region. That's my (albeit typically dislikeable) advice.
Quote from: Kitsune on December 14, 2017, 06:21:20 PM
I got one tile that has prop pox - the content in it is in every other tile in the region at the moment. The tiles that SC4save can open have 0 disabled props, however there are a couple where it runs out of memory (and the files themself are around 55mb in size). The tile in question is 63.9mb at the moment., and was doing fine until I built a road connection. Is it possible for file size itself to cause the issue?
Quote from: Wiimeiser on December 15, 2017, 03:13:08 AM
From what I've heard, if a plugin causes the pox it will cause it by simply being installed, so if only the one city is affected, then yes, there is a size limit.
That's hardly proof now is it?
We know that save files can get quite large, in fact that's exactly why the Network Subfile needs to be converted to a different format when a city gets beyond a certain size. So it can continue to save the data. So is there a size limit?, yes absolutely, it's only logical that a given data format will have an absolute limit. However, it's also logical that it would be pretty much impossible to ever hit that limit.
So what is most likely going on here? The application SC4 Save is simply unable to read the file, possibly a RAM issue, or an impatience one. You'd be surprised how often Windows will tell you an application has crashed when it's just busy in the background. Either way, if SC4 itself can load the file, you've not reached a limit the game or file system can't handle. Never in the history of this thread has any link been made between a large city/save file and problems of this nature. Bereft of some actual evidence to the contrary, I'm not convinced this is a sound or rational theory.
Thats the thing: those props are no where in my folder. The only peg lots I have are a couple seaport stuff and the avenue median. Interestingly, I found another tile that is not poxed but has disabled props - and I found ground zero for it as the lot was missing its props: something from another creater that I simply shrunk the lot in lot editor and deleted everything except the prop and then added a couple more. The new lot itself was prolly destroyed and replopped a couple times to properly place the props. The lot does contain an animated prop that I moved ever so carefully. At somepoint it got flagged and disabled, and the nature does suggest some modern digging may lead to a DLL that can change the parameter of whatever check its causing it to be disabled. Also - part of rl job is to triage programs that have issues that I may not have ever heard of (hey the joy of ITIL). Sometimes you go up the wrong tree, sometimes you notice things that have gone unnoticed in the past and sometimes you hit the golden nugget.
I did a ton of reading of the subject this week - is it correct that Large tiles with a network file that exceeds a unknown size gets poxed? And that smaller tiles (and possibly Large tiles with a large water content) are immune as the network file never exceeds that unknown size?
Also - here is a file with prop pox...
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fglidingeagle.com%2Fimages%2Fsc4%2Fpp1.jpg&hash=cf63add90810dea513885c867aa5f9eb98926ee1)
A file with disabled props that is slowly climbing and while not flag as poxed - it is in proto-pox and a ticking time bomb:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fglidingeagle.com%2Fimages%2Fsc4%2Fpp2.jpg&hash=52a19c0ac29dd944dfce9582ec49da6d4b476a34)
And a free of everything city:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fglidingeagle.com%2Fimages%2Fsc4%2Fnpp.jpg&hash=7d21834b989395031aa4630e0ecba8c581204343)
We can see when something gets poxed - they do not only get disabled but the entire line is corrupted. Cause is unknown on this one.
On the tile that has disabled props - we can already see the beginning of Pox. Although not flagged as poxed, you can see multiple line (and I can confirm thousands) have lost there TID, GID, IID and its only a matter of time before corruption occurs somewhere. I will note these props are still visible at this point as confirmed by sc4save and the game itself. For the disabled 7 props - I do wonder what would happen if we reflagged them to visible. While sc4save does not have modify capability on .sc4 city file due to a checksum issue according to that apps development thread.... I tested and confirmed iLives reader can modify the .sc4 city file. So it does seem if somebody took some coding from ilives reader we could get an app to reset the flag to try and stave off full blown pox. The cause in this case is the usage of two different plugin folders and merging the two together.
I included the last tile as an example of a normal happy tile with multiple visibility types.
Quote from: Kitsune on December 20, 2017, 10:35:19 AM
is it correct that Large tiles with a network file that exceeds a unknown size gets poxed? And that smaller tiles (and possibly Large tiles with a large water content) are immune as the network file never exceeds that unknown size?
The theory outlined here is based on the use of predefined data blocks as part of the save file. Think of this a bit like a card file system, one card or unit of data, can only contain a specific number of characters. The limitation in such a scenario is not actually based on the file size, technically it's based on the array size, data types and input length combined. When all the data blocks are full though, it's very likely that any given set of data at this point would be roughly the same size. Which is where we get the 6MB size before the Network Subfile needs to be converted, in order to store more data in an altered state.
Theoretically, assuming you could fit enough props into a small or medium tile to hit the same ceiling, the problem could exist for them too. In reality though, it does seem pretty unlikely when you consider that you have 4 times the space in a large city over a medium one. It's the same with a medium over a small tile, so for small tiles the odds are very low. Given this, unless your goal was to fill a tile with props, it's simply not very likely under normal use for this to occur.
QuoteI do wonder what would happen if we reflagged them to visible. While sc4save does not have modify capability on .sc4 city file due to a checksum issue according to that apps development thread.... I tested and confirmed iLives reader can modify the .sc4 city file. So it does seem if somebody took some coding from ilives reader we could get an app to reset the flag to try and stave off full blown pox.
When you loaded the game, it would probably delete your save file. Because that's what the Checksum is there to do, prevent the save files from being modified in any way. That's why SC4Save doesn't have the facility to edit the files, because whilst it could save the data, just like iLives reader can, it can't set a valid Checksum as part of the process.
QuoteA file with disabled props that is slowly climbing and while not flag as poxed - it is in proto-pox and a ticking time bomb:
You may be confusing cause with effect here. Prop Pox disables props in your save file, but having disabled props is not the cause of prop pox. There are other reasons why these may be disabled, although there isn't a whole load of solid facts surrounding such things. Ultimately, this doesn't tell us anything about what is happening.
But the real question here, how are you getting Prop Pox in these city tiles? That is the area you would benefit most from looking into. Because if Prop Pox is as simple as overriding RKT1 props with RKT4 props, (or similar where the data is larger), then something amongst your files must be the culprit, in the form of an override. If you don't have the Pegasus BDK file, then it's probably going to take some serious looking to find the potential problem file/exemplar. Datanode will help you to find all overrides, then it's just a case of trawling through it's output, to see if there is either an RTK or NitetimeState change amongst the results. But, assuming no such modifications are to be found, that rather supports my theory that there is more to this than initially thought.
The problem is, as of now, no one has ever taken the time to do such a thorough check. Given that all that time staring at exemplars won't bring your cities back, at best it may prevent problems in future. Add to that the general lack of technical ability of most players to interpret the data, it's really not so surprising this was never done. In short, we simply have no hard facts/data to go on. Frankly, the prospect of rummaging through a hideous list of data like that, doesn't exactly motivate me to the task. But in the first instance, if you saved the Override data from your entire plugins folder, maybe it's worth attaching here in case anyone else fancies a peek. That is assuming you aren't motivated to do this your own self?
But lets say someone did trawl through it all, what then? What if there were no instances that connected the dots based on our current understanding? Could we be 100% certain that your plugins folder now, has everything in it, that you ever had installed, since the inception of your affected region? Because if not, right away that data set is simply invalid, because the data is unreliable. The point being, without some sort of absolute reference data, there are simply too many if's, coupled with too little benefits to be had, to justify the amount of work involved. Being me, the only data-set I could trust was one I personally knew the history of. Ironically perhaps, if I found myself in this scenario, I couldn't trust my own set of plugins either, I simply change things too often to keep track of it all. Most of the really knowledgable players probably have the same problem, because learning the ins and outs is intrinsically linked to the sort of player that's modding things a lot.
Perhaps then a better solution is to look at the very first posts from Bap in this thread. Look at how he did his testing to locate the problem file. Replicate those tests and theoretically you should find the file causing your problems. Once we've a valid suspect file to look at, that may provide some meaningful data that moves our understanding forward. But bear in mind again, that any changes, especially removed files from your plugins folder, could prevent you from reaping any results here too.
Large datasets dont scare me so long as there is a CSV output or something I can have excel translate so I can have excel deal with it. However it does seem while Datanode outputs a csv file - it doesnt state the RTK or nightstatevalue. I will give the programs it due - it did handle my 6gb plugin folder like a champ. Also, the only thing that has been removed from my plugins folder are lots, not props. Infact its partial flaw I consider with the way I handle my plugin folder.
For those who haven't heard yet, simmaster07 of SC4Fix.dll fame cured the Prop Pox yesterday (https://community.simtropolis.com/forums/topic/74667-revisiting-prop-pox-and-prop-theory/). All the details (including where to download the fix) are in the link.
I don't think it's possible to thank him enough for solving not just one but two seemingly unsolvable showstoppers with the game--and 15 years after the game's release, no less.
Edit: Here (https://community.simtropolis.com/files/file/30883-sc4fix-third-party-patches-for-sc4/?tab=comments) is the link to the official release of the new, Prop Pox-curing version of SC4Fix.
-Alex
Wow, this is just amazing! Fortunately, I never suffered from the prop pox myself, but it has been one of the biggest obstacles in the history of SC4 alright. Surely one of the best birthday presents ever! :thumbsup: &apls
Wow! New version of SC4Fix!!! :thumbsup: &apls :bnn:
Wow wow wow indeed! Almost nine year since the start of this thread, and after 38 pages of explanation & confusion (in equals amounts :D) it seems we can finally close the prop pox chapter once and for all. What a momentous day! &apls &apls
Many years I've been playing always in mind it's possible to loose all your work and having to build everything again. Funny thing - I have to learn, these now are silly fears. The fear is still there like a bad habbit (saving every five minutes, making security copies all the time) but the reason has gone.
Quote from: vortext on January 21, 2018, 04:58:26 AM
Wow wow wow indeed! Almost nine year since the start of this thread, and after 38 pages of explanation & confusion (in equals amounts :D) it seems we can finally close the prop pox chapter once and for all. What a momentous day! &apls &apls
I have good news to add.
The current STEX Admins have taken the bold steps to update the 3 PEG files proven within this thread to be the only known causes of Prop Pox. New players just coming into the world of custom content will never have to worry about seeing the props in their cities totally decimated.
If you have already installed PEG's original files, whether you update them or not is up to you. But either way, I would still strongly suggest continuing to use SC4Fix.
Might I ask what three so I know what to update?
The files are:
https://community.simtropolis.com/files/file/19111-peg-oww2-bdk-beach-development-kit/
https://community.simtropolis.com/files/file/19145-peg-oww2-bdk-beach-restrooms/
https://community.simtropolis.com/files/file/19363-peg-oww2-rebalynns-beach-hut/
Again, if you are already using any of these files, it is important to continue using SC4Fix in order to prevent Prop Pox.
Quote from: xxdita on May 02, 2020, 01:23:36 PM
Quote from: vortext on January 21, 2018, 04:58:26 AM
Wow wow wow indeed! Almost nine year since the start of this thread, and after 38 pages of explanation & confusion (in equals amounts :D) it seems we can finally close the prop pox chapter once and for all. What a momentous day! &apls &apls
I have good news to add.
The current STEX Admins have taken the bold steps to update the 3 PEG files proven within this thread to be the only known causes of Prop Pox. New players just coming into the world of custom content will never have to worry about seeing the props in their cities totally decimated.
If you have already installed PEG's original files, whether you update them or not is up to you. But either way, I would still strongly suggest continuing to use SC4Fix.
It was before the time I joined community but I heared there was much quarrel and anger about this files and so propox even disunited the community and caused harm not only to the game but also to the players that turned away in bitterness.
So - imho - maybe this means something more than just a fix. Maybe it is also a chance for some old pals to make peace on those other things that happened by this time?
Quote from: fantozzi on May 03, 2020, 12:42:42 AM
It was before the time I joined community but I heared there was much quarrel and anger about this files and so propox even disunited the community and caused harm not only to the game but also to the players that turned away in bitterness.
So - imho - maybe this means something more than just a fix. Maybe it is also a chance for some old pals to make peace on those other things that happened by this time?
I think any chance of that has slipped away. The people that were directly involved on both sides are mostly no longer active, or have passed away. So any feud has been silent for some time now. Anyone coming in after and taking a side on the matter for personal reasons is just trying to stir a pot that has been empty for years, when they don't have all the information, nor do they care to do any research on the matter.
Whether it's Prop Pox, Seaports, whatever, some people are always going to have an opinion. I prefer dealing with facts whenever possible. But even on important real world issues, there are those that refuse to believe valid science.
Quote from: xxdita on May 02, 2020, 01:23:36 PM
The current STEX Admins have taken the bold steps to update the 3 PEG files proven within this thread to be the only known causes of Prop Pox.
Actually, it's only one file that has ever been said to have the problem, PEG-OWW2_BDK_RESOURCE.dat. Any other updates are simply because the lots using Props from that package needed updating to reflect their new IDs.
Quote from: mgb204 on May 03, 2020, 04:00:55 PM
Quote from: xxdita on May 02, 2020, 01:23:36 PM
The current STEX Admins have taken the bold steps to update the 3 PEG files proven within this thread to be the only known causes of Prop Pox.
Actually, it's only one file that has ever been said to have the problem, PEG-OWW2_BDK_RESOURCE.dat. Any other updates are simply because the lots using Props from that package needed updating to reflect their new IDs.
Good to know. That information didn't come out over the course of the ST thread.
I won't be testing any of these fixes further, as my involvement on matters concerning PEG seems to get people riled up. I also do not use PEG's files in my own gameplay.
But is it necessary for people to demolish existing instances of the altered lots for these lotting changes to take effect? That's pretty standard, right?