• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

On manipulating the FSX terrain.cfg file


Resource contributor
Hi all,

not surprisingly, the issue of manipulating the global terrain.cfg file keeps coming up. Below are my thoughts and ideas about this matter, meant to continue discussion and exchange of ideas and approaches for dealing with the cfg file. Primarily, I'd like to focus on design features for auto-installers that can handle any number of product/user modifications "thrown at" the terrain.cfg in any possible order or combination. A truly modest goal, I know :D

I realize that what should be expected of a payware product can't necessarily be expected of freeware projects; coding auto-installers that include config tweaking is no easy task. Thus, perhaps we can also brainstorm about a freeware generic terrain.cfg tool that would take new custom entries supplied by the addon (in a defined format) and deal with them in the same manner as custom autoinstallers for commercial projects.

The Issue:

FSX uses a global terrain.cfg file (located in the FSX root folder) that sets key parameters for all polygon and vector textures and their associated autogen annotations. Unlike FS9, the only way us FSX developers can use our own textures for, say, streams, or alter the width of our roads, is by changing the corresponding parameters in this terrain.cfg file. Given that these changes have global effect it's obvious that changing default entries should be discouraged. The alternative is to provide custom entries and add these to the terrain.cfg file. However, since all entries need to respect the required packed-sequential numbering system (no duplicate texture numbers or gaps in the number's sequence) this approach raises questions as to how the modifications of different projects or developers can all be combined into a single working terrain.cfg.

Adding entries to the terrain.cfg file:

The process of adding custom entries to the terrain.cfg is pretty straightforward and explained in the "Terrain Configuration File.html" document of the FSX Terrain Software Development Kit (SDK), included with FSX Deluxe. Obviously, the new entries themselves need to have correct parameter specifications, including a unique GUID associated with each entry. Other than that only the [Texture.xxx] line of each new entry needs to respect the packed sequential numbering format (no duplicates or gaps) and the "DefaultTextureCount" value in the [General] section need to reflect the new total number of entries. Slightly different rules apply for new vector autogen entries (sections [Autogen.x.x.x] and counter "AutogenCount"); see the information about the [General} section in "Terrain Configuration File.html".

Known limitations:

It is possible that there is a limit to the overall number of entries allowed in the terrain.cfg. However, the SDK doesn't mention this nor am I aware of anyone encountering such a limitation (yet). Similarly, there may be issues in regards to FSX performance or display with increasing numbers of terrain.cfg entries. Again, I'm not aware of such issues. However, we should be aware that these or other limits may exist and should try to test for them, wherever possible. Those knowable unknowns, you know? :rolleyes:

Proposed specs for a "neutral" auto-installer for adding/removing custom terrain.cfg entries:

For me, a key requirement of any terrain.cfg auto-installer is that it respects the integrity of the existing terrain.cfg. That means that the developer should make no assumptions as to what the user's terrain.cfg should contain. Instead, it merely adds the new entries to any existing state of the config file (provided it isn't internally corrupted) and removes them safely upon uninstallation. In other words, the new entries form a parallel set of cfg entries inside the existing terrain.cfg.

A second key requirement is that we cannot assume that the "average" users are willing or capable of making manual adjustments to their terrain.cfg file. As Jeff ("Quantumleap") posted elsewhere: "They will not know one exists, they will not know where it is, they will not know what it does and they will not understand what will happen if you change it. Also, no matter the amount of documentation provided to the end user, the majority will still not understand, and again, they should not need to."

What follows is the proposed list of installer features that is based on those two key requirements:

* a safety backup of existing terrain.cfg, either with a name that indicates which product made the backup or to a cache folder inside the project's scenery folders

* initial check for correct packed-sequential numbering of the existing entries, correcting any mistakes found. This is a required feature because adding a new block of entries to an already corrupt terrain.cfg won't work anyway

* correctly adding the block of new entries to the existing terrain.cfg. The physical location of the block inside the terrain.cfg doesn't appear to be of concern as long as the overall packed-sequential format is met

* a repair function that doesn't require a re-installation of the product should the user .cfg file become corrupted. This can either be a repair option in the auto-installer (as implemented by our Vancouver+ FSX), or, if applicable, a background check tied to the configurator utility (e.g., as implemented by Ultimate Terrain FSX)

* clearly advising the users about changes made to the terrain.cfg, how to detect situations that indicate that something is wrong with the terrain.cfg, and what to do in those cases (repair, reinstall, forum posts, etc.)

* upon uninstalling, correctly removing the custom block from the current terrain.cfg file, even if other add-ons with custom entries were installed afterwards (i.e., the ability to renumber other blocks of custom entries to fill gaps)

* removal of the safety backup to prevent clutter (and confusion) in the FSX folders


The "special case" of the Richard Ludowise/Luis Féliz-Tirado modifications (RL/LFT mods): fsx_modified_terrain_cfg.zip, at AVSIM http://library.avsim.net/esearch.php?CatID=fsxscen&DLID=93289

Richard and Luis started working on changes to the default terrain.cfg while FSX was still in Beta. Their initial motivation was to check for mistakes and inconsistencies in the Beta versions so that ACES could correct these prior to the release of FSX. Unfortunately, from their fairly long list of proposed changes ACES integrated only a few into the retail version of FSX (and no further changes in SP1), which prompted the two to upload their modified version to AVSIM and elsewhere.

The complete list of changes is listed in the read-me file of fsx_modified_terrain_cfg.zip.

It was the hope of Richard and Luis to have the community (both users and developers) adopt their modifications so that everyone benefited from the fixes and that developers had already a number of changes and additions to work with, minimizing the need for additional changes to the cfg file. However, it appears that these wishes have not been fulfilled. One the one hand, while many thousand FSX users have downloaded the RL/LFT mods there are many more that haven't (and there's some confusion as to whether the mods are still useful post-SP1; the answer being yes). Also, developers, including myself, have found the need to add new entries to the terrain.cfg in order to regain or exceed the options we had with FS9.

One reason why I decided not to include the RL/LFT mods into our own auto-installer (i.e., FSAddon products) is that the mods don't match with the key idea of being "neutral". For example, one of the main changes of the RL/LFT mods is that it suppresses the new FSX feature to automatically change water textures to rock textures on slopes steeper than a specific threshold. What if a user prefers the original FSX approach? Yes, the user can make these changes manually but that is awkward and error prone (and may be reversed upon re-installing or by error-checking codes). The alternative is to make the treatment of water textures an option, giving the user the choice upon installation. However, this requires additional installer code and user education.

Instead, I would prefer that the RL/LFT mods themselves are re-issued in the form of a "neutral" auto-installer as outlined above. Like I said, I don't expect this of a free contribution but perhaps one of our installer "gurus" can jump in or we can raise the funds to hire someone to write a generic tool for the freeware community. This tool would be able to install/unisntall external sets of custom entries supplied by an addon (in a defined format) and at the same time could include the RL/LFT mods as a basic install option.


Any feedback and ideas are welcome. I'd appreciate if we could keep this discussion technical, free of arm waiving and finger pointing :duck: I don't think it's reasonable to expect that the outcome of this discussion will be a single standard endorsed by all users and developers; in fact, I do not believe in standards for FS design, full stop, since many of the most innovative and popular add-ons don't adhere to SKDs or standards. Rather, I'd like this to be an educational thread, with people sharing ideas and commenting on ideas of others.

Kind regards,
Holger Sandmann


Resource contributor
Excellent summary of the issues, Holger, at least as I understand them. I look forward to a constructive dialog on this issue that results in a transparent user experience, and clear guidelines for developers to consider.

In particular I like the idea of a neutral installer for the so-called RL/LFT mods, and willing to support it's creation in whatever way I can.

Hi all,
I just started messing a bit with the terrain.cfg file (not much success yet), so this thread comes just in time.
I fully agree with Holgers list of requirements for an installer program. I already thought about including this type of functions in a newer version of my "Scenery Configurator", and I must admit that I didn't have such a comfortable thing in mind.
What I would like to add here is:
* the numbering system (or more exact: the "count" entries) in terrain.cfg is/are quite exceptionally compared to scenery.cfg and aircraft.cfg files - I would not really "count" on that, especially when it comes to corrupted files.
* all FS cfg files are readable via standard INI file functions (at least in Delphi) which makes reading and writing of complete sections easy
* as far as I know, the cvx BGL-files do not contain landclass or vector index numbers (the "n" in [texture.n]) any more. Instead, the required guid entries are contained as list in the beginning of these cvx files.
This means installing a new texture (or autogen) feature to terrain.cfg could be done by previously checking for a already existing guid - if nothing is found, a new [texture.n] section will be added. I imagine the following procedure:
- Addon scenery should provide a terrain.cfg file with all required NEW entries, starting section numbering with 0.
- The FSX terrain.cfg is searched for existing guids and the number of sections is counted. This gives the next free index (if the identifiers are unique and none is missing), and all the new sections will be written with simply shifting the section number n.
- Removing or uninstalling could be done by referencing guids as well. The problem I see here is that different add-on sceneries might use exactly the same texture definitions (and guids!) - which is reasonable to keep file size low. Maybe FSX won't bother about introducing a counter entry for each [texture.n] section. If this number is greater than 1, the section will not be deleted on deinstallation, only the counter will decremented - this procedure would be similar to the DLL handling in the windows registry.



Here is a first draft of a small application to automate manipulation of terrain.cfg: http://tml.pp.fi/fsx/TerrainCfg.cs

terraincfg -a addon.cfg
to add textures and autogens from addon.cfg to terrain.cfg, and
terraincfg -r addon.cfg
to remove textures and autogens listed in addon.cfg from terrain.cfg.

The sequence numbers of textures and autogens in the addon file aren't meaningful, textures and autogens will be renumbered when output anyway.

(If you browse the code, you will see that it doesn't actually rewrite the terrain.cfg as for now, it just outputs what the updated version should look like to stdout.)

Hmm, I now notice that I don't have code there to update the DefaultTextureCount and AutogenCount entries. That's easy to fix, will do that later... (I said it was a first draft...)

I haven't been programming in C# for long, so bear with me if I use wrong C style idioms.



Resource contributor
Great job! Our automated installer has another feature you may want to add: when done it scans the output file and ensures that all entry [xxx] numbers are sequential, in case something else has messed with them (like the user manually editting them).

hi all

The idea of a neutral installer for the so-called RL/LFT mods was really rocking...

still many more practical illustrations are giving more ideas to implement..

i can jus say that its simply world class:)