Moving this discussion from http://www.modthesims.info/showthread.php?t=502022:Yes, that's an excellent idea.

I believe that removing all custom terrain paints is pretty easy, as long as the program could just remove them all.

However, removing undefined custom terrain paints (while leaving the ones that are actually installed in Downloads) would be harder.

[Update #1]

Was this problem fixed in M&G? I've been installing lots without their terrain paints, but I can't seem to get anything bad to happen.

Is there a particular lot which has problems with a particular set of EPs that would help me to reproduce this problem?

[Update #2]

Looking inside the Lot Terrain Geometry (LOTG^wiki) records with instances from 0x5CC0 (up to but excluding 0x5CEE?), it would appear that M&G zeros out the entire 2D array when the terrain paint is unavailable. An alternative would be for the Clean Installer / LotAdjuster to delete the entire record. The one remaining question is how a record is associated with a specific terrain paint.

OK, I really can't seem to reproduce this problem. I've created a lot with custom terrain paints and then installed it without those terrain paints into the base game, open for business, seasons, and mansion and gardens. In all cases, the custom terrain paints disappeared from the lot without any issues at all.

Could someone please supply a link to a lot which has this problem, and tell me which EPs and SPs they are using? Thanks so much!

[Update:] Never mind, I got one:
http://www.modthesims.info/showthread.php?t=502996

The expected solution does not work. I removed all LOTG instances over 0x5CC0 except for 0x5CEE and the problem continued. Since these records hold the terrain paint usage data, I had expected that deleting these records would resolve the problem.

However, I noticed something very odd about the lot: it actually has more terrain paints than (what I expected to be) the maximum number of terrain paints, which is instances 0x5CC0 -> 0x5CED (since 0x5CEE is special). In addition, the 0x5CEE record has values which seem to point to these potentially invalid 2D arrays (I am guessing that the values in the 0x5CEE record are the numbers of each terrain paint used on a quarter tile (instance - 0x5CC0 + 1?)).

This may explain why I could not reproduce this problem. If the problem is not missing custom terrain paints, but an abnormally high number of terrain paints on the lot (only achievable if you have custom terrain paints), then far less lots will have this problem than we originally thought. That's both good news (because most lots won't have the problem) and bad news (because the problem is more complicated than I first imagined).

So, I theorized that values in 0x5CEE associated with instances over 05CEE could be the problem and tried the following:
- Delete LOTG instances over 0x5CEE.
- Replace those potentially invalid values in the 0x5CEE record with values that I thought would be valid, although incorrect.
Note that this did not resolve the problem.

Finally, tried deleting the 0x5CEE record entirely. This solves the problem, but may not be a valid solution. The question is whether the 0x5CEE record will regenerate if we delete all LOTG instances over 0x5CC0.

[Update:] Yes, it does. When a new terrain paint is added to the lot, the 0x5CEE record is regenerated. Unfortunately, so are all of the other LOTG instances. Which means that when you add terrain paints to the lot, they may end up with instances > 0x5CEE, which re-creates the original problem.

Making progress, but we need to determine how the game knows all of the terrain paints which have ever been used on the lot.

Looks like the terrain paint names are stored in the Lot Texture (LTTX) record. Instances of the LOTG are probably based on the order of the textures in the LTTX record.

When the Lot Texture record is deleted, it regenerates (in a game with all EPs and SPs except the Store Edition) with Beach followed by 4 textures: Cliff, Seabed-Shallow, Seabed-Deep, Beach. This leaves the lot with the beach texture, which isn't too bad if it's possible to fix in-game (needs research).

The default on a grass base game lot with no terrain paint is: Test-01 followed by the above 4 textures. Replacing the Lot Texture record with this default grass record produces a grass lot but has grass under the water on the lot. I believe that this is standard game behavior.

Note that these are the exact same 4 textures regardless of game configuration. With any luck, we can rely on this order for all lots; it holds for every lot that I have examined. The number of terrain paints in the LTTX record appears to be the number of textures in the LOTG records from 0x5CBC (excluding the terrain control in 0x5CEE and the water elevations in 0x3B76). The first 4 LOTG instances likely correspond with the 4 standard textures.

So, it looks like we can solve this problem by deleting all LOTG records from 0x5CC0 and then truncating the LTTX record after the first 4 textures.

Another interesting data point: the failing lot has the number of terrain paints as 0x42 = 66 (in LTTX). The terrain paint instances (LOTG) go from 0x5CBC -> 0x5CFD, which is exactly 0x42 instances. This really seems to imply that the problem is that 0x5CEE, which is the control record for all of the terrain instances, is being used by the game for both a normal terrain paint array and the control record.

In other words, an EA bug may limit the number of terrain paints ever used on a lot to 0x32 = 50.

I still don't understand why you need to remove custom terrain paints to actually see any problem, since the record seems to be improperly used as soon as you reach 51 terrain paints. My current theory is that the game normally keeps the control record version of 0x5CEE, but when the custom terrain paint is missing, the terrain paint version of 0x5CEE overwrites the control record during the display of the lot.

So, there seem to be a number of things that we can do. I've tried to list the options from least destructive to most destructive:
1) Delete all zero-filled (unused) terrain paint records from the lot, excluding the standard 4. *
2) Delete specific terrain paint records from the lot, if the custom terrain paint is unavailable.
3) Delete specific terrain paint records from the lot, based on user selection.
4) Delete any terrain paints past a specific number. We probably don't want to leave 50 terrain paints on the lot, because then no additional terrain paints can be used on the lot without risking recreating the problem again. Does it always make sense to allow the user to choose instead? If not, then what is the "correct" number of terrain paints to leave?
5) Delete all terrain paints, excluding the standard 4. **

In each of these cases, this means deleting the appropriate LOTG, modifying LOTG instance 0x5CEE, removing the corresponding terrain paint from the LTTX, and renumbering all remaining non-control LOTG to fill in the gaps. It probably also makes sense to do #1 and possibly #2 before doing any of 2-4.

One more thing that I'd like to try:
- Is there any way to modify LOTG instance 0x5CEE so that there is no terrain paint specified for LOTG instance 0x5CEE? If so, this might solve the problem of having more than 50 terrain paints without causing any problems in the game. [Update: I tried changing the name of the terrain paint which is associated with LOTG instance 0x5CEE to "". This did not resolve the problem. Too bad. That would have been a really nice solution.]

* This feature should be added to the LotCompressor as well. Note that the failing lot that I have has a large number of unused terrain paints.

** This may be the only reasonable alternative to add to the Clean Installer.

Status report:

Option #1 implemented and in testing. My test lot went from 66 terrain textures to 7 (including the standard 4 which were actually unused). 7 is so far away from the limit of 50 that I'm not sure that there's any need to implement the rest of the options.

The option which seems most useful after #1 is #3: Allow user to select which terrain paints to remove.

I've uploaded a new version of the LotAdjuster which will remove all unused terrain paints. If you find a lot which isn't fixed using this feature, please give me a link to the lot, so that I can investigate further.

Otherwise, I consider this issue closed.