• 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.

Reminder to developers: don't overwrite terrain.cfg

Status
Not open for further replies.
JonPatch

JonPatch

Resource contributor
Messages
443
Country
ca-britishcolumbia
Developers like FSAddon and Ultimate Terrain have been careful when adding entries to the terrain.cfg to respect entries already in place. However we found one product that overwrites the file with the Ludowise-Feliz-Tirado terrain.cfg. This is a Bad Thing. They made a reasonable assumption that this would be the defacto standard. But that ain't the case, and it's not difficult to parse the file and add entries. Overwriting will corrupt all other addons that have custom terrain.cfg entries.

So, please respect the texture entries, and take the time to ensure your installer/configurator doesn't corrupt other addons if you choose to add entries.

Thanks for considering this,

Jon

EDIT: the developer in question has clarified that they don't overwrite the terrain.cfg, but OPTIONALLY replace it at the users discretion, while backing up the previous version. As well they document the process well for the users. The net effect on Vancouver+, Ultimate Terrain, Megascenery and other addons that add new entries to terrain.cfg is that they will not function properly if the user chooses this option. However with both Vancouver+ and UT (I don't know about Megascenery), a repair or other utility can be run to fix this up. As I said above, I think this developer made a reasonable assumption, and I want to work together to come up with a proposal I hope works for everyone.
 
Last edited:
Hi Jon.

Both Luis and I were aware of the dangers of changing the terrain.cfg file. We did it because the original FSX was deficient. We made the alterations in hopes that the Aces team would adopt our changes, as they correct some problems and add designer funtionality to FSX. They did not.

As I understand it, your installer will look for the altered terrain.cfg Luis and I made, and adjusts for it in your installation. I believe Ultimate Terrain does the same.

Unfortunately, the reverse is not true, and that causes the problem


The fact is, you, Holger and Allen have also altered the terrain.cfg... and now we do have a problem. Future designers may have their own alterations, and they will certainly complain about your alterations corrupting their addons... and they will call your installation a BAD thing. It's possible we could end up with dozens of terrain.cfg alterations. Your installation makes no consideration for future cfg changes that you cannot forsee, or of which you are not currently aware.

The Aces could have made the terrain.cfg unalterable... that would have been one solution. Or they could have made each Scenery folder capable of having it's own CFG file. Maybe FS11.

We could all agree to stop any alterations of the terrain.cfg, and use only the default. That is certainly also a solution, but just as you and Holger would not like this, so Luis and I do not like this.

I do not see a solution for this other than the endusers showing an above average awareness of the potential difficulty. All developers of scenery that has any altered form of the terrain.cfg file should state this in the boldest terms before the installation, and offer solutions to the problem. And all endusers should keep a log of changes made to their sim, as addon conflicts are not limited to the terrain.cfg file.

This problem will get worse as the sim ages.

Dick
 
Hi Dick,

It is a conundrum, isn't it? It seems we either greatly constrain our ability to enhance FSX, or deal with the issue.

However, as long as developers respect the existing terrain.cfg entries, I don't see an issue. Our alterations are simply additions to whatever entries are already there, and I don't see how they would restrict or affect any future addons. That's how we designed it.

Wouldn't it be easy to provide an installer for your excellent terrain.cfg additions, which respects whatever terrain.cfg the user has, and simply adds those entires, just as Vancouver+ and Ultimate Terrain do? (Those products co-exist fine)

Am I being simplistic? Is the issue more complex than I think?

I agree that awareness of this issue is important, for developers and users.

Jon
 
Hi guys,

I remember throwing a bit of a temper tandrum when I first learned how ACES had decided to handle the parameters associated with area and line textures: a global config file?????

Well, that's what we have and so we decided to make our alterations in the most fool-proof way we could think of: no changes to existing entries (new entries only), an auto-installer that reliably adds the entries regardless of which entries already exist (default or modified), and an in-built checking system that looks for corruption of the required packed-sequential numbering format (no duplicates, no gaps).

In short, our alterations do not corrupt anyone's changes or additions to the terrain.cfg file and we do not depend on the basic entries being in their default state either. If, in turn, some add-on overwrites our entries, then our users merely need to select the "repair" option of our auto-installer and our custom entries will be added back in.

I'm with Jon: I don't see a problem with our approach. Perhaps a misunderstanding of what our configurator does?

Cheers, Holger

P.S.: The only alteration that the UT installer does in regards to the Ludowise/Feliz-Tirado modified cfg is to check for the incorrect RenderPriority parameter of Class 264 (the 20,000 vs. 200,000 issue). If it finds the incorrect value it will fix it, which is a good thing for any user.
 
Last edited:
Status
Not open for further replies.
Back
Top