Addon Scenery

[rwcatherall]

I'm a little confused regarding the correct method to add scenery. It's my understanding that the preferred method is the XML method which I've used. However if this is the case why does 'World->Scenery Library->Add Area...' continue to use the old method of writing to the 'scenery.cfg' file? So which is the preferred method XML or Add Area via the World->Scenery Library??

Robert Catherall

[Poppet]

Hello Robert

Going forward the preferred method of launching your 3rd Party Software is to utilise the add-on.xml system.

Quite a number 3rd Party Software developers are already using this method to launch there software

Many developers are still using the previous way and you also have the Option of manually adding your Scenery via World > Scenery Library > Add Area. When you add your Scenery this way an entry will show in your scenery.cfg

[kernowuk]

Poppet,
Continuing discussion regarding add-on scenery, I haven't seen this question asked, but maybe I missed it.

Is there any way to dictate the order in which the xml added scenery and the cfg added scenery combine?

For instance, I have xml add-ons dotted at random through my scenery library, when I would like them all in one place in the order, as certain sceneries need to be loaded higher or lower than others.

Thanks

Steve Marks

[Poppet]

Hello Steve

For a simple Scenery you can manually add an entry Layer like this <Layer>114</Layer> The below scenery will now sit 114 entries from the bottom of the Scenery library

You can adjust this Layer number to whatever you wish

<AddOn.Component>
<Category>Scenery</Category>
<Path>C:\MyTraffic Professional\MyTraffic</Path>
<Name>MyTrafficScenery</Name>
<Layer>114</Layer>
</AddOn.Component>

</SimBase.Document>

======================


There is also a free add-on.xml Organizing Tool you can download and Install

Click the link below and Scroll down to Lorby Prepar3D V4 Addon Organizer

For best results please read the Included Instructions

http://lorby-si.weebly.com/downloads.html

[FSTramp]

Scenery.cfg is the primary way around sceneries. All other methods are nonsense and make the matter unclear and lead to errors. FSTramp only supports Scenery.cfg

[mdata]

Hi,

First of all thank you for bringing P3Dv4 64bit to us. Finally we can simulate long haul fligths with a complex aircraft, between complex airports with complex graphics settings without the fear of OOM'ing. A dream has simply come true!

Now, I absolutely acknowledge the need for change and especially the need for changing the location where add-ons should be installed within P3Dv4 and future versions. This makes sense for any type of add-ons, except the ones of course that aim at increasing the immersion by e.g. altering base textures.

However, IMHO the one thing that does not seem to be fully thought through currently is managing scenery layering. I know that this has been mentioned already a couple of times here in the forum as well as in other places. But I have not yet seen (or have it maybe overlooked?) any trustable statement that the current situation would be worked on with the ultimate goal to make scenery layering manageable again.

I am now struggling since the release of v4 with the question of how to keep my scenery add-ons organized for overview, performance and functionality reasons.

I seem to fail to see where the new 'add-ons.xml-method' should be superior to the old 'scenery.cfg-method' - if we speak about adding scenery objects such as meshes, landclass, regions or airports.
The 'old' method allowed installation of add-ons outside the P3D root folder just as well. Alternate locations for effect, sound or gauge files could be specified in the effects.cfg, sound.cfg, etc. files in C:\ProgramData\Lockheed Martin\Prepar3D v3. It would be easy to move these files into the respective folder in C:\Users\...\AppData\Roaming\Lockheed Martin\Prepar3D v4 so to not needing to touch them when the simulation platform would neeed to be reinstalled. Configuration of the scenery order, enabling or disabling of series of scenery add-ons could still be done using the P3D built-in Scenery Library Editor if the scenery.cfg file would as well switch location to \AppData\Roaming\....

Currently with v4 we have multiple configuration files spread over multiple locations: add-on.xml files for each add-on, add-ons.cfg files in multiple folders, a scenery_add-ons.xml file and last but not least the scenery.cfg file. Is this really easier to manage? Again, sorry but I miss the point. The current state with the 'old' world and the new method coexisting and more interfering with each other than supportingly going hand in hand seems and feels like a big mess to me.

Now, what we as the customers miss (at least I do miss it feverishly) is a user interface to be able to again manage, sort, layer, enable and disable scenery objects, like we were used to it before. This should be an easy thing to do for a company that managed to transform the old ESP engine into a new shiny 64bit racehorse.

I have tested Lorby's tool and unfortunately it could not convince me. It did not manage to sort the library to my satisfaction; after a couple of additions and removals the layering got screwed up and the tool could not remove its own backup files anymore. But please do not misunderstand me; I am not criticizing Lorby's work. I acknowledge that this software is still in beta and that for simple scenery additions it served me very well. It even helped me understanding how this new add-on.xml system is supposed to work. This is the first step to pulling myself out of this mess.

Apologies for this lenghty burst of self-pity ... instead let's be serious and start to dream ... I think, I hope, that how we manage the scenery add-ons today with v4.0 is only a transition to a sophisticated P3D built-in add-on management system that will handle scenery add-ons - regardless their type - with drag-and-drop action, full flavor editing capabilities and will be based on tiny super-fast database system that diminishes P3D startup times to a flinching eye-blink.

Please?

Cheers
Frank

[vgbaron]

@FSTramp - everyone is entitled to their opinion. For now, both methods are in effect. When there is only one, I will only use products that comply.

@mdata - you sirt of hit the nail on the head - this is a transition period - more so than V3 - AND would expect that by V5 LM would REQUIRE the add-on method of installation. I would also expect that whether it be a polished Lorby tool or a custom interface from LM - the methods of implementation will be there.

IMHO, LM is in the business of making a sim. They have developed a darn good SDK so my bet is they leave an installation tool to the third party developers.

Vic

[WarpD]

I am going to point out something that is missing in this discussion. The end-user isn't the one who is supposed to be dealing with this. It's the developer who is supposed to set up their installer to properly install using the correct methods as desired by Lockheed-Martin.

[mdata]

Hi,

If it would be my project a standardized process of add-on installation would come as early as possible. Else most of the forum discussions and support effort will deal with issues that come from add-ons fighting with each other because of unclear rules and methods for their installation.
Phew, luckily I got my own projects with a much smaller customer base with all of their own beauty and quirks, so it's easy for me to talk ... ;)

For the moment I understand that the add-on.xml files in user-documents must be read first, since P3D uses them to auto-detect freshly added scenery. But then there is the add-ons.cfg files in ProgramData\... and in AppData\Roaming\... and there it seams to me that there is no clear rule which takes precedence over the other.

For instance I added my FlyTampa Munich and Seattle sceneries with the add-on.xml method and put the two components for Seattle and the three that came with Munich each into a separate add-on.xml file in Documents\...\P3Dv4 addons. So I can 'disable' the one or the other depending on the region I intend to fly into.
After the new sceneries have been detected by P3D on the next startup it has added them to the respective configuration files, so far so good. Add-ons.cfg in ProgramData and scenery_add-ons.xml are populated automatically.
Now, FSDT has installed their scenery similar but not exactly the same. They did the detection part for us users (I believe) but entered their scenery in add-ons.cfg in user\appdata\roaming\...
So, we have two add-ons.cfg files in different locations that are merged on startup of P3Dv4. Consequently the addition of scenery to the global scenery library (a marriage of scenery_add-ons.xml + scenery.cfg) seems to happen somewhat arbitrary to me. The scenery order now shows something like

...
FSDT KLAX
Seattle KSEA
FSDT KMEM
Seattle Terrain
FSDT KLAS
...

And of course entries made in scenery.cfg show up below other items that where added via the xml method.
I am still learning and I wonder if the <Layer> tag is really used or if it is ignored. And, I wonder how P3Dv4 resolves the conflict if there is conflicting layers in scenery.cfg and scenery_add-ons.xml?

My take away is that centralization of the scenery configuration is key and the longer LM would wait with this move the bigger our pain with scenery management would grow. Anyway we would need to reinstall all scenery to make it register via the new and only method when it will be released as a standard sometime in the future. So, IMHO it is a pity to not have gone this extra mile to solidify this interface before the release of v4.

Alas! Let's live happily with what we have already - it's definitely a great simulator! We can already enjoy OOM-free flying while we wait patiently for the things to come ;)

If in the meantime someone could confirm or correct my assumptions on scenery conflicts and how P3Dv4 actually resolves them I would be very, very happy.

I am going to point out something that is missing in this discussion. The end-user isn't the one who is supposed to be dealing with this. It's the developer who is supposed to set up their installer to properly install using the correct methods as desired by Lockheed-Martin.

Yes, I totally agree if it comes to the question of adding payware scenery. But the end-user wants to add freeware scenery too, or scenery he/she created on their own. These people cannot be asked to create installers. But they should be given again a standardized method of installation and built-in tools to manage scenery content.

Cheers
Frank

[pmb]

Frank, yours is a great contribution which definitely doubles some of my experiences and questions in this respect. I am a beta tester of two programs being faced with the new addon organization and there is a lot of confusion, not so much about the "old" or "new" method of adding addons as such but their interplay.

I fully agree LM has done a great job with version 4, however, this double-life of addons plus scattering of prepar3d core, addon, and countless configurations files all over the machine now is a major source of trouble - for the addon maker as well as the end user alike.

I hope someone from LM will read your text and take care.

Kind regards, Michael

[virtuali]

Scenery.cfg is the primary way around sceneries

Scenery.cfg used to be the primary way to add sceneries, in order to offer some backward compatibility with older version of the sim. But the new method, which has been introduced in P3D V3, is WAY better.

All other methods are nonsense and make the matter unclear and lead to errors.

It would best if you took some time to read the P3D SDK, which has an entire new section dedicated to the add-on packages.

I'll list some advantages of the new system:

Custom Folders

- The scenery.cfg method ONLY allows to add a folder for a scenery, and force to use a folder structure containing a \SCENERY and \TEXTURE. If a scenery required some Effects or Sounds, you are forced to add those in the core folders of the sim.

- The Add-on.xml method allows each scenery to have its own Scenery, Texture (which can be anywhere), Sounds, Effects, Autogen, Scripts, Shaders, DLLs, and more, which won't require to add anything to the main folders of the sim.

Reinstallation and auto-discovery

- If you added a scenery using the scenery.cfg, if this file is lost/corrupted or you want to do a clean reinstall for any reason, you will have to add again ALL your areas added this way, either manually, or by running ALL the scenery installers again, if required.

- Instead, sceneries added with their own add-on.xml, won't be affected by the complete reinstall of the sim because, when you restart the sim for the first time, it will ASK if you want to reactivate all the sceneries installed that way, provided the add-on.xml has been placed in the suggested location, which is under Documents/Prepar3d V4 addons.

And note that, ONLY the add-on.xml will go in that folder, NOT the whole add-on! That's a tiny file and, we can assume that, if you clean-reinstall the sim, you won't remove your Documents folder too, which is also something which is typically being backed up, if you want to reinstall the OS entirely.

Less chance for conflicts

- Having a centralized scenery.cfg, will increase the chances that any mistake, either by editing manually, or because of a problem with an utility or an installer that writes to it, will render the file useless, possibly preventing the sim from starting up. And this is an even more strong case to STOP using it and use only the add-on.xml method: if the scenery.cfg gets corrupted, you don't have to worry, because there's a backup, and since it contains only default areas, restoring from the backup won't cause any issues to your sceneries. The "smart" ones, of course...the ones that used the add-on.xml method...

Less issues with Simobjects paths

Lots of sceneries out there use their own Simobjects, and also utilities like SODE, and AI traffic packages will also add lots of Simobjects.

With the old method, the Simobjects had to be added to the centralized main .CFG of the sim, using SimobjectPaths= lines and, if they had a problem, like missing lines, numbers not in sequence or something like that, the missing lines would cause the product to fail, because it couldn't find its own Simobjects. And, of course, if you had to reset the .CFG of the sim for any reason, you would miss all the SimobjectPaths for every addon that required their own to be added, forcing to reinstall them again, or add the missing lines manually, for each addon.

With the new method, additional folders for SimObjects can be defined in the add-on.xml file so, no addon that requires Simobjects would fail because there's a problem with one of the SimobjectPaths lines missing, and it's possible to reset the .CFG files of the sim, without having to add the SimobjectPaths lines again.

Less problems with add-on modules

The add-on.xml can also add .DLL and .EXE files, used by add-on modules that might be required by some sceneries. Before, the centralized DLL.XML and EXE.XML caused lots of issues, because either defective installers or users hand-editing the XML files, and causing a problem with them, usually resulted in the add-on modules not loading.

Now (with the Hotfix 1), add-on modules requiring either a .DLL or an .EXE that has been added using the add-on.xml method, won't be affected anymore by problems with the centralized XML files.

Prepar3d.exe can add/remove/enable/disable addons for you

A very nice feature of the new system, is that you can ASK the sim itself to add an add-on for you, without having to mess with the add-on.cfg file directly! So, instead of having to parse the scenery.cfg or the add-on.cfg, you can just launch Prepar3D.exe from the command line, using the "Add", "Remove", "Enable" or "Disable" parameters, and just tell the location of the folder which contains your add-on.xml, so Prepar3d.exe will do all the work for you of adding/removing an add-on or enabling/disabling it.

This is usually done by an installer, which means less chances of installers having to reinvent the wheel, each one, to parse the .CFG files, possibly having problems, especially when these files are not entirely clean.

FSTramp only supports Scenery.cfg

Is that a "feature" ? Really, the new system is so much better than the old one that, the only possible reason why one wouldn't want to use it, is because he hasn't understood how it works.

I can only hope that LM will remove entirely the scenery.cfg method in future versions.

[mdata]

Yes, this sounds all nice, Umberto.
On the other hand you have not lost one word regarding the requirements of end users to properly and easily manage their add-ons with respect to scenery layers, priorities and pain-free enabling/disabling them. And there is this requirement, it cannot be negated.
Working on the command line is not pain free, at least not for 80% of the customer base of flight simulators.
And I still fail to see where keeping the overview over a multitude of configuration files (xmls) in different locations should be easier than overlooking one centralized configuration file. If the XML files become corrupt it has the same consequence than the scenery.cfg file or other config files becoming corrupt.
I do not deny that the new method gives us more flexibility; but I would not go so far to yell at everybody that it is the way better method.

This new method has come to most of us end users with a great surprise and with some shortcomings due to the missing of a UI that can manage add-on priorities. Especially to these guys who installed a FSDT or FB scenery with a new (aimed at P3Dv4) installer into P3Dv3. Suddenly the well ordered and well maintained scenery library was in an irreparable mess with parts of the scenery that could not be disabled anymore and priorities being upside down suddenly - without having asked for it or without having seen any word of warning beforehand.

It was the right time to introduce the new method with P3Dv4 and I think it will be embraced as well by end users with the time coming. But applying this to customers of P3Dv3 who needed to housekeep their scenery library due to the way v3 dealt with resources was a rather demoralizing idea.

Anyway, it is how it is and I do not want to turn the wheel back. It would just be a good thing to listen to the concerns of the end user instead of repeating the mantra of the way better method each time this topic is raised.

Just my two cents.

Best
Frank

[WarpD]

Actually... this method was introduced in v3.

[virtuali]

On the other hand you have not lost one word regarding the requirements of end users to properly and easily manage their add-ons with respect to scenery layers, priorities and pain-free enabling/disabling them. And there is this requirement, it cannot be negated.

Because it's not an inherent limitation of "the system", but ONLY of the GUI of the Scenery Library page of the sim.

Since the "system" accepts the Layer command, exactly like it was accepted in the scenery.cfg, just in a different file, it doesn't prevent the ability to re-arrange layers. And of course, there are already 3rd party utilities that support this system, which allows to re-arrange layers, if you don't want to wait LM to add the feature in the default UI of the sim.

Working on the command line is not pain free, at least not for 80% of the customer base of flight simulators.

Which is why I said "This is usually done by an installer". Having more reliable and easy to write/debug installers that don't have to rely on their own .CFG parsing and writing routines, it's an obvious benefit for everybody.

And I still fail to see where keeping the overview over a multitude of configuration files (xmls) in different locations should be easier than overlooking one centralized configuration file. If the XML files become corrupt it has the same consequence than the scenery.cfg file or other config files becoming corrupt.

First, the very fact a file is centralized and requires that every addon installer should write into it or users editing it manually, is increasing a lot the chances the file will end up corrupted, possibly making the whole sim unusable, or disable many sceneries at the same time.

Instead, if you have a separate XML file for each addon, the worse you can do, if that file has an issue, is that only ITS OWN add-on will be affected, not everything else!

This new method has come to most of us end users with a great surprise and with some shortcomings due to the missing of a UI that can manage add-on priorities.

That's because, while the system was introduced with P3D V3.0, it wasn't fully developed until 3.4, which explains why not many developers used it before.

Especially to these guys who installed a FSDT or FB scenery with a new (aimed at P3Dv4) installer into P3Dv3. Suddenly the well ordered and well maintained scenery library was in an irreparable mess with parts of the scenery that could not be disabled anymore and priorities being upside down suddenly

What LOOKS to be "well ordered", doesn't necessarily mean it's the most sensible technical choice. Someone said he think it might be a good idea to sort airport scenery by ICAO codes. While this surely "looks" neat, it's not really a very smart choice because, ICAO codes for airports that are close to each other sometimes are alphabetically close, like the 4 airports in Milan ( LIMB, LIMC, LIME and LIML ) so, if you are sorting them by ICAO, you increase the chance of conflicts, rather than reducing it.

Sceneries should be sorted by their covered area (the less area they cover, the higher layer they should go), instead.

But that's just my opinion. I understand everybody has his own idea of "tidiness" so, as I've said in many other places, I always agreed the Scenery Library page of the sim should allow to re-arrange all areas, regardless if they were added with the scenery.cfg or by an add-on.xml.

It was the right time to introduce the new method with P3Dv4 and I think it will be embraced as well by end users with the time coming.

Of course it was, since it's undoubtedly better, if one doesn't make the mistake of confusing the system with a limitation of the Scenery Library UI page, which might be only temporary.

But applying this to customers of P3Dv3 who needed to housekeep their scenery library due to the way v3 dealt with resources was a rather demoralizing idea.

First, if with "housekeep their scenery library" to save memory, you mean disabling/enabling a scenery, this is still totally possible, using the Options->Add-ons menu, and it doesn't require re-arranging.

Without even mentioning that, enabling/disabling an FSDT/Flighbeam scenery that uses the Addon Manager to save memory, was always a complete waste of effort, since these sceneries do custom memory management, and they are entirely unloaded from memory when you are not in their area.

instead of repeating the mantra of the way better method each time this topic is raised.

It's only after someone repeats the mantra that he doesn't seem any benefits or says the method is "nonsense", that I feel the urge to point of the facts, which might not be obvious, if not explained, and not everybody ever reads the SDK...

It would just be a good thing to listen to the concerns of the end user

There's really only ONE outstanding issue, which is the inability to re-arrange the areas using the Scenery Library page, which I always add to every single one of my posts, would be a WELCOME addition, but as a 3rd party developer, other than asking LM to take into consideration, which is surely something every user can do as well, there's not much else I could do.

But I won't renounce to all the other clear benefits of the new system, only for a limitation of the UI, which might well be temporary, and they outweigh the UI issue, by far, since they make the sim inherently more reliable, at the core.

[downscc]

Good try Umberto but no matter how good an idea is, there are people will not agree simply because they initially don't like it. It take time for changes to be generally accepted. I've taken the concept one step further than the FSDT installers in that I have combined all FSDT sceneries in one add-on.xml, all FlyTampa in one add-on.xml, etc. I keep my folders in the Document section to a minimum, which I consider aesthetically more pleasing. I am totally on board with this method. Look for developers to quickly realize the benefits and almost universally adopt it, in my opinion. I predict PMDG will in the future, right now they are keeping their focus on migrating the products and will return to the installation method down the road.