simulator:text_files [Aerofly FS Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Editable Text Files ======

The Aerofly FS 2 uses readable text files with specific file extensions for the definition a lot of its' content. Those files can be opened with Unicode capable text editors and are written using the Aerofly specific syntax.

The following file extensions are text-files used by the Aerofly FS 2:
  * [[aircraft:tmd|TMD]] - aircraft definition files
  * [[aircraft:tmc|TMC]] - aircraft description files
  * [[sdk:scenery_tsc|TSC]] - scenery and object description files
  * [[simulator:mcf|MCF]] - main simulator configuration files
  * [[simulator:log|LOG]] - simulator text output file (is generated)

===== Recommended Text Editors =====

For editing all Aerofly FS 2 text files the IPACS development team recommends using one of the following UNICODE capable text editors.

   * Visual Studio 2019
   * [[https://www.editpadlite.com|EditPad Lite/Pro]]
   * [[https://www.ultraedit.com|UltraEdit]]
   * [[https://notepad-plus-plus.org/|Notepad++]]
   * Windows Wordpad

===== Language =====

Throughout all files of the Aerofly FS 2 English is the language of choice. Descriptive names that are usually separated by white spaces in the common language or hyphens are usually written in CamelCase in the Aerofly FS 2 files. This means that the spaces and hyphens are left away and the following letter after the separation is turned into an upper case letter instead.

===== Units and Coordinate Systems =====

Aerofly FS 2 uses the international system of units (SI) exclusively. This means that all lengths and dimensions are meters, masses are in kilograms, forces are in Newtons, power values are in Watts, speeds are in meters per second.
Any rotation uses the positive mathematical direction (anti-clockwise), and all angles are measured in radians (1 rad = 180/pi degrees = 57.3°).
Fractions are used instead of percentages (20% would be written as 0.2).

The coordinate system the entire aircraft is defined in the 3D model of the aircraft. The origin is usually placed close to the center of gravity but does not have to be. The forward flight direction defines the x-axis of the aircraft's coordinate system.
The y-axis points towards the left of the aircraft, the z-axis points straight up. One unit in the coordinate system represents a real world length of one meter. The 3D model may use a scale factor which is removed when the aircraft is exported.

===== Character Set =====

Except in the description text in the specific languages in aircraft [[aircraft:tmc|TMC]]-files and other descriptive files only the following characters are to be used in any of the above mentioned text files. Only by strictly maintaining only a certain character set it can be assured that all content can be loaded without any issues across different platforms.

  * ''<'',''>'',''['','']'', ''('', '')'' to define the tree structure
  * white spaces for separation of lists, indentations and additional spacing
  * digits from ''0 - 9'' with a dot ''.'' as decimal separator, minus ''-'' and plus ''+'' as signs
  * English-alphabet from ''A - z''
  * underscores ''_'' instead of white spaces in names
  * double slash (''%%//%%'') to define the rest of a line as a comment
  * as well as ''%'', ''&'', ''/'', ''|'', ''\'', ''('', '')'', ''['', '']'', ''´'', ''%%'%%'', ''`'', ''!'', ''?'', ''"'', '':'', '';'', '','', ''*'', ''#'' inside comments
  * \r\n as line endings (carriage return and line-feed)

Especially forbidden is the usage of **tab** indentation or separation. Instead four white spaces are used for indentation and multiple white spaces for separation.

===== Syntax =====

==== Tree structure ====

The file types mentioned above (except the [[simulator:log|LOG]] file) are all structured in a tree like hierarchy.
A single opening pointy bracket ''<'' opens a new section and a ''>'' closes it. After each opening bracket three blocks in pairs of ''['' and '']'' follow. These define three parameters.

<code><[type][name][value]></code>

The first parameter is a definition of the type for the following variable or content. This could be a ''file'', a class-name or object/attribute name as text (''string8''), a double number (''float64'') and so on.
The second parameter is a descriptive name or attribute name.
The third parameter defines the content of that attribute.

==== Nesting ====
Before a section is closed by a ''>'' it is possible to nest child section by opening it with another ''<'' and three pairs of ''['' and '']''. This way a variable of an object is nested as a child of the object it belongs to. The object is then nested within a section of a file which in turn is also nested.

Here is an example code of an typical nested parameter inside an object:
<code><[servoclassic][ServoElevator][]
    <[string8][Input][ElevatorInput.Output]>
></code>

==== Indentation and Spacing ====
A nested section is usually indented by 4 spaces and starts in a new line. The closing bracket has the same indentation as the opening bracket of that section. **The tab operator must not be used here!** It's important that every tab is converted to four spaces by the Editor in use. Depending on the file complexity or the personal preferences of the person editing the file, the indentation may be adopted.

Spaces and empty lines can be used throughout the entire file, for example to indent the parameters better:
<code><[class_name][ObjectName][]
    <[float64][VeryLongAttributeNameThatWontEnd][1.0]>
    <[float64][SimilarAttribute]                [1.0]>
></code>

===== Comments =====
One philosophy of the IPACS development team is to use code that explains itself. Writing a comment on everything will just bloat up the code and make it less readable to humans. Therefor comments will likely only be found within aircraft definition files ([[aircraft:tmd|TMD]]) and only sparse. Temporary comments usually start at the first character of a new line whilst descriptive, permanent comments are usually indented as the object they describe.
The dynamics part of the [[aircraft:tmd|TMD]]-file for example has a very similar structure among all aircraft that is highlighted very well by comments.

All comments shall be written in English language to avoid special characters and give the best readability for everyone reading the code.

A comment is started by a double slash ''%%//%%'' and spans the entire line. Comments within a parameter (before a closing ']') are not allowed. All text inside a comment is ignored by the Aerofly FS 2 engine.

> ''/*'' and ''*/'' do not work for commenting.


===== Naming convention =====

Other objects of the section can and will reference an object by its unique name. Names therefore may only be given once in a section! If the Name of an object is left blank the object cannot be referenced later on - but it's not required to have a name for every object.

A good name for an object describes the object as short and as accurately as possible. Abbreviations are usually not used, except if they are very common and very long. Since most of the Code can be created by copy-pasting from somewhere else this doesn't take much more time when writing but it saves a lot of development time when trying to find names in long files (20 thousand lines are not unheard of).

If there are multiple similar objects like an upper and an lower wing or multiple wheels on a gear it's recommended to name the location of the object first (left, right, upper, lower, front, rear), then the aircraft part. A part could be Fuselage, Wing, Stabilizer, Aileron, Rudder, Elevator, Flap, Gear, Wheel, Blade, Canopy, Cockpit, Glass, Airbrake, Rotor, Engine, etc. It's easiest way to order the location is by the axes: 1st: X (front, rear), 2nd: Y (left, center, right, outer, inner) , 3rd: Z (up, upper, middle, down, bottom). And if the location doesn't help to identify the object precisely enough it's also possible to add numbers.

=== Examples ===
"left wing" would be written as "LeftWing". AuxiliaryPowerUnit could be shortened to "APU", MultiFunctionDisplay can be called "MFD", Bat1On should be expanded to Battery1On, LEngN1 should probably be expanded to LeftEngineN1, LGLvr -> LandingGearLever, Btn -> Button and so on.

Fuselage, LeftWing, LeftOuterWing, LeftOuterAileron, LeftUpperWing, LeftUpperAileron, LeftLowerAirbrake, TailWheel, CenterMainGear, Blade1, Blade2, LeftCenterGearFrontLeftWheel