Apron control - How to add more than one airline per stand/gate/ramp?

Hi!

Currently experimenting with setting up a proper apron control setup, including airlines for each gate. The SDK is a but unclear on this. Quote:

“After adding the code, click on Add to have it registered with Apron Control. Note that the parking spot object requires at least one airline code to be assigned to it, but you can add multiple airline codes and then switch between them if required, although only one of them will be used at any time.”
Source: TaxiwayParking Objects

Does that mean that only one single airline PER GATE can be assigned at the same time? I have tried multiple approaches through the GUI and XML code but this actually seems to be the case. Unfortunately the SDK Sample Airports do not contain any apron control setups for orientation.
This would be a serious limitation most gates share asignments for a large number of different airlines, see this example of a single gate in my scenario:
EZY,EJU,EZS,EWG,EWL,EIN,MSC,AMC,ASL,BAW,LZB,DAL,MSR,ELY,FIN,FIA,CHH,ISR,KLM,KLC,MGL,LBT,SXS,TWI,TAR,THY

1 Like

In MSFS2020 and before you can/could have as many airlines as you want and I believe it would be the same with FS24. There is currently a bug in FS24 where it appears that a gate with assigned airline(s) is not honoured but Asobo is working on this.

1 Like

I assume you refer to the “airlineCodes” in the XML properties, but those it seems are entirely different thing to “apron control” that controls GSE at the gates.

To a the assignment of an airline code is now possible in two locations for each stand:

This is quite confusing as it is not clear:

  • Which of both takes precedence.
  • How it is possible for the apron services to add more than one airline per stand

Yes, I was referring to the airline codes and I saw the two different parameters, and, like you, I understand that I don’t understand exactly what it means. Misobo complicates things with additional parameters that seem redundant because they are not explicit and detailed enough.

1 Like

I eventually removed all apron control values from my taxiway parkings again (apronControlIndex and passengerAccessType) as frustratingly they seem to cause CTDs and non-working jetways with the Inibuilds A320neo and other Inibuild default aircraft.

After removing those values I haven’t seen anymore CTDs with those and both custom and “ASO_Jetway” (default jetway) work again.

When I did what you are asking in 2020, I followed the example from FSX, I forget where I got it, I think the SDK from Lockheed, and, like you, separated multiple airlines by commas in the field. In 2020, the scenery editor did not support this function, at least not at the time, so I edited the parkings by hand in the project file before I compiled it. I don’t know if 2020 actually did anything with the data (it seemed to ignore it), but, I didn’t get CTD’s, and I felt good that I had coded for it, even if it didn’t work.

For what it’s worth: Airline codes are described in the MSFS2024 as working (whereas pushback tags for example are described as a not working legacy setting):
https://docs.flightsimulator.com/msfs2024/flighting/html/5_Content_Configuration/Environment/Airports_And_Facilities/Taxiway_XML_Properties.htm

Question though is if they do work as intended as users still mention that airlines are not properly parked at the applicable gates or at least not prioritized there.
Meaning if a gate has a particular airline assignment that doesn’t necessarily mean that it’s first spawned there before before filling other parking positions with no airline assignments. Unfortunately the logic behind that is not described in the SDK.

1 Like

I really don’t understand what’s going on with this “apron control” system.
Being an ADE boy, I managed to import the ADE project and build it into the MSFS2024 devmod.
My gates with their assigned airlines are well recognised in MSFS2024, but strictly transparent in the devmod/editor
Here is an example of a given gate from ADE for MS2020 (inherited from FSX) in the XML:
TaxiwayParking parentGroupID=“1” groupIndex=“634” index=“84” type=“GATE_HEAVY” lat=“49.00241568317740” lon=“2.56999909660667” heading=“343.000000” radius=“40.000000” name=“GATE_C” number=“14” suffix=“NONE” numberMarking=“TRUE” has3DMesh=“TRUE” drawDirt=“TRUE” numberBiasX=“0.000000” numberBiasZ=“0.000000” numberHeading=“0.000000” airlineCodes=“AIC,SZN,RJA,UAE,QFA,BAW,GFA,TAM,LAN,VTI,ETH,ACA,ACI”/>
FSLTL is working well and all the airlines are going where they are supposed to according to the XML.
I’m currently testing the apron control thing and it seems to be a dead end.
I have added two airline codes/apron control (AFR and WXC - fictitious) and… nothing. It’s well in the XML, but here :

AirportArchetype archetypeGUID=“{3B5C950E-F266-4AE7-A37E-A0F8AC6725C9}”/>
ApronControl airlineCodes=“AFR”/>
ApronControl airlineCodes=“WXC”/>
and, in the TaxiwayParking stuff, it creates a new : apronControlIndex="2"and that is all.
Try to understand…
Icing on the cake, it seems that we can’t delete this data in the parking properties, except via the XML… and so back to the desktop and deleting the entries inside the XML.

1 Like

And technically, just because it’s written in the SDK it doesn’t mean the code for it was actually finished. There is much that got into the SDK documentation that “shouldn’t” be there, per se (hopefully… yet).