Ideas for Extending the Maxis Terrain.ini Format

[Null 45 3,118]

I am using this thread to lay out a few ideas that I have for adding new features to the Maxis Terrain.ini file.

Longer Display Names

Currently the terrain mods listed in the Extend Terrain UI are limed to the single word prefixes for the terrain section names, e.g. [<Prefix>MiscTextures]. This could be handled by adding an optional [TerrainDisplayNames] section, that uses the prefix as the INI key name. For example:

[DisplayNames]
Arctic=Siberia
Desert=Sand Dunes

Allowing Multiple Terrain mods to Use Cutaway/Water Textures

The game uses a number of hard-coded texture ids: 0x10, 0x11, 0x13, 0x14, 0x15, 0xe0, 0x09187300-0x09187304, and possibly others that I missed. These textures are used for cutaways, water, etc. I have been looking in-game, the Reader, and various mods to see what each one is used for, but I don't know if it is already documented somewhere.

• 0x00000Z10 and 0x00000Z11 appear to be cutaway textures.
• 0x00000Z13 is the inshore water texture.
• 0x00000Z14 and 0x00000Z15 appear to be underwater textures.
• 0x00000ZE0 is possibly volcanic ash?
• 0x09187300-0x09187304 is the offshore water texture.

As I mentioned in the Show us What you're Working On thread, I recently added some code to the the Extended Terrain DLL that allows me to control the game's terrain texture loading. Currently it only logs the texture TGI values SC4 requests, but it could be used to remap the game's request to a different TGI value. This system was added based on a request for the hard-coded inshore and offshore water textures to be configurable in Terrain.ini.

An Offset System to Allow More Terrain Mods to Coexist

The terrain mod texture range is limited by the 0x00000ZTT format Maxis used, with several of the TT values being reserved by the game for other purposes. One possible solution to this would be an offset system that allows upper bytes of the id to be used as a prefix to separate mods with the same lower values.

As an example, the hypothetical terrain mods A and B would both use the Maxis Tropical texture range with the following beach texture ids.

• A: 0x00000039 - this overwrites the Maxis tropical texture.
• B: 0x10000039 - this mod uses an offset of 0x10000000.

When the B terrain mod is loaded, the game's request for texture 0x00000039 would be redirected to 0x10000039.

Feedback and additional ideas would be welcome. 

[Ulisse Wolf 4,461]

9 hours ago, Null 45 said:

I am using this thread to lay out a few ideas that I have for adding new features to the Maxis Terrain.ini file.

Longer Display Names

Currently the terrain mods listed in the Extend Terrain UI are limed to the single word prefixes for the terrain section names, e.g. [<Prefix>MiscTextures]. This could be handled by adding an optional [TerrainDisplayNames] section, that uses the prefix as the INI key name. For example:

[TerrainDisplayNames]
Arctic=Siberia
Desert=Sand Dunes

Allowing Multiple Terrain mods to Use Cutaway/Water Textures

The game uses a number of hard-coded texture ids: 0x10, 0x11, 0x13, 0x14, 0x15, 0xe0, 0x09187300-0x09187304, and possibly others that I missed. These textures are used for cutaways, water, etc. I have been looking in-game, the Reader, and various mods to see what each one is used for, but I don't know if it is already documented somewhere.

• 0x00000Z10 and 0x00000Z11 appear to be cutaway textures.
• 0x00000Z13 is the inshore water texture.
• 0x00000Z14 and 0x00000Z15 appear to be underwater textures.
• 0x00000ZE0 is possibly volcanic ash?
• 0x09187300-0x09187304 is the offshore water texture.

As I mentioned in the Show us What you're Working On thread, I recently added some code to the the Extended Terrain DLL that allows me to control the game's terrain texture loading. Currently it only logs the texture TGI values SC4 requests, but it could be used to remap the game's request to a different TGI value. This system was added based on a request for the hard-coded inshore and offshore water textures to be configurable in Terrain.ini.

An Offset System to Allow More Terrain Mods to Coexist

The terrain mod texture range is limited by the 0x00000ZTT format Maxis used, with several of the TT values being reserved by the game for other purposes. One possible solution to this would be an offset system that allows upper bytes of the id to be used as a prefix to separate mods with the same lower values.

As an example, the hypothetical terrain mods A and B would both use the Maxis Tropical texture range with the following beach texture ids.

• A: 0x00000039 - this overwrites the Maxis tropical texture.
• B: 0x10000039 - this mod uses an offset of 0x10000000.

When the B terrain mod is loaded, the game's request for texture 0x00000039 would be redirected to 0x10000039.

Feedback and additional ideas would be welcome. 

The most critical part of the terrain.ini is the handling of texture IIDs.

I am thinking about this but it depends on the possibility of how many changes we can make to the game code

0xQWRLHZTT

Q= Identifies the primary code of the biome (0 = Standard - 1 = Desert - 2 = Temperate - 3 = Artic - 4 = Tropical)
W= Identifies the season (0 = Standard - 1 = Winter - 2 = Spring - 3 = Summer - 4 = Fall)
RLH = Unique creator code.
Z = Identifies the zoom
TT = the unique Variable IIDs

Standard means the current behavior and the game ignores texture swap

[Null 45 3,118]

5 hours ago, Ulisse Wolf said:

Standard means the current behavior and the game ignores texture swap

What is the purpose of encoding the biome and season in the id? I am also somewhat skeptical that the per-season terrain would be worth the massive amount of effort it would take to try and implement, if it is even possible at all.

I would propose the following format:

 0xABCDRZTT

ABCD = Creator code (65535 values instead of 4096).
R = Reserved for marker codes/flags. Although it probably makes more sense to stick those in another INI field.
Z = Identifies the zoom.
TT = the unique Variable IIDs.

[Ulisse Wolf 4,461]

2 minutes ago, Null 45 said:

What is the purpose of encoding the biome and season in the id? I am also somewhat skeptical that the per-season terrain would be worth the massive amount of effort it would take to try and implement, if it is even possible at all.

I would propose the following format:

 0xABCDRZTT

ABCD = Creator code (65535 values instead of 4096).
R = Reserved for marker codes/flags. Although it probably makes more sense to stick those in another INI field.
Z = Identifies the zoom.
TT = the unique Variable IIDs.

It could work but is it possible to see a demo of the new system?

[Null 45 3,118]

Just now, Ulisse Wolf said:

It could work but is it possible to see a demo of the new system?

Which system? I haven't even written the code yet to handle these proposed texture range extensions.

[Ulisse Wolf 4,461]

11 minutes ago, Null 45 said:

Which system? I haven't even written the code yet to handle these proposed texture range extensions.

The whole system if it is possible. At least we can figure out where we can improve.

 

[Barroco Hispano 26,942]

To be honest, this is beyond my knowledge. Texture distribution is controlled by the .ini and the moisture map. With the system you are trying out, would it be possible to add more "colors" to the moisture map and increase the amount of textures mixed in a flat area? In my opinion, making SimCity 4 able to recognize multifsh terrain textures would be a great step forward.

[Null 45 3,118]

12 hours ago, Barroco Hispano said:

With the system you are trying out, would it be possible to add more "colors" to the moisture map and increase the amount of textures mixed in a flat area?

What do you mean? The moisture map is a fixed size and that can't be changed.

12 hours ago, Barroco Hispano said:

In my opinion, making SimCity 4 able to recognize multifsh terrain textures would be a great step forward.

That probably isn't feasible. The FSH loading and rendering code is opaque, I have no idea how the game renders the multi-image textures.

[Null 45 3,118]

Here is a prototype of the new terrain.ini sections, I am also attaching the full ini file to this post.

Spoiler

[DisplayNames]
TerrainMod1=Terrain Mod 1
TerrainMod2=Terrain Mod 2

[TropicalMiscTextures]
HighCliff=0x00000043
LowCliff=0x00000044
Beach=0x00000039
; All new textures use random instance ids.
; The game uses 0x7ab50e44,0x891b0e1a group for all terrain textures.
InshoreWater=0x12345678
OutshoreWater=0x12345678
; Possible entries for cutaway or sea floor textures below.

[TextureOffsets]
; Maxis used the texture format 0x00000ZTT.
; Z is the texture zoom level (0-4), and TT is the texture id.
; We re-purpose the unused 0 values as follows: 0xABCDRZTT.
; ABCD is an unsigned 16-bit creator id, with 0x000000000 and 0xffff0000
; being reserved.
; R is a 4-bit reserved value, and currently should be 0.
; One or more of those reserved bits could be used to extend the creator range
; beyond 65534, but I am not sure if that is necessary.
;
; In the following examples, both terrain mods use the Tropical texture range.
; When the game requests 0x00000Z39, the appropriate offset will be applied by
; adding it to the texture id the game requests.
; If TerrainMod1 is loaded, the games request for 0x00000Z39 would be converted to
; 0x00010Z39.
TerrainMod1=0x00010000
TerrainMod2=0x00020000

 

terrain_new_sections.zip

[Ulisse Wolf 4,461]

4 minutes ago, Null 45 said:

Here is a prototype of the new terrain.ini sections, I am also attaching the full ini file to this post.

  New INI Sections (Hide contents)

[DisplayNames]
TerrainMod1=Terrain Mod 1
TerrainMod2=Terrain Mod 2

[TropicalMiscTextures]
HighCliff=0x00000043
LowCliff=0x00000044
Beach=0x00000039
; All new textures use random instance ids.
; The game uses 0x7ab50e44,0x891b0e1a group for all terrain textures.
InshoreWater=0x12345678
OutshoreWater=0x12345678
; Possible entries for cutaway or sea floor textures below.

[TextureOffsets]
; Maxis used the texture format 0x00000ZTT.
; Z is the texture zoom level (0-4), and TT is the texture id.
; We re-purpose the unused 0 values as follows: 0xABCDRZTT.
; ABCD is an unsigned 16-bit creator id, with 0x000000000 and 0xffff0000
; being reserved.
; R is a 4-bit reserved value, and currently should be 0.
; One or more of those reserved bits could be used to extend the creator range
; beyond 65534, but I am not sure if that is necessary.
;
; In the following examples, both terrain mods use the Tropical texture range.
; When the game requests 0x00000Z39, the appropriate offset will be applied by
; adding it to the texture id the game requests.
; If TerrainMod1 is loaded, the games request for 0x00000Z39 would be converted to
; 0x00010Z39.
TerrainMod1=0x00010000
TerrainMod2=0x00020000

 

terrain_new_sections.zip

Let me see if I have understood correctly

Display Names would be the name of the terrain mod

So it would look something like this

TerrainMod1=Temperate
TerrainMod2=Desert

I think Inshore Water, Outshore Water, cutway and sea cutway will be found not only TropicalMiscTextures but also in the other DesertMiscTextures, ArticMiscTextures and DesertMiscTextures. Right?

Finally we have offset that performs the descriminant function between the two mods if they are in the same type of terrain. Right?

 

[Null 45 3,118]

51 minutes ago, Ulisse Wolf said:

Display Names would be the name of the terrain mod

Yes, the INI key is the same prefix used for [<Prefix>MiscTextures], etc. That feature is intended to allow more descriptive names than just the prefix would allow.

51 minutes ago, Ulisse Wolf said:

I think Inshore Water, Outshore Water, cutway and sea cutway will be found not only TropicalMiscTextures but also in the other DesertMiscTextures, ArticMiscTextures and DesertMiscTextures. Right?

Correct.

51 minutes ago, Ulisse Wolf said:

Finally we have offset that performs the descriminant function between the two mods if they are in the same type of terrain. Right?

Correct. More specifically, it separates terrain mods that use the same terrain texture id range. In the example I gave, there were two terrain mods using the Maxis 'Tropical' texture range.

Did you ever figure out ranges for the Desert, Temperate and Arctic terrain modes? IIRC Maxis assigned ranges for all but Arctic.

Now that I think about it some more, the 'Creator code' may make more sense as a 'Unique mod id'. That way terrain modders can receive codes to uniquely identify their terrain mods, under this scheme each 'Unique mod id' would have 4 possible sub ranges, one each for Desert, Temperate, Tropical and Arctic. With that in mind, I am revising the id scheme I proposed in a prior post:

0xABCDEZTT

ABCDE = Unique mod id,  0x00000 and 0xFFFFF are reserved.
Z = Identifies the zoom.
TT = the texture IIDs.

[Ulisse Wolf 4,461]

1 hour ago, Null 45 said:

Yes, the INI key is the same prefix used for [<Prefix>MiscTextures], etc. That feature is intended to allow more descriptive names than just the prefix would allow.

Correct.

Correct. More specifically, it separates terrain mods that use the same terrain texture id range. In the example I gave, there were two terrain mods using the Maxis 'Tropical' texture range.

Did you ever figure out ranges for the Desert, Temperate and Arctic terrain modes? IIRC Maxis assigned ranges for all but Arctic.

Now that I think about it some more, the 'Creator code' may make more sense as a 'Unique mod id'. That way terrain modders can receive codes to uniquely identify their terrain mods, under this scheme each 'Unique mod id' would have 4 possible sub ranges, one each for Desert, Temperate, Tropical and Arctic. With that in mind, I am revising the id scheme I proposed in a prior post:

0xABCDEZTT

ABCDE = Unique mod id,  0x00000 and 0xFFFFF are reserved.
Z = Identifies the zoom.
TT = the texture IIDs.

The new proposal should be this

ABCD = creator identification code

E = identifies the biome

Z = Zoom
TT = Texture IID

So we can have the same texture for multiple biomes but the E value acts as a discriminator for the biome to appear. Right?

 

 

[Null 45 3,118]

5 minutes ago, Ulisse Wolf said:

So we can have the same texture for multiple biomes but the E value acts as a discriminator for the biome to appear. Right?

I don't understand why you would need that when the TT value already has that effect, Maxis already assigned 3 of the 4 TT ranges to separate the different biomes.

[Ulisse Wolf 4,461]

1 hour ago, Null 45 said:

Now that I think about it some more, the 'Creator code' may make more sense as a 'Unique mod id'. That way terrain modders can receive codes to uniquely identify their terrain mods, under this scheme each 'Unique mod id' would have 4 possible sub ranges, one each for Desert, Temperate, Tropical and Arctic. With that in mind, I am revising the id scheme I proposed in a prior post:

More than anything else it is unclear this proposal because creating a system with 4 sub ranges I assume that in the 0xABCDEZTT the E value is the descriminant value for the biome

[Null 45 3,118]

1 minute ago, Ulisse Wolf said:

More than anything else it is unclear this proposal because creating a system with 4 sub ranges I assume that in the 0xABCDEZTT the E value is the descriminant value for the biome

The 4 sub ranges I was referring to are the assigned texture ranges for the Arctic, Desert, Temperate and Tropical terrain types, the TT value in the above scheme.

[Ulisse Wolf 4,461]

6 minutes ago, Null 45 said:

The 4 sub ranges I was referring to are the assigned texture ranges for the Arctic, Desert, Temperate and Tropical terrain types, the TT value in the above scheme.

One of the problems I found that the textures in the current mods all have overlapping IIDs (TT) creating conflicts even with the logic that Maxis had developed. For this reason, I wonder if it makes more sense to use a discriminant value that varies by biome

[Null 45 3,118]

1 hour ago, Ulisse Wolf said:

One of the problems I found that the textures in the current mods all have overlapping IIDs (TT) creating conflicts even with the logic that Maxis had developed. For this reason, I wonder if it makes more sense to use a discriminant value that varies by biome

Are you referring to how all terrain mods created before the Extended Terrain DLL use the Tropical IID range? Of course, even keeping the Tropical IID range would require renumbering all textures to add the prefix. But that does save the hassle of changing the wealth and IID portion.

SC4 doesn't care about the biome names that Maxis defined, only the accompanying IID ranges. I think the biome is user-data that can be communicated using the terrain mod name and/or section prefix. It does not need to be encoded in the IID of the textures.

[Ulisse Wolf 4,461]

42 minutes ago, Null 45 said:

Are you referring to how all terrain mods created before the Extended Terrain DLL use the Tropical IID range? Of course, even keeping the Tropical IID range would require renumbering all textures to add the prefix. But that does save the hassle of changing the wealth and IID portion.

SC4 doesn't care about the biome names that Maxis defined, only the accompanying IID ranges. I think the biome is user-data that can be communicated using the terrain mod name and/or section prefix. It does not need to be encoded in the IID of the textures.

Actually mods like Cycledogg Terrain and Gobias Terrain mods (Just to name a few) do not respect the tropical range IID (TT) but go to occupy half of the range 00 - FF creating quite a logistic chaos.

So I assume that with the new format I can say to load two terrain mods that have the same TT but thanks to ABCDE they will have different IIDs and I have to specify it like this

TerrainMod1=0xABCDE000

right?

[Null 45 3,118]

6 minutes ago, Ulisse Wolf said:

So I assume that with the new format I can say to load two terrain mods that have the same TT but thanks to ABCDE they will have different IIDs and I have to specify it like this

TerrainMod1=0xABCDE000

right?

Yes. There probably should be a registry for the IID ranges, similar to building styles, but that can wait until there is more feedback on the format.

Terrain mods not following the Maxis ranges is not something I considered.

[Ulisse Wolf 4,461]

18 minutes ago, Null 45 said:

Terrain mods not following the Maxis ranges is not something I considered.

Unfortunately, this is a very common practice and that's why I'm trying to understand it. If ABCDE allows us to solve this problem then we can easily create the new terrain mods with minor changes to be made in the various texture packs

18 minutes ago, Null 45 said:

Yes. There probably should be a registry for the IID ranges, similar to building styles, but that can wait until there is more feedback on the format.

Probably the IID creator register should not interfere with the Texture Range IID register but before checking into this we wait for feedback

[Null 45 3,118]

On 1/9/2025 at 7:22 PM, Ulisse Wolf said:

Probably the IID creator register should not interfere with the Texture Range IID register

If the existing public texture ranges are always in the form 0xABCD0000-0xABCDFFFF, it would make sense to have 0xABCD be the user's assigned texture prefix. But I don't know if the publicly assigned texture ranges would always follow that format.

[Ulisse Wolf 4,461]

9 hours ago, Null 45 said:

If the existing public texture ranges are always in the form 0xABCD0000-0xABCDFFFF, it would make sense to have 0xABCD be the user's assigned texture prefix. But I don't know if the publicly assigned texture ranges would always follow that format.

The only one who can provide us with help is @rsc204, which is the Texture Range manager

[rsc204 21,866]

It really depends on what Group ID is used by the terrain textures. If that falls into the NAM (Game) textures 1ABE787D or LE textures 0986135E then there will be limitations on the possible ranges that you can be sure are free.

[Null 45 3,118]

31 minutes ago, rsc204 said:

It really depends on what Group ID is used by the terrain textures.

The terrain textures use 0x891B0E1A.

[rsc204 21,866]

If you stick to that GID you’d have pretty good flexibility since it doesn’t conflict with the game/LE textures.

But you should get an idea of all textures in the SC4 DAT files that use it. Compare that with all the IDs you know are in use and everything else is fair game. 

[Null 45 3,118]

1 hour ago, rsc204 said:

Compare that with all the IDs you know are in use and everything else is fair game.

Done. There are 42 textures that could be a potential conflict with the upper 16 bits of the id, which is more than I expected.

Spoiler

0x08F6
0x0918
0x095A
0x0990
0x0999
0x0A05
0x0A0B
0x28EB
0x28F7
0x292C
0x2A05
0x4A05
0x695C
0x699C
0x69EF
0x69F0
0x69F1
0x69F4
0x69F5
0x69F8
0x69F9
0x69FA
0x69FB
0x6A05
0x6A6C
0x6A84
0x88F7
0x8A05
0xA986
0xAA05
0xC990
0xC9EF
0xCA05
0xCA13
0xCA5C
0xE8EA
0xE8F7
0xE92C
0xE95A
0xE986
0xE9A4
0xEA05

I plan to document these values as reserved by SC4, and make my code treat them as invalid. That is much simpler than trying to detect a conflict with the full 32-bit texture id when I am assembling it at runtime.

[Null 45 3,118]

The documentation for the display name, texture redirect, and texture offset features is now up on GitHub.

I expect that there are probably more textures that could be added to the redirect system, but I don't know which ones to look into adding.