jdenm8

I recall Paul Pedriana putting on record somewhere that the underlying engine is designed to use multiple CPUs. However, it broke Windows 98 compatibility so EA mandated they stick it behind a single-thread scheduler. Who knows if he was actually right.

The patches work by altering the game code in-memory. The 1.1.640 EXE (which was the only other version remotely considered for support, though only very recently) not only puts the code in different places, but is encrypted. The Encryption makes it significantly harder to find the needed addresses since the EXE can't be reverse engineered. You can't patch the code in memory if you don't know where it is in memory. I would have stressed the Encryption much more strongly than the DRM. SafeDiscShim was released at the beginning of the month, which solves the issues with SafeDisc without the legal complications or messing with driver signing. I've confirmed that the SafeDisc DRM in 1.1.640 passes validation under Windows 10 with SafeDiscShim installed. My copy immediately crashes afterwards, but that can be pinned on a dirty installation from 2012 (which hasn't been touched since 2013) that needs to be re-done.

The jobTotalCapacities property, and the lack of it on the Plopped version, sticks out to me. I wonder if maybe Maxis had used it interchangeably with jobCapacities in some contexts. The fact they're different makes me wonder if things on the lot other than buildings (like maybe a Prop) were supposed to be able to add Job Capacity at one point. Or maybe that's how Machinery, Outbuilding and Field lots add routes to their parent. I'll look at adding that to the Wiki tomorrow night. Anyone else is welcome to do it before then though, I'll check the edit log before I do it.

I think the Deals one might be related to Business Deals. I can't chase up where exactly it came from, the trail runs cold at the transfer from WakkaWikki to MediaWiki back in 2005. It does mention something about a Savegame XML file though. I might see if I can find it, though it was probably lost on the old MTS2 Forum. Also, if you do make any changes to the wiki, let me know. I'm working on cloning the Wiki into a newer version of MediaWiki (Making a WikiMarkup-format backup in the process) for when the new hosting is sorted out instead of transferring that outdated version from 2008.

Landfills are just weird. They also have some special properties that mean they completely lock the terrain under them. My understanding of how they work: All the tiles of a Landfill zone are treated as one building. The visual area indicates the usage of the storage capacity and how much the zone costs. This area expands (starting from the North-West corner IIRC) every (IIRC) 100t. A 3x3 Landfill zone uses 4 tiles at 0t, 6 at 400t, 8 at 600t and 9 from 800t, which allows the Max capacity for a 3x3 (900t). The area shrinks (starting from the most recently occupied tile) at the same intervals. There's some rules that change how they appear based on the configuration of the buildings in the Landfill Zone. SC4 is *supposed* to be able to make 1x1 landfills (IIRC the renders and everything are there), but can't for some reason and starts with at 2x2 instead. The issue starts when you expand an existing landfill zone, or if it isn't rectangular. This causes the game to mess it up and make some of the landfill tiles never despawn. Usually it's an entire line that won't disappear. As far as I'm aware, there's no way to fix it. I'm curious to see if messing with either of the Landfill subfiles can shed some light on the problem.

Some very interesting developments in here! I went ahead and added Speeder's C++ class names to the wiki, they can all be found in the Savegame article. It's cleared up quite a bit of mystery, though, interestingly, it isn't comprehensive. I'd be interested to see if anything could be done about Landfills. They're pretty broken in the base game and removing one that's been expanded after the fact can be impossible. Also, TID c97f987c controls lot base textures, a9c05c85 controls Flora (trees, bushes, etc), a9bd882d controls buildings and 2977aa47 controls props. I think the positions of each are stored in those. Just deleting 2977aa47 or a9c05c85 from the savefile forces the game to regenerate all of the Props or Flora from scratch (was an early Prop Pox fix). That should make the props appear in the correct location after moving a lot. The building would liikely have to be found and moved manually, there should be a reference to it in the Lot Subfile.

Simple. You won't unless you're using a pre-2009 version of a number of Prop Packs (most of which were fixed, then later combined into mega packs), a few packs that were no longer available in 2009, or the BDK Prop Pack mentioned. Which is still available, still causes Prop Pox without this patch, and carried no warning of that for many years. For Prop Pox to happen, you basically need to fill an entire large city tile with lots with lots of props. Most people don't have this happen so they don't see the issue. I've only had it happen twice myself.

A DAT file won't fix Prop Pox since fixing Prop Pox requires writing new game code (in C++) to fix the problem. A DAT file can't contain executable code except in very few rare circumstances (Even then, they're still DLL files, they're just inside a DAT). DATs can contain LUA scripts, but LUA can't fix Prop Pox. I would go over the extensive history regarding Pegasus and Prop Pox, but it involved inter-site drama. IIRC, that's not permitted on here. Suffice it to say, Pegasus did absolutely nothing to prevent Prop Pox and made no effort to fix it or prevent its spread. Still, it's awesome that it's now fixed!

In theory it could happen to any type of subfile stored in the savefile, that stores overrideable objects, at decompression time. Would it happen in practice? I don't know. It largely depends on the subfile structure and how the game loads it. It was assumed some time ago that the Flora subfile (That stores Flora objects on lots) would likely also be susceptible to this bug. Since nobody has really ever done anything with Lot Flora (Pretty much every flora pack (trees, shrubs, flowers, etc) I know of adds flora as props instead of as Lot Flora), it was considered dismissable.

Been a very long time since I last thought about this over here. Might as well dump my old second-hand knowledge (which was probably simplified in the threads I read for expediency) so don't know if it's 100% accurate. You probably already know it all. The 6MB limit for compressed subfiles was chosen not for performance reasons, but because that's all that the compression algorithm (QFS) can do. It can't compress a file larger than around 6MB. I think I read that there is a significant byte at the end of each entry in the prop subfile. A kind of 'End of File' marker. SC4 is obviously capable of finding this significant byte since it reads malformed entries correctly when the subfile is compressed. Either it doesn't look for the significant byte when reading an uncompressed entry or it discards it as part of the conversion from compressed to decompressed. I recall it being observed that SC4 only ever creates prop entries of one of two lengths. I don't remember what the lengths were, but the game used the wrong one (IIRC, the shorter when it should have used the longer) on these malformed entries. In theory, scanning an infected savefile for mismatching lengths and correcting them should repair the subfile (or at least make it load correctly) provided the subfile's not been saved over with an irreparably malformed one. The corruption definitely only occurs on load. All of the entries following the bad one are intact and present after conversion. Thanks for looking into this again, it'd be great to finally have it fixed.

There's some real interesting stuff in here nowadays thanks to the new FlexFlys. I made this this evening, just a quick, boring old Volleyball. Except the entire thing fits into a single Zoom 4 screenshot. I could probably get it a little smaller, shave off a tile here or there, but I'm pretty happy as-is.

Thought I'd check back in here and update the Wiki again. All the ones from the 6th of Oct are spot-on I think. Civic Theatre looks plenty close enough for me. The Gayoso Hotel one is interesting, that's actually at the back of the building. Looks like a later extension actually, it's more elaborate than the equivalent structures at the front. The residence floors look exactly right. It's like as if Maxis took the front, stuck it on the back and copied the the bay windows from the front to the side. I'm not happy with the others in that post though. Kanarowski and Co's second floor is pretty distinctive since it's a plant floor. Makes me think the real building would have one there too. The ground floor is pretty close, but the real building may have a similar one. Weber Designs is close, but the center of the fascia... They would have done that for a reason. Dunno about Cahalane. The structure is right, but the exterior is completely different. I don't think it's it. I think the tower from the St Paul City Hall is right but the base might be an original work. They've separated tower and base before. McCormack Place is spot on I think, as is Vernon Manor. The verandas are even in exactly the same places. The two in the 6th of Dec post look right. State Fair was a good spot, Maxis played it fast and loose with that one. A shame, the real thing looks pretty incredible. Sobchak looks right, though from what I can see only the Signage is really close. The entrance in particular looks completely different, it has to be based off a different building. Farly Audio looks right, I'm pretty sure it's been mentioned before. Shame they got rid of most of the details. Simon Manor is 895 Park Avenue through and through. I recall there being a version in Tycoon City: New York and I think the devs did a similar thing with their recreation. May Co looks spot on. I find it funny that Maxis named it 'Simcys' in the Exemplar and what was left of the May Company ended up as part of Macy's in 2005. I've added (or are adding) passages for all these to the Wiki at SC4D. Spurred me into making a few more articles for buildings I never got around to. Also, thought I might add that most of the 'Rendering Glitches' are actually bugs in the models, the DLC Landmarks are rife with them. Usually a column of models is too narrow or has incorrect UV Mapping. The renders themselves line up fine so I'm surprised that nobody's made a pack that fixes these yet.

It's nothing to do with disk accesses. Your HD 7950 is tripping the 7000 Series check. http://pcgamingwiki.com/wiki/SimCity_4#Details_disappear_when_scrolling That should fix it.

I've found that every time I start the game it lets me get away with increasing the settings more and more. Average FPS is around 60 on my 4 year old Graphics Card, though when the stutter hits, it hits hard. 2-5FPS for about 15 seconds, then it's back to 60 like nothing ever happened. I think the main problem is the game isn't efficient enough with its GRAM. Old GCs have more than enough power to run it, but not enough GRAM. The launcher's made of absolute suck too.

I've spent most of the last 24 hours trying to figure out which of the asset files is corrupt. Game crashes whenever I near either of the two south level crossings on Roy Lowenstein Blvd. Of course Rockstar's downloader doesn't have a file validator. At this rate, OpenIV will have been updated to open GTAV PC files before I figure out which file is corrupt.