Some questions that may have been asked before...

[Hakkie 0]

First of all, thank you very much Nico for creating this software for free! Makes my simulator world a lot more alive.

I've been using PSXT for a while now and have upgraded to the latest version yesterday. Over time some questions/thoughts came up:

• Isn't it possible to let ParkPosGenerator make use of P3D scenery database instead of scanning through folders that the user has to add in the settings? I believe using the (free) Lorby-SI AddOnOrganizer allows you to create a 'temporary' scenery.cfg that external tools like PPG can use. That would make adding paths to the setup obsolete, wouldn't it? Also this would guarantee that PPG uses the exact same activated sceneries (and priorities) as P3D does.
  AddOnOrganizer has a commandline option to generate a scenery.cfg for external tools. "Command line option: You can export the library directly from the command line too: P3D V4: P3DV4AddonOrganizer export allscenery.cfg P3D V3: P3DV4AddonOrganizer export_V3 allscenery.cfg This will create a file called “allscenery.cfg” containing the full library without altering your scenery.cfg"
• I am running PSXT64 on my laptop, while the airports in the 'parked' folder are per default on the P3D machine. At startup of the latest PSXT64 it reads all the XML-files. Over the network this takes about 3-4 minutes in my case (1gbit network). As mentioned in PPG the manual you can copy the XML's to a folder on the machine where PSXT64 is running and point PSXT64 to that folder. Wouldn't it be possible to make the output folder in PPG configurable? PPG could then write the XML's directly to the same folder (and machine) as defined in PSXT64. Yes, running PPG would take longer as it has to write the files over the network. But this would skip the need for users having to copy the parked folder. Having PSXT64 read the XML's over the network at each start is not very comfortable, so copying the files to the PSXT64 machine after each PPG run is a must to me. 😉
• Am I correct that the folder 'parked' has a higher priority than folder 'parked_default'. So PSXT64 handles the airportfiles in this prio: 1) parked-updates 2) parked 3) parked_default?

All for now. 😄 Thanks for taking the time to answer. 😇

[kiek 1,215]

3 hours ago, Hakkie said:

• Isn't it possible to let ParkPosGenerator make use of P3D scenery database instead of scanning through folders that the user has to add in the settings? I believe using the (free) Lorby-SI AddOnOrganizer allows you to create a 'temporary' scenery.cfg that external tools like PPG can use. That would make adding paths to the setup obsolete, wouldn't it? Also this would guarantee that PPG uses the exact same activated sceneries (and priorities) as P3D does.
  AddOnOrganizer has a commandline option to generate a scenery.cfg for external tools. "Command line option: You can export the library directly from the command line too: P3D V4: P3DV4AddonOrganizer export allscenery.cfg P3D V3: P3DV4AddonOrganizer export_V3 allscenery.cfg This will create a file called “allscenery.cfg” containing the full library without altering your scenery.cfg"
• I am running PSXT64 on my laptop, while the airports in the 'parked' folder are per default on the P3D machine. At startup of the latest PSXT64 it reads all the XML-files. Over the network this takes about 3-4 minutes in my case (1gbit network). As mentioned in PPG the manual you can copy the XML's to a folder on the machine where PSXT64 is running and point PSXT64 to that folder. Wouldn't it be possible to make the output folder in PPG configurable? PPG could then write the XML's directly to the same folder (and machine) as defined in PSXT64. Yes, running PPG would take longer as it has to write the files over the network. But this would skip the need for users having to copy the parked folder. Having PSXT64 read the XML's over the network at each start is not very comfortable, so copying the files to the PSXT64 machine after each PPG run is a must to me. 😉
• Am I correct that the folder 'parked' has a higher priority than folder 'parked_default'. So PSXT64 handles the airportfiles in this prio: 1) parked-updates 2) parked 3) parked_default?

@1st bullet: 

PPG has to work with all versions of FSX and P3D and since there are differences in how they treat the scenery.cfg file it would become too complicated. Hence my choise for the "brute force" approach. That has not necessarily to lead to many folder entries. I have all my P3Dv4 add-ons at D:\AddOns. So I only need a path to the main folder of Prepar3D v4 and one with D:\AddOns. Very simple. And when I have bought a new add-on airport I only have to run PPG with one entry: D:\AddOns.  Maybe you also have noticed that scanning a complete P3DV4 for .bgl files  does not take very long, also thanks too the fact that PPG uses all the cores at your cpu. So there is not really a need too change the scan approach.

@2nd bullet:

Making the output folder of PPG configurable, sounds a good idea! One could then create a folder say my_airport under PSXseeconTraffic, or wherever at the PSXT PC, and let PPG and PSXT point to that. Note that one should never overwrite parked_default. Will investigate it tomorrow, thx.

@3d bullet:

No, you are not correct. There are too aspects, one is airport names+positions and the other is parking positions for an ICAO airport.

1) airports:  When PSXT starts it creates (since 13.4) a list of airports (ICAO,IATA,lat,lon) by first searching in the folder indicated by your Airport files folder parameter. If that folder is different from parked_default it will also -if parked_default is available- search the parked_default folder for additional airports. Note that you are free to delete parked_default if you have created you own folder with your airport files.

2: parking positions: When PSXT needs an airport file with parking positions, it will first search in the parked_updates folder, and if no file is found, it will search in the folder indicated by your Airport files folder parameter. That's all.

As you can see, the parked folder of PPG only plays a role if you have assigned that folder as Airport files folder parameter. That is something I would only do if PPG is at the same PC as PSXT.

Nico

 

 

[Hakkie 0]

33 minutes ago, kiek said:

@1st bullet: 

PPG has to work with all versions of FSX and P3D and since there are differences in how they treat the scenery.cfg file it would become too complicated. Hence my choise for the "brute force" approach. That has not necessarily to lead to many folder entries. I have all my P3Dv4 add-ons at D:\AddOns. So I only need a path to the main folder of Prepar3D v4 and one with D:\AddOns. Very simple. And when I have bought a new add-on airport I only have to run PPG with one entry: D:\AddOns.  Maybe you also have noticed that scanning a complete P3DV4 for .bgl files  does not take very long, also thanks too the fact that PPG uses all the cores at your cpu. So there is not really a need too change the scan approach.

@2nd bullet:

Making the output folder of PPG configurable, sounds a good idea! One could then create a folder say my_airport under PSXseeconTraffic, or wherever at the PSXT PC, and let PPG and PSXT point to that. Note that one should never overwrite parked_default. Will investigate it tomorrow, thx.

@3d bullet:

No, you are not correct. There are too aspects, one is airport names+positions and the other is parking positions for an ICAO airport.

1) airports:  When PSXT starts it creates (since 13.4) a list of airports (ICAO,IATA,lat,lon) by first searching in the folder indicated by your Airport files folder parameter. If that folder is different from parked_default it will also -if parked_default is available- search the parked_default folder for additional airports. Note that you are free to delete parked_default if you have created you own folder with your airport files.

2: parking positions: When PSXT needs an airport file with parking positions, it will first search in the parked_updates folder, and if no file is found, it will search in the folder indicated by your Airport files folder parameter. That's all.

As you can see, the parked folder of PPG only plays a role if you have assigned that folder as Airport files folder parameter. That is something I would only do if PPG is at the same PC as PSXT.

Nico

 

 

Thanks for the quick reply.

1) OK, clear regarding differences in simulators. I asked this, because I have FlyTampa EHAM installed (and working correctly), but the XML generated by PPG says the data is from ORBX. I do have installed ORBX Global Base, Global Vector, Global OpenLC Europe and TrueEarth Netherlandsat a lower prio than FlyTampa. So I wondered if it had something to do with scenery priorities. I played around with the order of the folders in PPG and it looked like that did make a difference at some moment, eventhough it shouldn't according the manual. But it could have been me getting confused. 🙃 Will look into this a bit more this week.

2) Great, thanks.

3-1) Isn't parked_default always re-created and filled at each new PSXT version? So I have to delete it after each new version (if not saving my own PPG files in parked_default, which I do not), correct?

3-2) Clear

[kiek 1,215]

@1) It should not make a difference, but maybe a bug slipped in, I will look into it too. You can always go around this problem by running PPG once just with P3Dv4 (without add-ons), and then scan the add-ons in the next run(-s).

EDIT: You better download my FlyTampa EHAM.xml, gives you a head-start.

@3-1. There is no need to delete parked_default, a scan for additional airports will not do any harm. Whether an airport is at 8.2345 or 8.2399 does not make a difference in determining what the closest airport is. However, you are free to delete parked_default. In the installer for version 13.5 I will built in an option not to install the airport files in parked_default.

Edited January 29, 2019 by kiek

[kiek 1,215]

PPG version 9.1 is available with a configurable Output folder and improved recognition of ORBX airports.

[Hakkie 0]

Sorry for the late repsonse. Away from the sim a few days. Thanks a lot Nico for implementing the changes. Working fine here!