Parkpos xml - quicker way to get more accurate files

[Speedbird 217 126]

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!

[kiek 1,212]

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 ...

[Speedbird 217 126]

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.

[kiek 1,212]

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 September 4, 2019 by kiek

[Speedbird 217 126]

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.

[kiek 1,212]

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?

[Speedbird 217 126]

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 September 4, 2019 by Speedbird 217

[kiek 1,212]

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 September 4, 2019 by kiek

[Speedbird 217 126]

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

[kiek 1,212]

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 September 4, 2019 by kiek

[Speedbird 217 126]

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?

[kiek 1,212]

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!

[somiller 694]

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,

[GSalden 4,655]

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 September 5, 2019 by GSalden

[Speedbird 217 126]

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.