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
Help AVSIM continue to serve you!
Please donate today!

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?

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

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

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

 

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!

Share this post


Link to post
18 minutes ago, longrangecruise said:

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.

The trick is Uninstalling AND replying YES to the question "Do you want to remove the Add-on Manager?", which is made at the end. This will signal your intention to start again, and will clear up your initial choice, allowing to select a new global install folder for all FSDT products.

Share this post


Link to post

I may be misunderstanding the above (still need to install P3Dv4 and read the SDK), but am I hearing that if I wish to change priorities of one scenery over another I need to go to an .xml file and edit it... also make sure I save it as unicode?  What if I wish to disable a scenery for testing I can no longer "uncheck" it because that option is greyed out?

Share this post


Link to post
5 minutes ago, Clutch Cargo said:

I may be misunderstanding the above (still need to install P3Dv4 and read the SDK), but am I hearing that if I wish to change priorities of one scenery over another I need to go to an .xml file and edit it... also make sure I save it as unicode?  What if I wish to disable a scenery for testing I can no longer "uncheck" it because that option is greyed out?

To disable a scenery for testing, use the proper option in the UI: the "Add-ons" menu under the Options menu.

Yes, to rearrange the layering order of such sceneries added using the add-on.xml method, you must edit their add-on.xml and work and add/edit the Layer parameter. Right now, it's not possible from the UI, but it's possible that LM might add it as an option, if enough users request for it.

Share this post


Link to post

Whew... thx Umberto.  Had me worried for a moment.  P.S. - Luv your add-ons!

Clutch

Share this post


Link to post

Question for those in the know:

For those addons that rely on makerunways or otherwise scan the scenery.cfg file themselves to gather the necessary info, would it be sufficient as a stop-gap measure to place an "afcad" for those airports in an addon scenery folder that is then added to the scenery library in the old conventional way?

Share this post


Link to post
45 minutes ago, virtuali said:

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.

Strange, then, because my normal editor (UEDIT32) which CAN read either, definitely shows it as 8-bit ASCII.  I can check it in binary in any of sevceral ways, and it is defintielly ASCII.

47 minutes ago, virtuali said:

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.

Well, this is the same on 3 different PCs, two Win7 one Win10, which have had P3D4 installed on them from scratch and no scenery.cfg editing as yet on two of them. Perhaps the early betas of P3D4 set them so? But they've certainly not been replaced. But, true, I do not delete these things each time i do an update.

52 minutes ago, virtuali said:

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.

Okay. Thanks. And is that the priority order which P3D uses, with the last entries as highest, and layer numbers withing each one (r if omitted, just the order listed?).

This answers some questions about things I don't understand in the SDK Help. It's all getting too complicated for my 74-year old brain! I grew up programming valve computers! Like Abacus's compare to todays stuff, where, as if the hardware wasn't complicated enough, everyone insists on adding more and more complex file and library structures on top of it all. Ugh.

Pete

 

Share this post


Link to post
26 minutes ago, Pete Dowson said:

Perhaps the early betas of P3D4 set them so? But they've certainly not been replaced. But, true, I do not delete these things each time i do an update.

I think this might be possible, since I seem to have noticed this later during the Beta process, so it's possible they switched to Unicode some time during the Beta.

Note that, P3D V4 will be perfectly fine with a scenery.cfg encoded in Ansi! It works in either way, but that's also why it's very easy to fall for it, don't notice, and assume every old utility will surely work, when in fact it might not.

Try this:

- Move your existing scenery.cfg in C:\ProgramData\Lockheed Martin\Prepar3d v4 to a safe place, so the sim won't find it at the next start, and so it will recreate it from scratch.

- Open the newly created scenery.cfg with an editor, preferably an hex editor, so you know without any doubts what you are looking at, and you'll see it's definitely Unicode, with the FFFE BOM mark at the start, indicating Little Endian, and 2 bytes per character, which indicates UTF-16.

If you want a quick fix, you might want to reuse our method, which of course requires users having installed at least one FSDT product, and just read this file:

%PROGRAMDATA%\Virtuali\Couatl\prepar3dv4\scenery.cfg

Which contains our own version of the scenery.cfg, which will list ALL scenery areas, regardless if they are located in the scenery_addons.xml, or if they were in the main scenery.cfg of the sim, all in a single list, encoded in plain old Ansi, and ready to be used...the Addon Manager will keep the list always current, checking the md5 of both the main scenery.cfg and the scenery_addons.xml, and updating this one only if one of them changes.Note that, there will be several copies of it, for each installed simulator:

%PROGRAMDATA%\Virtuali\Couatl\fsx\scenery.cfg

%PROGRAMDATA%\Virtuali\Couatl\fsxse\scenery.cfg

%PROGRAMDATA%\Virtuali\Couatl\prepar3d\scenery.cfg

%PROGRAMDATA%\Virtuali\Couatl\prepar3dv2\scenery.cfg

%PROGRAMDATA%\Virtuali\Couatl\prepar3dv3\scenery.cfg

%PROGRAMDATA%\Virtuali\Couatl\prepar3dv4\scenery.cfg

Of course, under P3D V1 and V2 and FSX, this would be basically a copy of the original scenery.cfg, while on V3 and V4, will contain also the areas added in the new way.

It might just be easier to code to use this file if it's there, and use the normal scenery.cfg, if it's not.

Share this post


Link to post

Elaine from LM pointed me to this thread after I posted the same issue in the P3D forum the OP posted in this thread.

I gotta say after reading this thread so far, I can't remember seeing such a user UN-friendly fiasco in my 3 decades of flight simming.  Who on earth thought that a user wouldn't have to STILL prioritize their Scenery Library entries?  And that making the user do a MANUAL edit of EACH addon's XML file would be the way to do it in P3Dv4?  For EVERY Scenery Library entry?  That is what WOULD have to be done if Virtuali is saying they used the RECOMMENDED way to install addons.  If that is true, and if EVERY addon developer did it that way, then ALL addons in the Scenery Library would require a manual XML edit to re-prioritize their layer number EVERY TIME a new scenery was added to the Scenery Library.

I'm not sure how any of this can be (quote) "...the official and suggested way of installing any addon into the sim...(it is a) 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...".

How is changing a "Push a button to prioritize a Scenery Library entry" to "Oh, hey...just manually edit all of the XML files for your Scenery Library entries" NOT a Return to the Dark Ages???  The "old ways" were a lot easier than now.  :laugh:

 

PS - BTW, the new FSDT and Flightbeam P3Dv4 installers?  They not only did all of the above to my P3Dv4 installation, but when I followed the "suggestion" to use them to "update" my P3Dv3 installation, they did the SAME things to all the airports in my P3Dv3 install.  I can't move the airports around in the P3Dv3 Scenery Library anymore because none of the GUI buttons work THERE for them anymore either.  DUH!  :cool:

  • Upvote 1

Share this post


Link to post

Is it not possible to just copy the entries from the V3 scenery.cfg to the V4 scenery.cfg and save it under the UTF-16?

Share this post


Link to post
17 hours ago, virtuali said:

If you want a quick fix, you might want to reuse our method, which of course requires users having installed at least one FSDT product, and just read this file:

%PROGRAMDATA%\Virtuali\Couatl\prepar3dv4\scenery.cfg

Which contains our own version of the scenery.cfg, which will list ALL scenery areas, regardless if they are located in the scenery_addons.xml, or if they were in the main scenery.cfg of the sim, all in a single list, encoded in plain old Ansi, and ready to be used...the Addon Manager will keep the list always current, checking the md5 of both the main scenery.cfg and the scenery_addons.xml, and updating this one only if one of them changes.Note that, there will be several copies of it, for each installed simulator

Very nice! How about I buy that chunk of code from you to build into my (free) MakeRunways? :-)

Or of course I could tell everyone they MUST buy an FSDT product! ;-)

Thanks!

Pete

 

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