Parkpos xml - quicker way to get more accurate files

[GSalden 4,656]

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

[kiek 1,215]

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

[kiek 1,215]

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

[kiek 1,215]

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

[Speedbird 217 126]

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.

[Speedbird 217 126]

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? 

[kiek 1,215]

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 

[Speedbird 217 126]

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.

[Speedbird 217 126]

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

[kiek 1,215]

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

[Speedbird 217 126]

31 minutes ago, kiek said:

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?

 

Thanks Nico. The registration match method would work well for me. I have close to 34,000 registrations in a spreadsheet against airline ICAO and they all filter through into the aicraft.cfg atc_id fields read by AILG.

Just to understand the process, are you suggesting something like this?

1. the xml created by AILG is read to compile a Reg=ICAO lookup
2. when doing the steps 1-6 from further above, it reads reg from simconnect, looks up ICAO in the table from 1. and then writes airline+type into the parkpos xml

In my mind that makes sense. I would still like to have an error log of missing regs vs ICAO, so I can hunt them down and add them. There may even be cases where the BGL uses a flightplan from W18 and calls a DLH A320 reg that since has been retired and therefore doesn't feature in my AILG liveries file anymore, so the error log would allow me to make sure it still gets matched against a DLH A320 for parking purposes.

How would this lookup table you talk about be different from the mapping described above?

Edited September 6, 2019 by Speedbird 217

[kiek 1,215]

31 minutes ago, Speedbird 217 said:

Just to understand the process, are you suggesting something like this?

1. the xml created by AILG is read to compile a Reg=ICAO lookup
2. when doing the steps 1-6 from further above, it reads reg from simconnect, looks up ICAO in the table from 1. and then writes airline+type into the parkpos xml

Step 2 is what I suggest (and it reads type from Simconnect), but your first step is not needed. That info is already in AI_liveries.xml, so PSXT could build such a table already now.

I was suggesting that I create an XML by AILG for the users that have no registration codes and add it to the \data  folder, and let it read by PSXT on top of what it already has got from the AI_liveries.xml. But maybe we should start simple with just the info in AI_Liveries.xml.

Another thing that bothers me: Can we trust the aircraft type info in the AI schedules?  In the default trafficAircraft.bgl I see a lot of rubbish combinations of registration code and type.. Should I not only map registration code to airline, but registration code to airline and type?

On the other hand can we trust the registration code in the schedules? 🙂    

 

Edited September 6, 2019 by kiek

[Speedbird 217 126]

1 minute ago, kiek said:

Step 2 is what I suggest (and it reads type from Simconnect), but your first step is not needed. That info is already in AI_liveries.xml, so PSXT could build such a table already now.

I was suggesting to create an XML by AILG for the users that have no registration codes and let it read by PSXT on top of what it already has got from the AI_liveries.xml. But maybe we should start simple with just the info in AI_Liveries.xml.

Another thing that bothers me: Can we trust the aircraft type info in the AI schedules?  In the default trafficAircrfat.bgl I see a lot of rubbish combinations of registration code and type.. Should I not only map registration code to airline, but registration code to airline and type?

On the other hand can we trust the registration code in the schedules? 🙂    

 

Sounds good to me. How would you treat non-matches, i.e. a reg in simconnect is not available in AI_liveries.xml? As a perfectionist I'd like to make sure I get as many perfect matches as possible.

The OCI AI bgls are based on a flightplan and aicraft table unique to each airline. The flightplan has accurate regs for each aircraft type and they are linked to an "AC#X" entry. This entry is then looked up in the aircraft table to find the sim title and place the aircraft. So you'd have a representative schedule for PH-BKA for the week, it is identified by "AC#10" and then the aircraft table has "AC#10 = KLM B787-10".

So that should not be an issue.

[Speedbird 217 126]

On second thought, whilst accurate in terms of what type it is, I’m not sure if aircraft type from the BGL comes in the right format (ICAO), so it may be a good idea to include that in the reg lookup. You have it in the AILG file already.

You don’t want it pulling “Airbus A320-200” instead of “A320”?!

[kiek 1,215]

37 minutes ago, Speedbird 217 said:

Sounds good to me. How would you treat non-matches, i.e. a reg in simconnect is not available in AI_liveries.xml? 

They will be logged and you have to add the registration code to a [fltsim.x] section ...