-
Announcement
-
Simtropolis Returns! 05/26/2026
See here for details about our site recovery efforts.
-
Search the Community
Showing results for tags 'prop pox'.
Found 11 results
-
[Solved] Disappearing Props/Features from City
The Mayor of Hiversbridge posted a topic in SC4 Bugs & Technical Issues
I've been working on this city for most of the day. I decided to install the new version of NAM as I'd been holding out for awhile and when I went into the city all the props had disappeared. I kept a backup of the old NAM installation I had but this didn't seem to fix the issue. This is the only city that seems to be affected in the region too. It could be prop pox but I've got the SC4fix installed which is meant to prevent this. I'm totally stumped and this took hours of work to make to so it's a little deflating if this can't be fixed. Any clues? -
So that theory that we knew what causes Prop Pox...
rsc204 posted a topic in SC4 Modding - Open Discussion
Look at what I just got: Yes our old friend Prop Pox has come to visit the creatively named A1 city of my current test region. So I should clarify that whilst I am using SC4Fix, I have deliberately stuck with the R3 version, which does NOT have the Prop Pox fix included. The reason being, I wanted this to happen, for many years I've wondered if without forcing things, I could 'catch' the Pox and this evening I got it... or did I? There is a problem and a big one, my last backup was made on the 13th Feb and I had not actually saved this city since April last year either. However by looking at my previous save file, you can clearly see the Prop Subfile had already been compressed: Why is this important?, well we were told the cause of Prop Pox was data written to the save file in an improper format. This data doesn't cause a problem until this particular subfile is compressed, at which point any data that was written in places it shouldn't be, gets reordered such that the data becomes corrupted. Well that didn't happen here, 100% for certain, because if the Prop file was compressed, somehow the 'error' has uncompressed the previously compressed prop subfile? That to my knowledge, isn't supposed to be possible? Anything from here out is conjecture until such times as I can really dig into the problem, but let's start with what I do know: There is no way any props (or flora) have been altered between RKT1 and RKT4 (or other RKT) states. Everything I'm doing involves new, unique, ID systems, there are literally no changes I made in Plugins that fall under the previous explanation of the problem. Every other developed city in the region has a compressed Prop Subfile (5 pretty heavily developed large tiles), none of them show Prop Pox. This includes the one I used to test everything in the PEG CDK3 collection last year, which includes a fixed version of the Beach Development Kit, the file originally fingered as the cause. The only changes I've made to the Plugins is to add a bunch of T21s as per recent postings (OK, a lot of them - up from 13k to 122k). The only changes to my Plugins folder were adding the Flora, Flora Families and T21s, most of which is tried and tested stuff. Maxis used Flora Families and they used them on T21s too, so I'm pretty sure what I've done isn't unintended stuff. Although it's possible using RKT4 flora with many more Reps is itself a part of the problem. But honestly, I suspect there may be some upper limit on the number of objects, in a very quick time the number of Props has grown dramatically and that's when the problems started. I was noticing some terrible performance issues, especially in Zooms 1-3 earlier, I figured that was the T21 mod. So I went and added the ApperanceZoomFlag property to Girafe's signs so they only appear in zoom 4 and 5. I then added this property to all the trees for the mod, so they only appear in zooms 3-5. This should have removed any additional overhead in zoom 1 & 2 completely, but it didn't seem to stem the performance problem. I then realised the issues were focused on a certain part of my city, the low density residential area to the North, when I was elsewhere on the map, things quickly returned to normal for what is a sparsely modded region. The city in question is just shy of 200k residents and maybe 150k jobs, but one of the smaller ones, it was the founding city in the region. Now of course, the addition of a previously unused ApperanceZoomFlag property with existing objects can not be ignored as a potential cause. However, since the difference between my backup and the broken save, is simply that I had yet to add any of these T21s, means I'll be easily able to repeat the process with a save file where that flag has never not been present. If this backup corrupts as well, we could pretty much rule that out, I'll update on that one. But the one salient fact that is clear, it seems 'Prop Pox' is just another name for file corruption, SC4 can be quite finicky in this regard. As I have always believed, the problem is much less simple that one type of edit, not to mention that the way SC4 'dumps from RAM data into a file', just isn't ideal. We know of many different things that when changed, don't dynamically refresh, which can lead to a multitude of problems. The way I see it, it's quite easy under various scenarios for this data to go wrong and when it does corrupt, the way data is handled can lead to a runaway problem where things get worse. Speaking of which, I'm sure I noticed this pretty early on, but it wasn't long before being in the 'bad' area of my city, started causing instability in addition to the slow down. It was after a few CTDs that I then checked the save file using the recommended tool. Personally I have the feeling some of this stems from pushing the game to it's limits with the number of props. Whilst I am totally happy to release the files for this region, I seriously doubt anyone could use them due to the heavily customised setups I'm using. The city in question has the census repository, CAL's canal system and some other mods, but cosmetic stuff aside it's mostly vanilla. I'll run some checks on what happens without my Plugins suite present and see what the best way forward is there. But the main point is that for certain there is more to this bug than has been documented.- 15 Replies
-
- 12
-
-
-
Is it prop pox already? How to tell?
TheMurderousCricket posted a topic in SC4 Bugs & Technical Issues
Morning Everyone. So I've got this mid-density manufacturing industrial district. It's been recently lined with seven to eight "Mixing tanks" and my first thought is the dreaded "prop pox". How to tell it? Is this indeed the problem or is this a normal behavior to a certain extent? Thanks. -
Clevedon Valley - Revisited
Craig-Abcvs posted a City Journal entry in Auckland & Greater Region - II
Clevedon Valley - Revisited I'm back! Hey it's only been 4 years, and here is my old CJ, still here and ready for me to carry on where I left off! Clevedon Valley was one of my more important tiles, one like many of us, that I had put hours of work into, built a replica of the Raurimu Rail Spiral, and yeah - put - hours - and hours - of work into. To cut a long story short, a few years ago it got prop pox. At the time I quietly deleted the tile, and re-imported a non poxed tile from a back up. However I was then very cautious about developing it further, especially with any prop heavy lots like SPAM - those seasonal crops use a lot of props. Eventually I stopped developing it further as I did not want to risk going over the 6 mb limit on the save file. Time passed, and I stopped playing SC4 for a few years, but as you can see the last few weeks I have started playing again, (digital download version of SC4), reloaded by plugins and regions from a external hard drive back up, and wandered back here to ST. Then I found out that prop pox had been cured. Wow. With the fix installed I now feel confident to revisit some of my favourite tiles, and continue developing them without the worry that they will tip over the edge and get the pox. First things first though you need to open the tile and... Yeah get over it Fairbanks... I play rural. Spread out. Low density. You can take your medium and high density and... [insert PG13 appropriate burn]. Anyhoo.. yup, large tile, lots of SPAM farms, with their prop heavy crops. Note the large areas of pines, yes I like my pines, but they are flora, and apparently the game engine treats flora differently in the prop count thingy whatever - yeah I don't really understand it, but I'm just trying to sound intelligent. (Rail spiral top right corner, see here or more on that). Anyway, fast forward a RL few years, a couple of computer deaths, but an external hard drive back up later... (don't worry I fixed the power problem over on the left) Yup, I still have a rather nice space left in this tile to develop further.- 23 Comments
-
- 11
-
-
- clevedon valley
- prop pox
- (and 3 more)
-
My apologies if this has been covered - I've searched extensively and can't find the answer and would like some help, please. All of the trees and MMPs have disappeared from my latest city. I gather this is a result of "prop pox." So I read each of the following carefully: https://community.simtropolis.com/forums/topic/74667-revisiting-prop-pox-and-prop-theory/ https://community.simtropolis.com/files/file/32047-sc4macinjector-a-dynamic-code-plugin-loader-for-mac/ https://community.simtropolis.com/files/file/30883-sc4fix-third-party-patches-for-sc4/ https://community.simtropolis.com/forums/topic/70495-game-framework-compatible-dll-loading-and-other-modding-discoveries/ I downloaded the sc4macinjector and ran it. All seems unchanged - no harm done. (I backed up plugins and regions just in case.) I downloaded sc4fix - which seems to be doing wonders for our Windows friends - YAY!!! It is a .dll file. I have no clue what to do with it. My VERY basic computer knowledge is that .dll files can't run on Mac. Regarding the sc4macinjector it says the following on its page: "What does this do SC4MacInjector allows the Mac equivalent of .dll mods to be loaded on Aspyr's port of SimCity 4 for Intel Macs. Note: you will not be able to use Windows .dll mods directly. They need to be targeted specifically for Macs as .so files." OK. I comprehend those words, but haven't a clue as to what that means in action - or if there is something I can do to target a .dll file as an .so file. <insert very confused llama, perhaps > 1. Do I actually have prop pox? Have I made the correct assumption that the pox caused my MMPs and props on small residentials to disappear? 2. Can someone guide on what, if anything, there is to be done about it? I feel clueless and in way over my head from a technological standpoint. Like... I understand technology better than your 90 year old grandma who just made you those amazing cookies*, but ... sometimes... not much. *A hypothetical grandma. Now I want cookies.
-
Update 2018/01/21 SC4Fix has been updated with a stable build that fixes prop pox. Download on the STEX: --- I like a good challenge, so I decided to take this one up. Context Prop pox is a bug that causes decorative props in some cities to begin disappearing. The problem is exacerbated if the city continues to be played and saved, and persists even after adjusting graphics settings for prop detail or restarting the game. The prevailing hypothesis is bap's prop theory, which makes these main claims: In a normal game installation with absolutely no plugins, prop pox will never occur, even after updating. Prop pox is actually caused by plugins that redefine Maxis prop exemplars that add properties that were not originally in the exemplars. Prop pox will only manifest itself if one of these plugins is installed and the city's prop subfile* is sufficiently large. * bap refers to the prop subfile as the network subfile in his post, which seems to be a mistake. Testing this is pretty straightforward as all we need to do is clear our plugins, develop a city until the prop subfile is large enough (around 6MB, according to bap) and then use a plugin that causes pox by improperly redefining exemplars. For this I made a mostly flat large tile city with sprawling low-density developments to add as many props as possible in a short timeframe. When the prop subfile for the city was just under 6MB I made a copy of it and then allowed it to develop further until it crossed that limit. Why is this 6MB limit significant? The game determines whether a subfile should be compressed mainly by its filesize (along with a few other properties); subfiles smaller than 6MB can be compressed, but anything larger than that is saved decompressed in order to save time and computational resources when saving very large subfiles. Prop pox apparently begins most commonly when crossing this compression limit. With no plugins installed, the city was able to develop past the 6MB prop subfile limit without any pox or save corruption occurring, no matter how many times I saved or how long the simulation ran for, which I tested using wouanagaine's SC4 Savegame Explorer. If prop theory is correct, then pox should occur if we install a bad plugin and try to develop the city past that limit again. For this, bap used SimPEG's Beach Development Kit 1: In particular, you only need to extract PEG-OWW2_BDK_RESOURCE.dat as this contains the exemplar redefinitions. After installing this plugin, I loaded the test city, added some new zones to force new props to develop, ran the simulation for a bit and saved the city a couple of times. This immediately resulted in the city developing prop pox according to the savegame explorer. For your convenience for reproducing this, here are the savegame files I used: Test City, prop subfile under 6MB, no plugins and no pox Test City, prop subfile over 6MB, no plugins and no pox Test City, prop subfile under 6MB, BDK_RESOURCE installed and pox present Explaining the buffer corruption Since the savegame explorer reports buffer corruption at a particular location in the savegame, we should probably check out what's happening there to see if this improves our understanding of what causes prop pox. First we need to extract the prop subfile from the savegame using iLive's Reader: The pox-infected .sc4 save can be opened in the Reader. From there we need to extract the entry with type ID 0x2977aa47 (which is marked as Unknown, and that's fine). We also want to make sure we have the decompressed version of the subfile, so we'll save the decoded file and open it in an external hex editor since the one built into the Reader isn't great. I prefer using HxD. If we jump to the reported offset of corruption in the hex editor, we can read the bytes of the prop subfile as base-16 hex values, and the structure of the prop subfile is given in the SC4D wiki. (Note that DWORDs are four bytes large, WORDs are two bytes, and BYTEs are one.) Here's what the corrupted prop entry looks like in the hex editor: And here's what this looks like when filling it into the prop structure given on the SC4D wiki: DWORD Size: 0x00000058 DWORD CRC: 0x006C2462 DWORD Memory: 0x4CE00000 ??? : 0x59E6 ??? : 0xA084 ??? : 0x0F06 WORD Major: 0x0006 WORD Minor: 0x0004 WORD Zot: 0x0000 BYTE Unknown: 0x00 BYTE Appearance: 0x04 DWORD : 0xA823821E BYTE Min Tract X : 0x42 BYTE Min Tract Z : 0x6E BYTE Max Tract X: 0x42 BYTE Max Tract Z: 0x6E WORD X Tract Size: 0x0002 WORD Z Tract Size: 0x0002 DWORD Property Ct.: 0x00000001 SGPROP #1 DWORD Property Name: 0x89A1C16C DWORD Property Name: 0x89A1C16C DWORD : 0x00000000 BYTE Data Type: 0x03 BYTE Key Type: 0x00 WORD: 0x0000 DWORD Rep Count: 0x00000000 DWORD GID: 0xC977C536 DWORD TID: 0x6534284A DWORD IID Exemplar: 0x29000000 DWORD IID Given: 0x29000000 FLOAT32 Min X: 0x4308558C FLOAT32 Min Y: 0x43870000 FLOAT32 Min Z: 0x45386FA3 FLOAT32 Max X: 0x430A558C FLOAT32 Max Y: 0x43880000 FLOAT32 Max Z: 0x45389FA3 BYTE Orientation: 0x03 BYTE State: 0x00 BYTE Start Time: 0x00 BYTE Stop Time: 0x00 BYTE Count: 0x00 BYTE Rand. Chance: 0x64 BYTE Lot Type: 0x02 DWORD Object ID: 0x2A46EEFF BYTE Conditional: 0x00 Immediately something is wrong: there are six extra bytes after the first three pieces of data that don't correspond to anything in the prop file structure. Moreover, this entry gives its size as 0x58 (88) bytes but the hex editor says this is 0x72 (114) bytes in it. Where are the extra 26 bytes coming from? Well, first we can discount the seemingly random six bytes that appeared at the top. Next we can scrutinize the SGPROP since that's only an optional part of the prop subfile, and sure enough four DWORDs (16 bytes), a WORD (2 bytes) and two bytes add up to 20. And just out of curiosity, let's see what exemplar IID 0x29000000 maps to: Sure enough, it's a redefined residential beach umbrella exemplar from SimPEG's BDK resources. The main change in PEG's exemplar is that the Nighttime State Change entry (one byte large) in the Maxis exemplar was replaced by a Prop Time of Day entry (two Float32s, or eight bytes large). This is similar to what RippleJet observed when testing this. Because this prop entry is corrupted, closing this save and loading it will cause the game to believe that the entry really is only 88 bytes long, it will read several garbage values in the process, and after 88 bytes have been read it will attempt to read what it thinks is another prop entry. That prop entry will have a nonsensical size entry because it's being misinterpreted due to the corruption of the save, and that prop and all props that follow it in the savefile will not be present. As for why savefiles tend to continuously shrink on every save: When loading a file with corrupted props, incorrect size data and other malformed information will cause the corrupted prop and all props that follow it in the file to be misread. These misread props are discarded by the game, causing them to disappear from the city. Since the malformed props were discarded when loading, they will not appear when saving again, causing the filesize to shrink. On this new save, however, other malformed props could corrupt the savefile again, repeating the process. Towards a vaccine It's worth pointing out that bap originally speculated that prop pox was caused by a buffer overflow or some kind of memory error in the game that caused data for a modded prop to spill past the end of its buffer in memory. To test this, I installed the game on Fedora Linux 26 using WINE 3.0-rc6 and ran it under Valgrind, a memory debugging tool for Linux. However, I found no difference in the number of memory errors reported before and after installing PEG's beach resources. Since some reported instances of prop pox involve parts of the prop subfile being overwritten, we have to look at how the game actually writes data to disk. Since other prop poxxed cities appear to have prop definitions overwriting the middle of other prop definitions, it's possible that the game is incorrectly properly calculating where it should be writing when dealing with these overridden exemplars. Unfortunately this is where things go off the rails: in order to better determine what's going on in this process, I rewrote the function responsible for writing savegame objects, and this link shows what that looks like. Since the Mac version of the game contains the debugging symbols for this to work, I've only tested this on my Mac, and porting this to Windows is nontrivial. In another insane twist, I can't reproduce prop pox using my rewritten Mac serialization code, and can reproduce it immediately when not injecting that code, but I can't confidently say I fixed it since I can't demonstrate this to very many people without a usable Windows DLL, so that's my project for the time being. I also have no idea why my code doesn't cause prop pox to occur since I tried to recreate the original implementation of savegame serialization as closely as possible. For now, I'd speculate that prop pox is caused by a quirk in how the game saves records. Since the game may not know the size of all records in advance when saving a game, it has to resort to rewinding and fast-forwarding to arbitrary offsets in order to save data. For instance, when saving a prop record, the game will: Write the number 0 as a placeholder for the size in bytes. Write the number 0 as a placeholder for the CRC checksum. Write an identifier and the record itself. Rewind to the first zero. Calculate and rewrite the size based on how many more bytes there are in the file after writing the record. Fast-forward to the record itself and read the data in it back to a buffer. Rewind to the second zero and calculate and write the CRC checksum. Fast-forward to the end of the output stream to allow more data to be written. I think that miscalculated offsets when rewinding and fast-forwarding is causing previously written prop records to be overwritten by malformed props, corrupting the entire subfile in the process. How exactly does that relate to the redefinition of the prop exemplar? ¯\_(ツ)_/¯ I'm working on getting my serialization code ported to Windows ASAP to see what happens there. In the meantime, if you have a Mac and want to try it out and report if you're still seeing prop pox: Grab this dylib which was built from the source code linked above (and again here). Go to Utilities in Finder and open up a terminal. I used Steam, so I used these commands: cd "$HOME/Library/Application Support/Steam/steamapps/common/SimCity 4 Deluxe/SimCity 4 Deluxe Edition.app/Contents/MacOS" echo 24780 > steam_appid.txt DYLD_INSERT_LIBRARIES="$HOME/Downloads/libinjector.dylib" ./Sim\ City\ 4\ Deluxe\ Editionsub Your game should now be running with some output labeled COMSerialize, particularly when saving the game. And if you want to help me out, just send me PMs with prop poxxed savegames for me to download so I can look at them.
-
Diagonal Euro Road reverts US type road texture and Possible Prop Pox
Tyberius06 posted a topic in SimCity 4 General Discussion
Hi! 1. So I ran into a little problem after a longer hiatus from the game. I started to change a coulple of lot which were redone during the last couple of months, when I so the phenomena on the first picture. The diagonal roads which has any plopped item next to it reverts US style double yellow line road instead of the white dashed european stlye, which is my NAM setting. The funny thing is, that the zones are not affecting to the road, only the plopables. My question is: could it be a NAM issue OR maybe one of @rsc204 or @rivit mod does this. I'm using NAM 36 with rsc/mgb204's No Grass NAM (NGN), with the Side Walk NAM 1.0 PSS (SWN) and rivit's Tarsealed Streets and the latest RUM for RRW v5. I used the same mods before NAM36 and I didn't experience any problem like this. 2. I ran into this problem now I think the 2nd or 3rd times (first was sometimes end of summer, than today now 2 times.) I have a back-up from 8th october, and I didn't have any problem with that save file, however when I started to play and saved the city and quit, I don't know what happened, but the SC4 Save says I have Prop Pox. It used to come out (with a different map) when my save file reached the 12-ish MB, but now my save file is 43,2 MB and when I save the city it drops back to 42 MB, and the props from the right side of the map are completely wiped out. I brought back the file from the back up and import it into the map replacing the "damaged" file, but after little modification and saving the city I got the same result. It can't be the typical Prop Pox, since I don't have the BDK kit, and never was non of my cities, since I started to play with this map, and I don't remember I've ever met with this offset buffer error, but I don't really remeber either what is the standard prop pox error message. And the funny thing, that I don't have disabled props... So what the...? Any help or advise would be appreciated! Thanks in advance! - Tyberius -
Replies: Scribosilyn: Thanks a lot for your comment! Entry 7: Dealing With Prop Pox So all of those great pictures and scenes you saw in the previous have been lost. The reason why is that a week ago Pololomia suffered from Prop Pox. So I had to use an old back-up which is prop pox free- unfortunately it was dated three weeks ago. I haven't added too much in those three weeks, but still... All of those MMP scenes are gone. Oh well... But it did give me a chance to redo the outskirts of Pololomia and I believe I have found a better layout! Anyway enjoy the pictures! 1. Let's start off with a MEGA mosaic! Link to see the big version- https://imagizer.imageshack.us/v2/147x907q90/922/Eq1rSx.png 2. More sneak peaks of the city centre. 3. 4. 5. 6. And here is the new layout- look to the top of the picture and the outskirts look WAY better as they have now become less dense and there is more green space between them. Note some of these spaces have now been filled in with MMPs. 7. And now some more MMP goodiness! 8. I redid the FA neighbourhood and made it strictly attached to the road- there are no diagonal streets shooting off. 9. 10. 11. When I went to the Lake District a week ago, I was driving along the A66 and I noticed the layout of the trees amongst the fields: lines of trees for field perimetres, small clumps of woodland in the centre of fields, grassy areas marking the perimeter of a field, etc. 12. This got me thinking about how I could add woodland in the middle of my large MMP fields... 13. 14. A new development in my MMP farm/rural quest- wild meadows! 15. 16. Now THIS is what the rural/urban perimeter of Pololomia is going to look like- the grid meets organic MMPs, diagonal roads and FA roads! There will be another update next week!
- 2 Comments
-
- 18
-
-
-
I got prop pox :( How should I go around this?
nRVOUS posted a topic in SimCity 4 General Discussion
its only in one tile so should I wipe It and just move on to another region or do more? So far i deleted all my peg lots since they seem to be considered a problem so should I do anything else? -
Version 1.0.7
103,296 Downloads
What does this do? Fixes a serialization bug that could corrupt the savegame, particularly when mods are installed that modify existing exemplars (i.e. Prop Pox). Resolves a crash-to-desktop when hovering NAM puzzle pieces over transit-enabled lots. Allows other DLLs to load into SC4's memory without a GZCOM framework. Requirements This fix is made for versions 640 and 641 of SimCity 4 on Windows. Version 640 is a fully-patched SC4 retail copy, and version 641 is a fully-patched digital distribution version (i.e. Steam, Origin, GOG). Although v641 is supported, it has only been officially tested on Steam. Installation Unzip to Documents\SimCity 4\Plugins. To see if SC4Fix is working properly, check the title of your game window. If you are playing in fullscreen mode, alt-tab out and hover over the SimCity taskbar icon. The titlebar will show "SC4Fix (version #)" if loaded properly. Repairing cities already affected by Prop Pox Thanks to kingofsimcity for these instructions: In the region view, open the graphics settings and change City Detail to Low. Close and relaunch SC4. Open the offending city tile and save immediately. Exit to region without saving and change City Detail back to High. Close and relaunch SC4. Open the offending city tile and save again. Demonstration Click here for a video showing the ability to hover puzzle pieces over transit-enabled lots with this DLL. Development Thread and Source Code Development Thread Source Code -
I've read a bit about prop pox at SC4D and one thing is sure: this picture got me very worried: As you may see, I lack a bunch of props of that side of the city. In this moment, it seems to be the only "poxed" district, but I'm truly afraid of a pox expansion to other places. It is my capital city and the last thing I want is to lose it. What can I do? Is any way to fix this? Can I avoid the expansion? Should I keep playing with this city? Please, help me. Some useful data about the city: - About a 85-90% of its landmass has been constructed. - My game is fully updated. - This city file size is 9.43 MB.
