CAM killed R$$ and R$$$ in my smaller cities!

[jdenm8]

Okay... Ages ago I installed the CAM. Since then, my larger cities have absolutely flourished and they're bigger then ever before, R$$, R$$$, CO$$ and CO$$$ towers everywhere and still multiplying. However, I'm having issues having R$$ and R$$$ grow in new city tiles. I have recently built a rather sizeable city as a bedroom satellite-city for my larger city and yet, even though I have provided full facilities (police, health, education, RHW-6C connection to the city centre), there is still -2000 R$$ and R$$$ demand, as it has been since I started the city.

Some of my other newer cities in the same region have suffered the same fate, even ones completely independent of my large, multi-tile city and dependent on other industries (like I-M). It just baffles me how the CAM can just neuter growth like that.
On the same token, in these towns C$ buildings just don't grow. CS$$, CS$$$, CO$$ and CO$$$ buildings replace them almost immediately, even in Medium Density.

Any help on this would be helpful. (I use no demand cheats - in fact, I don't 'cheat' at all any more)

[z]

This is the infamous CAM Demand Bug, and it often manifests exactly as you describe.  The problem is that for reasons not well understood, the CAM exemplars don't replace the in-game ones, as normal plugins do; they simply add to them.  The result is that the game thinks that your regional population and workforce are twice what they actually are.  Since you have so many workers, the game figures that you obviously don't need more residents.  Sometimes there's just a drop in residential demand as a result of this; other times, R$$$ alone will go completely negative; still other times, both R$$ and R$$$ will go completely negative.  R$ is largely unaffected; nothing seems to deter the low-wealth Sims.

I use no demand cheats - in fact, I don't 'cheat' at all any more

Well, you may have to.  The game is essentially cheating you; you may have to cheat right back.  The only way I know of getting demand back in these situations is to drop your tax rates way down for the two affected categories.  When this has happened to me, I've found that dropping them to 2% gets demand almost as high as it will go for these wealth levels (which is still much lower than normal), while still leaving you with a little income.  And if that's not enough to keep you in the black, you're entitled to a little help from Cousin Vinnie; you can find him here.

This bug will be fixed in CAM 2.0.  Unfortunately, those regions that have the bug can't get rid of it, as memory of the high water mark of the population levels is stored in the city files.  There may be a way around this by importing these cities into a new region, but I haven't seen anyone who's reported definitive success at this.

[jdenm8]

Is there a way to open the back end of the city tiles and change this information to the correct figures? And could uninstallation of the CAM fix the problem?

[z]

Is there a way to open the back end of the city tiles and change this information to the correct figures?

Theoretically, yes.  I don't think anyone knows where those numbers are, though.

And could uninstallation of the CAM fix the problem?

Unfortunately, no.  Uninstallation would prevent it from getting worse, so that if you built enough to actually double your population, the problem should gradually disappear.  But I have found that the workaround I described above actually works quite well, and that for me, the benefits of CAM 1.0 far outweigh the problems caused by this bug.

[RippleJet]

Theoretically, yes.  I don't think anyone knows where those numbers are, though.

Unfortunately that's only a theory...
It probably wouldn't be too difficult finding where they are saved in the savegame file...

However, there's a CRC field at the start of all important subfiles included in the savegame,
and since nobody has managed to decode that CRC, we cannot make any changes to those subfiles.

A change would require the CRC to be correctly updated.
Otherwise the game will simply disregard the whole subfile as erroneous.

[z]

It probably wouldn't be too difficult finding where they are saved in the savegame file...

However, there's a CRC field at the start of all important subfiles included in the savegame,
and since nobody has managed to decode that CRC, we cannot make any changes to those subfiles.

Since we don't know where those numbers are, do we have enough information to conclude that they're in an "important" subfile?  If not, it seems it would be worth finding them and seeing if they are.  If there's no CRC associated with that subfile, it makes things an awful lot easier.

Even if there is a CRC associated with that subfile, there's still the question, How big is the subfile, and what does it contain?  If it could be replaced with a valid subfile from a much smaller region without causing problems, then the CRC would be OK, and over time, the numbers would adjust to be completely correct.  This would allow full conversions from CAM1 regions to CAM2.

I understand that there are a number of "ifs" in there, but the potential reward would seem to be great enough that I think that this would be something worth exploring.

[wouanagaine]

To my knowledge, any subfile in the SC4 save game which used one or more struct to save itself use a CRC, so far, the only one that doens't use such CRC besides TEXT/PNG subfiles is the terrain heights.

If someone is willing to takle on the CRC decoding, I'll be more than happy to provide some datas to try to decipher it. I even think that if you use C4SavegameExplorer, you have the CRC and the data associated with that CRC, so you can try to decrypt it

Beeing able to regenerate a valid CRC will oen a brand new space for some tools

[z]

Being able to regenerate a valid CRC will open a brand new space for some tools

I can certainly believe that.  But there are so many possible ways to generate CRCs - this would need to be done by someone who has some serious free time.

To my knowledge, any subfile in the SC4 save game which used one or more struct to save itself use a CRC, so far, the only one that doens't use such CRC besides TEXT/PNG subfiles is the terrain heights.

By this description, I would imagine that the prop subfile has a CRC - is this true?  This would be significant, because we know we can delete the prop subfile, and the game will regenerate it.  There are various other subfiles that can be deleted and then get regenerated.  If the population statistics are in a deletable subfile that would then get regenerated, we're home free.

[RippleJet]

By this description, I would imagine that the prop subfile has a CRC - is this true?

Yes, and as far as I know, you do also have access to the threads where the decoded savegame formats are listed...

[the00guvna]

what if you started a new city without the CAM, then once it had been established moved the CAM back into the plugins folder. in my experience, CAM works fine in existing cities, but only causes trouble in new cities

[RippleJet]

what if you started a new city without the CAM, then once it had been established moved the CAM back into the plugins folder. in my experience, CAM works fine in existing cities, but only causes trouble in new cities

Yes, but the doubling would after that (still and only) apply to any additional growth in your region after you moved the CAM back into your plugins folder.

[Lowkee33]

@Wouanagaine:  I am interested in trying to decrypt the CRC.  I dont promise any results, but I like to plug away at the things I dont understand.

But there are so many possible ways to generate CRCs - this would need to be done by someone who has some serious free time.

But are there a limited number of ways?  If I begin looking at this I can certainly educate myself, but I though I would post the basic way I understand this:

There is data in the save game.  This data has a certain size.  A function (algorithm?) is used on the size of the data to determine the CRC.  This is called a hash check. 

[wouanagaine]

you're on the good way Lowkee
I've tried generic CRC24 CRC32 and other variations to no extends on some savegame data
maybe I've done it wrong because it is a known fact that maxis used CRC24 in TheSims1&2 and certainly 3.
Maybe they use only a part of the data and not all of them, which might lead to many possible way to generate it
Basically you'll take data in SC4SaveGameExplorer which display the CRC associated with a data line, you have the data line and tried to find out the algorithm used

[Lowkee33]

Maybe in your version of the SaveGameExplorer.  Us mere mortals are at V.11.

Ah...Thread Hijacking... I dont even know what questions to ask.

[Lowkee33]

So... in the save game data I open up the Lot Section and see something like CRC 0x12345678 and MEM 0x12345678.

I have checked this value of MEM against about 30 CRCs and none of them give back the matching CRC.  Perhaps I am doing it wrong.  Perhaps the CRC size is within the MEM size, so that the value I give is not the proper one.

It could be worked backwards though right?  If I had the CRC and the Algorithm I could get the file size needed.  I then do something magical and separate the actual file size with the size the Algorithm said it should be.  Then I would know the size of the CRC.  Perhaps I am looking at it all wrong though.

[RippleJet]

Change the view from "Lot Record View" to "Bloc view".
In that view you get each record in one single line.
Only the offset and the Bloc size are decoded fields, the rest is pure hex, byte by byte.
The first four bytes following after the Bloc size would be the CRC (note that the bytes are stored little-endian).

As far as I know (wouanagaine, or someone else, will have to confirm or correct me on this...),
the CRC should be computed based on all bits of data following after the CRC itself.