answered When will this stop?!!

[Morten]

6 hours ago, Nick Cooper said:

 

 

The image is a guide from a topic named How to operate the FTX Central Insertion Point tool

and it states in green at the top that the yellow text will not be seen in FTX Central.

It also shows clearly where the insertion point should be placed and Holger has kindly explained exactly

what you should do and why what you have done is creating the problem.

 

Sorry Nick!

Me being too fast there..

And yes, in the next couple of minutes I will try out Holger's insertion advice and see how things work out. Cross fingers!

 

The point is that we, the users of Chris Bell's NE Black Marble, are strictly and unconditionally instructed by Chris to put our insertion point below his "CDSEXX" entry, which I have been following for quite some time now.

 

[demio]

28 minutes ago, Nick Cooper said:

both scenery.cfg files are identical and neither has numbers missing.

 

Excuse me, but...what? This is an excerpt from the scenery - before.cfg:

 

Quote

[General]
Title=Prepar3D Scenery
Description=Prepar3D Scenery Areas Data
Clean_on_Exit=TRUE

 

[Area.001]
Title=Default Terrain
Texture_ID=1
Local=Scenery\World
Layer=1
Active=TRUE
Required=TRUE

 

[Area.009]
Title=Default Scenery
Local=Scenery\BASE
Layer=9
Active=TRUE
Required=TRUE

 

Area.001, followed by Area.009. As you can see in the before.JPG, before running FTXC, they are a number of sceneries in between 1 and 9 (elevation corrections and MAIW), added via .xml. After FTXC, the .xml stay unchanged (I fully realize that), and thus are slotted in between the layers from the newly rearranged .cfg (after.JPG).

 

Maybe this information will help: As far as I know (and my experiences here confirm it), if a scenery in the .cfg has the layer 10, and a scenery in a .xml has the layer 10 (which can happen), P3D (and P4AO) slots the .xml scenery above the scenery from the .cfg. This is what happens here: The .xml files keep their layer, the layers in the .cfg are changed, and that changes the arrangement.

[Nick Cooper]

I see that, however, this is the software that I use to view it and they look like this:

 

I think that as the two methods of managing the scenery library are clearly

not compatible, it would be best if you keep a back up of your scenery - before.cfg file

and replace the scenery.cfg file after you have run FTX Central.

 

[Morten]

Quote

 

And yes, in the next couple of minutes I will try out Holger's insertion advice and see how things work out. Cross fingers!

 

The point is that we, the users of Chris Bell's NE Black Marble, are strictly and unconditionally instructed by Chris to put our insertion point below his "CDSEXX" entry, which I have been following for quite some time now.

 

 

Yes! Holger's insertion advice works so far according to my quick tests for scenery errors. Thanks for that!

I will ask Chris Bell to relate to our discussion here in this forum and make a statement about his justification for insisting on his CDSEXX insertion entry. 

 

Thanks again

Morten 

[Nick Cooper]

Hello,

I cannot see his support forum but I would be very surprised if he also told you to put the

CDSEXX  entry at the top of your scenery library.

If I were you, I would move it so that it becomes the lowest of your addon scenery entries.

If you do, both his guide and ours will be valid.

 

[demio]

1 hour ago, Nick Cooper said:

I think that as the two methods of managing the scenery library are clearly

not compatible

I disagree.

1 hour ago, Nick Cooper said:

it would be best if you keep a back up of your scenery - before.cfg file

and replace the scenery.cfg file after you have run FTX Central.

Fair enough, but what if I start FTXC install a ORBX scenery I just bought? If I restore the backup, it won't show. Really, I think the best would be an option to stop FTXC from rearranging the .cfg - OR make it aware of .xml files, as those are the future according to LM (afaIk).

[MyPC8MyBrain]

guys you are mixing unrelated issues and ingredients all in one bawl,

admins and orbx dev with LM beta access please read my post here

https://www.prepar3d.com/forum/viewtopic.php?f=109164&t=130521

 

im not here to argue anyone; just to inform respectable admins and dev on here about this wide spreading epidemic we are all seeing on each our ends,

as publisher and dev i am calling for collaboration on this epidemic spreading rapidly on all fronts ;if we want this contained,

i suggest we congregate at the link above and try to have a unified front to help correct this,

 

Demio you are simply wrong along with everyone else who believes there's a "new way" of doing things; there isn't and this is all in your minds!

one cannot be using 3 scenery index instead of one, you are messing up scenery index (SceneryIndexes_x64 folder listings will get corrupted)

 

addons.cfg is for dynamic type addons that purge their data on exit, weather, air traffic, model matching, or any none static type data,

addons scenery stack are not indexed in static scenery stack aka scenery.cfg or in SceneryIndexes_x64,

pushing addons from addons.cfg into scenery cfg will corrupt your static scenery index, period!

sim cannot see those and is not looking for those folders to index; and that's by design 100%!
new way of doing things is nothing but a rumor 

 

it may work ok for a bit as one install for the first time and keeps it in place;

move it around, uninstall, add a scenery in between and that's where your issue will start as you broke your indexing with uninstalling or changed layering to a scenery that resides in addons,

the addons in addons.cfg will not be indexed as part of SceneryIndexes_x64 , when you push them into scenery.cfg on the fly from addons.xml is were these issues arise,

 

GL to all <3 

 

Chris Bell,

Creative Design Studios

 

[Nick Cooper]

6 hours ago, demio said:

As far as I know (and my experiences here confirm it), if a scenery in the .cfg has the layer 10, and a scenery in a .xml has the layer 10 (which can happen), P3D (and P4AO) slots the .xml scenery above the scenery from the .cfg. This is what happens here: The .xml files keep their layer, the layers in the .cfg are changed, and that changes the arrangement.

 

Following on from the post by Chris Bell, apart from feeding this topic, is there any benefit to you

in using this method when the same can easily be achieved by simply creating the scenery library entries?

 

As we have pointed out, your method is not compatible with FTX Central which sees a fault in the scenery library

and corrects it.

The Scenery Config Editor sees the same fault, reports it and offers to reorder the numbers that are out of sequence.

Both of these programs are designed to deal with the scenery.cfg file only and as Chris points out, attempting to integrate

the xml files into the scenery library is neither the correct thing to do nor is it necessary.

 

If you wish to persist with this method, you will have to accept that your scenery.cfg will be reordered.

Changing the way it works might solve the problem that you have created but it would create problems for all the other

customers who have not gone down the same path.

 

Your simplest solution would be to add the MAIW entries to the scenery.cfg file, as was intended and do away with

the xml entries for them.

 

 

[carlosqr]

Hi Nick and everybody here

 

I would like to add a comment here after your note of " the other software that you use places the xml scenery where you told it to"

 

Some sceneries like the ones from UK2000, Fly Tampa, Drzewiecki Design and others are installed automatically. It is not that the user decides where to place them, they simply add, and get stuck, fixed in the scenery library. Once there you cannot lower or higher their priority. You can not untick them or even delete them! this is because they were added by this xml procedure.

 

I remember once a guy had a terrible issue with elevation in Saint Marteen. It was added by the xml procedure. This seemed to be the only third-party addon this user had and when he tried his FTX Central to find it to set his FTX entries below it, FTX Central was not able to locate it. It simply wasn't on the list to show.

 

I told him to uninstall the scenery and to reinstall.  When installing back, at the moment the application asks if you want it to be installed automatically, to say no. Then to add it to the library manually, this way FTX Central would detect it.

 

I have all these installed by this automatic procedure (as some don't offer the possibility to add manually like the ones purchased in Simmarket)  and as you can see they all are on top of the library:

 

 

You'll see that all the first ones are greyish on the check box square.

I cannot do anything to those ones because they were added by this other procedure

 

If I install now a new scenery it goes to down all of them to number  65 and it places itself there.

 

I hope this gives a light on what is going on with this installation procedure and this issue

 

Regards,

 

Carlos

[Stewart Hobson]

Carlos, I'm guessing you have a very large C: drive, with all that scenery and P3D as well.  I hope you have backups.

[carlosqr]

1 minute ago, Stewart Hobson said:

Carlos, I'm guessing you have a very large C: drive, with all that scenery and P3D as well.  I hope you have backups.

Hi Stewart

I have a 2T C disk and 1T for backing up. I have all the add-ons, planes etc stored in the 1T. as I could simply die if something happens to my C drive and would lose all. Too much money, time etc invested. But I hope nothing bad happens to it, I still need to add some Orbx sceneries I like but need to make the money yet.

BTW just wanted to so Nick how these sceneries get stuck in the library by the automatic install procedure, hoping this is useful.

Take good care of yourself my friend

 

Chees

[Stewart Hobson]

Carlos,  You know if your Windows installation goes to hell, with it also on your C drive, you'll be faced with a nightmare trying to reinstall everything.  But maybe it's easier than I think.  I have five (!) SSDs all containing different stuff, so that if one goes out, I don't lose everything--Windows on one, FSX on one (don't use it anymore), P3D on one, a swap file on one, Global mesh and temp folder on one.

[carlosqr]

3 minutes ago, Stewart Hobson said:

Carlos,  You know if your Windows installation goes to hell, with it also on your C drive, you'll be faced with a nightmare trying to reinstall everything.  But maybe it's easier than I think.  I have five (!) SSDs all containing different stuff, so that if one goes out, I don't lose everything--Windows on one, FSX on one (don't use it anymore), P3D on one, a swap file on one, Global mesh and temp folder on one.

 

Hi Stew

But how do you manage to get all spread?

 

I thought P3D required Windows structure to run... so it needs to be installed in the same drive as Windows...

 

This is interesting

[Stewart Hobson]

3 minutes ago, carlosqr said:

I thought P3D required Windows structure to run... so it needs to be installed in the same drive as Windows...

No, that is not the case.  Windows is on my C drive, P3D is on my P drive.  If Windows messes up, like it did earlier this year, it doesn't affect P3D at all.  Of course there are adjustments to make when Windows is reinstalled, but my computer tech knows how to do that.  I don't, but that's why I pay him and I give him my backups.

[Doug Sawatzky]

Or like this....

 

[Ben McClintock]

We are planning on using the new add-on structure in FTX Central soon.

 

It has a multitude of benefits for us and for end users. There are a few small issues with ordering, but nothing that we can't solve.

[FalconAF]

1 hour ago, Stewart Hobson said:

No, that is not the case.  Windows is on my C drive, P3D is on my P drive.  If Windows messes up, like it did earlier this year, it doesn't affect P3D at all.  Of course there are adjustments to make when Windows is reinstalled, but my computer tech knows how to do that.  I don't, but that's why I pay him and I give him my backups.

 

Stewart, I'm losing faith in you!  

 

Anybody who has the cost of FIVE SSD's already installed in their computer should also be in a position to afford ANOTHER NON-SSD DRIVE (preferably, an EXTERNAL USB drive at a significantly lower cost than an SSD) that would allow them to make a TOTAL IMAGE BACKUP of their ENTIRE computer.  You would never have to worry about needing a "computer tech" to "save" you if ANY of the internal hard drives failed.  Restoring the full image from the external USB drive (after replacing the trashed internal hard drive if needed) would put EVERYTHING back the way it was before, including the entire Windows OS and all of those P3D Windows data and settings in all those folders on the Windows OS drive.  I have six internal hard drives on the computer I use for my flight sims (3 less than Doug above) with different things for P3D on different drives.  But I also have one EXTERNAL very large storage capacity, inexpensive, regular (non-SSD) USB hard drive used only for creating IMAGE backups that will hold ALL of the information on it for a complete IMAGE backup of my entire computer.  An occasional Incremental backup every once in a while keeps the image on the external USB drive up-to-date with anything new or changed on the entire computer.  Once I reach a certain number of Incremental backups, I just create a full new backup so I never run out of space on the external USB backup drive.  Heck, the imaging application software will do that automatically for you if you tell it how many incremental backups maximum you want before making a total new backup again (which deletes all the incrementals, thus regaining disk space again). 

 

For the price of a couple addon airports today (and much less than even an SSD drive itself), start making your own backup images of your computer to an external USB drive.  Let other non-savvy users pay for your computer tech's $6 Starbucks coffees.  

 

[FalconAF]

56 minutes ago, Ben McClintock said:

We are planning on using the new add-on structure in FTX Central soon.

 

It has a multitude of benefits for us and for end users. There are a few small issues with ordering, but nothing that we can't solve.

 

Ben,

 

I've stayed out of this discussion because it has been beat to death over the last year in numerous forums already.  But I'd like to respectfully ask a question based on your post above.

 

It is a known problem that running FTXC will rearrange the order of the list of NON-FTX addons in a scenery.cfg file list if the flight sim has a COMBINATION of xml and non-xml addons added to the simulator.  I live with it, but it is not a user-friendly thing when it happens.  

 

Are you saying that a new FTXC will stop that from happening?  Because whenever I manually rearrange my Scenery Library order of my NON-FTX entries the way I want it (or need it, depending on the "priority order" required for all the addons to work together), while keeping all of my FTX entries where they should be by using the proper Insertion Point in FTXC, whenever I run FTXC it will still scramble the order of the NON-FTX items in my scenery library list by rearranging those items.  All of the FTX entries stay where they should, but the REST of my xml and non-xml entries get rearranged.  I know it is an issue between xml vs non-xml scenery library entries, and not necessarily ORBX's fault.  But it does happen every time running FTXC.

 

It doesn't matter what method I use to arrange the non-FTX entries in the scenery library "list" either.  It happens after using the default Scenery Library list in P3D, or using the third-party Lorby-SI Addon Manager, to set the order of my non-FTX addons.  No other utility tool I use will scramble the non-FTX entries in my library list the way running FTXC will.  FTXC is the only one that does it (as far as I know, but there may be other utility programs I don't use that will do it too).

 

And please don't take this wrong, but any answer that says something like, "Well, P3D now is designed to use the XML entry format, so if you are using any scenery that doesn't install that way....", then I would have to ask why the ORBX products do not install using the XML method now too.  That's not intended to be a slam, just an observation.

 

Thanks for any insight.

   

[carlosqr]

2 hours ago, Doug Sawatzky said:

Or like this....

 

 

Very interesting indeed. I had all in C, windows and the three sims and everything! just the storage in D  

Thanks Doug & Stewart

[carlosqr]

1 hour ago, Ben McClintock said:

We are planning on using the new add-on structure in FTX Central soon.

 

It has a multitude of benefits for us and for end users. There are a few small issues with ordering, but nothing that we can't solve.

 

Good to know Ben, thanks

[Ben McClintock]

55 minutes ago, FalconAF said:

It is a known problem that running FTXC will rearrange the order of the list of NON-FTX addons in a scenery.cfg file list if the flight sim has a COMBINATION of xml and non-xml addons added to the simulator.  I live with it, but it is not a user-friendly thing when it happens.  

 

Are you saying that a new FTXC will stop that from happening?  Because whenever I manually rearrange my Scenery Library order of my NON-FTX entries the way I want it (or need it, depending on the "priority order" required for all the addons to work together), while keeping all of my FTX entries where they should be by using the proper Insertion Point in FTXC, whenever I run FTXC it will still scramble the order of the NON-FTX items in my scenery library list by rearranging those items.  All of the FTX entries stay where they should, but the REST of my xml and non-xml entries get rearranged.  I know it is an issue between xml vs non-xml scenery library entries, and not necessarily ORBX's fault.  But it does happen every time running FTXC.   

Hi Falcon,

 

As I understand it, the core of the issue is that FTX Central attempts to re-number (but not re-order) the layers in the scenery.cfg so they are sequential. 

 

At the moment, if you have three entries in your library that are:

Layer=1

Layer=2 (added via add-on.xml)

Layer=10

Layer=20

 

They will be reordered to:

Layer=1

Layer=2

Layer=2 (added via add-on.xml)

Layer=3

 

This is a simple enough issue to fix: I'll just stop that renumbering behaviour for P3D v3 and v4. Each layer in the scenery library will keep its original layers unless FTX Central is adding new Orbx entries. The renumbering functionality was just added for cosmetic reasons - as far as I'm aware the simulator doesn't care about having gaps in between the layers.

 

1 hour ago, FalconAF said:

And please don't take this wrong, but any answer that says something like, "Well, P3D now is designed to use the XML entry format, so if you are using any scenery that doesn't install that way....", then I would have to ask why the ORBX products do not install using the XML method now too.  That's not intended to be a slam, just an observation.   

There are a few reasons for this. In short, there are a lot of small problems that need to be solved to get it working to an acceptable level which turns it into a massive task (especially when you consider that our library consists of 215 products). The current scenery.cfg system will work until at least the rest of the v4.x releases - so the justification would have to be very good to take developer resources away from other tasks.

 

That said, we are working on it. I would like it to be done before the end of the year, but that may change if we run into any additional problems

 

[demio]

3 hours ago, Ben McClintock said:

We are planning on using the new add-on structure in FTX Central soon.

 

It has a multitude of benefits for us and for end users. There are a few small issues with ordering, but nothing that we can't solve.

Great!

26 minutes ago, Ben McClintock said:

As I understand it, the core of the issue is that FTX Central attempts to re-number (but not re-order) the layers in the scenery.cfg so they are sequential. 

Yes, that's exactly the issue.

26 minutes ago, Ben McClintock said:

This is a simple enough issue to fix: I'll just stop that renumbering behaviour for P3D v3 and v4. Each layer in the scenery library will keep its original layers unless FTX Central is adding new Orbx entries. The renumbering functionality was just added for cosmetic reasons - as far as I'm aware the simulator doesn't care about having gaps in between the layers.

Good to hear, thanks!

[Nick Cooper]

8 hours ago, carlosqr said:

Hi Nick and everybody here

I would like to add a comment here after your note of " the other software that you use places the xml scenery where you told it to"

 

Hello Carlos,

there is no problem, as far as I can tell, until the user decides to spread the xml entries out among the

scenery.cfg entries.

In your case, which is the most common and causes no problem, all your xml installed products are in one block.

The installers are not the software to which I referred.

 

The relevant software, which you apparently do not use, is that which allows the user to create a scenery.cfg with

gaps in the AREA numbering which are then filled with xml entries.

At present, FTX Central automatically fills the gaps in the scenery.cfg file but does nothing to the xml entries, so when

P3D is restarted, there are two scenery library entries in the same place.

 

 

[Nick Cooper]

@demio

 

My advice above is, as it can only be, based on the information that I have.

It now seems that in due course, there will be a development that

takes account of the method you use.

 

Nevertheless, for now, I think that your best solution is to maintain a

back up of your "before" scenery.cfg file and in the event of you adding

new products, add them to it manually.

The other way, if needed, would be to let FTX Central add the new product's

scenery library entry and then once you have seen what it is, add that manually

to your back up.

This is not ideal but should allow you to maintain your chosen method with the

least input.

[demio]

Nick, thanks. Until the change is implemented, I will do that.

[Stewart Hobson]

I'm glad this has finally been cleared up.  Isn't it amazing?  That FTX Central works exactly as advertised?  Amazing.

[carlosqr]

18 hours ago, Nick Cooper said:

 

Hello Carlos,

there is no problem, as far as I can tell, until the user decides to spread the xml entries out among the

scenery.cfg entries.

In your case, which is the most common and causes no problem, all your xml installed products are in one block.

The installers are not the software to which I referred.

 

The relevant software, which you apparently do not use, is that which allows the user to create a scenery.cfg with

gaps in the AREA numbering which are then filled with xml entries.

At present, FTX Central automatically fills the gaps in the scenery.cfg file but does nothing to the xml entries, so when

P3D is restarted, there are two scenery library entries in the same place.

 

 

 

Hi Nick

I understand,  and yes I have no conflicts in my sim

Thank you very much for your attention

Regards,

Carlos

[AnkH]

You guys are aware  that you can add a "layer=xxx" line into your add-on.xml file to manually move your sceneries around that are installed via this XML method? It takes some time if you have that many XML entry based addons such as carlos, but it works perfectly. And if I am not entirely wrong, the Lorby Prepar3D V4 Addon Organizer is also capable of doing this.

[Nick Cooper]

Thanks, apparently we are, since that is the subject of demio's complaint.

[Stewart Hobson]

Innocent question:  Why does one want to move the add-on.xml entries around in the scenery.cfg file?  Why not let them reside where the installer puts them?

[Nick Cooper]

Hello Stewart,

an innocent answer from someone who does not use them as yet.

 

Certain scenery library entries must be above or below certain others to work as intended.

If one chooses to add them using the xml method, those rules still apply but without

intervention, P3D puts them all together on top of the scenery.cfg file entries.

 

I don't think that there are any installers that do this, the developers would probably be inundated

with topics like this one if they programmed their installer in that way, but there is software available

that allows you you do this to your own P3D installation.

[Stewart Hobson]

Thank you, Nick.  You are correct that P3D places the "xml method" airports on top of the scenery.cfg entries.  I have several airports where this is the case, but I have yet to notice any problems caused by their being placed above everything else.  In point of fact, they are supposed to be above the Orbx entries, and that's where they are.  So I don't understand the need to shift them around when they are already located in the positions they're supposed to be.  Thus my question above.

[Nick Cooper]

In the specific case, apparently the MAIW entries have been manually added using the xml method.

Presumably there is a requirement to place them there, otherwise the whole exercise was pointless.

 

 

then FTX Central has been run and has corrected the scenery.cfg Area numbering, adding the default entries

back to where they have always been.

The result is ten scenery areas in five slots.

 

 

In a future world, FTX Central would have to do something similar with the xml entries to what the Insertion Point tool does

to the scenery.cfg file at the moment, to ensure the correct location of the FTX entries.

[Stewart Hobson]

Thanks, Nick, I see the problem now.  I don't have, nor do I know what the MAIW entries are, so there ya go.........

 

 

Ok, MAIW--Military AI Works.  Not really interested in this.  But it seems the stuff ought to be installed at the top, like all the rest.

[FalconAF]

Stewart,

 

Here's another example.  Just because an installer selects what name IT wants to display as the "Scenery Area Title" in the scenery library doesn't mean the user will want to use THAT specific name as the display name in the scenery library.  For instance (as in my entries below) I do not want my scenery library display names to be ordered by something like Fly Tampa (then the scenery name, etc).  The default Fly Tampa installers will put all of THEIR sceneries in a row in the scenery library.  I have tons of scenery airports, both XML and non-XML entries in my scenery library.  I like to order them by the 4-letter airport identifier.  Yes, it's a personal choice, but ALL I am doing is changing the NAME of the entry in the scenery library list.  That should NOT affect the ORDER the entry is displayed, and it doesn't until I move them to the 4-letter alphabetical order I prefer to keep track of them by the AIRPORT instead of the developer's name.  I use the Lorby-SI Addon Organizer to do that, because it allows me to move either XML or non-XML library entries (the default P3D Scenery Library won't let you move both types).

 

So, I order my scenery library entries the way they make sense to me (and in the "priority order" they are needed to work properly too).  The first 2 pictures below show that, and they show that I end up with a mixture of non-XML and XML entries.  In other words...not ALL of my XML entries SHOULD be at the very top of the scenery library list.

 

 

Then, I "run" FTXC.  I don't have to do anything but "open" FTXC, then close it, then the below 3 pics show what has happened to my scenery library list.  The order of a LOT of things gets changed.  Note in the 3rd picture below, it even separates entries that SHOULD stay together, like the 3 layers for LFPG (Paris Charles de Gaulle) for Taxi2Gate.  This should not happen.  One of the "features" of the FSX (and now P3D) scenery library was it allowed the user to ORDER and use manually changed "Scenery Area Title" names in the scenery library list in a way that worked for the USER.  This should be maintained by any utility that makes "changes" to the scenery library list.

 

 

I was just asking if Ben's post was indicating a "new" FTXC would stop making the above unwanted changes to the scenery library.  The current FTXC works fine for keeping all the ORBX entries in the proper locations.  But not so much user friendly for all the other scenery library entries.  And it most likely isn't "just" ORBX's fault this is happening, but may be something that needs to be coordinated with the way P3D now handles combinations of XML and non-XML scenery library entries (in as much as the DEFAULT P3D scenery library in P3D itself won't allow the user to move both the XML and non-XML entries.

[Stewart Hobson]

Thanks for your explanation, Falcon, but you need not have gone to all that trouble, but thank you nevertheless.  I use SimStarter NG to organize my scenery entries, and all the xml entries are purposely placed at the top--I have control through Simstarter where those puppies are placed.  I'm not so much concerned if they are in proper alphabetical order or not.

[FalconAF]

But do they show up in the same order in the P3D Scenery Library in P3D?  If not, the question should be why not?  And would it cause any scenery "priority" conflicts?  Nobody...not even LM...has answered that question (and I know because I've asked).

 

And it's a valid question, because if it wasn't, then ORBX wouldn't need to worry about keeping IT'S scenery library entries in a "priority order" then either.  But they still need to do it, so why should I assume it isn't important for the REST of my scenery library too?  

[Stewart Hobson]

1 hour ago, FalconAF said:

But do they show up in the same order in the P3D Scenery Library in P3D?

Yes, of course they do.  The xml-addon airports are always at the top, in both the P3D library screens and the SimStarter displays as well.  There has never, to my knowledge, been a problem with proper scenery order using SimStarter to order the scenery library.

[tombestor3@gmail.com]

this is probably going to grow into a BIG problem.  i mean the use of both xml and cfg for scenery entries in p3d.  i'm already running into problems that make me tear hair out with, for instance, FSDC and FSDT airports (which insist on using xml).  there's nothing we poor slobs can do about it.  is there an accomodation or app that orbx can come up with? -- you have been the adults in the room for so long that i think some of us, unfairly, feel a bit cheesy if you don't want to step up now.  sorry if that was infelicitously phrased.  but many of us have made over the years a far greater investment in orbx stuff than any other, so now we are bush-whacked by p3d, who do we call -- ghostbusters of course.

 

tom bestor

[gregmorin]

My experience has been exactly the same as FalconAF. I am glad that Ben is working on a fix.

 

Greg