APRON SERVICES

IMPORTANT! Apron Services are currently a Work In progress and will be getting updated in the coming releases. The core information and methods will not change, but the setup will evolve and be expanded on.

Apron Services is the name given to all those things that move around an airport and provide the required services to aircraft. This includes passenger management, fuel trucks, catering, and all the other things that a busy airport needs to maintain the aircraft and ensure everything runs smoothly. In Microsoft Flight Simulator 2024 this is all handled by Apron Control Units, which are discreet controller instances that get assigned to one or more stands at the airport and then provide and control the services at those stands.

IMPORTANT! For any airport to make use of Apron Control the package must have been created using the Airport asset group. The legacy BGL airport will not use this system.

 

The image below is a schematic overview of how these apron control units are set up and operate:

Essentially, an airport will assign one or more Apron Control Units, as defined when the Airport Object was setup. These units will control general services (like passenger buses), and also create specific Apron Control Contexts when a request specifies it. A request context is created by an aircraft and can include anything specific to that aircraft like a boarding ramp, a fuel truck, or a passenger service. The specific service that an aircraft can request is defined in one of two ways depending on the situation:

• If the aircraft is using a default, built-in service, then the service requests being sent to the apron control context will be based on the options selected in the [SERVICES] section of the aircraft.cfg.
• If the aircraft is using a custom service, or being used in a mission or as part of a challenge, then the appropriate XML file should contain the <SimMission.ApronControlRequestContextAction> element to request the required service from the apron control context.

 

If the aircraft makes two service requests to an Apron Control Unit, then two contexts will be created, one for each request. Each Apron Control Unit can manage multiple request contexts as well as other services related to the stand (or stands) that it has been assigned to. Apart from the context requests that aircraft can make of the Apron Control unit, there may be additional requests or controls created by Mission files, either for the airport, or as part of a simulation mission or career choice.

 

To create your own airport services, you will need to have the following:

• An ApronControlService.xml file, which is where all Apron Services are registered for an airport.
• An ApronService.xml file, which contains the information that the Apron Control Unit needs to spawn and control the service.
• A Service.xml file, which is where each navigation service is registered.
• A NavigationService.xml file, which contains the information that governs how the service will behave and interact within the simulation.
• One or more navigation_graph.cfg files to define the paths and interaction areas that services can use.
• Set up the appropriate TaxiwayServiceStand Objects for spawning the various services.

 

Alternatively, if you don't need any specialised services in the airport, you can simply use the pre-defined apron services, which will only require that you define navigation graphs to be able to use them, as well as the Taxiway Service Stands for them to be spawned. This process is explained on the following page:

• Passenger Transport

 

Finally, some services can be set up as global services, which are services without vehicles and that only deal with people, eg: tarmac workers. For more information, please see here:

• Global Apron Services

 

 

Fallback Services

While you can create your own Apron Control units, every airport in the simulation will also create it's own "default" Apron Control. However, this version of apron control has been created without any specialization related to specific airports services, and is essentially a "generic" apron control unit. This makes it less powerful and less featured than a custom Apron Control, but it permits the airport to keep functioning and offer basic apron services in airports where no custom Apron Control has been created.

 

When creating the XML for the fallback service, it must be put in the same folder as the custom apron service XML, and it should be listed in the ApronControlServices.xml using the FallbackFilename attribute. Note that if your apron service doesn’t use any of the advanced apron control features, you may put the same name in the FallbackFilename as the Filename attribute. The main limitations imposed on the "default" apron control unit are as follows:

 

• The service can’t use existing vehicles in the airport. You will need to create the vehicles your service will use in the XML, and they will be deleted when the service is over.
• You can’t use Airport navigation graphs.
• You can’t refer to Taxiway Service Stands to indicate movement directions.
• Vehicles won’t have a navigation service file to direct their state. The apron service file must handle it all.
• All the other features can be used.