What causes Prop Pox (and how to avoid it)

[RippleJet]

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:



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.

[wouanagaine]

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

[Lord_Morpheus]

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 
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!

[RippleJet]

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...

[BarbyW]

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.

[wouanagaine]

BarbyW, does the prop you modded already exists in that city in its original form ?

[BarbyW]

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.

[RippleJet]

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.

[RippleJet]

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.

[Diggis]

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:

[RippleJet]

Diggis, you're clearly poxed.
I can see at least 10 missing props, the first one at offset 0x14.

[Ennedi]

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? 
There are several very important props in the human body 

[Diggis]

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.

[wouanagaine]

Well that is only because you're timed. If you were like me and not timed, you can save yourself anytime anywhere :p

[JBSimio]

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.  

[metarvo]

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.    I can confidently say that you're in the best of hands right here, though.  Nice work, everyone. 

[bap]

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. 

[sithlrd98]

Lmao

Jayson

[XiahouDun]

Sadly some of me is poxed as well. I seem to be losing props on the top of my head slowly.

[Diggis]

Don't worry: some of your props will be missing, but your lot will still be functional.