Speedbird 217

Parkpos xml - quicker way to get more accurate files

Recommended Posts

Hi Nico,

Currently there are essentially 2 ways to write to a parkpos generated xml file - the initial file created when an airport folder is scanned, and the regular updates with real life parked aircraft as time goes on.

The second option works great for airports where I fly frequently, i.e. my LHR and LGW are very accurate.

The first method doesn’t give me good results at all. I know I can configure ac types in the UI and select airlines by region in a separate file. However, when flying to airports that I don’t frequent much, I get highly inaccurate results that totally kill the immersion. The other day I wanted to do a flight to BLQ and when checking in sim I had about 15 wide bodies from carriers parked there that only flew 320s to BLQ, as well as a bunch of 747 freighters. I then checked DFW and had 4 KLM 747s parked there...

This got me thinking about how to quickly generate more accurate parking XMLs for an airport, including those that one flies to maybe once in a blue moon.

I had the following thought: Is there a way to use .bgl traffic to populate your xml?

Here’s an example - I’ve just installed BLQ. I run parkpos generator to create the xml with the correct positions. I then fire up P3D and turn my traffic slider for bgl to 100%, which means I get a pretty accurate representation of traffic at that airport as my bgls are based on current flight plans. Either through PSXT or Parkposgen a snapshot of my current airport location’s bgl traffic is made and used to update the parking xml similar to how you do it with live aircraft today. This could either be just a list of airline + aircraft type or more advanced by matching airline, aircraft and stand/gate. Whatever is easier to implement, both would be a massive improvement vs today. 

The whole thing takes 2 minutes and before actually flying I turn off bgl traffic again, restart my sim if necessary and use PSXT as today for my flight.

Does this make sense and is it possible? Using the above way you could create very accurate parked traffic snapshots for multiple airports in a couple of minutes. It’s basically turn on bgl traffic, load BLQ, snapshot, write to xml, load next airport, snapshot, write to xml, repeat, turn off bgl, use PSXT as today.

You could maybe even take it even further and i.e. load BLQ at 0800, 1400 and 2000 local to write different times and have more options - just like the live updates do today with their timestamp.

You could then still keep updating those XMLs with real updates as you do today (hierarchy being initial generic file < bgl populated file < live updated file), but it provides a kickstart and also helps at airports where ground coverage is poor so there are no live updates to the parked pos.

Just a thought but it would be amazing if this was possible to get better accuracy and immersion. 

Thanks!

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

58 minutes ago, Speedbird 217 said:

Here’s an example - I’ve just installed BLQ. I run parkpos generator to create the xml with the correct positions. I then fire up P3D and turn my traffic slider for bgl to 100%, which means I get a pretty accurate representation of traffic at that airport as my bgls are based on current flight plans.

What do you mean with "as my bgls are based on current flight plans"?

If I start at EHAM and set the AI traffic slider to 100% I get completely irrelevant airlines and aircraft types ...

Share this post


Link to post
Share on other sites

If you use either one of the payware AI addons or freeware (like the OCI from Alpha India Group) you get hundreds of accurate and recent BGL flightplans for AI traffic. This provides great coverage at the gate, but once they start moving the shortcomings of the BGL method become apparent. When I turn on BGL traffic I have ca. 90% of real world airlines at any airport based on flight plans from the past 2 years or so. My proposal is to snapshot that information and you get an accurate and pretty up to date list of Airline+Aircraft Type+Stand/Gate with a timestamp for any airport you want in seconds.

So being able to temporarily set the BGL traffic to 100% would give you a current snapshot of airline movements at an airport based on schedules. If there was a way to snapshot what's parked at the gate via BGL and feed it into the parked xml you would get the best of both worlds. Once you've taken the BGL snapshot at an airport you just dial back the BGL slider to 0% and use PSXT with an accurate parking xml for an airport. The advantage in doing this would be that it would take you a couple of minutes to create 80-90% accurate xmls based on current BGL flightplans, vs days and weeks of running the live update to the xml. I hope that makes sense? If not drop me a message and I can explain further.

Share this post


Link to post
Share on other sites
2 hours ago, Speedbird 217 said:

If you use either one of the payware AI addons or freeware (like the OCI from Alpha India Group) you get hundreds of accurate and recent BGL flightplans for AI traffic. This provides great coverage at the gate, but once they start moving the shortcomings of the BGL method become apparent. When I turn on BGL traffic I have ca. 90% of real world airlines at any airport based on flight plans from the past 2 years or so. My proposal is to snapshot that information and you get an accurate and pretty up to date list of Airline+Aircraft Type+Stand/Gate with a timestamp for any airport you want in seconds.

So being able to temporarily set the BGL traffic to 100% would give you a current snapshot of airline movements at an airport based on schedules. If there was a way to snapshot what's parked at the gate via BGL and feed it into the parked xml you would get the best of both worlds. Once you've taken the BGL snapshot at an airport you just dial back the BGL slider to 0% and use PSXT with an accurate parking xml for an airport. The advantage in doing this would be that it would take you a couple of minutes to create 80-90% accurate xmls based on current BGL flightplans, vs days and weeks of running the live update to the xml. I hope that makes sense? If not drop me a message and I can explain further.

Aha I see, interesting idea.

So you suggest that the end user of PSXT installs an AI addon, does the Traffic slider 'trick' for say a few minutes (and that a number times during the day), and PSXT should have a mode to detect these AI aircraft at gates and updates the airport file?

Don't you think that many end users will find that too clumsy? It's far from plug and play....

Are these BGL flightplans per Airport or is it one bgl file? 

 

 

 

Edited by kiek

Share this post


Link to post
Share on other sites
51 minutes ago, kiek said:

Aha I see, interesting idea.

So you suggest that the end user of PSXT installs an AI addon, does the Traffic slider 'trick' for say a few minutes (and that a number times during the day), and PSXT should have a mode to detect these AI aircraft at gates and updates the airport file?

Don't you think that many end users will find that too clumsy? It's far from plug and play....

Are these BGL flightplans per Airport or is it one bgl file? 

 

 

 

It's just another option. If users want to continue to only use the generic Parkpos xml plus the live updates that is ok.

For other users that have BGL traffic installed as well (and I would think there are actually quite a few that do, be it payware or the really easy to use free OCI from AIG) it gives them an option to quickly generate highly accurate parking xmls.

I don't know if anyone would install BGLs just for this purpose, but if you have them sitting idle already, then why not use them in this way? I'd venture a guess that quite a few people actually started their AI collection with some sort of add on and now use the models with PSXT. If they still have the flight plans that would work nicely. It doesn't even have to be 100% accurate. For example, if you have flightplan BGLs from 2016 or 2017 for a particular airline, when you load an airport it will still be much more accurate than the generic generation of xmls, because the snapshot will say there are 3x Easyjet A320s, 2x Ryanair B737s and a DHL B757F at this airport at 20:00. This should be quite representative, even if flightplans vary slightly between seasons.

It might also encourage people to share their accurate xmls more, like the couple live ones you already host on your site today.

To your last question - most traffic addons use one BGL file per airline. So when you install with the One-click installer from AIG it automatically installs all the repaints and models for an airline and one BGL with the schedules for that particular airline. If you install them all you end up with hundreds of BGLs for all the different airlines. I believe there are tools and ways to combine them all into one BGL file though if that makes any difference.

In my mind the BGL file itself is irrelevant though, other than to do its job of injecting the traffic into the sim when setting the slider to >0. With my limited understanding of how this could work, I see PSX "interrogating" the sim via simconnect as to what traffic is at the airport. So you load the sim with 100% traffic, the BGLs do their job of injecting it all, and then you snapshot via your tool and get something like "EHAM 20:00 - 28x KLM B737, 15x KLM B738, 7x KLM B744, 1x UAE A380, 1x AFR A320, 1x DLH A319, 2x DHL B757...". I'm not familiar with the detail, but I think it should even give you the stand/parking position coordinates to match? You could then take this information and populate the xml file with it, much like today with the live updates.

Share this post


Link to post
Share on other sites

Would it not be a better idea if ParkPosGenerator reads the OCI traffic bgl's in order to obtain the aircraft at the gate information and put that in the 9914 airport files directly?

Some problems: 

  • I googled for the traffic.bgl format but could not find it.
  • what about copy right?

Share this post


Link to post
Share on other sites

I don't know what's easier. I can send you a sample traffic bgl file later tonight if it helps? If you go straight to the bgl rather than via sim, you would need to read all of them in at once. My bgl folder has 600 or so airline_x.bgl files, so they would all need to be read individually, combined into one and then converted into the individual airport.xml files for PSXT. As I said earlier, there's already tools that can combine them all into one, so it's possible. I guess the advantage of this is that you could create 24/7 coverage for all airports at once. 

I believe the gate information would not be in the bgl itself. The bgl contains airline, aircraft type, dep airport, arr airport, dep time, arr time, days of operation. When the sim reads this it gets injected and the aircraft get placed according to the AFCAD.

My understanding is that copy right should not be an issue as long as this takes place on your own computer and is not used for anything else? So if I have bgls installed and press the button to read them into xml and use them in my sim I don't see any difference to a lot of what happens today already.

There are plenty of tools that decompile traffic bgls and turn them into different flightplan, aircraft and airport .txt files today.

Edited by Speedbird 217

Share this post


Link to post
Share on other sites
32 minutes ago, Speedbird 217 said:

I don't know what's easier. I can send you a sample traffic bgl file later tonight if it helps? If you go straight to the bgl rather than via sim, you would need to read all of them in at once. My bgl folder has 600 or so airline_x.bgl files, so they would all need to be read individually, combined into one and then converted into the individual airport.xml files for PSXT. As I said earlier, there's already tools that can combine them all into one, so it's possible. I guess the advantage of this is that you could create 24/7 coverage for all airports at once. 

I believe the gate information would not be in the bgl itself. The bgl contains airline, aircraft type, dep airport, arr airport, dep time, arr time, days of operation. When the sim reads this it gets injected and the aircraft get placed according to the AFCAD.

My understanding is that copy right should not be an issue as long as this takes place on your own computer and is not used for anything else? So if I have bgls installed and press the button to read them into xml and use them in my sim I don't see any difference to a lot of what happens today already.

There are plenty of tools that decompile traffic bgls and turn them into different flightplan, aircraft and airport .txt files today.

Thank you for your information.

I think the traffic slider way is easier. PSXT already detects third party aircraft. The only thing it has to add is to check, for AI aircraft at the ground, whether they are close to a parking position. If so it can detect the airline from the callsign and together with the type (and the actual utc hour) it has sufficient info to add it to the parking position in the airport  file as a "real time" update!

However, this can only take place in parallel with live aircraft from RT, otherwise the parking airport and the airport file will not be active and it will not check for aircraft in the Sim. But that should not be a problem, and one can always switch of Show GND TFC in RT.

Maybe a checkbox is needed to make this new behaviour active, because it should only be done with AI aircraft based on actual flight plans, and not with the default AI traffic.

Edited by kiek

Share this post


Link to post
Share on other sites

The more I think about it, the more I agree that reading it straight from the sim is cleaner and easier. P3D does a lot of work in the background and uses information from the Traffic bgl, the AFCAD and the respective aircraft.cfg files of each AI aircraft and combines it to inject traffic into the sim.

I like your idea a lot and think it would improve realism and immersion a lot! I have disabled the default P3D traffic.bgl (the one located in World/Scenery) by naming it to *.off anyway. So when I do set the traffic slider to >0 it only injects "real" traffic from airline bgls.

As I said earlier, my gates look realistic and great that way, but any moving traffic is 1,000x better with PSXT - so this presents an opportunity to combine the two and get the best of both worlds.

How exactly does your proposal work then? I currently understand it as:

  1. Start P3D
  2. Set traffic slider to >0 (ideally 100%)
  3. Open RealTraffic and turn off GND TFC
  4. Run PSXT and it will log any bgl injected traffic at the gate into the xml file for more accurate parking
  5. Repeat for any airport and as many different days of the week / times of day you want to improve the xml
  6. Turn traffic slider to 0

Next time I fly, I only run PSXT and I will have my xml updated with the output from above.

If I change the time in the sim while at step 4, it will timestamp different options into the xml, i.e. "09:00 BAW B77W, 14:00 BAW A320, 20:00 BAW A321"? What about when I use time acceleration? I think the traffic bgls support up to 4x, so theoretically traffic runs at 4x.

It also should still continue to update the xml with real traffic after that, correct? So the order would be:

  1. Run Parkposgenerator to create the initial XML file for an airport
  2. Follow steps 1-6 above to create an accurate XML from bgls
  3. XML continuously gets updated each time I fly to that airport with traffic slider set to 0 with live traffic at gates

Share this post


Link to post
Share on other sites
34 minutes ago, Speedbird 217 said:

How exactly does your proposal work then? I currently understand it as:

  1. Start P3D
  2. Set traffic slider to >0 (ideally 100%)
  3. Open RealTraffic and turn off GND TFC
  4. Run PSXT and it will log any bgl injected traffic at the gate into the xml file for more accurate parking
  5. Repeat for any airport and as many different days of the week / times of day you want to improve the xml
  6. Turn traffic slider to 0

Next time I fly, I only run PSXT and I will have my xml updated with the output from above.

If I change the time in the sim while at step 4, it will timestamp different options into the xml, i.e. "09:00 BAW B77W, 14:00 BAW A320, 20:00 BAW A321"? What about when I use time acceleration? I think the traffic bgls support up to 4x, so theoretically traffic runs at 4x.

It also should still continue to update the xml with real traffic after that, correct? So the order would be:

  1. Run Parkposgenerator to create the initial XML file for an airport
  2. Follow steps 1-6 above to create an accurate XML from bgls
  3. XML continuously gets updated each time I fly to that airport with traffic slider set to 0 with live traffic at gates

Steps 1 to 6, that's the idea indeed; note that turning off GND TFC is not mandatory.

Steps 1 to 3, correct.

Your ideas about time are not correct I'm afraid. PSXT takes the utc time from RealTraffic when adding info to the airport file (that's why this mechanism also works with shifted time...).

You have to synchronise your P3D time with the time in Real Traffic, otherwise the aircraft in the BGL schedules will get wrong timestamps when promoted to a parking position option. Note also that you cannot run PSXT + RT in accelerated time.

 

Edited by kiek

Share this post


Link to post
Share on other sites

Thanks Nico. I think it's fantastic how you listen to feedback and try to implement new features.

The above makes sense. So let's say I want to create a morning, afternoon and evening snapshot at KDFW. I would follow steps 1-6, load KDFW but need to do the following:

  • Morning snapshot - set time in P3D to i.e. 03-Sep-19, 09:00 UTC and sync in RealTraffic to 03-Sep-19, 09:00 UTC using the time offset feature for the past. I now have my morning snapshot from the bgl files
  • Afternoon snapshot - set time in P3D to i.e. 03-Sep-19, 14:00 UTC and sync in RealTraffic to 03-Sep-19, 14:00 UTC using the time offset feature for the past. I now have my afternoon snapshot from the bgl files
  • Evening snapshot - set time in P3D to i.e. 03-Sep-19, 20:00 UTC and sync in RealTraffic to 03-Sep-19, 20:00 UTC using the time offset feature for the past. I now have my evening snapshot from the bgl files

It therefore makes sense to do it for a date in the past, so you can sync P3D and RT time using the time offset. That's why I chose yesterday's date in my example above. Correct?

Share this post


Link to post
Share on other sites
50 minutes ago, Speedbird 217 said:

It therefore makes sense to do it for a date in the past, so you can sync P3D and RT time using the time offset. That's why I chose yesterday's date in my example above. Correct?

Correct!

Share this post


Link to post
Share on other sites

This idea for creating real parking options sounds REALLY great, but I can't help but think that the fastest and most seamless method would be a special feature of PPG to read OCI traffic bgl's. With this method, all parking options are built at once. I'm sure this would necessitate much more work for you, Nico, but it would really be a fantastic tool.

In any case thanks to Max for such a brilliant idea...Max I need inventive people like you working for me...need a job?

I'm am absolutely going to give this a try tomorrow evening and see what I get!

Kind Regards,

Share this post


Link to post
Share on other sites

A great idea.

But it will be as good as the Afcad files are. And often they are not correct : wingsize / airline different from reality.

Surely some developers have done a nice job or users have improved versions.

So the schedules might be good so the correct AC/airlines will show up, but the places where those AC are being parked would be randomwise. Unless PSX is able to overwrite them over time like it does now..

 

Edited by GSalden

Share this post


Link to post
Share on other sites

Nico, just to clarify; is the above process (steps 1-6) already possible without limitations today or are you working on an update to facilitate this properly?

2 hours ago, somiller said:

In any case thanks to Max for such a brilliant idea...Max I need inventive people like you working for me...need a job?

Ha, thanks! I’m afraid I already have a job.

I agree that the most efficient way would be to go straight into the BGLs, as you have described. There are a couple of issues that would need to be solved first though. I listed them a few posts above, but the main ones are around the way P3D takes the BGLs and combines that information into the AI traffic it injects into the sim. Nico would need to have to read all BGL files, decompile them, look up the aircraft.cfg files to match the aircraft title from the decoded BGL to an airline (=ICAO) and then analyse the AFCAD file for each airport to decide where to place the aircraft.

That sounds like a huge chunk of work for Nico. Sure, the advantage would be that you instantly get 24/7 coverage at all airports worldwide. Either way, the method mapped out in this thread allows us to get much more accurate parking files much quicker than before. At least we won’t have 5x Cargolux 747-8Fs and 2x BA A380s parked at Inverness and only get airline/type combinations that actually operate at an airport.

1 hour ago, GSalden said:

A great idea.

But it will be as good as the Afcad files are.

Thanks, and of course you are right.

This method should still be magnitudes better than the current generic approach. As you say, there are improved AFCADs out there, and Nico has confirmed here that XMLs populated via BGL will continue to receive live updates.

Share this post


Link to post
Share on other sites
43 minutes ago, Speedbird 217 said:

Nico, just to clarify; is the above process (steps 1-6) already possible without limitations today or are you working on an update to facilitate this properly?

Ha, thanks! I’m afraid I already have a job.

I agree that the most efficient way would be to go straight into the BGLs, as you have described. There are a couple of issues that would need to be solved first though. I listed them a few posts above, but the main ones are around the way P3D takes the BGLs and combines that information into the AI traffic it injects into the sim. Nico would need to have to read all BGL files, decompile them, look up the aircraft.cfg files to match the aircraft title from the decoded BGL to an airline (=ICAO) and then analyse the AFCAD file for each airport to decide where to place the aircraft.

That sounds like a huge chunk of work for Nico. Sure, the advantage would be that you instantly get 24/7 coverage at all airports worldwide. Either way, the method mapped out in this thread allows us to get much more accurate parking files much quicker than before. At least we won’t have 5x Cargolux 747-8Fs and 2x BA A380s parked at Inverness and only get airline/type combinations that actually operate at an airport.

Thanks, and of course you are right.

This method should still be magnitudes better than the current generic approach. As you say, there are improved AFCADs out there, and Nico has confirmed here that XMLs populated via BGL will continue to receive live updates.

Your idea would help with airports where pilots shut of their transponder already at the end of the runway. So PSX cannot update the airport files.

Now I an doing mods myself in some airport files like Bodrum, Turkey ( just went there on holiday )...

Share this post


Link to post
Share on other sites
3 hours ago, somiller said:

I'm am absolutely going to give this a try tomorrow evening and see what I get!

Wait a minute, it is not yet implemented, we're talking about ideas ;-)

 

Edited by kiek

Share this post


Link to post
Share on other sites
3 hours ago, GSalden said:

But it will be as good as the Afcad files are. And often they are not correct : wingsize / airline different from reality.

It will be as good as the info in the Schedules.

PSXT will only park an aircraft if the wing size of their type fits the parking position, so that is not a problem (as long as the type is correct).

However, if the gate is wrong I cannot do much, PSXT will add airline and type at that wrong gate with the label real=true (just like it does for live aircraft), and this will not be corrected later on... (not a problem for "Bodrum like airports" though...)

Edited by kiek

Share this post


Link to post
Share on other sites

I have managed to get this far for the default AI traffic in P3Dv4 at EDDF:

"D-ASZU has correct type CRJ7 at gate G5"

My problem is that I only get a registration code (D-ASZU) instead of a callsign from which I have to derive the airline code ....

Is that the same for AIG's traffic/flightplans? What do you see when you open P3D->View->Change View->Air Traffic? 

Edited by kiek

Share this post


Link to post
Share on other sites

I will check tonight what the view says with OCI traffic.

Surely the airline parking code (ICAO) must get processed somewhere, not least because without it the AFCAD wouldn't know where to put the object.

Share this post


Link to post
Share on other sites

Another thought - you're saying "default traffic". So I'm assuming you're testing with the default traffic.bgl which uses those fictional airlines and default simobjects?

Could it be that the aircraft.cfg of the default traffic simobjects doesn't have the "atc_parking_codes=XXX" line for fltsim.x entries? If it doesn't, can you add it and see if that changes what you see in the sim? 

Share this post


Link to post
Share on other sites
23 minutes ago, Speedbird 217 said:

Could it be that the aircraft.cfg of the default traffic simobjects doesn't have the "atc_parking_codes=XXX" line for fltsim.x entries? If it doesn't, can you add it and see if that changes what you see in the sim? 

They do not have that line indeed. I've added atc_parking_codes=KLM but no luck...

The ATC ID field in SimConnect for the default AI contains the registration code.

In SimConnect there is only one other field ATC AIRLINE which describes the airline in a string of max 50 chars, so not the ICAO code. There is no callsign field...

Note that PSXT creates AI aircraft with the callsign as ATC ID, and that is what you see in Change View-> Air Traffic 

Share this post


Link to post
Share on other sites

Thanks Nico.

I'll let you know tonight what OCI looks like in sim and whether if features ICAO airline codes.

Atc_airline=xxx is the callsign. Callsigns should be standardised and unique, so a simple lookup against ICAO might be a workaround if the ICAO code does indeed not feature? Example, atc_airline=SPEEDBIRD, lkup SPEEDBIRD=BAW.

Share this post


Link to post
Share on other sites

I just had a look in sim. The string in the view menu shows as "Airbus A319-100 - G-EUPP". So you are right, it doesn't include the ICAO airline code.

They are still used to position the aircraft according to AFCAD, so they must be processed somewhere in the inner workings of the sim.

I guess this brings me back to my previous point, you could either look up the ICAO via the registration (more tedious) or via the callsign (simpler). When I say callsign, it's the radio callsign for the airline only, without flight number. So SHAMROCK, SPEEDBIRD, KLM (that one actually works ha) or AMERICAN.

I'm thinking along the lines of having a lookup xml in the format "Callsign = ICAO". There are already plenty of extensive lists out there, I'm happy to help if you want to test this method. Some examples are here in column 4 https://en.wikipedia.org/wiki/List_of_airline_codes. If you come across one of the few small airlines that may not have a callsign, the logic could either generate a generic "PVT/GOV" or the user could just add a unique callsign to that small airline in the aircraft.cfg and define it in the xml lookup, i.e. " Atc_airline = GENERIC1" and then add "GENERIC1 = XYZ" to the xml. It might be useful for the logic to print any non-matches to an error file, so it's easier to hunt down missing ones.

Storing it in an xml would have the advantage that it's easier to add/edit callsigns similar to the way you already do it for airlines and aircraft types. You could then read the info from the sim, look up the ICAO via callsign and then write to the parking xml. Would that work?

Edited by Speedbird 217

Share this post


Link to post
Share on other sites
15 hours ago, Speedbird 217 said:

I guess this brings me back to my previous point, you could either look up the ICAO via the registration (more tedious) or via the callsign (simpler). When I say callsign, it's the radio callsign for the airline only, without flight number. So SHAMROCK, SPEEDBIRD, KLM (that one actually works ha) or AMERICAN.

Unfortunately the radio callsign is not available via SimConnect, just the name of the airline (in all sorts of ways of writing I'm afraid) . The only possible way forward (with the "slider method") is to use the Registration code...

It is rather easy to let PSXT build up a mapping of registration code, defined in your liveries, to the ICAO codes of the airlines, just as it already does for livery title. An advantage of that method is that after an airline/type has been added to the airport file you can be sure that PSXT will find a livery to put it on that spot later on.

However, this method does not work very well for users that have litlle or no registration codes defined in their liveries.The FLAi package for instance does not have many. I have about 6500 registration codes for 2900 liveries so for me it will work well.

Another option is a lookup table. I could create an initial one out of the ..\info\AirlineData.txt file created by AILG, and add it to the data folder of PSXT.

What do you think?

 

Edited by kiek

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.