Airline coded parking

[Yapoyapo2]

Oh no, I hope it‘s just the issue with the wingspan. I thought they adjusted the issue that the heavier planes are just in gate E or B and that the smaller planes in lszh, like lufthansa, air croatia, tap portugal, air france etc. are in gate A or at the ramp. Well but thank you for your explanation.

[Ankh]

I hope it‘s just the issue with the wingspan.

It is, just tested it with the default wingspan and AIG. Now heavies are back at Terminal E as they should. Bummer, as for most other airport sceneries I have installed, using the reduced wingspan actually improves things a lot, just not in LSZH. Seems that MSFS first fills gates according to the size and then only in a second step considering the parking codes. Or whatever, it seems that this whole AFCAD/ADE story is a mess in MSFS anyway.

[virtuali]

But in my case, all heavies are sitting on Terminal A or B or close to the hangars south of RWY34. Means: completely wrong.

And since the radius we set in the scenery are of course correct and they always have (not a single gate on Terminal is bigger than 25m radius or 26m at B, with many of them smaller, the only ones bigger than 30m are on E), we just added the airline codes in this update, if you see heavies in the A or B, it clearly nothing we can likely fix.

Parking codes are only helpful AFTER whatever other criteria used to assign a gate, and my guess is that MSFS is even ignoring the radius, before it will just have an AI disappearing, for example of all gates that are big enough for its size are already taken.

Now you are adding another variable, which is the AIG program. This means it reads the airport .BGL directly? Or it uses the official Navdata API? Because, assuming it IS reading the airport information to handle and assign traffic, there are only two possible outcomes:

- If it reads the airport .BGL directly, it CAN read the airline codes (assuming it's programmed to do so), but then it won't work with Marketplace airports.

- If it uses the official Navdata API, it will work with Marketplace airports, but then it can't read the airline codes, since the Navdata is not supplying those.

- The last option is, of course, it doesn't use airline codes in the first place, so it relies on MSFS hopefully doing something with those, which again it really depends how much priority is given to them, surely even in FSX or P3D, they had the lowest priority, with parking radius vs airplane size being the most important one.

[Ankh]

Now you are adding another variable, which is the AIG program. This means it reads the airport .BGL directly? Or it uses the official Navdata API? Because, assuming it IS reading the airport information to handle and assign traffic, there are only two possible outcomes:

- If it reads the airport .BGL directly, it CAN read the airline codes (assuming it's programmed to do so), but then it won't work with Marketplace airports.

- If it uses the official Navdata API, it will work with Marketplace airports, but then it can't read the airline codes, since the Navdata is not supplying those.

- The last option is, of course, it doesn't use airline codes in the first place, so it relies on MSFS hopefully doing something with those, which again it really depends how much priority is given to them, surely even in FSX or P3D, they had the lowest priority, with parking radius vs airplane size being the most important one.

Slightly suprised about those questions Umberto, or what was the airline code update intended for if not for AIG and/or FSLTL? Neither one uses .bgl or Navigraph API, they simply inject aircraft into MSFS and from the moment they are injected, they are completely handled by MSFS itself. Of course, all AI planes have their correct gate and airline designators within their individual aicraft.cfgs.

BUT the problem of MSFS parking radius is that gates are smaller as they are because (I cite from discord): "of ground service vehicles - the virtual gates on MSFS have got an additional exclusion zone of 6ft (I guess) which makes gates artificially smaller as they are, so a gate which should be large enough to accommodate an A320 by the value entered by scenery designers is too small in sim. While that could be covered by making the virtual gate markers larger this leads to another issue on airports like DBX on which gates are sitting right next to other gates - when the virtual gates overlap and one of the overlapping gates already is occupied the other gate won't be used. In worst case this leads to only half the gates a terminal features to be used by ai"

As I wrote, I am no expert but I can observe. And while FSDT LSZH looks perfectly fine using 1.6.5 with the airline codes, it becomes a complete mess when using reduced wingspan option in AIG and I wonder why.

[Yapoyapo2]

First of all I want to mention I‘m not a developer and I don‘t have any clue how complex this whole process of building a flightsimulator with its addons can be. But wouldn‘t it be possible to adjust the gate size in order to make it work with die AIG wingspan mod? I mean as Ankh mentions, the developer of MSFS2020 has defined a buffer zone of 6m. Technically speaking, you could reduce your actual correct gate sizes by reducing it 6m. This very very simple solution could maybe lead to a better compatibility between the updated version of LSZH (1.6.5) and the adjusted wingspan. Is this to simple? Sorry if it‘s a dumb idea. It was just the first thing coming to my mind. But I thought why not giving it a try.

[Ankh]

I just discussed it with Kai over at the AIG discord and he confirmed that using reduced wingspan would need an adjusted AFCAD on some airports while others are fine out of the box. Bummer, but I am back to normal wingspan then, doubt that so many scenery designers are keen to offer two AFCADs for their sceneries...

EDIT: if of any relevance for you, Umberto, one of the cracks over at AIG added the following information I was not aware about: "Quick tip for airline codes, each airline position is also its priority for spawning in sim

For example: airlineCode"KAL,SHU,CES,SPA,EVA,CAL,CCA,TAX,HAL,THA,TWB,CRK,CQK,CQH,XAX,GCR,ABL,JJA,AAR,TGW,DKH,ASV,MXD,CSN,CSZ,OKA,CDG,FIN,CXA,CXA,CSC,TTW,SJX"

KAL=Priority 1
SHU=Priority 2
CES=Priority 3
SPA=Priority 4
EVA=Priority 5 and so on.

With that behaviour, every other airline will try to park before SJX. It's recommended that you at least randomize the order of every gate's airline code or find the specific spot for each airline as per real-world ops. When an airline is coded so far back, sometimes it will park itself in a remote stand or a gate that isn't coded at all"

Still does not explain why it goes total nuts when using the reduced wingspan, but then...

[Yapoyapo2]

And how well is this update working with FSLTL?

[Ankh]

And how well is this update working with FSLTL?

I guess equally well (or bad) as with AIG, as FSLTL uses the exact same approach by having parking and airline codes included in their AI plane aircraft.cfgs.

[Yapoyapo2]

Well that seems a bit strange. Just tried out the new version 1.6.5 with AIG (without the adjusted wingspan) and I have a lot of small planes like a320, a220, embraer of Helvetic, Lufthansa, TAPortugal, etc. in Gate Eco which is incorrect. Umberto, wouldn‘t it be possible to differentiate between heavy planes and smaller planes like for example is there something you could do, to tell the program only SWISS heavy planes should park at Gate Eco and not the smaller ones. Furthermore I noticed that I don‘t get Traffic or just 1 plane in Terminal A and B. What settings should I use? Thanks a lot.

[virtuali]

Umberto, wouldn‘t it be possible to differentiate between heavy planes and smaller planes like for example is there something you could do, to tell the program only SWISS heavy planes should park at Gate Eco and not the smaller ones.

As I already replied before, the only thing we can set that would (or *should*) differentiate heavy airplanes from others, is the parking radius and, as I also already replied, parking radius in the scenery are of course correct so, NO heavy airplanes should park anywhere other than Terminal E.

That is, assuming the parking radius works as one expects to, as a comparison between the parking radius and the airplane wingspan.

[Ankh]

Back in FSX/P3D days, when modifying AFCADs was easy, I achieved this by using the "X" designator specifically. E.g. I changed all "atc_parking_codes" for my SWISS AI planes to SWRX instead of SWR only and adjusted the AFCAD of LSZH in such way, that only the SWRX planes were allowed on Terminal E and only the SWR planes on Terminal A and B. This was the only option to have no A32x or A220 from SWISS sitting on Terminal E and no heavies on Terminals A and B. With the exception of the Swiss 777, which is quiet often sitting on Terminal B though...

This system has its limitations, it is simply not possible to cover everything up worldwide, and for a real good solution, you need to adjust both AI traffic planes aircraft.cfgs AND the AFCAD. Bummer that modifying AFCADs is such a hassle in MSFS...

[Yapoyapo2]

Do you think this will be better in MSFS2024 or BATC?

[Ankh]

Do you think this will be better in MSFS2024 or BATC?

I doubt. If I am not mistaken, BATC wont do any parking of AI aircraft on their own, it will be based on the MSFS ADE/AFCAD as well. But if they do, it might be better (comparable to PSXT Traffic maybe?). MSFS 2024 will for sure be based on the very same technique regarding ADE/AFCAD, so coming with the same drawbacks. It is simply impossible to have the data needed in the sim, even PSXT Traffic needs hours of "learning" per airport to get it straight and in regions with bad coverage, it never will.

And to be honest, if you have a good set of AI planes with correct and useful designations in the aircraft.cfg (which is true for both FSLTL and AIG), and you have a good ADE/AFCAD, the result is still pretty neat even if it will never be 100% accurate.

[virtuali]

Whatever ATC/AI add-on that will come out, will have to face the same issues we had with GSX initially, for other reasons, but the issues are the same:

- If the add-on uses the official way of getting data about the airport, which is the Navdata API, it won't get any info about parking codes, because parking codes are just not returned by the API. It will have to work with just the parking radius.

- If the add-on wanted to be extra-accurate and use also the parking codes to assign AI, it would have to do what we USED to do in GSX (and still do in FSX/P3D), that is scanning all installed sceneries and open the .BGL directly. Which can be tricky and have other issues as well, and it won't ever be compatible with encrypted airports bought on the Marketplace, which was the main reason the Navdata API has been introduced.

So, the only chance that an ATC/AI add-on could *possibly* become smarter and improve over the default AI parking assignment, is that Microsoft would add airline codes to the Navdata API, that would be the first step of making such add-on possible.

[Ankh]

Whatever ATC/AI add-on that will come out, will have to face the same issues we had with GSX initially, for other reasons, but the issues are the same:

PSXT Traffic does NOT have this issues as it "trains" itself based on RL data and currently, the already trained airport list is around 12'000 airports worldwide, both addons and default. But of course, it is quiet costly.