xml method of adding scenery question ?

[Crusader]

I've Googled this and have read what I think is the reason LM would prefer users to add scenery via the xml method but for this dense , non-programmer type like me maybe someone could give me a simple explanation .

I always thought that LM wanted us to keep the default P3D folder as clean as possible . (scenery and AC) Is this to make the program(P3D) run smoother and quicker (not FPS wise) ? As many do , I keep addon scenery out of the P3D main folder . What I am asking , what is the main advantage of the xml method over the old method of just linking it to the Scenery Library to where ever we have the scenery ?

Rich ( sorry to be " beating a dead horse " as the expression goes "

 

[falcon409]

I've Googled this and have read what I think is the reason LM would prefer users to add scenery via the xml method but for this dense , non-programmer type like me maybe someone could give me a simple explanation.

I always thought that LM wanted us to keep the default P3D folder as clean as possible . (scenery and AC) Is this to make the program(P3D) run smoother and quicker (not FPS wise) ? As many do , I keep addon scenery out of the P3D main folder . What I am asking , what is the main advantage of the xml method over the old method of just linking it to the Scenery Library to where ever we have the scenery ?

Rich (sorry to be "beating a dead horse" as the expression goes")

Rich, I'm with you. I have a very clear cut setup for all my scenery that is kept on another drive and has been that way for years. I add scenery via the Scenery Library and in FTX Central I set an Insertion point that tells Orbx how to arrange it's scenery whenever it does an update (previously it would automatically move all of it's files to the top of the priority list).

Anyway, I don't get the need for doing xml files to group scenery. I already have my scenery grouped thank you very much, lol. . .and so far I haven't gotten an error message saying "HEY YOU CAN'T DO THAT", lol

 

[jeansy]

I've Googled this and have read what I think is the reason LM would prefer users to add scenery via the xml method but for this dense , non-programmer type like me maybe someone could give me a simple explanation .

I always thought that LM wanted us to keep the default P3D folder as clean as possible . (scenery and AC) Is this to make the program(P3D) run smoother and quicker (not FPS wise) ? As many do , I keep addon scenery out of the P3D main folder . What I am asking , what is the main advantage of the xml method over the old method of just linking it to the Scenery Library to where ever we have the scenery ?

Rich ( sorry to be " beating a dead horse " as the expression goes "

horses for courses Rich

I prefer it all in one location, its faster for my SSD HD to access everything in the same location as I have the sim on a separate drive than my C: drive thats not a SSD
while it works, i say stick with what you know and feel comfortable with

the only shortfall with the new method is that the folder for addons supersedes all other addons in the P3D folder, so that scenery you rarely use that is in the addon folder will sit higher than the scenery you want as a priority that installs into the LM folder, that could cause some long term problems if all devs dont go that way

its still early days, theres another several yrs to nut this out and everyone to adopt and stick to one formula, and I highly doubt that will happen anyway, developers will do what they feel suits their addon regardless

sorry i know that wasnt any help, but at the moment there is no right or wrong way of doing things just yet, if it works it works.....

 

[gman5250]

I haven't found a clear cut definition as to why LM "highly recommends" using the .xml method for third party scenery.

To answer your question, I believe the intent is to provide an additional option to control the management of large and complex packages via the small .xml file, which tells the sim where to look for the content. The option builds in flexibility for individual users to tailor the data allocation to best suit their systems.

I'll relate my experience in installing my own scenery packages in P3Dv4.

I originally installed using the (previously) acknowledged method of creating an Addons folder in P3D root folder. I've done it this way for years, as have most others.
The scenery worked fine for the first 24 hours, then I ran into anomalies. The scenery would partially display, but leave out random elements of vegetation and buildings.

I then updated my Flightbeam KSFO HD package to the available P3Dv4 installer. I installed the scenery without issue..it displayed correctly.
With the new FB package installed, the Virtuali add on manager also updated all of my other Flightbeam and FS DreamTeam packages as well without need to re-download individual packages.

When I looked at the architecture, I found that FB and FSDT were now installed in the Options/Add-Ons folder, using the .xml syntax and architecture. This was a new format for me, so I took some time and brought myself up to speed on the new method LM suggests.

From that point I wrote .xml files for my scenery packages and installed them using the same architecture as FB and FSDT.
My scenery packages have worked without issue since I made those changes.


IMO:
I don't have the inside track on LM syntax or file architecture in the new 64 bit platform, but I am reasonably confident that they "highly recommend" using the .xml method for a reason. I understand all of the arguments for using the old methods, which favor "stacking" scenery etc.

In my installation, I can place third party scenery in an external location which keeps the basic sim clean. My load times are a bit longer, but overall 64 bit load times are vastly improved so I don't experience any significant lags when loading. I have a very large library of scenery and load times remain under one minute for the sim.

I think people should use what suits them best. I simply contribute my observations and experience on this matter in the interest of helping others possibly prevent a timely re-install due to syntax/architecture conflicts down the road.

 

[dougal]

After I installed a bunch of my old v3 scenery into v4 (all stored on a separate SSD), by just using the 'Scenery Library' in v4, I then installed the new v4 version of 'Scenery Config Editor' (now known as Snapshot). It failed to work, telling me the scenery.cfg file was corrupt. The only app I'd used to previously look at this file, was Notepad++

I've now gone back to a vanilla v4, and will be MUCH more careful about what and how I install:-(