AIRPORT SERVICES

Airport Services describes service vehicles creation and behavior, as well as some other parameters for airport life, and Idle Workers generation and behaviors.

 

Actual services are usually vehicles that can interact with the aircraft, such as pushbacks, baggage services, fuel trucks, etc... Such services can be available for some aircrafts but not others, as determined in their aircraft.cfg file. When interacting with an aircraft, most services use the aircraft's interactive_point.N to properly connect to the aircraft.

 

You can find further information on the airport services XML form the following sections, and below we give a high-level overview of some things to take into consideration:

 

 

 

Basics

Airport services are described by a file called Services.xml and several XML script files. The Services.xml file should be exported under AirportServices\Shared or AirportServices\ICAO, where ICAO is the airport's ICAO code. The script files can be anywhere in the AirportServices folder or sub-subfolders.

 

The Services.xml main file describes what services will be created at each airport (and mention the script files to use them), as well as the parameters controlling the position and frequency of creation of such services. A file in Shared will describe any airport that does not have a specific folder named after its ICAO code in any package.

 

In order to include such files in your own package, just make sure your package contain a direct folder named AirportServices, which contains one or multiple folders whose names are ICAOs or Shared, and that each of these subfolders contain a file Services.xml or Services.spb (*.spb are compiled *.xml). Also make sure any script file (xml or spb) is contained in AirportServices or one of its sub-folders. We recommend using a unique prefix (such as your company name) to name your script files.

 

Note that, although your Services.xml file(s) will partially or totally override any previous similar Services.xml, the Shared\Services.xml will not override any airport-specific Services.xml. However, airport-specific Services.xml that are only partially filled will use the Shared\Services.xml for missing sections.

 

 

Main File: Services.xml

The main file in a Services folder (whether Shared or an ICAO code for some airport) is named Services.xml. The details of its configuration are available in the XML Definitions, but here is an informal description...

 

This file is comprised of two main parts :

The second one, <Service.AirportServices>, is simpler and lists some services that are available to the whole airport, as well as where to spawn them. Currently in Microsoft Flight Simulator it is only used for Fuel Trucks, which are the only type of service with an AI able to travel across the airport.

 

The <Service.ParkingSpaceServices> contain a list of <ParkingSpace>, each one corresponding to one or several types of parkings. Each such <ParkingSpace> then describes the IdleWorkers and Services that can spawn around this type of parking, as some <SleepingActivities> defining parameters for Parked Aircrafts behaviors.

 

Each Service describes some parameters regarding spawning, and reference a script file that will actually create objects and possible additional behavior. More details on this script file can be found in the Service Script Files section, below.

 

IdleWorkers are actually divided into <Spot>s, and each <Spot> describes some spawning parameters and contains a list of possible script files to use. For each parking in an airport, each <Spot> will spawn one of these scripts at random, or nothing at all (based on frequency and options density).

 

About Overriding

For the Shared.xml file, it is possible to only partially fill it with data, and have it only override parts of the default file. More precisely, any parking type not mentioned will keep its original behavior. Moreover, for specified parking types, a missing section among <IdleWorkers>, <Services>, and <SleepingActivities>, will result in this section keeping its original values, contrary to such a section being present but empty. The same is also true for the <Service.AirportServices> section, which will keep its original values if not specified.

 

 

Service Script Files

A Service script file uses the same scripting options as a mission.xml file. In a main <WorldBase.Flight> element, it should generally contain a <Service.GroundService> to create the main object of the service, and can also contain a <Service.GroundService> to trigger some scripts based on the AI state.

 

The main behavior of the services is determined by the AIType and code in Microsoft Flight Simulator. Scripts can be added for additional behavior, and are necessary for proper initialization and creation of the objects.

 

A <SimContain.Container> will be created at a spawn position defined by the parameters in Services.xml, as long as it has a correct <AIType>. If other objects (whether <SimContain.Container> or <SceneryObjects.LibraryObject>) are also created, we recommend for good practice to use an <AttachedWorldObject> in order to spawn them relative to the first object. If an object is not of a correct AIType and not attached to another object, its base position will be the center of the parking.

 

Some generally useful option is to also create a human character as a pilot (or driver) for a service vehicle. In this case, the human object should have an <AttachedWorldObject> reference to the vehicle, and have:

<HumanPilotAI>
    <HumanPilotType>Pilot</HumanPilotType>
</HumanPilotAI>

This will determine its position in the vehicle based on the vehicle configuration, as detailed here:

 

 

IdleWorker Script Files

IdleWorker script files are very similar to Service script files. They do not use <Service.GroundService>, and the AIType of the IdleWorker objects should be IdleWorker. Contrary to Services, their AI has no actual behavior in Microsoft Flight Simulator code. This means that, by default, they will just stand doing nothing. The script file will thus entirely determine their behavior.

 

The two most useful script actions for IdleWorker are probably <SimMission.PlayBlendTreeStateAction> and <SimMission.ActivateWaypointsAction>. The first one asks the object to play an animation by referencing its BlendTreeState name (see Model Animation Definitions for more information). The second one asks the object to walk through a series of waypoints, which should generally use <LocalOffsetXYZ> to be positioned relative to the initial spawning position of the IdleWorker.

 

 

How Services And IdleWorkers Are Generated

All services take into account the "Airport Vehicle Density" option in Microsoft Flight Simulator, and IdleWorkers use the "Worker Density" option (both are located in the General > Traffic category of the in-sim options menu). Both multiply this density by their own frequency (defined in Spot for IdleWorkers) to serve as a base to determine whether or not to create an object, but more criteria exist.

 

Airport Services

For each parking of the corresponding type, a Service is created with a probability equal to density*frequency. However, there is an exception: the first such parking found in the airport will always create a service (for each airport service type). This is to ensure each airport has at least one FuelTruck even if the density option is low.

 

Parking Services

Initially (when getting close to an airport), each parking will generate some Services with constraints (see below). Later, whenever an aircraft reserves a parking through ATC, the services of this parking are automatically re-generated in order to better match the aircraft needs. When an aircraft un-reserve a parking (by announcing to ATC it will leave this parking), the services remain unchanged.

 

During generation, if a parking is reserved by an aircraft, only services relevant to this aircraft can be generated (as defined in its ai.cfg file), others are ignored. Empty parking spots can generate any type of services. In any case, services are not generated if the parking overlaps (or near-overlaps) another parking that is reserved or already has spawned services.

 

Finally, each service (individually) will be created with a probability equal to density*frequency for parking reserved by aircrafts, a probability of 1 for a parking reserved by the User (including if the density or frequency is 0!), and a probability of density*frequency*FrequencyOfServicesOnEmptyParkings for empty parking spots, where FrequencyOfServicesOnEmptyParkings is defined in the Living World General Settings.

 

Note that, since the User-reserved parking will always generate the relevant services for the User aircraft, a Service with a frequency of 0 can be defined in order to have this Service be created only for the User.

 

IdleWorkers

IdleWorkers are only generated on parking reserved by an aircraft. For each Spot, an IdleWorker is generated with probability density*frequency. If an IdleWorker is indeed created on a Spot, a random one is chosen among the list of possibilities, taking the entryWeight into account.

 

When an aircraft un-reserves its parking (when informing ATC about its intentions to leave the parking), the IdleWorkers are destroyed, except if the aircraft was the Users. This is to prevent having IdleWorkers hanging around empty parking spots, which could break the immersion, and can become more noticeable if Microsoft Flight Simulator is left running for a long time with some AirTraffic active.