AUDebugINI - orbitersoftware Wiki - orbitersoftware

Debug INI file format

The INI file generally has the format

[ <section> ]

<key> = <value>

Sections

There are currently 2 special sections:

• TAXIWAYS - allows arrays, paths and holds the only collection of end points as well as accepts route definitions
• RUNWAYS - allows arrays and paths; no end points, but accepts route

All other sections allow only arrays, but no paths, end points or route. These sections represent the various building classes and instances of the base. Currently, there are 5 classes:

• HANGAR - the Turn Around Hangar
• LEASE - the lease hangars combined (0-5 Light Storage Hangar, 6-8 Heavy Storage Hangar)
• DRADAR - the doppler radar
• LAUNCHTUNNEL - the Launch Facility & Mission Control
• VERTICALLAUNCH - the Vertical Launch Complex

In addition to every class section - whose definitions apply to every instance of the building - there are instance sections, having the format

<class><instance ID>

with instance ID ranging from 0 to N-1, where N is the amount of buildings on the base of the appropriate class. There is one exception from the format, though: the doppler radar's instance has the letters "TGT" appended to the format, so e.g. the second radar instance is addressed via "DRADAR1TGT".

Keys

There are currently 6 keys:

• BeaconParams - default parameters for arrays
• BeaconParamsX - parameters especially for array X
• BeaconArrayN - coordinates for the Nth array
• BeaconPathN - definition of the Nth path as sequence of arrays
• BeaconEndPointN - text for Nth route end point
• BeaconRouteN - Nth definition for route collection

All keys ending with "N" start from N=0 and end where the key N+1 is missing. There is no limit to the amount of such keys.

BeaconParams are set during coordinate read-in. If no special setting for an array is found, the default setting is used. The TAXIWAYS and RUNWAYS sections treats the parameters in a special way, as the route class handles the parameters globally if you switch e.g. taxiways on/off. The first array's parameters are used to initialize the route class info. All other arrays are then overwritten. BUT: the RUNWAYS section also re-reads the parameters section and overwrites the route setting for directly addressed arrays (by means of BeaconParamsX). This is in order to specify the lead-in strobes. The format for BeaconParams is

<size in meter> , <fall-off parameter> , <period in seconds> , <duration in seconds> , <propagation in seconds>

The BeaconArrayN key sets the coordinates for the Nth array. The TAXIWAYS and RUNWAYS sections use coordinates relative to the logical base origin. All other sections use coordinates relative to the appropriate mesh's origin. The format is

<x> , <y> , <z> <a> , <b> , <c> <R> , <G> , <B> <size>

with <x,y,z> coordinates of start point, <a,b,c> coordinates of end point, <R,G,B> color coding in values of 0-255 and <size> as amount of beacons in the array.

The BeaconPathN key lists the arrays for the given path as comma separated list of array IDs.

The BeaconEndPointN key simply denotes the name of the end point.

The BeaconRouteN key has the format

<path ID> <start point> : <end point> <reversed> <priority>

with <path ID> referencing the path definition to be used, <start/end point> references the end point name to be used, <reversed> in values 0-1 toggling direction of the path and <priority> defining the priority of the path in the route.