Jump to content
Sign in to follow this  
Farlis

New Scenery.cfg conventions?

Recommended Posts

So I installed my first FSDT airports into P3Dv4 with their new installers. They show up fine. 

But then I wanted to rearange my scenery.cfg. In P3D istself their entries are greyed out and can't be selected. I then opened the scenery.cfg both in notepad and with scenery.cfg editor. The entries don't show up in the document.

Yet they are still active in the sim. It's magic. But I don't want them sitting at the top of my scenery library. So where are the entries? How do I edit them?

This is all so confusing.

Share this post


Link to post

yes. This morning on FSDT forum, related to KCLT questions, Umberto explained that he followed new conventions and laid out by LM. Greyed out sections can be edited via the options menu. Scenery that follows the new convention does not show up anymore in the scenery.cfg.

FSDT forum seems to be down but I guess there might be info on other fora as well.

b rdgs / Dick

=

 

Share this post


Link to post
11 minutes ago, dick said:

yes. This morning on FSDT forum, related to KCLT questions, Umberto explained that he followed new conventions and laid out by LM. Greyed out sections can be edited via the options menu. Scenery that follows the new convention does not show up anymore in the scenery.cfg.

FSDT forum seems to be down but I guess there might be info on other fora as well.

b rdgs / Dick

=

 

Thank you. I noticed that FSDT forums are down, that's why I asked here.

Now lets see if I can get this to work.

 

Hmmm... I can switch them on and off. But one can't change the priority. The problem I have here is that I also use the FSAeroData Navigation Data. This comes with the most recent ILS and Comm frequencies. But they have to have a higher priority in the scenery library to overule outdated scenery data.

Share this post


Link to post

First, be VERY careful opening the scenery.cfg, because in P3D V4, it's encoded in Unicode ( UTF-16LE ) so, if your editor doesn't support that, you risk destroying it or, if the editor or utility somewhat converts it into Ansi, it might confuse other (proper) utilities that expect the file to be Unicode. Notepad it's safe, because it handles Unicode just fine, but this might not be always the case with 3rd party utilities.

Having said that, what you are looking at is clearly not magic, but it's the official and suggested way of installing any addon into the sim, starting with Prepar3d 3, and which was subsequently improved in 3.3.

With V4, we took the chance to switch to this vastly superior method, which has quite a bit of advantages so, once you'realize them, you won't ever want to go back to the dark ages of the old ways.

- With a centralized scenery.cfg file, the risk was always too great that, either users or rogue installers would cause problems to it, and the usual result was that other installers, even if not bugged as such, might be easily confused by a corrupted scenery.cfg, and this always cause a lot of grief, because the .INI format (the scenery.cfg IS an .INI) is a inherently fragile standard, and it's too easy to mess it up, also considering there's not even a recognized or enforced standard about what is a comment on an .INI file. It's just a convention (on Windows), to use a semicolon, but some use the // c++ style, some the # style, and everything might work or not, depending how the file is parsed. It was a mess.

Using the new installation system, an add-on can add its own Scenery, Texture, Effects, Sounds, Simobjects DLL/EXE files using its own private configuration file, called add-on.xml, which can be located anywhere, but it's suggested that all addons should place their own into their own sub-folder, located under Documents\Prepar3d v4 Add-ons folder.  Sceneries added this way, will appear in the Scenery Library greyed out, as you have noticed.

I'm not entirely sure of the reasons why LM has decided to prevent you from rearranging sceneries added this way, but I'm sure there are. It IS possible, however, to specify a Layer, but right now it requires editing the add-on.xml file for the affected file, adding a Layer attribute, with a number. This is all explained in the P3D Help file, under the SDK section, the explanation of the Add-ons package file format.

Since it's also possible to specify dll and executables, this removes the need for any installer to have to deal with the centralized DLL/EXE.XML files so, no chance that a bugged installer would cause issues to another product modules, which happened too often.

Same for Simobjects: if a product needs its own Simobject folder, it can be specified there so, again, good bye to addon not working anymore, because some rogue installers or an user mistakenly removed one of the default Simobjectspaths line in the FSX/Prepar3d.CFG file.

This has also the added advantage that, you can reinstall the sim, and even clean up all the default configuration files, and all your installed add-ons (those installed that way, of course) will continue to work, without having to be reinstalled! A big feature, which for me is worth alone the minor annoyance of having to learn a new system.

Really, the new system is so much better, that I can only hope that LM would consider dropping the old method entirely for the next major version, once all 3rd party developers will realize the benefits.

  • Upvote 7

Share this post


Link to post

KCLT worked for me.. but all of my other FSDT and Flightbeam sceneries had the missing building syndrome. Also GSX did not work anymore.. and this was all in P3D V3.4. Haven't touched V4 sofar.

Share this post


Link to post

If KCLT works and the other don't, it seems to indicate something was wrong during the migration process, which in fact further proves my point that having to deal with the scenery.cfg was a mess, since you cannot be sure this file would be entirely clear.

The KCLT installer, while migrating, will have to deal (for the last time) with the scenery.cfg, removing all the previous entries for FSDT ahd Flightbeam sceneries to move them to the new standard so, a problem with it might have resulted in an incomplete migration.

The migration was made just to save users time, otherwise we would have had to force everybody to Uninstall everything, re-download everything and reinstall everything, when little really changed in the actual sceneries, and it surely works most of the time.

If it didn't work in your case, you always have the option to install normally, by downloading again all the updated installers, and install them.

Share this post


Link to post

Thanks for your in depth explanation Umberto.

I remembered that Lockheed had introduced this new system for v3, but next to no one of the add-on developers seemed to adopt it.

I really hope that more companies will go this route when they update their installers for v4.

And I want to add that I really appreciate you updating the installers that quickly. I really wished other companies were as fast (I'm looking at you Aerosoft!).

  • Upvote 1

Share this post


Link to post
54 minutes ago, virtuali said:

First, be VERY careful opening the scenery.cfg, because in P3D V4, it's encoded in Unicode ( UTF-16LE ) so, if your editor doesn't support that, you risk destroying it or, if the editor or utility somewhat converts it into Ansi, it might confuse other (proper) utilities that expect the file to be Unicode. Notepad it's safe, because it handles Unicode just fine, but this might not be always the case with 3rd party utilities.

Having said that, what you are looking at is clearly not magic, but it's the official and suggested way of installing any addon into the sim, starting with Prepar3d 3, and which was subsequently improved in 3.3.

With V4, we took the chance to switch to this vastly superior method, which has quite a bit of advantages so, once you'realize them, you won't ever want to go back to the dark ages of the old ways.

- With a centralized scenery.cfg file, the risk was always too great that, either users or rogue installers would cause problems to it, and the usual result was that other installers, even if not bugged as such, might be easily confused by a corrupted scenery.cfg, and this always cause a lot of grief, because the .INI format (the scenery.cfg IS an .INI) is a inherently fragile standard, and it's too easy to mess it up, also considering there's not even a recognized or enforced standard about what is a comment on an .INI file. It's just a convention (on Windows), to use a semicolon, but some use the // c++ style, some the # style, and everything might work or not, depending how the file is parsed. It was a mess.

Using the new installation system, an add-on can add its own Scenery, Texture, Effects, Sounds, Simobjects DLL/EXE files using its own private configuration file, called add-on.xml, which can be located anywhere, but it's suggested that all addons should place their own into their own sub-folder, located under Documents\Prepar3d v4 Add-ons folder.  Sceneries added this way, will appear in the Scenery Library greyed out, as you have noticed.

I'm not entirely sure of the reasons why LM has decided to prevent you from rearranging sceneries added this way, but I'm sure there are. It IS possible, however, to specify a Layer, but right now it requires editing the add-on.xml file for the affected file, adding a Layer attribute, with a number. This is all explained in the P3D Help file, under the SDK section, the explanation of the Add-ons package file format.

Since it's also possible to specify dll and executables, this removes the need for any installer to have to deal with the centralized DLL/EXE.XML files so, no chance that a bugged installer would cause issues to another product modules, which happened too often.

Same for Simobjects: if a product needs its own Simobject folder, it can be specified there so, again, good bye to addon not working anymore, because some rogue installers or an user mistakenly removed one of the default Simobjectspaths line in the FSX/Prepar3d.CFG file.

This has also the added advantage that, you can reinstall the sim, and even clean up all the default configuration files, and all your installed add-ons (those installed that way, of course) will continue to work, without having to be reinstalled! A big feature, which for me is worth alone the minor annoyance of having to learn a new system.

Really, the new system is so much better, that I can only hope that LM would consider dropping the old method entirely for the next major version, once all 3rd party developers will realize the benefits.

Thanks for this description of the Prepar3D v4 Add-ons folder.

Maybe I missed something here.

But, does this means that all add-ons files (airplanes, airports and sceneries) have to go to c:\User\username\Documents\Prepar3D v4 Add-ons? That will certainly fill up the C drive very fast.

Or is it possible to relocate the Prepar3D Add-ons folder to another drive?


Roar Kristensen    www.flightsim4fun.com

P3Dv4 with Opencockpits hardware controlled by OC4BAv4 for immersive PMDG B737/777/747 flying

XPLANE 11 with Opencockpits hardware controlled by OC4BA_XP for immersive  B737 flying

rmMShli.jpg?1 WylQl0J.jpg?3

Share this post


Link to post
1 hour ago, roarkr said:

Thanks for this description of the Prepar3D v4 Add-ons folder.

Maybe I missed something here.

But, does this means that all add-ons files (airplanes, airports and sceneries) have to go to c:\User\username\Documents\Prepar3D v4 Add-ons? That will certainly fill up the C drive very fast.

Or is it possible to relocate the Prepar3D Add-ons folder to another drive?

No no, only the tiny add-on.xml is usually located there, but the actual files of the scenery can be anywhere.

So, assuming you are installing, let's say, FSDT KCLT and GSX, and chose an external drive as destination with plenty of space left, for example D:\, it will result in:

C:\Users\YOURNAME\Documents\Prepar3D v4 Add-ons\Fsdreamteam_AddonManager (GSX will use this)

C:\Users\YOURNAME\Documents\Prepar3D v4 Add-ons\Fsdreamteam_KCLT

Each one containing ONLY the small add-ons.XML file, with paths inside pointing all to D:\Addon Manager ( assuming you choose D:\ as destination ), and the actual files which take most of the space will then go in:

D:\Addon Manager\Couatl ( GSX and other script files )

D:\Addon Manager\fsdreamteam\KCLT\scenery

D:\Addon Manager\fsdreamteam\KCLT\texture

D:\Addon Manager\Simobjects\Misc\FSDT_KCLT

 

If you add Flightbeam KSFOHD, for  example, it will end up here:

 

C:\Users\YOURNAME\Documents\Prepar3D v4 Add-ons\Flightbeam_KSFOHD (just the small add-on.xml file )

 

D:\Addon Manager\flightbeam\KSFOHD\scenery

D:\Addon Manager\flightbeam\KSFOHD\texture

D:\Addon Manager\Simobjects\Misc\Flightbeam_KSFOHD

 

Need to reinstall the sim ? No problem, you can even clear up all the sim folders to do a completely clean reinstall. At the first startup of the sim, you will be then asked if you want to re-enable all your previously installed addons, with no need to reinstall them separately.

This is called "auto-discovery", and it's VERY easy and very convenient, and it works only if the add-on.xml were located in the Documents\Prepar3D v4 Add-ons\ folder, with each addon having its own sub-folder, containing its own add-on.xml.

  • Upvote 5

Share this post


Link to post

Helpful posts Umberto thanks.


i9 7920X @ 4.7  | MSi x299 Gaming Pro Carbon  | Gigabyte Aorus 1080Ti | 32GB DDR4 GSkill 3000mhz | 1 TB Samsung 960 EVO | 3TB Toshiba 7200rpm.

Share this post


Link to post

A developer doesn't have to use the auto-discovery either... they can explicitly tell Prepar3D to install an addon from it's own folder location.  This allows the user to install wherever they want (drive/path) and then the addon's installer tells Prepar3D where it is.

  • Upvote 1

Ed Wilson

Mindstar Aviation
My Playland - I69

Share this post


Link to post
3 hours ago, virtuali said:

First, be VERY careful opening the scenery.cfg, because in P3D V4, it's encoded in Unicode

Well, that's odd. UIt isn't here, and my MakeRunways is working fine on the file with no change apart from locating in in ProgramData\Lockheed Martin\Prepar3D v4.

4 hours ago, virtuali said:

Using the new installation system, an add-on can add its own Scenery, Texture, Effects, Sounds, Simobjects DLL/EXE files using its own private configuration file, called add-on.xml, which can be located anywhere, but it's suggested that all addons should place their own into their own sub-folder, located under Documents\Prepar3d v4 Add-ons folder.  Sceneries added this way, will appear in the Scenery Library greyed out, as you have noticed.

Ah, perhaps you are saying that these additional CFG files are in Unicode?

Currently MakeRunways doesn't know about these, so its files will be missing add-on airports which use this new method.

I'm afraid i won't have time for a while to modify the program. Too much to do with FSUIPC and ancillaries.

Pete

 


Win10: 22H2 19045.2728
CPU: 9900KS at 5.5GHz
Memory: 32Gb at 3800 MHz.
GPU:  RTX 24Gb Titan
2 x 2160p projectors at 25Hz onto 200 FOV curved screen

Share this post


Link to post
1 hour ago, WarpD said:

A developer doesn't have to use the auto-discovery either... they can explicitly tell Prepar3D to install an addon from it's own folder location.  This allows the user to install wherever they want (drive/path) and then the addon's installer tells Prepar3D where it is.

Not really.

Auto-discovery only refers to the fact that, if an add-on.xml file is found in a sub-folder of Documents\Prepar3d v4 addons, it will trigger a question from P3D about re-enabling it, even in case all default configuration files would be wiped out (clean reinstall), so users won't be required to re-launch any installers only to re-enable the addon in the centralized Add-ons.CFG, which is the file that Prepar3d.exe itself, when launched from the command line, usually by an installer, will modify.

But auto-discover doesn't hamper in *any* way the complete freedom to install the actual products file everywhere in the system. As I've said, it's only the tiny add-on.xml file that will be usually located in the Documents folder: what really matters are the various "Path" lines in the XML file, which can be absolute paths in every location, see my previous example.

So, to recap, with auto-discovery ( small add-on.xml file in the various Documents\Prepar3d v4 add-ons subfolders ), there will no need to re-run any installation utility after a clean reinstall, because the sim *itself* will prompt users to re-enable add-ons that have their add-on.xml under Documents.

Without auto-discovery ( small add-on.xml file located everywhere else ), after a clean reinstall of the sim, which assumes the existing add-ons.cfg file would have been reset, you would have to launch an installer again, or have users editing the add-ons.cfg manually to re-enable each addon, or have user learning how to call Prepar3d from the command line to use the various "Add" or "Remove" options available.

I fail to see the value of having the add-on.xml file located in a different folder, thus losing the auto-discovery feature, just to save a bunch of bytes. And, it's usually assumed that users, even after a reformat, would backup their own Documents folder, which means doing something potentially catastrophic, like a Windows reformat, shouldn't be *that* difficult, if you had all the addons configured by the Documents folder, with their own files installed on a separate drive, which is entirely possible with this setup.

A small note, which might not be entirely obvious is:

When an addon has been enabled using the Prepar3d config facility from the command line, which usually is done by an installer, the file affected will be located here:

%PROGRAMDATA\Lockheed Martin Prepar3d V4\Add-ons.CFG

But if an addon was re-enabled after a clean reinstall of the sim by auto-discovery ( P3D asked the user to re-enable an addon for which an add-on.xml was found in the Documents folder ), the file affected will be the one under %APPDATA%

%APPDATA%\Lockheed Martin Prepar3d V4\Add-ons.CFG

  • Upvote 1

Share this post


Link to post
31 minutes ago, Pete Dowson said:

Well, that's odd. UIt isn't here, and my MakeRunways is working fine on the file with no change apart from locating in in ProgramData\Lockheed Martin\Prepar3D v4.

Ah, perhaps you are saying that these additional CFG files are in Unicode?

 

The main scenery.cfg file is now, by default, encoded in Unicode. More precisely, it's UTF16LE, with the first two bytes being a BOM indicating Little-Endian, which is the most common kind of UTF16.

It might not have been a problem reading from it, if you used the standard Windows API function such as GetPrivateProfileString because, depending on your C++ project settings (Unicode enabled or not), they would be mapped to either the GetPrivateProfileStringW call (Unicode) or the GetPrivateProfileStringA (Ansi) version so, you might only use GetPrivateProfileString, but the compiler is compiling something else, which changes depending on the Unicode settings of the project.

If you have a project set as non-Unicode, so you are sure you are really calling the Ansi version of the API, then I'm afraid you are testing a scenery.cfg that, for some reason, is not default anymore, perhaps some installer or something else might have changed its encoding, but I assure you that, if you clean up all %APPDATA% and %PROGRAMDATA% folders for P3D, then you start it again, the default scenery.cfg will revert to its standard Unicode encoding.

 

Quote

Currently MakeRunways doesn't know about these, so its files will be missing add-on airports which use this new method.

I'm afraid i won't have time for a while to modify the program. Too much to do with FSUIPC and ancillaries.

Have a look at the Scenery_Addons.XML file under %PROGRAMDATA%\Lockheed Martin\Prepar3d V4 (or V3), it contains a list created by the sim itself, of all areas that have been added with the Add-ons.XML method so, any utility that needs to scan the Scenery Library completely, should first read all the areas in the scenery.cfg file, then add the ones found in the Scenery_Addons.XML to have a complete list.

Share this post


Link to post
3 hours ago, virtuali said:

No no, only the tiny add-on.xml is usually located there, but the actual files of the scenery can be anywhere.

I was a bit quick in accepting the proposed installation location under Program Files ( x86)) when installing KCLT and others.  I tried uninstalling and reinstalling, but I still can't choose another location with the subsequent install.

Any hint appreciated.

Btw. many thanks Virtuali for the quick update of your products!


Regards, Perry

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...