FlightGear wiki - User contributions [en]

Changelog 2020.3

2023-04-03T12:31:02Z

Legoboyvdlp: /* 2020.3.18 */

{{changelogs|prev=2020.1|next=2022.1}}

Available in: [[Changelog_2020.3|English]], [[Pl/Changelog_2020.3|Polish]], [[Zh/2020.3|Chinese]]

Please help us translate into other languages!

----
The FlightGear development team is delighted to announce the v2020.3 LTS release of FlightGear, the free, open-source flight simulator. This is the second Long Term Support release for FlightGear, since the project changed to offering both Long Term Support releases, and more cutting-edge Preview releases. This release represents the culmination of two years of development effort by a worldwide group of volunteers, brought together by a shared ambition to create the most realistic flight simulator possible that is free to use, modify and distribute. FlightGear is used all over the world by desktop flight simulator enthusiasts, for research in universities and for interactive exhibits in museums.

Major enhancements since the v2020.3 LTS include:
* a developer preview of the upcoming Compositor graphical rendering framework as a separate pre-built binary,
* enhancements to both the JSBSim and YASim flight dynamics models
* DDS texture caching to reduce load times
* faster loading and more memory efficient buildings
* improved aircraft carrier support

Additionally 30 completely new aircraft have been added to the official hangar, and a further 71 have received major updates.

{{Disclaimer|id=final-fixed-function-release}}

Founded in 1997, FlightGear features more than 700 aircraft, a worldwide scenery database, a multiplayer environment, detailed sky modelling, a flexible and open aircraft modelling system, varied networking options, multiple display support, a powerful scripting language, and an open architecture. Best of all, being open-source, the simulator is owned by the community and everyone is encouraged to contribute.

FlightGear - Fly Free!

----

== Launcher ==
* Addition of a welcome screen on first launch, providing helpful information to first time users.
* Aircraft can now be marked as Favourites, and filtered, making it easier to see find your favourite aircraft out of the hundreds available.
* The launcher now supports aircraft carriers, including selecting a carrier and setting a start position.
* {{key press|Ctrl|F}} shortcut for when you just want to Fly!
* Improved support for helipads and seaports, including detection of current aircraft type.
* Numerous bugfixes and stability improvements, in particular for the aircraft and addons tabs.

== Graphics ==
* To provide a developer preview, the [[Compositor]] renderer is included as part of this release. It provides a fully XML-configurable multi-pass rendering pipeline that is compatible with ALS and includes clustered shading.
* Support for DDS Texture Cache, improving loading times for texture files.
* Star visibility is configurable based on magnitude of star and atmospheric conditions.
* Use of non-directional point sprites as a fallback for drivers that do not support triangles of point sprites is now supported by setting <code>/rendering/triangle-directional-lights=false</code>.
* A new Tower AGL view has been added. This is similar to Tower View, except that it keeps both the aircraft and the ground immediately below the aircraft in view, zooming and panning smoothly as the aircraft moves. Good for viewing landings.
* Improved airport grass textures
* Implemented tidal movement for littoral areas.
* Updated regional material definitions for California, Asia, Northern Brazil, Iceland, Jan Mayen island.
* Active volcanoes - Katla, Eyjafjallajokull, Surtsey.
* Instanced-based random and OpenStreetMap buildings, improving performance and graphical quality significantly.
* Improvements to the Wingflex Shader.
* Users may enable/disable the pilot model from the View Options dialog.

== JSBSim ==
* Added the ability to set up the starter and acceleration times of a turbine (parameters <code><n1spinup></code>, <code><n2spinup></code>, <code><n1startrate></code>, <code><n2startrate></code>).
* The <code><integrator></code> filter can now be reset to 0.0 by setting its <code><trigger></code> property to a negative value.
* The integration scheme of the <code><integrator></code> filter can now be chosen among <code>rect</code> (Euler), <code>trap</code> (Trapezoidal), <code>ab2</code> (2nd order Adams-BashForth) and <code>ab3</code> (3rd order Adams-Bashforth)
* The following functions can now be used in <code><function></code>: <code>floor</code>, <code>ceil</code> and <code>fmod</code>. Their functionalities are the same than the corresponding C/C++ functions.
* <code><function></code> now checks the number of its arguments.
* New system component linear_actuator
* Export the fuel density to the property tree
* Added cyclic clipping for FCS components
* Added the ability to control the turbine engines spin down factor
* [Backward compatibility breakage] Gyros are now measuring rotation rates instead of rotational accelerations. Gyros that measure rotational accelerations do not exist in the real world.
* Output properties of flight control elements are no longer tied. This saves a lot of spurious warning messages and allows direct references of the same properties among several flight controls.
* Water vapor in the atmosphere is now managed through its mass fraction rather than its partial pressure. The former being the physical quantity that is conserved when pressure and temperature vary.
* Check that there are at least 3 contacts before trying to trim on ground.
* Added optional transmission of the simulation time for FG UDP interface
* The existence of the property that is used for table independent vars is now checked during execution rather than when the XML definition is parsed. This relaxes the order in which filters, table and more generally flight controls need to be declared in the XML definition files.
* Electric engines RPM is now exported in UDP sockets.
* The parameter <code><ignitionn2></code> now affects N2 rather than N1.
* A warning is now given when max < min in a <code><clipto></code> rather than throwing an exception
* Added the ability to log properties in a CSV file with the new fgfs executable argument <code>--jsbsim-output-directive-file</code>

== YASim ==
* Ground friction (stiction) changes
* Support for transonic flow effects.
* Control initial gear state directly by setting <code>/fdm/yasim/respect-external-gear-state=true</code>, rather then YASim settings this depending on whether the aircraft is in the air or on the ground.
* Electric engines are now supported.

== Weather and Environment ==
* Increased turbulence will be encountered near active volcanoes.
* Configurable METAR URL.
* METAR strings are decoded and displayed in a human-readable form in the weather dialog.

== Carriers ==
* Two new carrier-specific starting options are supported in the launcher: <code>carrier-takeoff</code> and <code>carrier-approach</code>.
* A new <code>--carrier-position</code> command-line argument has been added. This can be used to select the aircraft start position on an aircraft carrier. Either a catapult (e.g. <code>cat-1</code>), a parking position (e.g. <code>park-1</code>), on final approach on the FLOLS (<code>flols</code>) or abeam the carrier (<code>abeam</code>).
* MPCarrier can now be detected by the GUI even if not available on startup. To enable this feature set <code>/sim/mp-carriers/auto-attach=true</code>.

== AI ==
* New fgcommands <code>add-aiobject</code> and <code>remove-aiobject</code> for adding/removing objects to the AI subsystem.
* New AI aircraft, including 747 Freighter, CRJ900, SR-71, Saab 340.
* Numerous updates to AI traffic schedules and airline liveries.
* Space Shuttle TAEM and approach at KEDW scenario.
* Accurate Britten-Norman Islander performance data, from an Islander pilot.

== Multiplayer ==
* Connection to VATSIM via swift is now available via the GUI.
* FGCom now supports both COM1 and COM2, as well as volume settings.
* The views defined by the user's aircraft (Pilot view, Helicopter view, Tower view etc) can now be used with multiplayer aircraft. Viewing a particular multiplayer aircraft is done by clicking in the Pilot List dialogue's "view' column (see the "Multiplayer/Pilot List" menu).
* <code>--disable-hold-short</code> option which allows the user to force a start on the runway when multiplayer is enabled. This option should be used with caution - it can give other pilots and ATC a nasty fright to find an aircraft materialize on the runway!
* Support for recording multiplayer data

== Nasal Scripting ==
* Configurable load order for core Nasal modules.
* Improvements and bug fixes to Emesary, the messaging interface.
* Improvements to the core libraries.
* Garbage collection improvements to reduce frame stuttering
* Re-loadable Nasal modules
* Canvas EFIS framework
* New methods in Canvas Image to set colors of pixels in the image.

== Aircraft ==
* FG1000 Glass Panel improvements include user-configurable VFR transponder codes, volume controls, new fascia, UI is now resizeable, support for custom SVG files (e.g. for a G500). The FG1000 is now available on the Cessna 182T, J3 Cub, Diamond DA40.
* Improved glider vario instrument.
* New Aircraft:
** Airbus A320 - airliner
** Alisport Silent2Electro - glider with electric sustainer motor
** Bombardier Q400 DHC8-402 - shorthaul turboprop airliner
** Breguet Atlantic BR 1150 - long-range maritime patrol aircraft
** Cessna 140 - GA aircraft
** Cessna 208B Caravan - short range passenger, freighter and utility aircraft
** Cirrus SR22T - GA aircraft
** Diamond DA40 NG - GA aircraft, including FG1000 glass panel cockpit
** Diamond DA62 Twinstar- Twin engine GA aircraft
** Diamond HK36 Super Dimona - motorglider
** Dornier DO 28 Skyservant - Twin engine STOL utility aircraft
** Douglas TBD Devastator - WWII Torpedo bomber
** Draco Wilga - turboprop taildragger bush plane
** Fokker T.V - twin engine bomber
** Glasfluegel H201B Standard Libelle - glider
** Grumman F11-Tiger - carrier-based fighter
** Grumman HU-16A Albatross - twin engine amphibian
** Petliakov PE-8 (Ant-42/TB-7) - WWII bomber
** Piper PA28-161 Warrior II - GA aircraft
** Pipistrel Alpha Electro - electric training aircraft
** Pipistrel Taurus Electro G2.5 - glider with electric sustainer motor
** Rolladen Schneider LS8sc neo - standard glider with electric sustainer motor
** Robin DR400 Ecoflyer - GA Aircraft
** Scheibe Bergfalke II/55 - training glider
** Schempp-Hirth Arcus S - high performance glider
** Schleicher Ka6(CR) "Rhoensegler" - training glider
** SEPECAT Jaguar GR.1 - jet attack aircraft
** SUMPAC - Human powered airplane
** Supermarine Swift - jet fighter
** Yak 52 - training aircraft
* Major updates to over 70 aircraft. Including 737-100, 737-300, 777, A-26-Invader, AR-234, ASG29, ASK13, ASK21, Aero-Commander, Aichi-D3A, B-17, B-24-Liberator, B-25, Bombardier-415, CH750STOL, CRJ700-family, Cessna-208-Caravan, Cessna Citation II, Cessna-L19, Cirrus-SR22, Concorde, DO-228, DO-335, Diamond-Da40, Diamond-Da42, Dragonfly, Embraer-ERJ-145, F-15, Fairchild-Metroliner, Falcon-50, Fokker-S-11, Fw200, H4-Hercules, Harrier-GR3, Horten-Ho-IX, Hughes-XF11, J3Cub, JA37, JAS39-Gripen, Jaguar, LS4, Lancair-235, Lionceau, Lockheed-NF104A, Lockheed-P38, ME-262, Mirage-2000, MirageIV, Northrop-xb35, PC-12, Piaggio-P166, Piper-PA-28, Potez-630, R44, Ryan-Navion, SIAI-Marchetti-SF.260, Socata-ST10, SpaceShuttle, Starship, Tecnam-P2006T, UH-1, Yak-18T, Zlin-50lx, an24b, bluebird, c182s, dhc1, f-14b, f16.

== Miscellaneous ==
* Updated Chinese, Dutch, French, German, Italian, Polish and Slovak translations.
* Map dialog displays heliports and allows configurable cursor key panning
* Faster Terrasync: Download a tarball of airport information on first start and only check for updates every 24 hours rather than every simulator run.
* GPS fly-by mode
* Sentry.io integration to provide centralized crash reporting.
* Change screenshot filename to have date and time
* New thread safe particle manager -- should reduce random crashes around particles.

=Updates since 2020.1=
Changes since the 2020.1 preview release include:
* Various launcher improvements including a Welcome screen and a keyboard shortcut ({{key press|Ctrl|F}}) to Fly!
* Improved regional definitions for California, Iceland and Northern Brazil and better grass textures.
* Implemented tidal movement for littoral areas.
* New AI model for the 747 Freighter, and numerous AI livery and traffic updates.
* Updates to the FG1000 glass panel display including configurable VFR transponder codes, volume controls, a new fascia, resizeable UI and support for custom SVG files.
* A hangar full of new aircraft: HU-16A-Albatross, LS8, Embraer-ERJ-145, Cessna 208B Caravan, PZL 104 wilga 2000 Draco, Scheibe Bergfalke, Taurus, f16, Dornier Do 28 Skyservant, Petliakov Pe 8 (Ant 42/DB 7), Grumman F.11 Tiger
* Updates to a large number of aircraft including CRJ700, Dragonfly, Mirage 2000, Jaguar GR1, H4 Hercules, JA37, Supermarine Swift, A320, Cirrus-SR22, Cessna Citation, J3Cub
* Updated Chinese, Dutch, French, German, Italian, Polish and Slovak translations.
* Faster Terrasync: Download a tarball of airport information on first start and only check for updates every 24 hours rather than every simulator run.
* GPS fly-by mode
* Sentry.io integration to provide centralized crash reporting.
* New thread safe particle manager -- should reduce random crashes around particles.

=Updates since 2020.3.0=

As 2020.3 is a long term supported release, there are ongoing bug-fixes and small improvements happening, based on user feedback and automatic reporting of crashes and issues. Significant fixes are listed below:

==2020.3.1==
* Add help page to the launcher
* Fix handling of helipads at heliports
* Migrate installed aircraft packages, when migrating to the new stable catalog
* TerraSync: improve startup performance on Windows

==2020.3.2==
* TerraSync waits for Models to be completely sync-ed, to avoid missing models when starting
* First-run screen: add a 'scroll to the bottom' hint icon
* Tides fixes from Erik Hofman
* Use nicer scrollbar for the launcher, fixes some issue with long aircraft lists
* Support Apt.dat v1000 comm frequencies
* Fix an ATC crash when repositioning
* Many translations fixes identified by Michael Danilov
* Greatly improve the Brazilian cerradio areas (near SBMQ)
* Russian translation updates
* Iceland materials fixes

==2020.3.3==
* Fix accidental mouse picks while using a right-mouse-drag to look around
* Fix the download location we recommend in the 'setup root' dialog

==2020.3.4==
* Handle more METAR strings correctly, including wind sensor failures
* Fix airmass velocity being applied to sub-models twice (eg, when dropping payloads in a cross-wind)
* Fix crash on shutdown in the properties code
* Spanish translation updates
* Disable flights to EGEL to avoid crashes in traffic code

==2020.3.5==
* Change default Windows download location to %USERS%\FlightGear\Downloads, to avoid problems with Windows Defender blocking un-trusted applications from writing to Documents, which was the previous location.
* Fix a crash when returning to FlightGear from another application and scrolling or clicking
* Avoid crashing with UIUC-based aircraft such as the Wright Flyer
* Fix a crash on macOS when a joystick failed to open
* Update the macOS application icon
* Fix Nasal crash on reset
* Canvas: allow anisotropic filtering
* Larger, improved moon texture
* UFO speed goes to 11
* Fix taxiway markings disappearing in specific graphics settings

==2020.3.6==
* Fixed crash downloading the default aircraft catalog
* Fix a hang starting at scenery in the ocean
* Fix incorrect sky & cockpit rendering with certain METAR values
* Add getting-started hints to the launcher (English only for now)
* Fix Shuttle AI scenarios
* Improvements to flight-planning mode
* Sun / moon scaling fixes
* Fix initial position of submodels
* macOS: warn if running with app translocation
* Windows: detect missing OpenGL drivers
* Fix UIUC FDM crashes
* Fix crash with invalid view numbers
* Catch FDM NaN errors more gracefully
* KAP-140 approach mode improvements
* Traffic+AI livery updates

== 2020.3.7 ==
* Enable OSM2City buildings via TerraSync for the whole planet
* C172 bug-fixes and updates
* Improved regional material definitions for Europe, California
* Allow chat box to be re-positioned
* Fix crashes related to particle systems
* Fix selection of time-zone around Beijing
* Fix display of non-Latin1 strings in Canvas displays
* Fix Multi-player mode runway-start logic to select hold-short position correctly
* macOS: fix crash on text with certain fonts
* Fix launcher language selection when the UI language include a script specifier (eg zh-Hans-CN)
* Fix aircraft-id property when loading from a hangar ( https://sourceforge.net/p/flightgear/codetickets/2502/ )
* Improve checks for out-of-date Intel Graphics drivers on Windows

== 2020.3.8 ==
* Fix behaviour of <code><local></code> particle systems
* Fix autumn tree appearance

== 2020.3.9 ==
* Fix crash in Swift
* Corrections to MP protocol timing
* Correct URL to FGData
* Fix bug in cache reload dialog
* Improvements to ATC dialog to display frequencies with 3 decimal places correctly
* Improve material definitions for Africa, Mediterranean regions
* Add updated ocean and water visual effects

== 2020.3.10 ==
* Transponder: make standby mode work
* Launcher: pick up scenery and aircraft paths from the command line
* Launcher: store locations differently, to avoid problems when running multiple FlightGear versions and switching between them.
* Launcher: add 'restart on quit' option
* Fix NavCache errors loading ShapeFile data
* Fix NavCache errors when running multiple copies of FlightGear

== 2020.3.11 ==
* Fix a crash introduced in 2020.3.10
* Improve error message when no aircraft search paths are available
* Fix a crash with misconfigured traffic taxi routes
* Update AI traffic schedules

== 2020.3.12 ==
* Add aircraft directory name validation
* Add an extra step of antialiasing (8x)
* Add feature allowing aircraft to define custom fonts for osg::Text
* Add generic combined ALS procedural lights and Compositor lights
* Add new regional materials for Australia
* Fix Basic Weather producing invalid pressure altitudes
* Fix bug in path searching for previews
* Fix bug in sound system when approaching max-dist range
* Fix crashes after reset
* Fix crash when AI aircraft has invalid destination runway
* Fix Mapstructure error in RTE layer
* Fix <code>--view-offset</code> to use the correct property
* HUD: make vertical gauges look the same as horizontal ones
* Improved Russian and Spanish translations
* Miscellaneous improvements to weather dialog
* Property browser: display values for folders in verbose mode
* Route manager: select correct waypoint when duplicate waypoints exist
* Update AI traffic schedules and add new AI models

== 2020.3.13 ==
* Fix for the disappearing MP pilot list
* Fix JSBsim linear actuators behaving badly in certain conditions

== 2020.3.14 ==
* Support for add-on paths
* Instant audio queue
* Allow canvas dialogs to not grab focus away from FG (more like how focus in PUI dialogs behaves)

== 2020.3.15 ==
* Fix radio audio morse issue.

== 2020.3.16 ==
* Fix audio indent issue.

== 2020.3.17 ==
* Navradio: disable low-pass filter when changing selected freq or leaving GPS slave mode. When the selected frequency is changed or when leaving GPS slave mode, disable the low-pass filter applied to signal quality.
* Navradio: fix regression and optimize older code. Fix a little regression introduced in previous commit. Add: changing the standby frequency disabled the low-pass filter for the next call to updateReceiver(); this must happen when the selected frequency is changed but not when the standby frequency is changed.
* AP input: add property-path support to Inputs. Allow making the AP source indirect (via a string property), so that the actual source property can be configured or adjusted from a -set.xml, or at runtime.
* Replace displaying in Launcher `--on-ground=false` to `--in-air` for on final. The option`--on-ground=false` doesn't exist which can be misleading.

== 2020.3.18 ==

* Added photoscenery capability.
* New basic autopilot system.
* Fix crash with a 'between' type constraint in Navigraph procedure files



== References ==
{{Appendix}}

[[Category:FlightGear changelogs‎]]
[[pl:Changelog_2020.3]]
[[Zh:2020.3]]

Changelog 2020.3

2023-04-03T12:28:07Z

Legoboyvdlp: /* 2020.3.18 */

{{changelogs|prev=2020.1|next=2022.1}}

Available in: [[Changelog_2020.3|English]], [[Pl/Changelog_2020.3|Polish]], [[Zh/2020.3|Chinese]]

Please help us translate into other languages!

----
The FlightGear development team is delighted to announce the v2020.3 LTS release of FlightGear, the free, open-source flight simulator. This is the second Long Term Support release for FlightGear, since the project changed to offering both Long Term Support releases, and more cutting-edge Preview releases. This release represents the culmination of two years of development effort by a worldwide group of volunteers, brought together by a shared ambition to create the most realistic flight simulator possible that is free to use, modify and distribute. FlightGear is used all over the world by desktop flight simulator enthusiasts, for research in universities and for interactive exhibits in museums.

Major enhancements since the v2020.3 LTS include:
* a developer preview of the upcoming Compositor graphical rendering framework as a separate pre-built binary,
* enhancements to both the JSBSim and YASim flight dynamics models
* DDS texture caching to reduce load times
* faster loading and more memory efficient buildings
* improved aircraft carrier support

Additionally 30 completely new aircraft have been added to the official hangar, and a further 71 have received major updates.

{{Disclaimer|id=final-fixed-function-release}}

Founded in 1997, FlightGear features more than 700 aircraft, a worldwide scenery database, a multiplayer environment, detailed sky modelling, a flexible and open aircraft modelling system, varied networking options, multiple display support, a powerful scripting language, and an open architecture. Best of all, being open-source, the simulator is owned by the community and everyone is encouraged to contribute.

FlightGear - Fly Free!

----

== Launcher ==
* Addition of a welcome screen on first launch, providing helpful information to first time users.
* Aircraft can now be marked as Favourites, and filtered, making it easier to see find your favourite aircraft out of the hundreds available.
* The launcher now supports aircraft carriers, including selecting a carrier and setting a start position.
* {{key press|Ctrl|F}} shortcut for when you just want to Fly!
* Improved support for helipads and seaports, including detection of current aircraft type.
* Numerous bugfixes and stability improvements, in particular for the aircraft and addons tabs.

== Graphics ==
* To provide a developer preview, the [[Compositor]] renderer is included as part of this release. It provides a fully XML-configurable multi-pass rendering pipeline that is compatible with ALS and includes clustered shading.
* Support for DDS Texture Cache, improving loading times for texture files.
* Star visibility is configurable based on magnitude of star and atmospheric conditions.
* Use of non-directional point sprites as a fallback for drivers that do not support triangles of point sprites is now supported by setting <code>/rendering/triangle-directional-lights=false</code>.
* A new Tower AGL view has been added. This is similar to Tower View, except that it keeps both the aircraft and the ground immediately below the aircraft in view, zooming and panning smoothly as the aircraft moves. Good for viewing landings.
* Improved airport grass textures
* Implemented tidal movement for littoral areas.
* Updated regional material definitions for California, Asia, Northern Brazil, Iceland, Jan Mayen island.
* Active volcanoes - Katla, Eyjafjallajokull, Surtsey.
* Instanced-based random and OpenStreetMap buildings, improving performance and graphical quality significantly.
* Improvements to the Wingflex Shader.
* Users may enable/disable the pilot model from the View Options dialog.

== JSBSim ==
* Added the ability to set up the starter and acceleration times of a turbine (parameters <code><n1spinup></code>, <code><n2spinup></code>, <code><n1startrate></code>, <code><n2startrate></code>).
* The <code><integrator></code> filter can now be reset to 0.0 by setting its <code><trigger></code> property to a negative value.
* The integration scheme of the <code><integrator></code> filter can now be chosen among <code>rect</code> (Euler), <code>trap</code> (Trapezoidal), <code>ab2</code> (2nd order Adams-BashForth) and <code>ab3</code> (3rd order Adams-Bashforth)
* The following functions can now be used in <code><function></code>: <code>floor</code>, <code>ceil</code> and <code>fmod</code>. Their functionalities are the same than the corresponding C/C++ functions.
* <code><function></code> now checks the number of its arguments.
* New system component linear_actuator
* Export the fuel density to the property tree
* Added cyclic clipping for FCS components
* Added the ability to control the turbine engines spin down factor
* [Backward compatibility breakage] Gyros are now measuring rotation rates instead of rotational accelerations. Gyros that measure rotational accelerations do not exist in the real world.
* Output properties of flight control elements are no longer tied. This saves a lot of spurious warning messages and allows direct references of the same properties among several flight controls.
* Water vapor in the atmosphere is now managed through its mass fraction rather than its partial pressure. The former being the physical quantity that is conserved when pressure and temperature vary.
* Check that there are at least 3 contacts before trying to trim on ground.
* Added optional transmission of the simulation time for FG UDP interface
* The existence of the property that is used for table independent vars is now checked during execution rather than when the XML definition is parsed. This relaxes the order in which filters, table and more generally flight controls need to be declared in the XML definition files.
* Electric engines RPM is now exported in UDP sockets.
* The parameter <code><ignitionn2></code> now affects N2 rather than N1.
* A warning is now given when max < min in a <code><clipto></code> rather than throwing an exception
* Added the ability to log properties in a CSV file with the new fgfs executable argument <code>--jsbsim-output-directive-file</code>

== YASim ==
* Ground friction (stiction) changes
* Support for transonic flow effects.
* Control initial gear state directly by setting <code>/fdm/yasim/respect-external-gear-state=true</code>, rather then YASim settings this depending on whether the aircraft is in the air or on the ground.
* Electric engines are now supported.

== Weather and Environment ==
* Increased turbulence will be encountered near active volcanoes.
* Configurable METAR URL.
* METAR strings are decoded and displayed in a human-readable form in the weather dialog.

== Carriers ==
* Two new carrier-specific starting options are supported in the launcher: <code>carrier-takeoff</code> and <code>carrier-approach</code>.
* A new <code>--carrier-position</code> command-line argument has been added. This can be used to select the aircraft start position on an aircraft carrier. Either a catapult (e.g. <code>cat-1</code>), a parking position (e.g. <code>park-1</code>), on final approach on the FLOLS (<code>flols</code>) or abeam the carrier (<code>abeam</code>).
* MPCarrier can now be detected by the GUI even if not available on startup. To enable this feature set <code>/sim/mp-carriers/auto-attach=true</code>.

== AI ==
* New fgcommands <code>add-aiobject</code> and <code>remove-aiobject</code> for adding/removing objects to the AI subsystem.
* New AI aircraft, including 747 Freighter, CRJ900, SR-71, Saab 340.
* Numerous updates to AI traffic schedules and airline liveries.
* Space Shuttle TAEM and approach at KEDW scenario.
* Accurate Britten-Norman Islander performance data, from an Islander pilot.

== Multiplayer ==
* Connection to VATSIM via swift is now available via the GUI.
* FGCom now supports both COM1 and COM2, as well as volume settings.
* The views defined by the user's aircraft (Pilot view, Helicopter view, Tower view etc) can now be used with multiplayer aircraft. Viewing a particular multiplayer aircraft is done by clicking in the Pilot List dialogue's "view' column (see the "Multiplayer/Pilot List" menu).
* <code>--disable-hold-short</code> option which allows the user to force a start on the runway when multiplayer is enabled. This option should be used with caution - it can give other pilots and ATC a nasty fright to find an aircraft materialize on the runway!
* Support for recording multiplayer data

== Nasal Scripting ==
* Configurable load order for core Nasal modules.
* Improvements and bug fixes to Emesary, the messaging interface.
* Improvements to the core libraries.
* Garbage collection improvements to reduce frame stuttering
* Re-loadable Nasal modules
* Canvas EFIS framework
* New methods in Canvas Image to set colors of pixels in the image.

== Aircraft ==
* FG1000 Glass Panel improvements include user-configurable VFR transponder codes, volume controls, new fascia, UI is now resizeable, support for custom SVG files (e.g. for a G500). The FG1000 is now available on the Cessna 182T, J3 Cub, Diamond DA40.
* Improved glider vario instrument.
* New Aircraft:
** Airbus A320 - airliner
** Alisport Silent2Electro - glider with electric sustainer motor
** Bombardier Q400 DHC8-402 - shorthaul turboprop airliner
** Breguet Atlantic BR 1150 - long-range maritime patrol aircraft
** Cessna 140 - GA aircraft
** Cessna 208B Caravan - short range passenger, freighter and utility aircraft
** Cirrus SR22T - GA aircraft
** Diamond DA40 NG - GA aircraft, including FG1000 glass panel cockpit
** Diamond DA62 Twinstar- Twin engine GA aircraft
** Diamond HK36 Super Dimona - motorglider
** Dornier DO 28 Skyservant - Twin engine STOL utility aircraft
** Douglas TBD Devastator - WWII Torpedo bomber
** Draco Wilga - turboprop taildragger bush plane
** Fokker T.V - twin engine bomber
** Glasfluegel H201B Standard Libelle - glider
** Grumman F11-Tiger - carrier-based fighter
** Grumman HU-16A Albatross - twin engine amphibian
** Petliakov PE-8 (Ant-42/TB-7) - WWII bomber
** Piper PA28-161 Warrior II - GA aircraft
** Pipistrel Alpha Electro - electric training aircraft
** Pipistrel Taurus Electro G2.5 - glider with electric sustainer motor
** Rolladen Schneider LS8sc neo - standard glider with electric sustainer motor
** Robin DR400 Ecoflyer - GA Aircraft
** Scheibe Bergfalke II/55 - training glider
** Schempp-Hirth Arcus S - high performance glider
** Schleicher Ka6(CR) "Rhoensegler" - training glider
** SEPECAT Jaguar GR.1 - jet attack aircraft
** SUMPAC - Human powered airplane
** Supermarine Swift - jet fighter
** Yak 52 - training aircraft
* Major updates to over 70 aircraft. Including 737-100, 737-300, 777, A-26-Invader, AR-234, ASG29, ASK13, ASK21, Aero-Commander, Aichi-D3A, B-17, B-24-Liberator, B-25, Bombardier-415, CH750STOL, CRJ700-family, Cessna-208-Caravan, Cessna Citation II, Cessna-L19, Cirrus-SR22, Concorde, DO-228, DO-335, Diamond-Da40, Diamond-Da42, Dragonfly, Embraer-ERJ-145, F-15, Fairchild-Metroliner, Falcon-50, Fokker-S-11, Fw200, H4-Hercules, Harrier-GR3, Horten-Ho-IX, Hughes-XF11, J3Cub, JA37, JAS39-Gripen, Jaguar, LS4, Lancair-235, Lionceau, Lockheed-NF104A, Lockheed-P38, ME-262, Mirage-2000, MirageIV, Northrop-xb35, PC-12, Piaggio-P166, Piper-PA-28, Potez-630, R44, Ryan-Navion, SIAI-Marchetti-SF.260, Socata-ST10, SpaceShuttle, Starship, Tecnam-P2006T, UH-1, Yak-18T, Zlin-50lx, an24b, bluebird, c182s, dhc1, f-14b, f16.

== Miscellaneous ==
* Updated Chinese, Dutch, French, German, Italian, Polish and Slovak translations.
* Map dialog displays heliports and allows configurable cursor key panning
* Faster Terrasync: Download a tarball of airport information on first start and only check for updates every 24 hours rather than every simulator run.
* GPS fly-by mode
* Sentry.io integration to provide centralized crash reporting.
* Change screenshot filename to have date and time
* New thread safe particle manager -- should reduce random crashes around particles.

=Updates since 2020.1=
Changes since the 2020.1 preview release include:
* Various launcher improvements including a Welcome screen and a keyboard shortcut ({{key press|Ctrl|F}}) to Fly!
* Improved regional definitions for California, Iceland and Northern Brazil and better grass textures.
* Implemented tidal movement for littoral areas.
* New AI model for the 747 Freighter, and numerous AI livery and traffic updates.
* Updates to the FG1000 glass panel display including configurable VFR transponder codes, volume controls, a new fascia, resizeable UI and support for custom SVG files.
* A hangar full of new aircraft: HU-16A-Albatross, LS8, Embraer-ERJ-145, Cessna 208B Caravan, PZL 104 wilga 2000 Draco, Scheibe Bergfalke, Taurus, f16, Dornier Do 28 Skyservant, Petliakov Pe 8 (Ant 42/DB 7), Grumman F.11 Tiger
* Updates to a large number of aircraft including CRJ700, Dragonfly, Mirage 2000, Jaguar GR1, H4 Hercules, JA37, Supermarine Swift, A320, Cirrus-SR22, Cessna Citation, J3Cub
* Updated Chinese, Dutch, French, German, Italian, Polish and Slovak translations.
* Faster Terrasync: Download a tarball of airport information on first start and only check for updates every 24 hours rather than every simulator run.
* GPS fly-by mode
* Sentry.io integration to provide centralized crash reporting.
* New thread safe particle manager -- should reduce random crashes around particles.

=Updates since 2020.3.0=

As 2020.3 is a long term supported release, there are ongoing bug-fixes and small improvements happening, based on user feedback and automatic reporting of crashes and issues. Significant fixes are listed below:

==2020.3.1==
* Add help page to the launcher
* Fix handling of helipads at heliports
* Migrate installed aircraft packages, when migrating to the new stable catalog
* TerraSync: improve startup performance on Windows

==2020.3.2==
* TerraSync waits for Models to be completely sync-ed, to avoid missing models when starting
* First-run screen: add a 'scroll to the bottom' hint icon
* Tides fixes from Erik Hofman
* Use nicer scrollbar for the launcher, fixes some issue with long aircraft lists
* Support Apt.dat v1000 comm frequencies
* Fix an ATC crash when repositioning
* Many translations fixes identified by Michael Danilov
* Greatly improve the Brazilian cerradio areas (near SBMQ)
* Russian translation updates
* Iceland materials fixes

==2020.3.3==
* Fix accidental mouse picks while using a right-mouse-drag to look around
* Fix the download location we recommend in the 'setup root' dialog

==2020.3.4==
* Handle more METAR strings correctly, including wind sensor failures
* Fix airmass velocity being applied to sub-models twice (eg, when dropping payloads in a cross-wind)
* Fix crash on shutdown in the properties code
* Spanish translation updates
* Disable flights to EGEL to avoid crashes in traffic code

==2020.3.5==
* Change default Windows download location to %USERS%\FlightGear\Downloads, to avoid problems with Windows Defender blocking un-trusted applications from writing to Documents, which was the previous location.
* Fix a crash when returning to FlightGear from another application and scrolling or clicking
* Avoid crashing with UIUC-based aircraft such as the Wright Flyer
* Fix a crash on macOS when a joystick failed to open
* Update the macOS application icon
* Fix Nasal crash on reset
* Canvas: allow anisotropic filtering
* Larger, improved moon texture
* UFO speed goes to 11
* Fix taxiway markings disappearing in specific graphics settings

==2020.3.6==
* Fixed crash downloading the default aircraft catalog
* Fix a hang starting at scenery in the ocean
* Fix incorrect sky & cockpit rendering with certain METAR values
* Add getting-started hints to the launcher (English only for now)
* Fix Shuttle AI scenarios
* Improvements to flight-planning mode
* Sun / moon scaling fixes
* Fix initial position of submodels
* macOS: warn if running with app translocation
* Windows: detect missing OpenGL drivers
* Fix UIUC FDM crashes
* Fix crash with invalid view numbers
* Catch FDM NaN errors more gracefully
* KAP-140 approach mode improvements
* Traffic+AI livery updates

== 2020.3.7 ==
* Enable OSM2City buildings via TerraSync for the whole planet
* C172 bug-fixes and updates
* Improved regional material definitions for Europe, California
* Allow chat box to be re-positioned
* Fix crashes related to particle systems
* Fix selection of time-zone around Beijing
* Fix display of non-Latin1 strings in Canvas displays
* Fix Multi-player mode runway-start logic to select hold-short position correctly
* macOS: fix crash on text with certain fonts
* Fix launcher language selection when the UI language include a script specifier (eg zh-Hans-CN)
* Fix aircraft-id property when loading from a hangar ( https://sourceforge.net/p/flightgear/codetickets/2502/ )
* Improve checks for out-of-date Intel Graphics drivers on Windows

== 2020.3.8 ==
* Fix behaviour of <code><local></code> particle systems
* Fix autumn tree appearance

== 2020.3.9 ==
* Fix crash in Swift
* Corrections to MP protocol timing
* Correct URL to FGData
* Fix bug in cache reload dialog
* Improvements to ATC dialog to display frequencies with 3 decimal places correctly
* Improve material definitions for Africa, Mediterranean regions
* Add updated ocean and water visual effects

== 2020.3.10 ==
* Transponder: make standby mode work
* Launcher: pick up scenery and aircraft paths from the command line
* Launcher: store locations differently, to avoid problems when running multiple FlightGear versions and switching between them.
* Launcher: add 'restart on quit' option
* Fix NavCache errors loading ShapeFile data
* Fix NavCache errors when running multiple copies of FlightGear

== 2020.3.11 ==
* Fix a crash introduced in 2020.3.10
* Improve error message when no aircraft search paths are available
* Fix a crash with misconfigured traffic taxi routes
* Update AI traffic schedules

== 2020.3.12 ==
* Add aircraft directory name validation
* Add an extra step of antialiasing (8x)
* Add feature allowing aircraft to define custom fonts for osg::Text
* Add generic combined ALS procedural lights and Compositor lights
* Add new regional materials for Australia
* Fix Basic Weather producing invalid pressure altitudes
* Fix bug in path searching for previews
* Fix bug in sound system when approaching max-dist range
* Fix crashes after reset
* Fix crash when AI aircraft has invalid destination runway
* Fix Mapstructure error in RTE layer
* Fix <code>--view-offset</code> to use the correct property
* HUD: make vertical gauges look the same as horizontal ones
* Improved Russian and Spanish translations
* Miscellaneous improvements to weather dialog
* Property browser: display values for folders in verbose mode
* Route manager: select correct waypoint when duplicate waypoints exist
* Update AI traffic schedules and add new AI models

== 2020.3.13 ==
* Fix for the disappearing MP pilot list
* Fix JSBsim linear actuators behaving badly in certain conditions

== 2020.3.14 ==
* Support for add-on paths
* Instant audio queue
* Allow canvas dialogs to not grab focus away from FG (more like how focus in PUI dialogs behaves)

== 2020.3.15 ==
* Fix radio audio morse issue.

== 2020.3.16 ==
* Fix audio indent issue.

== 2020.3.17 ==
* Navradio: disable low-pass filter when changing selected freq or leaving GPS slave mode. When the selected frequency is changed or when leaving GPS slave mode, disable the low-pass filter applied to signal quality.
* Navradio: fix regression and optimize older code. Fix a little regression introduced in previous commit. Add: changing the standby frequency disabled the low-pass filter for the next call to updateReceiver(); this must happen when the selected frequency is changed but not when the standby frequency is changed.
* AP input: add property-path support to Inputs. Allow making the AP source indirect (via a string property), so that the actual source property can be configured or adjusted from a -set.xml, or at runtime.
* Replace displaying in Launcher `--on-ground=false` to `--in-air` for on final. The option`--on-ground=false` doesn't exist which can be misleading.

== 2020.3.18 ==

* Added photoscenery capability.
* New basic autopilot system.
* Add AI submodel collision
* Fix crash with a 'between' type constraint in Navigraph procedure files
* Fix crash with invalid METAR strings

== References ==
{{Appendix}}

[[Category:FlightGear changelogs‎]]
[[pl:Changelog_2020.3]]
[[Zh:2020.3]]

User:D-ECHO

2022-09-05T11:05:28Z

Legoboyvdlp: /* Zenith Air */ Remove real name

== List of aircraft ==
This is a list of all aircraft in FGAddon which I either currently maintain or started:

==== Alexander Schleicher Segelflugzeugbau ====

* [[Schleicher Ka 6|Ka6]]
* [[ASK13]], originally created by Patrice Poly, who doesn't seem to be around anymore, so I took over maintaining the fgaddon version as well as improving the aircraft.
*[[ASK21]], originally created by Heiko Schulz and AJ MacLeod, from 2017 on developed by Viktor Radnai, Gilberto Agostinho as well as Herbert Wagner, Thomas Polzer and me.

*[[ASG 29|ASG29]]

==== Diamond Aircraft ====

*[[Diamond HK36]]
*[[Diamond_DA40|Diamond DA40NG]], not to be confused with the (other) FGAddon DA40 found under [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Diamond-Da40/ this link].

==== Zenith Air ====
*[[Zenith Air CH650]], converted from an X-Plane addon by hydroz (with his kind permission) with help by legoboyvdlp
*[[CH750|Zenith Air CH750 STOL]], same as with the CH650

==== Other ====

*[https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Silent2Electro/ Alisport Silent2Electro]
*[https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/c140/ Cessna 140]
*[[Dornier 228NG]]
*[https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Libelle/ Glasflügel Libelle]
*[https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Dragonfly Moyes Dragonfly]

*[[Pipistrel Alpha Electro|Pipistrel Alpha Electro / Pipistrel Velis Electro]]
*[[QSeries]]

*[https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/LS4 Rolladen-Schneider LS4]

*[https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/LS8 Rolladen-Schneider LS8]

*[https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/SG38 SG38]

Template:Nasal Navigation

2022-06-28T16:57:00Z

Legoboyvdlp:

<noinclude>{{Informative template|1=
Navigation box for core [[Nasal]] articles.

== Usage ==
Put this at the top of the article:
{{obr}}'''Nasal Navigation'''{{cbr}}

}}

[[Category:Navigation templates]]

</noinclude><includeonly>{{nocat|{{{nocat|}}}|Nasal}}</includeonly>{{forum|30|Nasal Scripting}}

{{Sidebar with collapsible lists
| name = Nasal Navigation
| pretitle = [[File:Nasallogo3.png|link=Nasal]]
| title = [[Nasal|Nasal scripting]]
| expanded = {{{expanded|}}}

| content1 =
* [[What is Nasal]]?
* [[Nasal success stories|Success stories]]
* [[Nasal FAQ]]
* [[Nasal Snippets]]
* [[Howto:Syntax highlighting for Nasal]]

| list2title = Tools and utilities
| list2 = [[Nasal Console|Console]] • [[Interactive Nasal Console|REPL Console]] • [[Nasal Browser|Browser]]

| list3title = Getting started
| list3 =
* [[Nasal Best Practices]]
* [[Nasal for C++ programmers]]
* [[Creating new Nasal scripts]]
* [[Nasal Hello World]]
* [[Howto:Create a new Nasal module]]
* [[Using Nasal functions]]
* [[Nasal Variables]]
* [[Nasal Namespaces]]
* [[Howto:Understand Namespaces and Methods|Namespace and Methods]]
* [[Nasal Namespaces in-depth]]
* [[Nasal Conditionals]]
* [[Nasal Loops]]
* [[Numbers in Nasal]]
* [[Nasal Operators]]
* [[Howto:Use vectors and foreach loops to write shorter code]]
* [[Howto:Start using vectors and hashes in Nasal]]
* [[Nasal library]] ([[Nasal library#Core library functions|core]]/[[Nasal library#Extension functions|extension]] functions)
** [[Nasal library/clipboard|<code>clipboard</code> namespace]]
** [[Nasal library/debug|<code>debug</code> namespace]]
** [[Nasal library/geo|<code>geo</code> namespace]]
** [[Nasal library/io|<code>io</code> namespace]]
** [[Nasal library/math|<code>math</code> namespace]]
** [[Nasal library/os.path|<code>os.path</code> namespace]]
** [[Nasal library/props|<code>props</code> namespace]]
** [[Nasal String Manipulation|<code>string</code> namespace]]
** [[Nasal library/flightplan|flightplan library]]
* [[Howto:Write a parser in Nasal]]
* [[Nasal Flightplan]]
* [[Object oriented programming in Nasal|OOP Introduction]]
* [[Object Oriented Programming with Nasal]]
* [[Nasal Callbacks Explained]]
* [[Exception handling with Nasal]]
* [[Using listeners and signals with Nasal]]
* [[Developing and debugging Nasal code]]

| list4title = Advanced Tutorials
| list4 =
* [[Caching Nasal function calls]]
* [[Nasal Unit Testing Framework]] (WIP)
* [[Nasal Meta-Programming]]
* [[A GPX flight logger in Nasal]]
* [[Multiplayer scripting in Nasal]]
* [[Howto:Making HTTP Requests from Nasal]]
* [[Howto:Transmit properties over MP]]
* [[Howto:Terrain sampling in Nasal]]
* [[Howto:Create a new system in Nasal]]
* [[Howto:Load a Nasal file at runtime]]
* [[Howto:Control the route manager in Nasal]]
* [[Howto:Get a number of elevation offsets for a number of objects]]
* [[Howto:Nasal in scenery object XML files]]
* [[Howto:Create animation XML files from Nasal]]
* [[Howto:Port I/O from Nasal]]
* [[Howto:Continuation-passing style programming in Nasal]]
* [[Howto:Start worker threads using listeners in Nasal]]
* [[Howto:Developing a DSL interpreter in Nasal]]
* [[Howto:Nasal Metaprogramming]]
* [[Nasal/JavaScript Subset]]
}}

{{Nasal Internals}}

Nasal library/flightplan

2022-06-28T16:55:51Z

Legoboyvdlp: Add redirect under Nasal library for flightplan

#redirect[[Nasal_Flightplan]]

Software testing

2022-05-16T11:35:40Z

Legoboyvdlp: /* Running the test suite */

{{Note|There’s already the test_suite in {{fg src file|path=test_suite}} using [[Cppunit effort|CppUnit]], thanks to some hard work by [[User:Bugman|Edward]]. We need more tests written for it, submissions welcome. (Pick an area of interest)<ref>https://sourceforge.net/p/flightgear/mailman/message/36972720/</ref>}}

{{See also|Cppunit effort}}

The FlightGear source code and data are tested by the FlightGear developers using a number of tools. This includes automated testing via unit tests in [[SimGear]] and a full test suite with multiple test categories in the [[FlightGear Git|flightgear repository]], as well as manual in-sim testing. Writing tests is one of the best ways to jump into FlightGear development.

One improving area is unit-testing: because of which, certain areas and features (eg, carrier start) now ‘can’t break’. As we add more such areas (eg Multi-player, AI, protocols and replay are all possible), we increase the baseline quality, and also have a clearer idea when we make incompatible changes. (The idea being we capture the ‘supported API’ in the tests: when an aircraft deviates from that, we can decide to add another test case, fix the aircraft, etc). Of course, there’s some pretty major areas where Automated Testing Is Hard (TM).<ref>https://sourceforge.net/p/flightgear/mailman/message/37078825/</ref>

== SimGear ==

The [[SimGear]] sources are checked via unit testing. This is implemented using the CMake CTest unit testing infrastructure. A number of tests are currently implemented using the BOOST unit testing infrastructure tied to the build system using CTest, however this should be avoided when writing tests as there is a shift towards eliminating BOOST by the FlightGear developers.

=== Building and running the SimGear tests ===
<syntaxhighlight lang="bash">
$ make
$ ctest
</syntaxhighlight>

== FlightGear ==

Testing of the [[FlightGear Git|flightgear sources]] is via a comprehensive test suite implemented using [https://www.freedesktop.org/wiki/Software/cppunit/ CppUnit], a port of the famous JUnit framework.

=== Building the test suite ===

To run the tests you will need to build FlightGear from source using cmake. See [[Building FlightGear]] for details.

Once you have your cmake build environment do the following:
# Change to your FlightGear build directory
# Enable building the tests by setting a cmake variable: <code>cmake -LBUILD_TESTING=ON .</code>
# Ensure the <code>[[$FG ROOT|$FG_ROOT]]</code> environment variable points to fgdata e.g. <code>$FG_INSTALL_DIR/share/fgdata</code>
# Build the test suite: <code>make test_suite</code>

This will also run the full test suite (see below), because you will typically want to write a test and then immediately compile and run it.

On a Windows MSVC-based build environment, after generating files with cmake, run the following code:
# cmake --build . --config RelWithDebInfo --target test_suite/test_suite

=== Running the test suite ===

To run the test suite, simply run <code>./test_suite/fgfs_test_suite</code>

This will run the full test suite and print a Synopsis of results similar to the following:

Synopsis
========

System/functional tests ....................................... [ OK ]
Unit tests .................................................... [ OK ]
Simgear unit tests ............................................ [ OK ]
FGData tests .................................................. [ OK ]
Synopsis ...................................................... [ OK ]

You can also run individual test cases. Run <code>./test_suite/fgfs_test_suite -h</code> to see the various options

For example, fgfs_test_suite --log-level=alert -d -u GPSTests will run the GPS unit tests while displaying the output.

=== Why write unit tests? ===

A well tested piece of software will have a much lower bug count/load. An extensive test suite with '''unit tests''', system/functional tests, GUI tests, installer tests, and other categories of tests can significantly help in this regard.

The benefits of not just chasing clear "wins" are great: An awesome learning experience for new developers; the ability to catch latent, unreported bugs; making it easier to refactor current code by creating a safety net; making it easier for current developers to accept new contributions (when accompanied with passing tests); helping other test writers by contributing to the common test suite infrastructure; and being able to easily check for memory leaks or other issues via Valgrind.<ref>https://sourceforge.net/p/flightgear/mailman/message/36977686/</ref>

If you are a new developer, just jump in and write any test! It does not need to catch a bug. Do whatever how ever you wish! Just dive in this shallow end and you'll see that the water is not cold.

Writing a test as a safety net. You write the test to pass, make your changes, then make sure that the test still passes. Then you push both the test and core changes.<ref>https://sourceforge.net/p/flightgear/mailman/message/36977465/</ref>

It'd be better jumping into a specific area of interest to you, and submitting merge-requests. That would naturally trigger some C++ feedback when reviewed but we aren’t looking for perfection here, more to increase the overall pool of knowledge of what best-practice looks like, even if a given commit is less than perfect.

I,e It’s more important to have 10 or 20 people actively contributing correct-and-reasonable code than three people contributing absolutely perfect, micro-optimised C++. <ref>https://sourceforge.net/p/flightgear/mailman/message/36951247/</ref>

=== Benefits of unit testing ===
There are lots of benefits to writing tests that pass.

Benefits include :

* Learning! New developers can learn a ton from writing a number of passing tests in the area they are interested in. This is one of the quickest ways to learn about a pre-existing and mature code base. You have zero worries about breaking things. This is diving in the shallow end.

* Latent bug uncovering. For every ten tests you write expecting them to pass, one will probably fail. Or at least uncover unexpected behavior that can be improved.

* Refactoring. If we had 10,000 passing tests (assuming universal test coverage), large scale refactoring of the entire code base would be quick and reliable. It would enable refactoring on a scale currently unimaginable. I cannot emphasize enough how much of a benefit this would be.

* Developer turnover. Again if we had 10,000 passing tests (assuming universal test coverage), it would encourage new developers. This is because the fear of breaking something is removed. It is a total safety net. It also would give existing developers peace of mind when a new developer is touching one of the dark parts of FlightGear that no current developer understands (there are plenty of those) .

* Test suite infrastructure. The more passing tests written, the better the test suite infrastructure will become. We can already do a lot. But the addition of more passing tests will help other test writers.

* Memory checking. Running a single test through Valgrind is amazing. Running FlightGear through Valgrind is close to impossible. Passing tests can be written to catch memory leaks!

* Low code quality and standards. This is related to the learning point. As long as a test compiles on all OSes without warning, it passes, and Valgrind gives you an ok, it is good enough. You dont need to be a C++ expert to dive into this shallow end of the pool.

=== Bootstrapping completely new tests ===
To start diving straight into the test suite code, firstly copy what has been done in this commit: {{repo link
| site = sf
| user = edauvergne
| repo = flightgear
| commit = 8474df
| view = commit
}}

Just modify all names for a JSBSim test (or any other test fixture you
want to code). You should then be able to compile and check that your
new testDummy() test passes as expected. You can then slowly build up
from this basic infrastructure as you learn the fgfs internals, c++,
and git skills required for implementing your test on your fork's new
development branch :)

=== Headless testing ===
{{Main article|FlightGear Headless}}

For an FDM+systems test, we should run FG without a renderer (which is what the test_suite does), to benchmark the pure C++ performance of whatever system it is we care about (FDM or whatever). But this is not really worth doing anyway, since a few hours playing with ‘perf’ on Linux / Instruments on macOS will show you that 80% of our CPU time is spent in OSG + the GL drivers, and hence Amdhal’s law will always get you.<ref>https://sourceforge.net/p/flightgear/mailman/message/36977666/</ref>

=== Graphics testing ===
{{See also|FlightGear Benchmark}}

The other thing is to setup some test-case scenes where you can quickly measure differences and compare via screenshots. The brain/eye/memory are very bad at this stuff, setup something you can load from the command line via a script to test old/new versions, if possible. <ref>https://sourceforge.net/p/flightgear/mailman/message/36959002/</ref>

For example, a test would would be a .[[fgfsrc]] that makes:
* c172p at some parking in a detailed airport;
* camera looking at it in specific direction with specific FOV;
* AW with specific METARs around (if not possible, BW with specific METAR);
* fixed rendering settings (several variants may be needed for renderers and threading modes) <ref>https://sourceforge.net/p/flightgear/mailman/message/36975122/</ref>

We can already load a [[Instant Replay|replay tape]] on startup, however, which is good for testing rendering (scenery, loading) performance, since the FDM is not involved, nor is the user-interface.

But essentially any and all of the methods proposed can be done here with small amounts of shell-script + Nasal hacking I think, and any of them would be welcome additions. For lower-level tests run by developers, the unit-test framework is great (i.e ‘does the API call produce the right results in the system’), but a smoke-test that regular users can run would be ideal.

A rendering performance would likely do:

* select some particular rendering settings (clouds, draw distance, etc)
* run a saved fgtape recording
* record the mean/min/max FPS during this and save it in some text file / copy to the clipboard

So yes, if anyone wants to work on the above, the code is all there, please jump in and start hacking - I don’t think it needs any more from the core code, but as ever, please just ask if it does.<ref>https://sourceforge.net/p/flightgear/mailman/message/36975213/</ref>

For example, describing a /rendering/ test (to establish FPS) - the advantage of a replay tape is the actual position (and therefore what is rendered) will be 100% consistent acorss different computers.

Keep in mind that the CPU use of the FDM+systems is typically < 10% of our total CPU use, even when running OSG single-threaded, so for a rendering performance test, whether the FD is run or not is probably noise compared to other things that do run (Nasal, Canvas for example)

Also, Multi-monitor setup is not tested so commonly unfortunately. <ref>https://sourceforge.net/p/flightgear/mailman/message/36904782/</ref>

== Fgdata ==
=== Nasal scripting (comments) ===
{{WIP}}

The now builtin CppUnit framework can obviously solve all the issues
identified in the old [[Nasal Unit Testing Framework]] wiki article and the discussions it points to
and provide the full framework required.<ref>https://sourceforge.net/p/flightgear/mailman/message/36990615/</ref>

have some very simple tests running now for the route-manager, which rely on Nasal. we're skipping a few of the bigger Nasal modules (local-weather, jetways) and have a few lingering issues in some other modules but the basic concept is working.

A very interesting further step, which you might wish to discuss with Edward, is writing test checks *in* Nasal, since this could be quite a fast way to test some area of the code. There’s several ways that could work, and I don’t know if Edward has always planned something around this, so I won’t preempt that conversation.
<ref>https://sourceforge.net/p/flightgear/mailman/message/36764781/</ref>

we have route-manager tests which validate route_manager.nas is working correctly, and we have Canavs tests ({{fg src file|path=test_suite/simgear_tests/canvas|}}) which poke the Nasal API. <ref>https://sourceforge.net/p/flightgear/mailman/message/36991200/</ref>

We need more FGData testing via the test suite.

Adding the CppUnit assertions to Nasal, is the task James has been suggesting he would do, so others can write tests in pure Nasal.

The other piece is some C++ code to scan a directory for files matching a pattern, eg test_XYZ.nas, and to run each of those automatically.

The idea for testing Nasal would be that you write a small CppUnit
interface in c++ in $FG_SRC/test_suite/*_tests/ (the FGData Nasal
testing would be in a fgdata_tests/ directory). This would register
each test which points to the script in
$FG_SRC/test_suite/shared_data/nasal/, and the setUp() and tearDown()
functions would use helper functions in the fgtest namespace to start
and stop Nasal. The Nasal scripts could then call the CppUnit
assertion macros wrapped up as Nasal functions for communicating
failures and errors to the test suite. <ref>https://sourceforge.net/p/flightgear/mailman/message/36991150/</ref>

Scanning for scripts is a great idea. Then developers (core and content) could write tests in pure Nasal.

However all scripts found and executed will be seen as a single test within the test suite. So maybe we should have a $FG_SRC/test_suite/nasal_staging/ directory for initial development of such auto-scanned scripts. But then we have someone shift them into $FG_SRC/test_suite/system_tests/, $FG_SRC/test_suite/unit_tests/, or $FG_SRC/test_suite/fgdata_tests/ later on? That would give better diagnostics and would avoid long-term clutter.<ref>https://sourceforge.net/p/flightgear/mailman/message/36991198/</ref>

* First we should probably hard code tests into the C++ framework. The CppUnit assertion macros will have to be wrapped up as Nasal functions for this.
* Then implement the scanning code as we need some CMake magic (probably using file(COPY, ...)).
* Finally work out if and how we need to improve the Nasal debugging output.

the code could go into a subdirectory in $FG_SRC/test_suite/fgdata_tests/, and the Nasal script in $FG_SRC/test_suite/shared_data/nasal/.

== References ==
{{Appendix}}

[[Category:Core development]]

Software testing

2022-05-16T10:53:06Z

Legoboyvdlp: /* Building the test suite */

{{Note|There’s already the test_suite in {{fg src file|path=test_suite}} using [[Cppunit effort|CppUnit]], thanks to some hard work by [[User:Bugman|Edward]]. We need more tests written for it, submissions welcome. (Pick an area of interest)<ref>https://sourceforge.net/p/flightgear/mailman/message/36972720/</ref>}}

{{See also|Cppunit effort}}

The FlightGear source code and data are tested by the FlightGear developers using a number of tools. This includes automated testing via unit tests in [[SimGear]] and a full test suite with multiple test categories in the [[FlightGear Git|flightgear repository]], as well as manual in-sim testing. Writing tests is one of the best ways to jump into FlightGear development.

One improving area is unit-testing: because of which, certain areas and features (eg, carrier start) now ‘can’t break’. As we add more such areas (eg Multi-player, AI, protocols and replay are all possible), we increase the baseline quality, and also have a clearer idea when we make incompatible changes. (The idea being we capture the ‘supported API’ in the tests: when an aircraft deviates from that, we can decide to add another test case, fix the aircraft, etc). Of course, there’s some pretty major areas where Automated Testing Is Hard (TM).<ref>https://sourceforge.net/p/flightgear/mailman/message/37078825/</ref>

== SimGear ==

The [[SimGear]] sources are checked via unit testing. This is implemented using the CMake CTest unit testing infrastructure. A number of tests are currently implemented using the BOOST unit testing infrastructure tied to the build system using CTest, however this should be avoided when writing tests as there is a shift towards eliminating BOOST by the FlightGear developers.

=== Building and running the SimGear tests ===
<syntaxhighlight lang="bash">
$ make
$ ctest
</syntaxhighlight>

== FlightGear ==

Testing of the [[FlightGear Git|flightgear sources]] is via a comprehensive test suite implemented using [https://www.freedesktop.org/wiki/Software/cppunit/ CppUnit], a port of the famous JUnit framework.

=== Building the test suite ===

To run the tests you will need to build FlightGear from source using cmake. See [[Building FlightGear]] for details.

Once you have your cmake build environment do the following:
# Change to your FlightGear build directory
# Enable building the tests by setting a cmake variable: <code>cmake -LBUILD_TESTING=ON .</code>
# Ensure the <code>[[$FG ROOT|$FG_ROOT]]</code> environment variable points to fgdata e.g. <code>$FG_INSTALL_DIR/share/fgdata</code>
# Build the test suite: <code>make test_suite</code>

This will also run the full test suite (see below), because you will typically want to write a test and then immediately compile and run it.

On a Windows MSVC-based build environment, after generating files with cmake, run the following code:
# cmake --build . --config RelWithDebInfo --target test_suite/test_suite

=== Running the test suite ===

To run the test suite, simply run <code>./test_suite/fgfs_test_suite</code>

This will run the full test suite and print a Synopsis of results similar to the following:

Synopsis
========

System/functional tests ....................................... [ OK ]
Unit tests .................................................... [ OK ]
Simgear unit tests ............................................ [ OK ]
FGData tests .................................................. [ OK ]
Synopsis ...................................................... [ OK ]

You can also run individual test cases. Run <code>./test_suite/fgfs_test_suite -h</code> to see the various options

=== Why write unit tests? ===

A well tested piece of software will have a much lower bug count/load. An extensive test suite with '''unit tests''', system/functional tests, GUI tests, installer tests, and other categories of tests can significantly help in this regard.

The benefits of not just chasing clear "wins" are great: An awesome learning experience for new developers; the ability to catch latent, unreported bugs; making it easier to refactor current code by creating a safety net; making it easier for current developers to accept new contributions (when accompanied with passing tests); helping other test writers by contributing to the common test suite infrastructure; and being able to easily check for memory leaks or other issues via Valgrind.<ref>https://sourceforge.net/p/flightgear/mailman/message/36977686/</ref>

If you are a new developer, just jump in and write any test! It does not need to catch a bug. Do whatever how ever you wish! Just dive in this shallow end and you'll see that the water is not cold.

Writing a test as a safety net. You write the test to pass, make your changes, then make sure that the test still passes. Then you push both the test and core changes.<ref>https://sourceforge.net/p/flightgear/mailman/message/36977465/</ref>

It'd be better jumping into a specific area of interest to you, and submitting merge-requests. That would naturally trigger some C++ feedback when reviewed but we aren’t looking for perfection here, more to increase the overall pool of knowledge of what best-practice looks like, even if a given commit is less than perfect.

I,e It’s more important to have 10 or 20 people actively contributing correct-and-reasonable code than three people contributing absolutely perfect, micro-optimised C++. <ref>https://sourceforge.net/p/flightgear/mailman/message/36951247/</ref>

=== Benefits of unit testing ===
There are lots of benefits to writing tests that pass.

Benefits include :

* Learning! New developers can learn a ton from writing a number of passing tests in the area they are interested in. This is one of the quickest ways to learn about a pre-existing and mature code base. You have zero worries about breaking things. This is diving in the shallow end.

* Latent bug uncovering. For every ten tests you write expecting them to pass, one will probably fail. Or at least uncover unexpected behavior that can be improved.

* Refactoring. If we had 10,000 passing tests (assuming universal test coverage), large scale refactoring of the entire code base would be quick and reliable. It would enable refactoring on a scale currently unimaginable. I cannot emphasize enough how much of a benefit this would be.

* Developer turnover. Again if we had 10,000 passing tests (assuming universal test coverage), it would encourage new developers. This is because the fear of breaking something is removed. It is a total safety net. It also would give existing developers peace of mind when a new developer is touching one of the dark parts of FlightGear that no current developer understands (there are plenty of those) .

* Test suite infrastructure. The more passing tests written, the better the test suite infrastructure will become. We can already do a lot. But the addition of more passing tests will help other test writers.

* Memory checking. Running a single test through Valgrind is amazing. Running FlightGear through Valgrind is close to impossible. Passing tests can be written to catch memory leaks!

* Low code quality and standards. This is related to the learning point. As long as a test compiles on all OSes without warning, it passes, and Valgrind gives you an ok, it is good enough. You dont need to be a C++ expert to dive into this shallow end of the pool.

=== Bootstrapping completely new tests ===
To start diving straight into the test suite code, firstly copy what has been done in this commit: {{repo link
| site = sf
| user = edauvergne
| repo = flightgear
| commit = 8474df
| view = commit
}}

Just modify all names for a JSBSim test (or any other test fixture you
want to code). You should then be able to compile and check that your
new testDummy() test passes as expected. You can then slowly build up
from this basic infrastructure as you learn the fgfs internals, c++,
and git skills required for implementing your test on your fork's new
development branch :)

=== Headless testing ===
{{Main article|FlightGear Headless}}

For an FDM+systems test, we should run FG without a renderer (which is what the test_suite does), to benchmark the pure C++ performance of whatever system it is we care about (FDM or whatever). But this is not really worth doing anyway, since a few hours playing with ‘perf’ on Linux / Instruments on macOS will show you that 80% of our CPU time is spent in OSG + the GL drivers, and hence Amdhal’s law will always get you.<ref>https://sourceforge.net/p/flightgear/mailman/message/36977666/</ref>

=== Graphics testing ===
{{See also|FlightGear Benchmark}}

The other thing is to setup some test-case scenes where you can quickly measure differences and compare via screenshots. The brain/eye/memory are very bad at this stuff, setup something you can load from the command line via a script to test old/new versions, if possible. <ref>https://sourceforge.net/p/flightgear/mailman/message/36959002/</ref>

For example, a test would would be a .[[fgfsrc]] that makes:
* c172p at some parking in a detailed airport;
* camera looking at it in specific direction with specific FOV;
* AW with specific METARs around (if not possible, BW with specific METAR);
* fixed rendering settings (several variants may be needed for renderers and threading modes) <ref>https://sourceforge.net/p/flightgear/mailman/message/36975122/</ref>

We can already load a [[Instant Replay|replay tape]] on startup, however, which is good for testing rendering (scenery, loading) performance, since the FDM is not involved, nor is the user-interface.

But essentially any and all of the methods proposed can be done here with small amounts of shell-script + Nasal hacking I think, and any of them would be welcome additions. For lower-level tests run by developers, the unit-test framework is great (i.e ‘does the API call produce the right results in the system’), but a smoke-test that regular users can run would be ideal.

A rendering performance would likely do:

* select some particular rendering settings (clouds, draw distance, etc)
* run a saved fgtape recording
* record the mean/min/max FPS during this and save it in some text file / copy to the clipboard

So yes, if anyone wants to work on the above, the code is all there, please jump in and start hacking - I don’t think it needs any more from the core code, but as ever, please just ask if it does.<ref>https://sourceforge.net/p/flightgear/mailman/message/36975213/</ref>

For example, describing a /rendering/ test (to establish FPS) - the advantage of a replay tape is the actual position (and therefore what is rendered) will be 100% consistent acorss different computers.

Keep in mind that the CPU use of the FDM+systems is typically < 10% of our total CPU use, even when running OSG single-threaded, so for a rendering performance test, whether the FD is run or not is probably noise compared to other things that do run (Nasal, Canvas for example)

Also, Multi-monitor setup is not tested so commonly unfortunately. <ref>https://sourceforge.net/p/flightgear/mailman/message/36904782/</ref>

== Fgdata ==
=== Nasal scripting (comments) ===
{{WIP}}

The now builtin CppUnit framework can obviously solve all the issues
identified in the old [[Nasal Unit Testing Framework]] wiki article and the discussions it points to
and provide the full framework required.<ref>https://sourceforge.net/p/flightgear/mailman/message/36990615/</ref>

have some very simple tests running now for the route-manager, which rely on Nasal. we're skipping a few of the bigger Nasal modules (local-weather, jetways) and have a few lingering issues in some other modules but the basic concept is working.

A very interesting further step, which you might wish to discuss with Edward, is writing test checks *in* Nasal, since this could be quite a fast way to test some area of the code. There’s several ways that could work, and I don’t know if Edward has always planned something around this, so I won’t preempt that conversation.
<ref>https://sourceforge.net/p/flightgear/mailman/message/36764781/</ref>

we have route-manager tests which validate route_manager.nas is working correctly, and we have Canavs tests ({{fg src file|path=test_suite/simgear_tests/canvas|}}) which poke the Nasal API. <ref>https://sourceforge.net/p/flightgear/mailman/message/36991200/</ref>

We need more FGData testing via the test suite.

Adding the CppUnit assertions to Nasal, is the task James has been suggesting he would do, so others can write tests in pure Nasal.

The other piece is some C++ code to scan a directory for files matching a pattern, eg test_XYZ.nas, and to run each of those automatically.

The idea for testing Nasal would be that you write a small CppUnit
interface in c++ in $FG_SRC/test_suite/*_tests/ (the FGData Nasal
testing would be in a fgdata_tests/ directory). This would register
each test which points to the script in
$FG_SRC/test_suite/shared_data/nasal/, and the setUp() and tearDown()
functions would use helper functions in the fgtest namespace to start
and stop Nasal. The Nasal scripts could then call the CppUnit
assertion macros wrapped up as Nasal functions for communicating
failures and errors to the test suite. <ref>https://sourceforge.net/p/flightgear/mailman/message/36991150/</ref>

Scanning for scripts is a great idea. Then developers (core and content) could write tests in pure Nasal.

However all scripts found and executed will be seen as a single test within the test suite. So maybe we should have a $FG_SRC/test_suite/nasal_staging/ directory for initial development of such auto-scanned scripts. But then we have someone shift them into $FG_SRC/test_suite/system_tests/, $FG_SRC/test_suite/unit_tests/, or $FG_SRC/test_suite/fgdata_tests/ later on? That would give better diagnostics and would avoid long-term clutter.<ref>https://sourceforge.net/p/flightgear/mailman/message/36991198/</ref>

* First we should probably hard code tests into the C++ framework. The CppUnit assertion macros will have to be wrapped up as Nasal functions for this.
* Then implement the scanning code as we need some CMake magic (probably using file(COPY, ...)).
* Finally work out if and how we need to improve the Nasal debugging output.

the code could go into a subdirectory in $FG_SRC/test_suite/fgdata_tests/, and the Nasal script in $FG_SRC/test_suite/shared_data/nasal/.

== References ==
{{Appendix}}

[[Category:Core development]]

Nasal optimisation

2022-04-29T19:36:00Z

Legoboyvdlp: /* PartitionProcessor */

{{Nasal Navigation}}

= Introduction to writing Nasal for optimum performance =

Writing optimal performing code in a real time system (in any language) is usually related to minmising the per frame impact of any given set of code; which may end up with slightly slower code but the point is to ensure that the real time frame rate does not degrade.

The basic techniques are as follows;

# Measure and locate (profile) code.
# Do less
# Cache more
# Spread out workload
# Avoid garbage collection

Inside each [[Nasal]] frame the programmer needs to ensure that the minimum necessary work is performed; ideally a predictable workload to ensure that Nasal processing per frame is constant - because otherwise there can be frame pauses - which is where an occasional frame will take much longer than usual.

Splitting any given task across frames is the normal way of ensuring that performance remains good; unfortunately a lot of Nasal doesn't do this and instead will process everything each frame. This is what the PartitionProcessor is designed to help with

Do not use getprop or setprop - these are very slow; instead use the props.nas module to refer to the property tree.

All property tree access is much slower than using native Nasal variables; and it is therefore wise to only read each property from the tree once per frame. This is what the FrameNotification is designed to help with.

Writing data to Canvas displays can be considered to be a slow operation; so only write values that are changed. props.UpdateManager can help with this.

Generally using props.UpdateManager (with the FrameNotification hash) can be generally used to perform OnChange processing that is more efficient than the property listeners - however property listeners should still be used to perform occasional actions (rather than per frame actions)

== fdm-initialized listener ==
It is important to realise that sim/fdm-initialized will be set to true every time the model is repositioned; i.e. it does not fire just once. When sim/fdm-initialized is set to false the model should clean up all previously initialised listeners, threads, timers etc.

Generally it is much better to set timers, listeners (etc) at module level scope inside any Nasal file; as these will be executed only once. Using the Emesary FrameNotification can further simplify per frame processing because there is no need to use a timer per module and instead any modules can register themselves for frame processing simply by using GlobalNotifier.Register and all of the details are abstracted away and all that needs to happen is to handle the received notifications.

This is an example of acquiring and releasing listeners and timers.

<syntaxhighlight lang="nasal">
var l1 = nil;
var timer_loopTimer = nil;
var fdm_init = func(v) {

# always clean up values that aren't nil - this is safe
if (l1 != nil)
removelistener(l1);
l1 = nil;

if (timer_loopTimer != nil)
timer_loopTimer.stop();
timer_loopTimer = nil;

# then acquire new values
if (v.getValue()){
print("Initializing Systems");
l1 = setlistener("/some-prop", listener_func);
timer_loopTimer = maketimer(0.25, timer_loop);
timer_loopTimer.start();
}
else {
# now perform any other cleanup.
print("Cleaning up");
}
}

setlistener("sim/signals/fdm-initialized", fdm_init);
</syntaxhighlight>

However the above can be better written as follows;

<syntaxhighlight lang="nasal">
var l1 = setlistener("/some-prop", listener_func);
var timer_loopTimer = maketimer(0.25, timer_loop);

var fdm_init = func(v) {
if (v.getValue()){
timer_loopTimer.start();
}
else {
timer_loopTimer.stop();
}
}
setlistener("sim/signals/fdm-initialized", fdm_init);
</syntaxhighlight>

== Nasal threads ==

Nasal threads are of limited use because most of the time it is property tree access and other API calls that are slow and a lot of the API library (including properties) are not thread safe and should not be called from outside the main loop.

= Optimisation techniques =

The F-15 I think is the reference implementation of my three main Nasal optimisation techniques;

== Nasal Profiling ==

As yet there isn't a profiler available so instead there is an OperationTimer that is ships as part of emexec (2020.3 or later released after Aprial 2022).

This makes it easy to output (via logprint) information about how much time a module is taking.

To create an instance of a timer there are two parameters, the first is the ident and the second the log level (3=info, 2=debug)
<code>var ot = emexec.OperationTimer.new("VSD",2);</code>
The output is a cumulative number of milliseconds since the OperationTimer was reset.
<code>ot.reset();
ot.log("Start");
<some code to time>
ot.log("1");
<more code>
ot.log("ed");</code>

== Emesary real time executive ==

Starting from 2020.3 released after April 2022 FGdata includes the emexec module which provides an easy to use object scheduler that uses Emesary to do most of the work.

By default it is recommended to use the built in scheduler <code>emexec.ExecModule</code>

The scheduler will adjust the frequency from 50hz right down to 4hz.

Any object that wishes to be invoked simply needs to provide an <code>update(notification)</code> method and register itself via ExecModule.register method.

The register method takes the following arguments

# ident - text to identify this object registration
# properties_to_monitor : a key value pair hash of properties to include in the notification. This helps to optimise property tree access (see FrameNotification below for the format)
# object : an instance of an objec that has an update(notification) method
# rate : frame skip rate (1/rate is the effective rate)
# frame_offset : frame skip offset. Must be less than rate and when used with rate it can allow interleaving of modules (usually for performance)

During development it would be usual to set the overrun detection active emexec.ExecModule.transmitter.OverrunDetection(9) for a warning (log leve info) of any frame that exceeds 9 ms

== FrameNotification ==

The FrameNotification is a notification sent out at defined intervals that contains a hash with property values.

Use the FrameNotificationAddProperty to request that certain properties are contained within the FrameNotification.

<syntaxhighlight lang="nasal">
notifications.FrameNotificationAddProperty.new("F15-HUD", **[HASH-Name]**, **[property-string]**)
</syntaxhighlight>

e.g.

<syntaxhighlight lang="nasal">
emesary.GlobalTransmitter.NotifyAll(notifications.FrameNotificationAddProperty.new("F15-HUD", "AirspeedIndicatorIndicatedMach", "instrumentation/airspeed-indicator/indicated-mach"));`
</syntaxhighlight>

although more typically used by having a hash that contains the keys and properties that you want to monitor and then using a loop to send out the FrameNotificationAddProperty; e.g.:

<syntaxhighlight lang="nasal">
input = {
AirspeedIndicatorIndicatedMach : "instrumentation/airspeed-indicator/indicated-mach",
Alpha : "orientation/alpha-indicated-deg",
AltimeterIndicatedAltitudeFt : "instrumentation/altimeter/indicated-altitude-ft",
ArmamentAgmCount : "sim/model/f15/systems/armament/agm/count",
ArmamentAim120Count : "sim/model/f15/systems/armament/aim120/count",
ArmamentAim7Count : "sim/model/f15/systems/armament/aim7/count",
ArmamentAim9Count : "sim/model/f15/systems/armament/aim9/count",
ArmamentRounds : "sim/model/f15/systems/gun/rounds",
AutopilotRouteManagerActive : "autopilot/route-manager/active",
AutopilotRouteManagerWpDist : "autopilot/route-manager/wp/dist",
AutopilotRouteManagerWpEtaSeconds : "autopilot/route-manager/wp/eta-seconds",
CadcOwsMaximumG : "fdm/jsbsim/systems/cadc/ows-maximum-g",
ControlsArmamentMasterArmSwitch : "sim/model/f15/controls/armament/master-arm-switch",
ControlsArmamentWeaponSelector : "sim/model/f15/controls/armament/weapon-selector",
ControlsGearBrakeParking : "controls/gear/brake-parking",
ControlsGearGearDown : "controls/gear/gear-down",
ControlsHudBrightness : "sim/model/f15/controls/HUD/brightness",
ControlsHudSymRej : "sim/model/f15/controls/HUD/sym-rej",
ElectricsAcLeftMainBus : "fdm/jsbsim/systems/electrics/ac-left-main-bus",
HudNavRangeDisplay : "sim/model/f15/instrumentation/hud/nav-range-display",
HudNavRangeETA : "sim/model/f15/instrumentation/hud/nav-range-eta",
OrientationHeadingDeg : "orientation/heading-deg",
OrientationPitchDeg : "orientation/pitch-deg",
OrientationRollDeg : "orientation/roll-deg",
OrientationSideSlipDeg : "orientation/side-slip-deg",
RadarActiveTargetAvailable : "sim/model/f15/instrumentation/radar-awg-9/active-target-available",
RadarActiveTargetCallsign : "sim/model/f15/instrumentation/radar-awg-9/active-target-callsign",
RadarActiveTargetClosure : "sim/model/f15/instrumentation/radar-awg-9/active-target-closure",
RadarActiveTargetDisplay : "sim/model/f15/instrumentation/radar-awg-9/active-target-display",
RadarActiveTargetRange : "sim/model/f15/instrumentation/radar-awg-9/active-target-range",
RadarActiveTargetType : "sim/model/f15/instrumentation/radar-awg-9/active-target-type",
InstrumentedG : "instrumentation/g-meter/instrumented-g",
VelocitiesAirspeedKt : "velocities/airspeed-kt",
};
foreach (var name; keys(input)) {
emesary.GlobalTransmitter.NotifyAll(notifications.FrameNotificationAddProperty.new("F15-HUD", name, input[name]));
}
</syntaxhighlight>

The idea of the FrameNotification is that it provides an easy way to run your update logic; simply by registering with the GlobalTransmitter and then processing the FrameNotification you can call your update logic in an efficient manner;

e.g.

<syntaxhighlight lang="nasal">
var HUDRecipient =
{
new: func(_ident)
{
var new_class = emesary.Recipient.new(_ident);
new_class.MainHUD = nil;
new_class.Receive = func(notification)
{
if (notification.NotificationType == "FrameNotification")
{
if (new_class.MainHUD == nil)
new_class.MainHUD = F15HUD.new("Nasal/HUD/HUD.svg", "HUDImage1");
if (!math.mod(notifications.frameNotification.FrameCount,2)){
new_class.MainHUD.update(notification);
}
return emesary.Transmitter.ReceiptStatus_OK;
}
return emesary.Transmitter.ReceiptStatus_NotProcessed;
};
return new_class;
},
};
</syntaxhighlight>
and then register that function with the Emesary Global transmitter.

<syntaxhighlight lang="nasal">
emesary.GlobalTransmitter.Register(HUDRecipient.new("F15-HUD"));
</syntaxhighlight>

------

== props.UpdateManager ==

This will monitor one or more property, or values from a hash and call a function (or inline function) when the value or a value changes more than a defined amount.

e.g.
<syntaxhighlight lang="nasal">
obj.update_items = [
props.UpdateManager.FromHashList(["ElectricsAcLeftMainBus","ControlsHudBrightness"] , 0.01, func(val)
{
if (val.ElectricsAcLeftMainBus <= 0
or val.ControlsHudBrightness <= 0) {
obj.svg.setVisible(0);
} else {
obj.svg.setVisible(1);
}
}),
props.UpdateManager.FromHashValue("AltimeterIndicatedAltitudeFt", 1, func(val)
{
obj.alt_range.setTranslation(0, val * alt_range_factor);
}),

props.UpdateManager.FromHashValue("VelocitiesAirspeedKt", 0.1, func(val)
{
obj.ias_range.setTranslation(0, val * ias_range_factor);
}),
props.UpdateManager.FromHashValue("ControlsHudSymRej", 0.1, func(val)
{
obj.symbol_reject = val;
}),
...
</syntaxhighlight>

and then in the update method
<syntaxhighlight lang="nasal">
foreach(var update_item; me.update_items)
{
update_item.update(notification);
}
</syntaxhighlight>
As you can see above the update method is called from the recipient of the frame notification.

== PartitionProcessor ==

When working with lists (arrays) of data that can get quite long (e.g. targets from radar) the partition processor is an easy way to only process a part of that list each frame.

What it does is to manage the processing of data in a manner suitable for real time operations. Given a data array [0..size] this will process a number of array elements each time it is called This allows for a simple way to split up intensive processing across multiple frames.

The limit is the number of elements to process per frame (invocation of .process method) or to limit the processing to a specified amount of time using a Nasal timestamp to measure the amount (in usec)

example usage (object);

<syntaxhighlight lang="nasal">
var VSD_Device =
{
new : func(designation, model_element, target_module_id, root_node)
{
...
# new : func(_name, _size, _timestamp=nil)
obj.process_targets = PartitionProcessor.new("VSD-targets", 20, nil);
obj.process_targets.set_max_time_usec(500);
...
me.process_targets.set_timestamp(notification.Timestamp);
</syntaxhighlight>

then invoke.

<syntaxhighlight lang="nasal">
# process : func (object, data, init_method, process_method, complete_method)

me.process_targets.process(me, awg_9.tgts_list,
func(pp, obj, data){
initialisation; called before processing element[0]
params
pp is the partition processor that called this
obj is the reference object (first argument in the .process)
data is the entire data array.
}
,
func(pp, obj, element){
process individual element;
params
pp is the partition processor that called this
obj is the reference object (first argument in the .process)
element is the element data[pp.data_index]
return 0 to stop processing any more elements and call the completed method
return 1 to continue processing.
},
func(pp, obj, data)
{
completed; called after the last element processed
params
pp is the partition processor that called this
obj is the reference object (first argument in the .process)
data is the entire data array.
});
</syntaxhighlight>

Changelog 2020.3

2022-02-03T11:35:31Z

Legoboyvdlp: /* 2020.3.12 */ New changelog

{{changelogs|prev=2020.1|next=2022.1}}

Available in: [[Changelog_2020.3|English]], [[Zh/2020.3|Chinese]]

Please help us translate into other languages!

----
The FlightGear development team is delighted to announce the v2020.3 LTS release of FlightGear, the free, open-source flight simulator. This is the second Long Term Support release for FlightGear, since the project changed to offering both Long Term Support releases, and more cutting-edge Preview releases. This release represents the culmination of two years of development effort by a worldwide group of volunteers, brought together by a shared ambition to create the most realistic flight simulator possible that is free to use, modify and distribute. FlightGear is used all over the world by desktop flight simulator enthusiasts, for research in universities and for interactive exhibits in museums.

Major enhancements since the v2020.3 LTS include:
* a developer preview of the upcoming Compositor graphical rendering framework as a separate pre-built binary,
* enhancements to both the JSBSim and YASim flight dynamics models
* DDS texture caching to reduce load times
* faster loading and more memory efficient buildings
* improved aircraft carrier support

Additionally 30 completely new aircraft have been added to the official hangar, and a further 71 have received major updates.

{{Disclaimer|id=final-fixed-function-release}}

Founded in 1997, FlightGear features more than 700 aircraft, a worldwide scenery database, a multiplayer environment, detailed sky modelling, a flexible and open aircraft modelling system, varied networking options, multiple display support, a powerful scripting language, and an open architecture. Best of all, being open-source, the simulator is owned by the community and everyone is encouraged to contribute.

FlightGear - Fly Free!

----

== Launcher ==
* Addition of a welcome screen on first launch, providing helpful information to first time users.
* Aircraft can now be marked as Favourites, and filtered, making it easier to see find your favourite aircraft out of the hundreds available.
* The launcher now supports aircraft carriers, including selecting a carrier and setting a start position.
* {{key press|Ctrl|F}} shortcut for when you just want to Fly!
* Improved support for helipads and seaports, including detection of current aircraft type.
* Numerous bugfixes and stability improvements, in particular for the aircraft and addons tabs.

== Graphics ==
* To provide a developer preview, the [[Compositor]] renderer is included as part of this release. It provides a fully XML-configurable multi-pass rendering pipeline that is compatible with ALS and includes clustered shading.
* Support for DDS Texture Cache, improving loading times for texture files.
* Star visibility is configurable based on magnitude of star and atmospheric conditions.
* Use of non-directional point sprites as a fallback for drivers that do not support triangles of point sprites is now supported by setting <code>/rendering/triangle-directional-lights=false</code>.
* A new Tower AGL view has been added. This is similar to Tower View, except that it keeps both the aircraft and the ground immediately below the aircraft in view, zooming and panning smoothly as the aircraft moves. Good for viewing landings.
* Improved airport grass textures
* Implemented tidal movement for littoral areas.
* Updated regional material definitions for California, Asia, Northern Brazil, Iceland, Jan Mayen island.
* Active volcanoes - Katla, Eyjafjallajokull, Surtsey.
* Instanced-based random and OpenStreetMap buildings, improving performance and graphical quality significantly.
* Improvements to the Wingflex Shader.
* Users may enable/disable the pilot model from the View Options dialog.

== JSBSim ==
* Added the ability to set up the starter and acceleration times of a turbine (parameters <code><n1spinup></code>, <code><n2spinup></code>, <code><n1startrate></code>, <code><n2startrate></code>).
* The <code><integrator></code> filter can now be reset to 0.0 by setting its <code><trigger></code> property to a negative value.
* The integration scheme of the <code><integrator></code> filter can now be chosen among <code>rect</code> (Euler), <code>trap</code> (Trapezoidal), <code>ab2</code> (2nd order Adams-BashForth) and <code>ab3</code> (3rd order Adams-Bashforth)
* The following functions can now be used in <code><function></code>: <code>floor</code>, <code>ceil</code> and <code>fmod</code>. Their functionalities are the same than the corresponding C/C++ functions.
* <code><function></code> now checks the number of its arguments.
* New system component linear_actuator
* Export the fuel density to the property tree
* Added cyclic clipping for FCS components
* Added the ability to control the turbine engines spin down factor
* [Backward compatibility breakage] Gyros are now measuring rotation rates instead of rotational accelerations. Gyros that measure rotational accelerations do not exist in the real world.
* Output properties of flight control elements are no longer tied. This saves a lot of spurious warning messages and allows direct references of the same properties among several flight controls.
* Water vapor in the atmosphere is now managed through its mass fraction rather than its partial pressure. The former being the physical quantity that is conserved when pressure and temperature vary.
* Check that there are at least 3 contacts before trying to trim on ground.
* Added optional transmission of the simulation time for FG UDP interface
* The existence of the property that is used for table independent vars is now checked during execution rather than when the XML definition is parsed. This relaxes the order in which filters, table and more generally flight controls need to be declared in the XML definition files.
* Electric engines RPM is now exported in UDP sockets.
* The parameter <code><ignitionn2></code> now affects N2 rather than N1.
* A warning is now given when max < min in a <code><clipto></code> rather than throwing an exception
* Added the ability to log properties in a CSV file with the new fgfs executable argument <code>--jsbsim-output-directive-file</code>

== YASim ==
* Ground friction (stiction) changes
* Support for transonic flow effects.
* Control initial gear state directly by setting <code>/fdm/yasim/respect-external-gear-state=true</code>, rather then YASim settings this depending on whether the aircraft is in the air or on the ground.
* Electric engines are now supported.

== Weather and Environment ==
* Increased turbulence will be encountered near active volcanoes.
* Configurable METAR URL.
* METAR strings are decoded and displayed in a human-readable form in the weather dialog.

== Carriers ==
* Two new carrier-specific starting options are supported in the launcher: <code>carrier-takeoff</code> and <code>carrier-approach</code>.
* A new <code>--carrier-position</code> command-line argument has been added. This can be used to select the aircraft start position on an aircraft carrier. Either a catapult (e.g. <code>cat-1</code>), a parking position (e.g. <code>park-1</code>), on final approach on the FLOLS (<code>flols</code>) or abeam the carrier (<code>abeam</code>).
* MPCarrier can now be detected by the GUI even if not available on startup. To enable this feature set <code>/sim/mp-carriers/auto-attach=true</code>.

== AI ==
* New fgcommands <code>add-aiobject</code> and <code>remove-aiobject</code> for adding/removing objects to the AI subsystem.
* New AI aircraft, including 747 Freighter, CRJ900, SR-71, Saab 340.
* Numerous updates to AI traffic schedules and airline liveries.
* Space Shuttle TAEM and approach at KEDW scenario.
* Accurate Britten-Norman Islander performance data, from an Islander pilot.

== Multiplayer ==
* Connection to VATSIM via swift is now available via the GUI.
* FGCom now supports both COM1 and COM2, as well as volume settings.
* The views defined by the user's aircraft (Pilot view, Helicopter view, Tower view etc) can now be used with multiplayer aircraft. Viewing a particular multiplayer aircraft is done by clicking in the Pilot List dialogue's "view' column (see the "Multiplayer/Pilot List" menu).
* <code>--disable-hold-short</code> option which allows the user to force a start on the runway when multiplayer is enabled. This option should be used with caution - it can give other pilots and ATC a nasty fright to find an aircraft materialize on the runway!
* Support for recording multiplayer data

== Nasal Scripting ==
* Configurable load order for core Nasal modules.
* Improvements and bug fixes to Emesary, the messaging interface.
* Improvements to the core libraries.
* Garbage collection improvements to reduce frame stuttering
* Re-loadable Nasal modules
* Canvas EFIS framework
* New methods in Canvas Image to set colors of pixels in the image.

== Aircraft ==
* FG1000 Glass Panel improvements include user-configurable VFR transponder codes, volume controls, new fascia, UI is now resizeable, support for custom SVG files (e.g. for a G500). The FG1000 is now available on the Cessna 182T, J3 Cub, Diamond DA40.
* Improved glider vario instrument.
* New Aircraft:
** Airbus A320 - airliner
** Alisport Silent2Electro - glider with electric sustainer motor
** Bombardier Q400 DHC8-402 - shorthaul turboprop airliner
** Breguet Atlantic BR 1150 - long-range maritime patrol aircraft
** Cessna 140 - GA aircraft
** Cessna 208B Caravan - short range passenger, freighter and utility aircraft
** Cirrus SR22T - GA aircraft
** Diamond DA40 NG - GA aircraft, including FG1000 glass panel cockpit
** Diamond DA62 Twinstar- Twin engine GA aircraft
** Diamond HK36 Super Dimona - motorglider
** Dornier DO 28 Skyservant - Twin engine STOL utility aircraft
** Douglas TBD Devastator - WWII Torpedo bomber
** Draco Wilga - turboprop taildragger bush plane
** Fokker T.V - twin engine bomber
** Glasfluegel H201B Standard Libelle - glider
** Grumman F11-Tiger - carrier-based fighter
** Grumman HU-16A Albatross - twin engine amphibian
** Petliakov PE-8 (Ant-42/TB-7) - WWII bomber
** Piper PA28-161 Warrior II - GA aircraft
** Pipistrel Alpha Electro - electric training aircraft
** Pipistrel Taurus Electro G2.5 - glider with electric sustainer motor
** Rolladen Schneider LS8sc neo - standard glider with electric sustainer motor
** Robin DR400 Ecoflyer - GA Aircraft
** Scheibe Bergfalke II/55 - training glider
** Schempp-Hirth Arcus S - high performance glider
** Schleicher Ka6(CR) "Rhoensegler" - training glider
** SEPECAT Jaguar GR.1 - jet attack aircraft
** SUMPAC - Human powered airplane
** Supermarine Swift - jet fighter
** Yak 52 - training aircraft
* Major updates to over 70 aircraft. Including 737-100, 737-300, 777, A-26-Invader, AR-234, ASG29, ASK13, ASK21, Aero-Commander, Aichi-D3A, B-17, B-24-Liberator, B-25, Bombardier-415, CH750STOL, CRJ700-family, Cessna-208-Caravan, Cessna Citation II, Cessna-L19, Cirrus-SR22, Concorde, DO-228, DO-335, Diamond-Da40, Diamond-Da42, Dragonfly, Embraer-ERJ-145, F-15, Fairchild-Metroliner, Falcon-50, Fokker-S-11, Fw200, H4-Hercules, Harrier-GR3, Horten-Ho-IX, Hughes-XF11, J3Cub, JA37, JAS39-Gripen, Jaguar, LS4, Lancair-235, Lionceau, Lockheed-NF104A, Lockheed-P38, ME-262, Mirage-2000, MirageIV, Northrop-xb35, PC-12, Piaggio-P166, Piper-PA-28, Potez-630, R44, Ryan-Navion, SIAI-Marchetti-SF.260, Socata-ST10, SpaceShuttle, Starship, Tecnam-P2006T, UH-1, Yak-18T, Zlin-50lx, an24b, bluebird, c182s, dhc1, f-14b, f16.

== Miscellaneous ==
* Updated Chinese, Dutch, French, German, Italian, Polish and Slovak translations.
* Map dialog displays heliports and allows configurable cursor key panning
* Faster Terrasync: Download a tarball of airport information on first start and only check for updates every 24 hours rather than every simulator run.
* GPS fly-by mode
* Sentry.io integration to provide centralized crash reporting.
* Change screenshot filename to have date and time
* New thread safe particle manager -- should reduce random crashes around particles.

=Updates since 2020.1=
Changes since the 2020.1 preview release include:
* Various launcher improvements including a Welcome screen and a keyboard shortcut (Ctrl+F) to Fly!
* Improved regional definitions for California, Iceland and Northern Brazil and better grass textures.
* Implemented tidal movement for littoral areas.
* New AI model for the 747 Freighter, and numerous AI livery and traffic updates.
* Updates to the FG1000 glass panel display including configurable VFR transponder codes, volume controls, a new fascia, resizeable UI and support for custom SVG files.
* A hangar full of new aircraft: HU-16A-Albatross, LS8, Embraer-ERJ-145, Cessna 208B Caravan, PZL 104 wilga 2000 Draco, Scheibe Bergfalke, Taurus, f16, Dornier Do 28 Skyservant, Petliakov Pe 8 (Ant 42/DB 7), Grumman F.11 Tiger
* Updates to a large number of aircraft including CRJ700, Dragonfly, Mirage 2000, Jaguar GR1, H4 Hercules, JA37, Supermarine Swift, A320, Cirrus-SR22, Cessna Citation, J3Cub
* Updated Chinese, Dutch, French, German, Italian, Polish and Slovak translations.
* Faster Terrasync: Download a tarball of airport information on first start and only check for updates every 24 hours rather than every simulator run.
* GPS fly-by mode
* Sentry.io integration to provide centralized crash reporting.
* New thread safe particle manager -- should reduce random crashes around particles.

=Updates since 2020.3.0=

As 2020.3 is a long term supported release, there are ongoing bug-fixes and small improvements happening, based on user feedback and automatic reporting of crashes and issues. Significant fixes are listed below:

==2020.3.1==
* Add help page to the launcher
* Fix handling of helipads at heliports
* Migrate installed aircraft packages, when migrating to the new stable catalog
* TerraSync: improve startup performance on Windows

==2020.3.2==
* TerraSync waits for Models to be completely sync-ed, to avoid missing models when starting
* First-run screen: add a 'scroll to the bottom' hint icon
* Tides fixes from Erik Hofman
* Use nicer scrollbar for the launcher, fixes some issue with long aircraft lists
* Support Apt.dat v1000 comm frequencies
* Fix an ATC crash when repositioning
* Many translations fixes identified by Michael Danilov
* Greatly improve the Brazilian cerradio areas (near SBMQ)
* Russian translation updates
* Iceland materials fixes

==2020.3.3==
* Fix accidental mouse picks while using a right-mouse-drag to look around
* Fix the download location we recommend in the 'setup root' dialog

==2020.3.4==
* Handle more METAR strings correctly, including wind sensor failures
* Fix airmass velocity being applied to sub-models twice (eg, when dropping payloads in a cross-wind)
* Fix crash on shutdown in the properties code
* Spanish translation updates
* Disable flights to EGEL to avoid crashes in traffic code

==2020.3.5==
* Change default Windows download location to %USERS%\FlightGear\Downloads, to avoid problems with Windows Defender blocking un-trusted applications from writing to Documents, which was the previous location.
* Fix a crash when returning to FlightGear from another application and scrolling or clicking
* Avoid crashing with UIUC-based aircraft such as the Wright Flyer
* Fix a crash on macOS when a joystick failed to open
* Update the macOS application icon
* Fix Nasal crash on reset
* Canvas: allow anisotropic filtering
* Larger, improved moon texture
* UFO speed goes to 11
* Fix taxiway markings disappearing in specific graphics settings

==2020.3.6==
* Fixed crash downloading the default aircraft catalog
* Fix a hang starting at scenery in the ocean
* Fix incorrect sky & cockpit rendering with certain METAR values
* Add getting-started hints to the launcher (English only for now)
* Fix Shuttle AI scenarios
* Improvements to flight-planning mode
* Sun / moon scaling fixes
* Fix initial position of submodels
* macOS: warn if running with app translocation
* Windows: detect missing OpenGL drivers
* Fix UIUC FDM crashes
* Fix crash with invalid view numbers
* Catch FDM NaN errors more gracefully
* KAP-140 approach mode improvements
* Traffic+AI livery updates

== 2020.3.7 ==

* Enable OSM2City buildings via TerraSync for the whole planet
* C172 bug-fixes and updates
* Improved regional material definitions for Europe, California
* Allow chat box to be re-positioned
* Fix crashes related to particle systems
* Fix selection of time-zone around Beijing
* Fix display of non-Latin1 strings in Canvas displays
* Fix Multi-player mode runway-start logic to select hold-short position correctly
* macOS: fix crash on text with certain fonts
* Fix launcher language selection when the UI language include a script specifier (eg zh-Hans-CN)
* Fix aircraft-id property when loading from a hangar ( https://sourceforge.net/p/flightgear/codetickets/2502/ )
* Improve checks for out-of-date Intel Graphics drivers on Windows

== 2020.3.8 ==

* Fix behaviour of <code><local></code> particle systems
* Fix autumn tree appearance

== 2020.3.9 ==

* Fix crash in Swift
* Corrections to MP protocol timing
* Correct URL to FGData
* Fix bug in cache reload dialog
* Improvements to ATC dialog to display frequencies with 3 decimal places correctly
* Improve material definitions for Africa, Mediterranean regions
* Add updated ocean and water visual effects

== 2020.3.10 ==

* Transponder: make standby mode work
* Launcher: pick up scenery and aircraft paths from the command line
* Launcher: store locations differently, to avoid problems when running multiple FlightGear versions and switching between them.
* Launcher: add 'restart on quit' option
* Fix NavCache errors loading ShapeFile data
* Fix NavCache errors when running multiple copies of FlightGear

== 2020.3.11 ==

* Fix a crash introduced in 2020.3.10
* Improve error message when no aircraft search paths are available
* Fix a crash with misconfigured traffic taxi routes
* Update AI traffic schedules

== 2020.3.12 ==

* Add aircraft directory name validation
* Add an extra step of antialiasing (8x)
* Add feature allowing aircraft to define custom fonts for osg::Text
* Add generic combined ALS procedural lights and Compositor lights
* Add new regional materials for Australia
* Fix Basic Weather producing invalid pressure altitudes
* Fix bug in path searching for previews
* Fix bug in sound system when approaching max-dist range
* Fix crashes after reset
* Fix crash when AI aircraft has invalid destination runway
* Fix Mapstructure error in RTE layer
* Fix --view-offset to use the correct property
* HUD: make vertical gauges look the same as horizontal ones
* Improved Russian and Spanish translations
* Miscellaneous improvements to weather dialog
* Property browser: display values for folders in verbose mode
* Route manager: select correct waypoint when duplicate waypoints exist
* Update AI traffic schedules and add new AI models

== References ==
{{Appendix}}

[[Category:FlightGear changelogs‎]]
[[Zh:2020.3]]

Nasal Flightplan

2022-01-26T12:31:22Z

Legoboyvdlp: /* Leg methods and variables */

{{Systems Modeling Disclaimer}}
{{Autoflight Navigation}}
{{Nasal Navigation}}

Because FlightGear's [[route manager]] flight plan system is exposed to [[Nasal]], '''Nasal can be used to interact with flight plans'''. Obviously, this is very useful, especially for aircraft like airliners, which have complex route managers systems. This article shows how this can be done.

== Background ==
The Nasal functions relating to the route manager system include:
* {{func link|flightplan()}} - return the active plan.
* {{func link|airwaysRoute()}}
* {{func link|createFlightplan()}} - creates new empty plan. A path can be supplied to load a plan from xml.

Flight plans are based on waypoints, which, in C++, inherit from the {{API Link|flightgear|class|FGPositioned}} class.

== Waypoint ghost ==
The following are members of a waypoint ghost, as generated by, for example, {{func link|airwaysRoute()}}:

; wp_name ''or'' id: Name of the waypoint, returned as string.
; wp_type :Waypoint type, returned as string. One of "basic," "navaid," "offset-navaid," "runway," "hold", "hdgToAlt," "dmeIntercept," "radialIntercept," "discontinuity", "via", or "vectors."
; wp_role:Role of waypoint. One of "pseudo", "sid", "star", "missed", "approach"
; wp_lat ''or'' lat : Latitude of waypoint.
; wp_lon ''or'' lon : Longitude of waypoint.
; wp_parent_name : Name of waypoint's parent.
; wp_parent :Waypoint's parent as a ghost.
; fly_type : How to waypoint should be flown over or reacted to. One of "flyOver" or "flyBy" or "Hold".
; heading_course :Heading of runway, hdgToAlt, hold, radialIntercept, or dmeIntercept waypoints
; hidden:Boolean flag as to whether it should be shown on map / navigation display when included in a flightplan

=== Hold members ===
The following are hold-specific members:
; hold_is_left_handed : boolean, defines direction of turns in the hold
; hold_is_distance : boolean, defines if hold is measured by distance
; hold_is_time : boolean, defines if hold is measured by time
; hold_inbound_radial ''or'' hold_inbound_radial_deg : returns the inbound radial of the hold, measured in degrees
; hold_time_or_distance : the leg length, defined either in seconds or nautical miles

== Flightplan methods and variables ==
Notice that instead of passing a leg as parameter, a waypoint can be passed.
; getWP(index) : Returns the leg for specified index.
; currentWP() : Return current active leg.
; nextWP() : Make next waypoint active.
; getPlanSize() : Returns number of waypoints
; appendWP(leg) : Add a leg to the end of the flightplan.
; insertWP(leg, index) : Pass a leg object and its position. Example: insertWP(leg, 1) --> leg becomes waypoint at index 1.
; deleteWP(index) : Deletes the waypoint at specified index. Example: deleteWP(0) --> deletes first waypoint.
; insertWPAfter() :
; insertWaypoints(vector, index) : Pass a vector of waypoint objects, and the position to insert.
; cleanPlan() : Clears all waypoints except destination and departure.
; clearWPType(type) : Supply a type string, it will clear all waypoints of the type.
; clone() : Return a copy of the flightplan.
; pathGeod() or pointAlongRoute() : (function has two associated names). This is used for graphical display: it’s an array of coordinates which show the path of the plan. This includes holds, procedure turns, turn anticipation and more.
; finish() : Finish the plan. (a call to delegate will be made)
; indexOfWP(wp) : Returns the index of the passed waypoint/leg.
; destination : airport object as destination.
; destination_runway : rwy object as destination and its airport implicit.
; departure : airport object as departure.
; departure_runway : rwy object as departure and its airport implicit.
; id : optional name of plan.
; sid : procedure object for SID.
; star : procedure object for STAR.
; sid_trans : procedure object for SID transition (as of 2020.2, may be written to)
; star_trans : procedure object for STAR transition (as of 2020.2, may be written to)
; approach : procedure object for approach.
; current : Index of current waypoint.
; aircraftCategory : ICAO aircraft category.
; followLegTrackToFix : Specific used by some procedures. It controls whether the system will fly on an intersection course (and hence, different track) to the end of the leg, or make a corrective S-turn to get back on the leg track immediately it becomes possible.
; activate() : This will make the flight plan the default (the one used in route-manager).
; save(path) : Save a plan to xml. Will return true or false for success.

== Leg methods and variables ==
A leg is a wrapper for a waypoint, so it will have all waypoints variables and methods plus what is listed below.
Notice, that a leg you have gotten from a plan, but deleted in the plan, will be invalid and should not be used or modified.
A leg you have gotten from a plan, when modified, will modify the leg inside the plan you got it from.
; setSpeed(speed, type) : Sets the speed restriction. Setting nil type, will crash FG, setting empty type is same as setting "at". See below for type list.
; setAltitude(altitude, type) : Sets the altitude restriction. Setting nil type, will crash FG, setting empty type is same as setting "at". See below for type list.
; path() : Returns a vector of hashes containing lat and lon variables. These compromise a curved path for long non straight legs.
; courseAndDistanceFrom(coord) : Return vector with true course and distance. Coord is a geo.Coord.
; parents : Nasal parents.
; wp_parent: Will return you the owning route-structure of the WP - this could be an airway, procedure, or the flightplan if the waypoint doesn’t belong to a route structure.
; index : Returns the index of the leg in the owning route-structure.
; alt_cstr : Read-only. Altitude restriction output. Set using setAltitude.
; alt_cstr_type : Read-only. Altitude restriction type. See below for list.
; speed_cstr : Read-only. Speed restriction output. Set using setSpeed.
; speed_cstr_type : Read-only. Speed restriction. See below for list.
; leg_distance : Returns distance along the leg, from the preceding waypoint.
; leg_bearing : Returns the bearing along the leg.
; distance_along_route : Return the total distance laterally along the route to the beginning of the leg.

For speed restrictions these types can be used:
* "at" = kt should be spot on
* "above" = kt should be higher
* "below" = kt should be under
* "computed" = predicted kt
* "computed-mach" = predicted mach
* "mach" = its in mach instead of kt
* "delete" = Cleared by ATC

For altitude restrictions these types can be used:
* "at" = alt should be spot on
* "above" = alt should be higher
* "below" = alt should be below
* "computed" = predicted alt
* "computed-mach" = not used for altitude
* "mach" = not used for altitude
* "delete" = Cleared by ATC

== Procedure methods and variables ==
; id : a string containing the name of the procedure
; airport : airport object associated with the procedure
; radio: for instrument approaches, returns the type of procedure (VOR, ILS, RNAV, or NDB)
; tp_type: returns the type of procedure (sid, star, or iap)
; runways: a vector containing the runways associated with the procedure
; transitions : a vector containing the transitions of the procedure (for SIDS and STARS only)
; route(runway) : Returns a vector of waypoints.
; transition() : Only works on STAR and SID.

== Airport methods and variables ==

; runway : a ghost for the runway passed as a string or nil
; runwaysWithoutReciprocals :
; helipad : a ghost for the helipad passed as a string or nil
; tower : returns hash containing airport tower location
; comms : contains vector containing communication frequencies
; sids : a vector containing the ids of sids of the airport, if a runway is passed, just for that runway. Pass an id into getSid to get the ghost.
; stars : a vector containing the ids of stars of the airport, if a runway is passed, just for that runway. Pass an id into getStar to get the ghost.
; getApproachList : a vector containing the ids of IAPs of the airport, if a runway is passed, just for that runway. Pass an id into getIAP to get the ghost.
; parking : a vector containing parking positions of the airport
; getSid : a ghost for a SID
; getStar : a ghost for a STAR
; getIAP : a ghost for a IAP
; findBestRunwayForPos : passed a position, returns a ghost for the runway it decides is best
; toString : returns "an airport " + the airport id

== Airway methods and variables ==

; id : returns identifier of airway
; level: "high", "low", or "both"

== Examples ==
<syntaxhighlight lang="nasal">
# get the active flight plan (the one being used by the route manager)
var fp = flightplan();

# or create one an XML file
fp = flightplan('/path/to/xml');

# save the active flight plan
fgcommand("save-flightplan", props.Node.new({"path": 'path/to/xml'}));

# duplicate a flight-plan
var secondary = fp.clone();

var dest = airportinfo('KSFO');
var rwy = dest.runway('19L');
# the the arrival runway (and airport, automatically)
fp.destination_runway = rwy;

# or if no runway is known/specified
fp.destination = dest;
</syntaxhighlight>

Building procedures and transitions. As mentioned above there's a couple of different ways to handle this, the examples below assume the C++ code automatically deletes and re-inserts waypoints for procedures, but that's only one possible design.
<syntaxhighlight lang="nasal">
var apt = airportinfo('KSFO');
# example for SIDs, STARs are the same, approaches too
var allSids = apt.sids();

# SIDs for a specific runway - note these return SID IDs as string, for compatibility with existing code
var rwySids = apt.sids('28L');
</syntaxhighlight>

Inserting and deleting waypoints (possibly in batches)
<syntaxhighlight lang="nasal">
var fp = flightplan();
# waypoint created from lat, lon, or a navaid, or anything else?
var pos = geo.aircraft_position().apply_course_distance(getprop("/orientation/heading-deg"), 100000);
var wp = createWP(pos.lat(), pos.lon(), "EPICA");

# manually insert a waypoint at the end of the plan
fp.insertWP(wp, fp.getPlanSize());

# manually insert a waypoint at a defined position (n) into the plan
fp.insertWP(wp, n);

# route along airways, and insert a whole bunch of waypoints
# this is needed for the route-manager dialog, maybe not for a
# real FMS interface....
var segment = [<waypoint object>, <waypoint object>, <waypoint object>];
# segment is a vector of waypoints now
fp.insertWaypoints(segment, fp.getPlanSize());
</syntaxhighlight>

== aircraft.history() (3.2+) ==

Function to expose flight history as aircraft.history()

<syntaxhighlight lang="nasal">
var hist = aircraft.history();

# get history of aircraft position/orientation collapsing
# nodes with a distance smaller than the given minimum
# edge length
debug.dump( hist.pathForHistory(<minimum-edge-length-meter>) );
</syntaxhighlight>

== Related content ==
=== Wiki articles ===
* [[Nasal library#Extension functions|Nasal library § Extension functions]]
* [[Navdata cache#Accessing via Nasal|Navdata cache § Accessing via Nasal]]
* [[Route Manager]]
* [[Route Manager internals]]
* [[Howto:Control the route manager in Nasal]]

=== Documentation ===
* [http://api-docs.freeflightsim.org/flightgear/NasalPositioned_8cxx_source.html#l00585 flightplanGhostSetMember] — ''Members of a flight plan object that can be set.''
* [http://api-docs.freeflightsim.org/flightgear/NasalPositioned_8cxx_source.html#l00557 flightplanGhostGetMember] — ''Members of flight plan object that can be read.''
* [http://api-docs.freeflightsim.org/flightgear/NasalPositioned_8cxx_source.html#l02485 initNasalPositioned] — ''Contains a list of functions that can be called on airport, flight plan, waypoint, procedure, or flight plan leg objects.''
* [http://api-docs.freeflightsim.org/flightgear/route__mgr_8cxx_source.html#l00220 FGRouteMgr::FGRouteMgr] — ''List of [[fgcommands]] relating to the route manager.''

=== Misc ===
* https://sourceforge.net/p/flightgear/mailman/message/34688624/
* https://sourceforge.net/p/flightgear/mailman/message/35164289/
* https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/BB67C9F3-028B-40E5-94E4-246CD1E0B2CC%40mac.com/#msg23708827
* https://sourceforge.net/p/flightgear/mailman/message/33699574/
* https://sourceforge.net/p/flightgear/mailman/message/21010010/
* https://sourceforge.net/p/flightgear/mailman/message/23678747/

=== Search Queries ===

=== Commits ===

=== Threads ===
{{Appendix}}

[[Category:Nasal]]

Nasal Flightplan

2022-01-19T09:40:02Z

Legoboyvdlp: /* Waypoint ghost */ Add extra members

{{Systems Modeling Disclaimer}}
{{Autoflight Navigation}}
{{Nasal Navigation}}

Because FlightGear's [[route manager]] flight plan system is exposed to [[Nasal]], '''Nasal can be used to interact with flight plans'''. Obviously, this is very useful, especially for aircraft like airliners, which have complex route managers systems. This article shows how this can be done.

== Background ==
The Nasal functions relating to the route manager system include:
* {{func link|flightplan()}} - return the active plan.
* {{func link|airwaysRoute()}}
* {{func link|createFlightplan()}} - creates new empty plan. A path can be supplied to load a plan from xml.

Flight plans are based on waypoints, which, in C++, inherit from the {{API Link|flightgear|class|FGPositioned}} class.

== Waypoint ghost ==
The following are members of a waypoint ghost, as generated by, for example, {{func link|airwaysRoute()}}:

; wp_name ''or'' id: Name of the waypoint, returned as string.
; wp_type :Waypoint type, returned as string. One of "basic," "navaid," "offset-navaid," "runway," "hold", "hdgToAlt," "dmeIntercept," "radialIntercept," "discontinuity", "via", or "vectors."
; wp_role:Role of waypoint. One of "pseudo", "sid", "star", "missed", "approach"
; wp_lat ''or'' lat : Latitude of waypoint.
; wp_lon ''or'' lon : Longitude of waypoint.
; wp_parent_name : Name of waypoint's parent.
; wp_parent :Waypoint's parent as a ghost.
; fly_type : How to waypoint should be flown over or reacted to. One of "flyOver" or "flyBy" or "Hold".
; heading_course :Heading of runway, hdgToAlt, hold, radialIntercept, or dmeIntercept waypoints
; hidden:Boolean flag as to whether it should be shown on map / navigation display when included in a flightplan

=== Hold members ===
The following are hold-specific members:
; hold_is_left_handed : boolean, defines direction of turns in the hold
; hold_is_distance : boolean, defines if hold is measured by distance
; hold_is_time : boolean, defines if hold is measured by time
; hold_inbound_radial ''or'' hold_inbound_radial_deg : returns the inbound radial of the hold, measured in degrees
; hold_time_or_distance : the leg length, defined either in seconds or nautical miles

== Flightplan methods and variables ==
Notice that instead of passing a leg as parameter, a waypoint can be passed.
; getWP(index) : Returns the leg for specified index.
; currentWP() : Return current active leg.
; nextWP() : Make next waypoint active.
; getPlanSize() : Returns number of waypoints
; appendWP(leg) : Add a leg to the end of the flightplan.
; insertWP(leg, index) : Pass a leg object and its position. Example: insertWP(leg, 1) --> leg becomes waypoint at index 1.
; deleteWP(index) : Deletes the waypoint at specified index. Example: deleteWP(0) --> deletes first waypoint.
; insertWPAfter() :
; insertWaypoints(vector, index) : Pass a vector of waypoint objects, and the position to insert.
; cleanPlan() : Clears all waypoints except destination and departure.
; clearWPType(type) : Supply a type string, it will clear all waypoints of the type.
; clone() : Return a copy of the flightplan.
; pathGeod() or pointAlongRoute() : (function has two associated names). This is used for graphical display: it’s an array of coordinates which show the path of the plan. This includes holds, procedure turns, turn anticipation and more.
; finish() : Finish the plan. (a call to delegate will be made)
; indexOfWP(wp) : Returns the index of the passed waypoint/leg.
; destination : airport object as destination.
; destination_runway : rwy object as destination and its airport implicit.
; departure : airport object as departure.
; departure_runway : rwy object as departure and its airport implicit.
; id : optional name of plan.
; sid : procedure object for SID.
; star : procedure object for STAR.
; sid_trans : procedure object for SID transition (as of 2020.2, may be written to)
; star_trans : procedure object for STAR transition (as of 2020.2, may be written to)
; approach : procedure object for approach.
; current : Index of current waypoint.
; aircraftCategory : ICAO aircraft category.
; followLegTrackToFix : Specific used by some procedures. It controls whether the system will fly on an intersection course (and hence, different track) to the end of the leg, or make a corrective S-turn to get back on the leg track immediately it becomes possible.
; activate() : This will make the flight plan the default (the one used in route-manager).
; save(path) : Save a plan to xml. Will return true or false for success.

== Leg methods and variables ==
A leg is a wrapper for a waypoint, so it will have all waypoints variables and methods plus what is listed below.
Notice, that a leg you have gotten from a plan, but deleted in the plan, will be invalid and should not be used or modified.
A leg you have gotten from a plan, when modified, will modify the leg inside the plan you got it from.
; setSpeed(speed, type) : Sets the speed restriction. Setting nil type, will crash FG, setting empty type is same as setting "at". See below for type list.
; setAltitude(altitude, type) : Sets the altitude restriction. Setting nil type, will crash FG, setting empty type is same as setting "at". See below for type list.
; path() : Returns a vector of hashes containing lat and lon variables. These compromise a curved path for long non straight legs.
; courseAndDistanceFrom(coord) : Return vector with true course and distance. Coord is a geo.Coord.
; parents : Nasal parents.
; wp_owner : Will return you the owning route-structure of the WP - this could be an airway, procedure, or the flightplan if the waypoint doesn’t belong to a route structure.
; index : Returns the index of the leg in the owning route-structure.
; alt_cstr : Read-only. Altitude restriction output. Set using setAltitude.
; alt_cstr_type : Read-only. Altitude restriction type. See below for list.
; speed_cstr : Read-only. Speed restriction output. Set using setSpeed.
; speed_cstr_type : Read-only. Speed restriction. See below for list.
; leg_distance : Returns distance along the leg, from the preceding waypoint.
; leg_bearing : Returns the bearing along the leg.
; distance_along_route : Return the total distance laterally along the route to the beginning of the leg.

For speed restrictions these types can be used:
* "at" = kt should be spot on
* "above" = kt should be higher
* "below" = kt should be under
* "computed" = predicted kt
* "computed-mach" = predicted mach
* "mach" = its in mach instead of kt
* "delete" = Cleared by ATC

For altitude restrictions these types can be used:
* "at" = alt should be spot on
* "above" = alt should be higher
* "below" = alt should be below
* "computed" = predicted alt
* "computed-mach" = not used for altitude
* "mach" = not used for altitude
* "delete" = Cleared by ATC

== Procedure methods and variables ==
; id : a string containing the name of the procedure
; airport : airport object associated with the procedure
; radio: for instrument approaches, returns the type of procedure (VOR, ILS, RNAV, or NDB)
; tp_type: returns the type of procedure (sid, star, or iap)
; runways: a vector containing the runways associated with the procedure
; transitions : a vector containing the transitions of the procedure (for SIDS and STARS only)
; route(runway) : Returns a vector of waypoints.
; transition() : Only works on STAR and SID.

== Airport methods and variables ==

; runway : a ghost for the runway passed as a string or nil
; runwaysWithoutReciprocals :
; helipad : a ghost for the helipad passed as a string or nil
; tower : returns hash containing airport tower location
; comms : contains vector containing communication frequencies
; sids : a vector containing the ids of sids of the airport, if a runway is passed, just for that runway. Pass an id into getSid to get the ghost.
; stars : a vector containing the ids of stars of the airport, if a runway is passed, just for that runway. Pass an id into getStar to get the ghost.
; getApproachList : a vector containing the ids of IAPs of the airport, if a runway is passed, just for that runway. Pass an id into getIAP to get the ghost.
; parking : a vector containing parking positions of the airport
; getSid : a ghost for a SID
; getStar : a ghost for a STAR
; getIAP : a ghost for a IAP
; findBestRunwayForPos : passed a position, returns a ghost for the runway it decides is best
; toString : returns "an airport " + the airport id

== Airway methods and variables ==

; id : returns identifier of airway
; level: "high", "low", or "both"

== Examples ==
<syntaxhighlight lang="nasal">
# get the active flight plan (the one being used by the route manager)
var fp = flightplan();

# or create one an XML file
fp = flightplan('/path/to/xml');

# save the active flight plan
fgcommand("save-flightplan", props.Node.new({"path": 'path/to/xml'}));

# duplicate a flight-plan
var secondary = fp.clone();

var dest = airportinfo('KSFO');
var rwy = dest.runway('19L');
# the the arrival runway (and airport, automatically)
fp.destination_runway = rwy;

# or if no runway is known/specified
fp.destination = dest;
</syntaxhighlight>

Building procedures and transitions. As mentioned above there's a couple of different ways to handle this, the examples below assume the C++ code automatically deletes and re-inserts waypoints for procedures, but that's only one possible design.
<syntaxhighlight lang="nasal">
var apt = airportinfo('KSFO');
# example for SIDs, STARs are the same, approaches too
var allSids = apt.sids();

# SIDs for a specific runway - note these return SID IDs as string, for compatibility with existing code
var rwySids = apt.sids('28L');
</syntaxhighlight>

Inserting and deleting waypoints (possibly in batches)
<syntaxhighlight lang="nasal">
var fp = flightplan();
# waypoint created from lat, lon, or a navaid, or anything else?
var pos = geo.aircraft_position().apply_course_distance(getprop("/orientation/heading-deg"), 100000);
var wp = createWP(pos.lat(), pos.lon(), "EPICA");

# manually insert a waypoint at the end of the plan
fp.insertWP(wp, fp.getPlanSize());

# manually insert a waypoint at a defined position (n) into the plan
fp.insertWP(wp, n);

# route along airways, and insert a whole bunch of waypoints
# this is needed for the route-manager dialog, maybe not for a
# real FMS interface....
var segment = [<waypoint object>, <waypoint object>, <waypoint object>];
# segment is a vector of waypoints now
fp.insertWaypoints(segment, fp.getPlanSize());
</syntaxhighlight>

== aircraft.history() (3.2+) ==

Function to expose flight history as aircraft.history()

<syntaxhighlight lang="nasal">
var hist = aircraft.history();

# get history of aircraft position/orientation collapsing
# nodes with a distance smaller than the given minimum
# edge length
debug.dump( hist.pathForHistory(<minimum-edge-length-meter>) );
</syntaxhighlight>

== Related content ==
=== Wiki articles ===
* [[Nasal library#Extension functions|Nasal library § Extension functions]]
* [[Navdata cache#Accessing via Nasal|Navdata cache § Accessing via Nasal]]
* [[Route Manager]]
* [[Route Manager internals]]
* [[Howto:Control the route manager in Nasal]]

=== Documentation ===
* [http://api-docs.freeflightsim.org/flightgear/NasalPositioned_8cxx_source.html#l00585 flightplanGhostSetMember] — ''Members of a flight plan object that can be set.''
* [http://api-docs.freeflightsim.org/flightgear/NasalPositioned_8cxx_source.html#l00557 flightplanGhostGetMember] — ''Members of flight plan object that can be read.''
* [http://api-docs.freeflightsim.org/flightgear/NasalPositioned_8cxx_source.html#l02485 initNasalPositioned] — ''Contains a list of functions that can be called on airport, flight plan, waypoint, procedure, or flight plan leg objects.''
* [http://api-docs.freeflightsim.org/flightgear/route__mgr_8cxx_source.html#l00220 FGRouteMgr::FGRouteMgr] — ''List of [[fgcommands]] relating to the route manager.''

=== Misc ===
* https://sourceforge.net/p/flightgear/mailman/message/34688624/
* https://sourceforge.net/p/flightgear/mailman/message/35164289/
* https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/BB67C9F3-028B-40E5-94E4-246CD1E0B2CC%40mac.com/#msg23708827
* https://sourceforge.net/p/flightgear/mailman/message/33699574/
* https://sourceforge.net/p/flightgear/mailman/message/21010010/
* https://sourceforge.net/p/flightgear/mailman/message/23678747/

=== Search Queries ===

=== Commits ===

=== Threads ===
{{Appendix}}

[[Category:Nasal]]

Nasal Flightplan

2022-01-19T09:38:08Z

Legoboyvdlp: /* Waypoint ghost */

{{Systems Modeling Disclaimer}}
{{Autoflight Navigation}}
{{Nasal Navigation}}

Because FlightGear's [[route manager]] flight plan system is exposed to [[Nasal]], '''Nasal can be used to interact with flight plans'''. Obviously, this is very useful, especially for aircraft like airliners, which have complex route managers systems. This article shows how this can be done.

== Background ==
The Nasal functions relating to the route manager system include:
* {{func link|flightplan()}} - return the active plan.
* {{func link|airwaysRoute()}}
* {{func link|createFlightplan()}} - creates new empty plan. A path can be supplied to load a plan from xml.

Flight plans are based on waypoints, which, in C++, inherit from the {{API Link|flightgear|class|FGPositioned}} class.

== Waypoint ghost ==
The following are members of a waypoint ghost, as generated by, for example, {{func link|airwaysRoute()}}:

; wp_name ''or'' id: Name of the waypoint, returned as string.
; wp_type :Waypoint type, returned as string. One of "basic," "navaid," "offset-navaid," "runway," "hold", "hdgToAlt," "dmeIntercept," "radialIntercept," "discontinuity", "via", or "vectors."
; wp_role:Role of waypoint. One of "pseudo", "sid", "star", "missed", "approach"
; wp_lat ''or'' lat : Latitude of waypoint.
; wp_lon ''or'' lon : Longitude of waypoint.
; wp_parent_name : Name of waypoint's parent.
; wp_parent :Waypoint's parent as a ghost.
; fly_type : How to waypoint should be flown over or reacted to. One of "flyOver" or "flyBy" or "Hold".
; heading_course : Heading of runway.

=== Hold members ===
The following are hold-specific members:
; hold_is_left_handed : boolean, defines direction of turns in the hold
; hold_is_distance : boolean, defines if hold is measured by distance
; hold_is_time : boolean, defines if hold is measured by time
; hold_inbound_radial ''or'' hold_inbound_radial_deg : returns the inbound radial of the hold, measured in degrees
; hold_time_or_distance : the leg length, defined either in seconds or nautical miles

== Flightplan methods and variables ==
Notice that instead of passing a leg as parameter, a waypoint can be passed.
; getWP(index) : Returns the leg for specified index.
; currentWP() : Return current active leg.
; nextWP() : Make next waypoint active.
; getPlanSize() : Returns number of waypoints
; appendWP(leg) : Add a leg to the end of the flightplan.
; insertWP(leg, index) : Pass a leg object and its position. Example: insertWP(leg, 1) --> leg becomes waypoint at index 1.
; deleteWP(index) : Deletes the waypoint at specified index. Example: deleteWP(0) --> deletes first waypoint.
; insertWPAfter() :
; insertWaypoints(vector, index) : Pass a vector of waypoint objects, and the position to insert.
; cleanPlan() : Clears all waypoints except destination and departure.
; clearWPType(type) : Supply a type string, it will clear all waypoints of the type.
; clone() : Return a copy of the flightplan.
; pathGeod() or pointAlongRoute() : (function has two associated names). This is used for graphical display: it’s an array of coordinates which show the path of the plan. This includes holds, procedure turns, turn anticipation and more.
; finish() : Finish the plan. (a call to delegate will be made)
; indexOfWP(wp) : Returns the index of the passed waypoint/leg.
; destination : airport object as destination.
; destination_runway : rwy object as destination and its airport implicit.
; departure : airport object as departure.
; departure_runway : rwy object as departure and its airport implicit.
; id : optional name of plan.
; sid : procedure object for SID.
; star : procedure object for STAR.
; sid_trans : procedure object for SID transition (as of 2020.2, may be written to)
; star_trans : procedure object for STAR transition (as of 2020.2, may be written to)
; approach : procedure object for approach.
; current : Index of current waypoint.
; aircraftCategory : ICAO aircraft category.
; followLegTrackToFix : Specific used by some procedures. It controls whether the system will fly on an intersection course (and hence, different track) to the end of the leg, or make a corrective S-turn to get back on the leg track immediately it becomes possible.
; activate() : This will make the flight plan the default (the one used in route-manager).
; save(path) : Save a plan to xml. Will return true or false for success.

== Leg methods and variables ==
A leg is a wrapper for a waypoint, so it will have all waypoints variables and methods plus what is listed below.
Notice, that a leg you have gotten from a plan, but deleted in the plan, will be invalid and should not be used or modified.
A leg you have gotten from a plan, when modified, will modify the leg inside the plan you got it from.
; setSpeed(speed, type) : Sets the speed restriction. Setting nil type, will crash FG, setting empty type is same as setting "at". See below for type list.
; setAltitude(altitude, type) : Sets the altitude restriction. Setting nil type, will crash FG, setting empty type is same as setting "at". See below for type list.
; path() : Returns a vector of hashes containing lat and lon variables. These compromise a curved path for long non straight legs.
; courseAndDistanceFrom(coord) : Return vector with true course and distance. Coord is a geo.Coord.
; parents : Nasal parents.
; wp_owner : Will return you the owning route-structure of the WP - this could be an airway, procedure, or the flightplan if the waypoint doesn’t belong to a route structure.
; index : Returns the index of the leg in the owning route-structure.
; alt_cstr : Read-only. Altitude restriction output. Set using setAltitude.
; alt_cstr_type : Read-only. Altitude restriction type. See below for list.
; speed_cstr : Read-only. Speed restriction output. Set using setSpeed.
; speed_cstr_type : Read-only. Speed restriction. See below for list.
; leg_distance : Returns distance along the leg, from the preceding waypoint.
; leg_bearing : Returns the bearing along the leg.
; distance_along_route : Return the total distance laterally along the route to the beginning of the leg.

For speed restrictions these types can be used:
* "at" = kt should be spot on
* "above" = kt should be higher
* "below" = kt should be under
* "computed" = predicted kt
* "computed-mach" = predicted mach
* "mach" = its in mach instead of kt
* "delete" = Cleared by ATC

For altitude restrictions these types can be used:
* "at" = alt should be spot on
* "above" = alt should be higher
* "below" = alt should be below
* "computed" = predicted alt
* "computed-mach" = not used for altitude
* "mach" = not used for altitude
* "delete" = Cleared by ATC

== Procedure methods and variables ==
; id : a string containing the name of the procedure
; airport : airport object associated with the procedure
; radio: for instrument approaches, returns the type of procedure (VOR, ILS, RNAV, or NDB)
; tp_type: returns the type of procedure (sid, star, or iap)
; runways: a vector containing the runways associated with the procedure
; transitions : a vector containing the transitions of the procedure (for SIDS and STARS only)
; route(runway) : Returns a vector of waypoints.
; transition() : Only works on STAR and SID.

== Airport methods and variables ==

; runway : a ghost for the runway passed as a string or nil
; runwaysWithoutReciprocals :
; helipad : a ghost for the helipad passed as a string or nil
; tower : returns hash containing airport tower location
; comms : contains vector containing communication frequencies
; sids : a vector containing the ids of sids of the airport, if a runway is passed, just for that runway. Pass an id into getSid to get the ghost.
; stars : a vector containing the ids of stars of the airport, if a runway is passed, just for that runway. Pass an id into getStar to get the ghost.
; getApproachList : a vector containing the ids of IAPs of the airport, if a runway is passed, just for that runway. Pass an id into getIAP to get the ghost.
; parking : a vector containing parking positions of the airport
; getSid : a ghost for a SID
; getStar : a ghost for a STAR
; getIAP : a ghost for a IAP
; findBestRunwayForPos : passed a position, returns a ghost for the runway it decides is best
; toString : returns "an airport " + the airport id

== Airway methods and variables ==

; id : returns identifier of airway
; level: "high", "low", or "both"

== Examples ==
<syntaxhighlight lang="nasal">
# get the active flight plan (the one being used by the route manager)
var fp = flightplan();

# or create one an XML file
fp = flightplan('/path/to/xml');

# save the active flight plan
fgcommand("save-flightplan", props.Node.new({"path": 'path/to/xml'}));

# duplicate a flight-plan
var secondary = fp.clone();

var dest = airportinfo('KSFO');
var rwy = dest.runway('19L');
# the the arrival runway (and airport, automatically)
fp.destination_runway = rwy;

# or if no runway is known/specified
fp.destination = dest;
</syntaxhighlight>

Building procedures and transitions. As mentioned above there's a couple of different ways to handle this, the examples below assume the C++ code automatically deletes and re-inserts waypoints for procedures, but that's only one possible design.
<syntaxhighlight lang="nasal">
var apt = airportinfo('KSFO');
# example for SIDs, STARs are the same, approaches too
var allSids = apt.sids();

# SIDs for a specific runway - note these return SID IDs as string, for compatibility with existing code
var rwySids = apt.sids('28L');
</syntaxhighlight>

Inserting and deleting waypoints (possibly in batches)
<syntaxhighlight lang="nasal">
var fp = flightplan();
# waypoint created from lat, lon, or a navaid, or anything else?
var pos = geo.aircraft_position().apply_course_distance(getprop("/orientation/heading-deg"), 100000);
var wp = createWP(pos.lat(), pos.lon(), "EPICA");

# manually insert a waypoint at the end of the plan
fp.insertWP(wp, fp.getPlanSize());

# manually insert a waypoint at a defined position (n) into the plan
fp.insertWP(wp, n);

# route along airways, and insert a whole bunch of waypoints
# this is needed for the route-manager dialog, maybe not for a
# real FMS interface....
var segment = [<waypoint object>, <waypoint object>, <waypoint object>];
# segment is a vector of waypoints now
fp.insertWaypoints(segment, fp.getPlanSize());
</syntaxhighlight>

== aircraft.history() (3.2+) ==

Function to expose flight history as aircraft.history()

<syntaxhighlight lang="nasal">
var hist = aircraft.history();

# get history of aircraft position/orientation collapsing
# nodes with a distance smaller than the given minimum
# edge length
debug.dump( hist.pathForHistory(<minimum-edge-length-meter>) );
</syntaxhighlight>

== Related content ==
=== Wiki articles ===
* [[Nasal library#Extension functions|Nasal library § Extension functions]]
* [[Navdata cache#Accessing via Nasal|Navdata cache § Accessing via Nasal]]
* [[Route Manager]]
* [[Route Manager internals]]
* [[Howto:Control the route manager in Nasal]]

=== Documentation ===
* [http://api-docs.freeflightsim.org/flightgear/NasalPositioned_8cxx_source.html#l00585 flightplanGhostSetMember] — ''Members of a flight plan object that can be set.''
* [http://api-docs.freeflightsim.org/flightgear/NasalPositioned_8cxx_source.html#l00557 flightplanGhostGetMember] — ''Members of flight plan object that can be read.''
* [http://api-docs.freeflightsim.org/flightgear/NasalPositioned_8cxx_source.html#l02485 initNasalPositioned] — ''Contains a list of functions that can be called on airport, flight plan, waypoint, procedure, or flight plan leg objects.''
* [http://api-docs.freeflightsim.org/flightgear/route__mgr_8cxx_source.html#l00220 FGRouteMgr::FGRouteMgr] — ''List of [[fgcommands]] relating to the route manager.''

=== Misc ===
* https://sourceforge.net/p/flightgear/mailman/message/34688624/
* https://sourceforge.net/p/flightgear/mailman/message/35164289/
* https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/BB67C9F3-028B-40E5-94E4-246CD1E0B2CC%40mac.com/#msg23708827
* https://sourceforge.net/p/flightgear/mailman/message/33699574/
* https://sourceforge.net/p/flightgear/mailman/message/21010010/
* https://sourceforge.net/p/flightgear/mailman/message/23678747/

=== Search Queries ===

=== Commits ===

=== Threads ===
{{Appendix}}

[[Category:Nasal]]

Nasal Flightplan

2022-01-19T09:35:49Z

Legoboyvdlp: /* Waypoint ghost */ Add more types

{{Systems Modeling Disclaimer}}
{{Autoflight Navigation}}
{{Nasal Navigation}}

Because FlightGear's [[route manager]] flight plan system is exposed to [[Nasal]], '''Nasal can be used to interact with flight plans'''. Obviously, this is very useful, especially for aircraft like airliners, which have complex route managers systems. This article shows how this can be done.

== Background ==
The Nasal functions relating to the route manager system include:
* {{func link|flightplan()}} - return the active plan.
* {{func link|airwaysRoute()}}
* {{func link|createFlightplan()}} - creates new empty plan. A path can be supplied to load a plan from xml.

Flight plans are based on waypoints, which, in C++, inherit from the {{API Link|flightgear|class|FGPositioned}} class.

== Waypoint ghost ==
The following are members of a waypoint ghost, as generated by, for example, {{func link|airwaysRoute()}}:

; wp_name : Name of the waypoint, returned as string.
; wp_type :Waypoint type, returned as string. One of "basic," "navaid," "offset-navaid," "runway," "hold", "hdgToAlt," "dmeIntercept," "radialIntercept," "discontinuity", "via", or "vectors."
; wp_role: Role of waypoint.
; wp_lat ''or'' lat : Latitude of waypoint.
; wp_lon ''or'' lon : Longitude of waypoint.
; wp_parent_name : Name of waypoint's parent.
; wp_parent : Waypoint's parent.
; fly_type : How to waypoint should be flown over or reacted to. One of "flyOver" or "flyBy" or "Hold".
; heading_course : Heading of runway.

=== Hold members ===
The following are hold-specific members:
; hold_is_left_handed : boolean, defines direction of turns in the hold
; hold_is_distance : boolean, defines if hold is measured by distance
; hold_is_time : boolean, defines if hold is measured by time
; hold_inbound_radial ''or'' hold_inbound_radial_deg : returns the inbound radial of the hold, measured in degrees
; hold_time_or_distance : the leg length, defined either in seconds or nautical miles

== Flightplan methods and variables ==
Notice that instead of passing a leg as parameter, a waypoint can be passed.
; getWP(index) : Returns the leg for specified index.
; currentWP() : Return current active leg.
; nextWP() : Make next waypoint active.
; getPlanSize() : Returns number of waypoints
; appendWP(leg) : Add a leg to the end of the flightplan.
; insertWP(leg, index) : Pass a leg object and its position. Example: insertWP(leg, 1) --> leg becomes waypoint at index 1.
; deleteWP(index) : Deletes the waypoint at specified index. Example: deleteWP(0) --> deletes first waypoint.
; insertWPAfter() :
; insertWaypoints(vector, index) : Pass a vector of waypoint objects, and the position to insert.
; cleanPlan() : Clears all waypoints except destination and departure.
; clearWPType(type) : Supply a type string, it will clear all waypoints of the type.
; clone() : Return a copy of the flightplan.
; pathGeod() or pointAlongRoute() : (function has two associated names). This is used for graphical display: it’s an array of coordinates which show the path of the plan. This includes holds, procedure turns, turn anticipation and more.
; finish() : Finish the plan. (a call to delegate will be made)
; indexOfWP(wp) : Returns the index of the passed waypoint/leg.
; destination : airport object as destination.
; destination_runway : rwy object as destination and its airport implicit.
; departure : airport object as departure.
; departure_runway : rwy object as departure and its airport implicit.
; id : optional name of plan.
; sid : procedure object for SID.
; star : procedure object for STAR.
; sid_trans : procedure object for SID transition (as of 2020.2, may be written to)
; star_trans : procedure object for STAR transition (as of 2020.2, may be written to)
; approach : procedure object for approach.
; current : Index of current waypoint.
; aircraftCategory : ICAO aircraft category.
; followLegTrackToFix : Specific used by some procedures. It controls whether the system will fly on an intersection course (and hence, different track) to the end of the leg, or make a corrective S-turn to get back on the leg track immediately it becomes possible.
; activate() : This will make the flight plan the default (the one used in route-manager).
; save(path) : Save a plan to xml. Will return true or false for success.

== Leg methods and variables ==
A leg is a wrapper for a waypoint, so it will have all waypoints variables and methods plus what is listed below.
Notice, that a leg you have gotten from a plan, but deleted in the plan, will be invalid and should not be used or modified.
A leg you have gotten from a plan, when modified, will modify the leg inside the plan you got it from.
; setSpeed(speed, type) : Sets the speed restriction. Setting nil type, will crash FG, setting empty type is same as setting "at". See below for type list.
; setAltitude(altitude, type) : Sets the altitude restriction. Setting nil type, will crash FG, setting empty type is same as setting "at". See below for type list.
; path() : Returns a vector of hashes containing lat and lon variables. These compromise a curved path for long non straight legs.
; courseAndDistanceFrom(coord) : Return vector with true course and distance. Coord is a geo.Coord.
; parents : Nasal parents.
; wp_owner : Will return you the owning route-structure of the WP - this could be an airway, procedure, or the flightplan if the waypoint doesn’t belong to a route structure.
; index : Returns the index of the leg in the owning route-structure.
; alt_cstr : Read-only. Altitude restriction output. Set using setAltitude.
; alt_cstr_type : Read-only. Altitude restriction type. See below for list.
; speed_cstr : Read-only. Speed restriction output. Set using setSpeed.
; speed_cstr_type : Read-only. Speed restriction. See below for list.
; leg_distance : Returns distance along the leg, from the preceding waypoint.
; leg_bearing : Returns the bearing along the leg.
; distance_along_route : Return the total distance laterally along the route to the beginning of the leg.

For speed restrictions these types can be used:
* "at" = kt should be spot on
* "above" = kt should be higher
* "below" = kt should be under
* "computed" = predicted kt
* "computed-mach" = predicted mach
* "mach" = its in mach instead of kt
* "delete" = Cleared by ATC

For altitude restrictions these types can be used:
* "at" = alt should be spot on
* "above" = alt should be higher
* "below" = alt should be below
* "computed" = predicted alt
* "computed-mach" = not used for altitude
* "mach" = not used for altitude
* "delete" = Cleared by ATC

== Procedure methods and variables ==
; id : a string containing the name of the procedure
; airport : airport object associated with the procedure
; radio: for instrument approaches, returns the type of procedure (VOR, ILS, RNAV, or NDB)
; tp_type: returns the type of procedure (sid, star, or iap)
; runways: a vector containing the runways associated with the procedure
; transitions : a vector containing the transitions of the procedure (for SIDS and STARS only)
; route(runway) : Returns a vector of waypoints.
; transition() : Only works on STAR and SID.

== Airport methods and variables ==

; runway : a ghost for the runway passed as a string or nil
; runwaysWithoutReciprocals :
; helipad : a ghost for the helipad passed as a string or nil
; tower : returns hash containing airport tower location
; comms : contains vector containing communication frequencies
; sids : a vector containing the ids of sids of the airport, if a runway is passed, just for that runway. Pass an id into getSid to get the ghost.
; stars : a vector containing the ids of stars of the airport, if a runway is passed, just for that runway. Pass an id into getStar to get the ghost.
; getApproachList : a vector containing the ids of IAPs of the airport, if a runway is passed, just for that runway. Pass an id into getIAP to get the ghost.
; parking : a vector containing parking positions of the airport
; getSid : a ghost for a SID
; getStar : a ghost for a STAR
; getIAP : a ghost for a IAP
; findBestRunwayForPos : passed a position, returns a ghost for the runway it decides is best
; toString : returns "an airport " + the airport id

== Airway methods and variables ==

; id : returns identifier of airway
; level: "high", "low", or "both"

== Examples ==
<syntaxhighlight lang="nasal">
# get the active flight plan (the one being used by the route manager)
var fp = flightplan();

# or create one an XML file
fp = flightplan('/path/to/xml');

# save the active flight plan
fgcommand("save-flightplan", props.Node.new({"path": 'path/to/xml'}));

# duplicate a flight-plan
var secondary = fp.clone();

var dest = airportinfo('KSFO');
var rwy = dest.runway('19L');
# the the arrival runway (and airport, automatically)
fp.destination_runway = rwy;

# or if no runway is known/specified
fp.destination = dest;
</syntaxhighlight>

Building procedures and transitions. As mentioned above there's a couple of different ways to handle this, the examples below assume the C++ code automatically deletes and re-inserts waypoints for procedures, but that's only one possible design.
<syntaxhighlight lang="nasal">
var apt = airportinfo('KSFO');
# example for SIDs, STARs are the same, approaches too
var allSids = apt.sids();

# SIDs for a specific runway - note these return SID IDs as string, for compatibility with existing code
var rwySids = apt.sids('28L');
</syntaxhighlight>

Inserting and deleting waypoints (possibly in batches)
<syntaxhighlight lang="nasal">
var fp = flightplan();
# waypoint created from lat, lon, or a navaid, or anything else?
var pos = geo.aircraft_position().apply_course_distance(getprop("/orientation/heading-deg"), 100000);
var wp = createWP(pos.lat(), pos.lon(), "EPICA");

# manually insert a waypoint at the end of the plan
fp.insertWP(wp, fp.getPlanSize());

# manually insert a waypoint at a defined position (n) into the plan
fp.insertWP(wp, n);

# route along airways, and insert a whole bunch of waypoints
# this is needed for the route-manager dialog, maybe not for a
# real FMS interface....
var segment = [<waypoint object>, <waypoint object>, <waypoint object>];
# segment is a vector of waypoints now
fp.insertWaypoints(segment, fp.getPlanSize());
</syntaxhighlight>

== aircraft.history() (3.2+) ==

Function to expose flight history as aircraft.history()

<syntaxhighlight lang="nasal">
var hist = aircraft.history();

# get history of aircraft position/orientation collapsing
# nodes with a distance smaller than the given minimum
# edge length
debug.dump( hist.pathForHistory(<minimum-edge-length-meter>) );
</syntaxhighlight>

== Related content ==
=== Wiki articles ===
* [[Nasal library#Extension functions|Nasal library § Extension functions]]
* [[Navdata cache#Accessing via Nasal|Navdata cache § Accessing via Nasal]]
* [[Route Manager]]
* [[Route Manager internals]]
* [[Howto:Control the route manager in Nasal]]

=== Documentation ===
* [http://api-docs.freeflightsim.org/flightgear/NasalPositioned_8cxx_source.html#l00585 flightplanGhostSetMember] — ''Members of a flight plan object that can be set.''
* [http://api-docs.freeflightsim.org/flightgear/NasalPositioned_8cxx_source.html#l00557 flightplanGhostGetMember] — ''Members of flight plan object that can be read.''
* [http://api-docs.freeflightsim.org/flightgear/NasalPositioned_8cxx_source.html#l02485 initNasalPositioned] — ''Contains a list of functions that can be called on airport, flight plan, waypoint, procedure, or flight plan leg objects.''
* [http://api-docs.freeflightsim.org/flightgear/route__mgr_8cxx_source.html#l00220 FGRouteMgr::FGRouteMgr] — ''List of [[fgcommands]] relating to the route manager.''

=== Misc ===
* https://sourceforge.net/p/flightgear/mailman/message/34688624/
* https://sourceforge.net/p/flightgear/mailman/message/35164289/
* https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/BB67C9F3-028B-40E5-94E4-246CD1E0B2CC%40mac.com/#msg23708827
* https://sourceforge.net/p/flightgear/mailman/message/33699574/
* https://sourceforge.net/p/flightgear/mailman/message/21010010/
* https://sourceforge.net/p/flightgear/mailman/message/23678747/

=== Search Queries ===

=== Commits ===

=== Threads ===
{{Appendix}}

[[Category:Nasal]]

Howto:Complete TerraGear example using docker

2022-01-06T21:13:49Z

Legoboyvdlp: /* Process Elevation Data */

This article aims to serve as a quick starting point for people wanting to build scenery using the dockerized version of the TerraGear scenery toolchain. This will allow users to build scenery on all popular operating systems including Windows, macOS and Linux without the hassle of building the terragear toolchain themselves. This is in no way a comprehensive introduction, but should be enough to get one used to the scenery generation process.

[[File:Saint Helena Island generated using dockerized TerraGear.jpg|thumb|Saint Helena island generated using the docker image for the TerraGear toolchain]]

== Background ==
TerraGear requires three pieces of data for scenery generation:

# Elevation data: This data defines how high each point in the scenery or land is. One source for such data is http://viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm.
# Landclass data: This data defines what kind of "land" is under each point in the scenery or land is. For example, some point might be "urban" class, or "forest" class. One source for such data is http://download.geofabrik.de/, which is derived from OSM.
# Airport data: This data defines the position of runways, taxiways and other assorted airport information. One source for such data is the XPlane gateway.

TerraGear consists of five tools:

# hgtchop - Processing elevation data
# terrafit - Processing elevation data
# genapts - Processing airport data
# ogr-decode - Processing landclass data
# tg-construct - Generating the final scenery.

== Scenery location ==
We will build Saint Helena Island, an island in the Atlantic Ocean. Specifically, we will be building the island around [https://en.wikipedia.org/wiki/Saint_Helena_Airport Saint Helena Airport] (ICAO: '''FHSH''').

Its location is: DMS 15° 57′ 33″ S, 5° 38′ 45″ W, Decimal -5.645833 -15.959167

A good vantage point to see progress is to start FG with the following options:

--lon=-5.62000000 --lat=-16.00000000 --altitude=4000 --heading=310

The bounds for our build will be:
* Latitude: -6 to -5
* Longitude: -17 to -15

Let <code>$SCENERY_BUILD_DIR</code> be the directory containing all of our working files for this project.

== Getting docker running ==
The first step is to have docker installed and accessible through the command line. Run the following command to fetch the terragear toolchain:
docker pull flightgear/terragear:ws20

Next, start a docker container to access the terragear tools:

docker run -i -v $SCENERY_BUILD_DIR:/terragear-work/ -t flightgear/terragear:ws20 /bin/bash

Once this command runs successfully, the command line will now be a "window" into the docker container, allowing you to run the entire terragear toolchain. Because of the <code>-v</code> argument (bind mount), the container can see the contents of <code>$SCENERY_BUILD_DIR</code> will be visible at <code>/terragear-work/</code> inside the container.

== Process Elevation Data ==
The elevation data can be obtained from [http://viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm ViewFinderPanoramas], specifically, the [http://viewfinderpanoramas.org/dem3/SD30.zip SD30] and [SE30 http://viewfinderpanoramas.org/dem3/SE30.zip] tiles cover this island.

Extract and add to <code>$SCENERY_BUILD_DIR/data/SRTM-3/*.hgt</code>. Run the following commands in the docker container:

cd /terragear-work/
for f in data/SRTM-3/*.hgt; do hgtchop 3 "${f}" "work/SRTM-3"; done
terrafit work/SRTM-3 -m 50 -x 22500 -e 1

== Process Airport Data ==
'''FHSH''' is not available in FlightGear's <code>apt.dat</code>, so the airport information has to be fetched from elsewhere. The XPlane gateway is one possible source. For this sample project, we can use the following data from https://github.com/accek/fg-nav-fixups:

1 1023 1 0 FHSH St Helena
100 45.00 2 0 0.00 1 2 1 02 -15.96694276 -005.64575428 100 0 2 9 0 2 20 -15.94934298 -005.64615237 300 0 2 9 0 2
110 1 0.00 358.7100 New Taxiway 4
111 -15.96166211 -005.64927678
111 -15.96340503 -005.64926307
111 -15.96340434 -005.64836151
111 -15.96290056 -005.64836043
111 -15.96284142 -005.64854134
111 -15.96265507 -005.64854103
113 -15.96155909 -005.64854086
110 2 0.00 358.7100 New Taxiway 3
111 -15.94934844 -005.64635879 3 102
111 -15.94935248 -005.64663563 3 102
111 -15.94995561 -005.64662024 3 102
113 -15.95019415 -005.64634336
110 2 0.00 358.7100 New Taxiway 2
111 -15.96693818 -005.64554618 3 102
111 -15.96693596 -005.64524600 3 102
111 -15.96628657 -005.64526997 3 102
113 -15.96603006 -005.64556883
110 2 0.00 358.7100 New Taxiway 1
111 -15.96305635 -005.64765837 3 102
111 -15.96240410 -005.64767341 3 102
112 -15.96226078 -005.64761762 -15.96220044 -005.64756860 3 102
111 -15.96219925 -005.64745814 3 102
111 -15.96219005 -005.64624609 3 102
112 -15.96223439 -005.64613746 -15.96227201 -005.64609544 3 102
111 -15.96236947 -005.64606567
111 -15.96184016 -005.64607709 3 102
112 -15.96195708 -005.64616687 -15.96199469 -005.64621034 3 102
111 -15.96199881 -005.64627387 3 102
111 -15.96200448 -005.64744540 3 102
112 -15.96197248 -005.64759953 -15.96193665 -005.64765444 3 102
111 -15.96183543 -005.64768917 3 102
111 -15.96154350 -005.64769949 3 102
111 -15.96155909 -005.64854086
111 -15.96265507 -005.64854103
111 -15.96265481 -005.64818499
113 -15.96306600 -005.64818480 3 102
130 Airport Boundary
111 -15.95876878 -005.64712051
111 -15.96005216 -005.64729370
111 -15.96043831 -005.64731000
111 -15.96048880 -005.64864132
111 -15.96154716 -005.64921198
111 -15.96159626 -005.65014384
111 -15.96388391 -005.64953797
111 -15.96430513 -005.64699927
111 -15.96882642 -005.64692255
111 -15.96885682 -005.64412109
111 -15.94564642 -005.64456651
113 -15.94563863 -005.64716916
120 Hold
111 -15.96200516 -005.64660225 4 103
115 -15.96218383 -005.64660129
120 Linear Feature 5
111 -15.96210864 -005.64767019 1 101
112 -15.96206007 -005.64782922 -15.96201482 -005.64792776 1 101
115 -15.96188449 -005.64810582
120 Linear Feature 4
111 -15.96210864 -005.64767019 1 101
112 -15.96213878 -005.64782592 -15.96215760 -005.64789051 1 101
115 -15.96229199 -005.64808544
120 Linear Feature 3
111 -15.96156820 -005.64813668 20
111 -15.96263721 -005.64810368 20
111 -15.96263233 -005.64792345 20
115 -15.96304480 -005.64791075
120 Linear Feature 2
111 -15.96210864 -005.64767019 1 101
111 -15.96210128 -005.64660525 1 105
115 -15.96209919 -005.64630388
120 Linear Feature 1
111 -15.96154408 -005.64588717 1 105
111 -15.96184445 -005.64588139 1 105
112 -15.96204503 -005.64596036 -15.96210198 -005.64604073 1 105
111 -15.96209919 -005.64630388 1 105
112 -15.96217524 -005.64595582 -15.96225060 -005.64588070 1 105
111 -15.96236918 -005.64587174 1 105
115 -15.96269552 -005.64586403
21 -15.95361317 -005.64657631 3 180.0000 3.0 Papi
21 -15.95359638 -005.64551140 2 180.0000 3.0 Papi
21 -15.96347774 -005.64645343 2 -1.2600 3.0 Papi
20 -15.96192491 -005.64660719 90.0000 0 3 {@R}20-02{@@}{@Y}APRON
20 -15.96225995 -005.64660719 90.0000 0 3 {@R}20-02{@@}{@Y}APRON
14 -15.96312208 -005.64867411 82.02 0 Tower Viewpoint
15 -15.96179344 -005.64822577 -50.36 Ramp Start 1
1300 -15.96238032 -005.64819725 -129.45 gate jets Ramp Start 2
15 -15.96285880 -005.64779046 -181.04 Ramp Start 3
19 -15.95196179 -005.64670036 0 New Windsock 2
19 -15.96603475 -005.64630065 0 New Windsock 1

Copy and paste the above into <code>$SCENERY_BUILD_DIR/data/airports/FHSH.dat</code>. We can now run <code>genapts</code>:

genapts850 --input=data/airports/FHSH --work=./work --dem-path=SRTM-3 --min-lon=-6 --max-lon=-5 --min-lat=-17 --max-lat=-15
genapts850 --input=data/airports/FHSH.dat --work=./work --dem-path=SRTM-3 --airport=FHSH

== Process Landclass Data ==
We can download landclass data from GeoFabrik, specifically from http://download.geofabrik.de/africa/saint-helena-ascension-and-tristan-da-cunha.html. Download the *.shp files and extract them into <code>$SCENERY_BUILD_DATA/data/shapefiles</code>. Each type of file should go into its own folder. For example, copy all <code>gis_osm_places_a_free_1.*</code> files into <code>$SCENERY_BUILD_DATA/data/shapefiles/gis_osm_places_a_free_1/*</code>, as this is the format that TerraGear expects the files to be in. Usually, we would use a landmass (See Notes below) shapefile as our Default, but to simplify things for this tutorial, we can use the <code>gis_osm_places_a_free_1.shp</code> file, as the landmass file and this file are identical for this particular island. We are now ready to run <code>ogr-decode</code>:

ogr-decode --max-segment 500 --area-type Default work/Default data/shapefiles/gis_osm_places_a_free_1/

We have to run <code>ogr-decode</code> for every land class (so urban, forest, lakes, roads etc). At each time, we need to specify the shapefile (the last argument in the above command) and the corresponding area material type that FlightGear recognizes ("Default") in the above command. For this tutorial, we will run the command just once to get the construct the entire island as a "Default" landclass.

== Bringing it all together ==
We can finally run <code>tg-construct</code> to bring everything together
tg-construct --priorities=/usr/local/share/TerraGear/default_priorities.txt --work-dir=./work --output-dir=./output/Terrain --min-lon=-6 --max-lon=-5 --min-lat=-17 --max-lat=-15 AirportArea AirportObj Default SRTM-3

The <code>$SCENERY_BUILD_DIR/output</code> will now contain the built scenery. Point your FG instance to this path using <code>--fg-scenery</code> and take a look at the built scenery!

== Notes ==
* There are two docker images, <code>flightgear/terragear:ws20</code> and <code>flightgear/terragear:latest</code>. The former corresponds to the 2.0 world scenery build, while the later points to the latest code. The latest container has several improvements and GDAL tools which can be used to manipulate shapefiles, but also unfortunately has bugs in the hgtchop and terrafit tools for SRTM-3 data. The best way is to use <code>flightgear/terragear:ws20</code> for elevation data processing, and <code>flightgear/terragear:latest</code> for everything else.
* The [https://osmdata.openstreetmap.de/data/land-polygons.html OSM coastlines data] is a good source for the landmass ("Default") terrain, but is a single file for the entire world.
* You can use the following command (found in the latest terragear docker image) to "crop" the shapefile to an area of interest:
ogr2ogr -clipsrc -6 -17 -5 -15 cut_landmass.shp land_polygons.shp
* As mentioned in the introduction, this tutorial is just a starting point. Have a look at the other TerraGear wiki articles. A good resource is also provided [https://forum.flightgear.org/viewtopic.php?t=35618 on the forum], which uses TerraGear GUI. You can use the concepts learned from there and run the commands in the docker image.

Nasal library

2022-01-04T00:46:36Z

Legoboyvdlp: /* courseAndDistance() */

{{Nasal Navigation|nocat=1}}
This page documents the global '''library functions and variables''' of FlightGear's built-in scripting language, [[Nasal]]. This includes ''[[#Core library functions|core library functions]]'', which were included in Nasal before its integration into FlightGear, the ''[[#Extension functions|extension functions]]'', which have been subsequently added, and are specifically designed for FlightGear, and the ''[[#variables|global variables]]'', which are conversion variables, added with extension functions, for converting between units. The relevant folders in [[Git]] are:
* {{flightgear file|src/Scripting}}
* {{simgear file|simgear/nasal}}

All these functions and variables are in the global namespace, that is, they are directly accessible (e.g., one can call <syntaxhighlight lang="nasal" inline>magvar()</syntaxhighlight> instead of <syntaxhighlight lang="nasal" inline>namespace.magvar()</syntaxhighlight>). However, if a namespace must be used, <code>globals</code> is the correct namespace, but using it is not recommended. For a more complete explanation, see [[Nasal Namespaces in-depth]].

{{tip|Copy & paste the examples into your [[Nasal Console]] and execute them to see what they do.|width=70%}}

== Core library functions ==
This is the list of the basic '''core library functions.''' Most of these functions were part of the original Nasal library (before its integration in to FlightGear), while some have been added or changed over time. See also:
* http://plausible.org/nasal/lib.html ([http://web.archive.org/web/20101010094553/http://plausible.org/nasal/lib.html archive])
* {{simgear file|simgear/nasal/lib.c}} ([http://sourceforge.net/p/flightgear/simgear/ci/next/log/?path=/simgear/nasal/lib.c history])

=== append() ===
{{Nasal doc
|syntax = append(vector, element[, element[, ...]]);
|source = {{simgear file|simgear/nasal/lib.c|l=42|t=Source}}
|text = This function appends, or adds, the given element(s) to the end of the vector given in the first argument. Returns the vector operated on.
|param1 = vector
|param1text = The vector to which the arguments will be appended.
|param2 = element
|param2text = An element to be added to the vector.
|example1 =
var vector = [1, 2, 3]; # Initialize the vector
append(vector, 4); # Append the number 4 to the end of the vector
debug.dump(vector); # Print the contents of the vector
|example2 =
var vector = [1, 2, 3]; # Initialize the vector
append(vector, 4, 5, 6); # Append the numbers 4, 5, and 6 to the end of the vector
debug.dump(vector); # Print the contents of the vector
}}

=== bind() ===
{{Nasal doc
|syntax = bind(function, locals[, outer_scope]);
|source = {{simgear file|simgear/nasal/lib.c|l=502|t=Source}}
|text = This creates a new function object. A function in Nasal is three things: the actual code, a hash/namespace of local variables available to the function namespace, and the closure object of that namespace. These correspond to the three arguments respectively.
|param1 = function
|param1text = Function to evaluate.
|param2 = locals
|param2text = Hash containing values that will become the namespace (first closure) for the function.
|param3 = outer_scope
|param3text = Optional function which is bound to the next closure. This can be bound to yet another, making a linked list.
|example1 = # This is a namespace/hash with a single member, named "key," which is initialized to 12
var Namespace = {
key: 12
};

# This is different namespace/hash containing a function
# dividing a variable "key" (which is unavailable/nil in this namespace) by 2
var AnotherNamespace = {
ret: func {
key /= 2;
}
};

# To see that key is not available, try to call AnotherNamespace.ret() first
call(AnotherNamespace.ret, [], nil, nil, var errors = []);
if(size(errors)){
print("Key could not be divided/resolved!");
debug.printerror(errors);
}

# Associate the AnotherNamespace.ret() function with the first namespace
# so that "key" is now available
var function = bind(AnotherNamespace.ret, Namespace);

# Invoke the new function
function();

# Print out the value of Namespace.key
# It was changed to 12 from 6 by AnotherNamespace.ret()
print(Namespace.key);
}}

=== call() ===
{{Nasal doc
|syntax = call(func[, args[, me[, locals[, error]]]);
|source = {{simgear file|simgear/nasal/lib.c|l=247|t=Source}}
|text = Calls the given function with the given arguments and returns the result. This function is very useful as it allows much more control over function calls and catches any errors or {{func link|die()}} calls that would normally trigger run-time errors cancelling execution of the script otherwise.
|param1 = func
|param1text = Function to execute.
|param2 = args
|param2text = Vector containing arguments to give to the called function.
|param3 = me
|param3text = <code>'''me'''</code> reference for the function call (i.e., for method calls). If given, this will override any <code>'''me'''</code> value existing in the namespace (locals argument).
|param4 = locals
|param4text = A hash with key/value pairs that will be available to the called function, typically used as the namespace for the function to be called.
|param5 = error
|param5text = A vector to append errors to. If the called function generates an error, the error, place, and line will be written to this. These errors can be printed using {{func link|printerror()|debug}}.
|example1 =
# prints "Called from call()"
call(func {
print("Called from call()");
});
|example2 =
# prints "a = 1 : b = 2
call(func(a, b){
print("a = ", a, " : b = ", b);
},
[1, 2]
);
|example3 =
var Hash = {
new: func {
var m = { parents: [Hash] };

m.el1 = "string1";
m.el2 = "string2";

return m;
}
};

# prints "me.el1 = string1", then "me.el2 = string2" on the next line
call(func(a, b){
print("me.el", a, " = ", me["el" ~ a]);
print("me.el", b, " = ", me["el" ~ b]);
},
[1, 2],
Hash.new()
);
|example4 =
# prints the value of math.pi
call(func {
print(pi);
}, nil, nil,
math
);
|example5 =
call(func {
print(math.ip); # math.ip doesn't exist
}, nil, nil, nil,
var errs = []
);
debug.printerror(errs); # The error is caught and printed using debug.printerror()
}}

=== caller() ===
{{Nasal doc
|syntax = caller([level]);
|source = {{simgear file|simgear/nasal/lib.c|l=404|t=Source}}
|text = Returns a vector containing a record from the current call stack. The level numbering starts from the currently executing function (level 0). Level 1 (the default) is the caller of the current function, and so on.

The result is a four-element vector containing '''[0]''' a hash of local variables, '''[1]''' the function object, '''[2]''' the full source file name (incl. path) and '''[3]''' the line number.
|param1 = level
|param1text = Optional integer specifying the stack level to return a result from. Defaults to 1 (i.e. the caller of the currently executing function).
|example1 =
var myFunction = func(a, b){
debug.dump(caller(0)[0]); # prints a hash of local variables, including arguments a and b
return 2 * 2;
};

print("2 x 2 = ", myFunction(2, 2));
|example2 =
var get_arg_value = func(){
print("Argument to myFunc = ", caller(1)[0]['a']); # print the value of myFunc's single argument, using caller()
};

var myFunc = func(a){
get_arg_value();
};

myFunc(3);
|example3text = This is a real example taken from {{fgdata file|Nasal/canvas/MapStructure.nas}}. Function <code>r()</code> (above the TODOs) returns a hash with the key/value pairs as per its arguments. For example, something like this is returned: <code>{ name: "<name>", vis: 1, zindex: nil }</code>.
|example3 =
var MapStructure_selfTest = func() {
var temp = {};
temp.dlg = canvas.Window.new([600,400],"dialog");
temp.canvas = temp.dlg.createCanvas().setColorBackground(1,1,1,0.5);
temp.root = temp.canvas.createGroup();
var TestMap = temp.root.createChild("map");
TestMap.setController("Aircraft position");
TestMap.setRange(25); # TODO: implement zooming/panning via mouse/wheel here, for lack of buttons :-/
TestMap.setTranslation(
temp.canvas.get("view[0]")/2,
temp.canvas.get("view[1]")/2
);
var r = func(name,vis=1,zindex=nil) return caller(0)[0];
# TODO: we'll need some z-indexing here, right now it's just random
# TODO: use foreach/keys to show all layers in this case by traversing SymbolLayer.registry direclty ?
# maybe encode implicit z-indexing for each lcontroller ctor call ? - i.e. preferred above/below order ?
foreach(var type; [r('TFC',0),r('APT'),r('DME'),r('VOR'),r('NDB'),r('FIX',0),r('RTE'),r('WPT'),r('FLT'),r('WXR'),r('APS'), ] )
TestMap.addLayer(factory: canvas.SymbolLayer, type_arg: type.name,
visible: type.vis, priority: type.zindex,
);
}; # MapStructure_selfTest
}}

=== chr() ===
{{Nasal doc
|syntax = chr(code);
|source = {{simgear file|simgear/nasal/lib.c|l=175|t=Source}}
|text = Returns a character as per the single argument. Extended ASCII is supported (see http://www.asciitable.com/ for a list of supported characters), although this may vary between different systems. For a list of the most commonly used characters, see the {{wikipedia|ASCII#ASCII printable code chart|ASCII printable code chart}} ('''Dec''' column). The following table lists supported control characters, along with their equivalent control characters in Nasal strings. {{Note|In Nasal, only strings enclosed with double-quotes (<code>"string"</code>) supports control chracters. Strings in single quotes (<code>'string'</code>) do not.}}
{{{!}} class="wikitable"
! Code !! Name !! Equivalent to
{{!-}}
{{!}} 10 {{!!}} {{Wikipedia|Newline}} {{!!}} <code>\n</code>
{{!-}}
{{!}} 9 {{!!}} {{Wikipedia|Tab key#Tab characters|Horizontal tab}} {{!!}} <code>\t</code>
{{!-}}
{{!}} 13 {{!!}} {{Wikipedia|Carriage return}} {{!!}} <code>\r</code>
{{!}}}
|param1 = code
|param1text = Integer character code for the desired glyph.
|example1 = print("Code 65 = ", chr(65)); # prints "Code 65 = A"
|example2text = This example displays all of the characters in a list, in the format <code>Code '''n''' = >'''char'''<</code>, '''n''' being the index, and '''char''' being the character.
|example2 =
for(var i = 0; i <= 255; i += 1){
print("Code ", i, " = >", chr(i), "<");
}
}}

=== closure() ===
{{Nasal doc
|syntax = closure(func[, level]);
|source = {{simgear file|simgear/nasal/lib.c|l=421|t=Source}}
|text = Returns the hash table containing the lexical namespace of the given function. The level numbering start with level 0 being the namespace of '''func'''.
|param1 = func
|param1text = Function to evaluate.
|param2 = level
|param2text = Optional integer specifying the scope level. Defaults to 0 (the namespace of '''func''').
|example1 =
var get_math_e = func {
return e; # return the value of math.e
}

var myFunction = bind(get_math_e, math); # bind get_math_e to the math namespace, so that math.e is immediately available to get_math_e
debug.dump(closure(myFunction)); # print the namespace of get_math_e

print(myFunction());
}}

=== cmp() ===
{{Nasal doc
|syntax = cmp(a, b);
|source = {{simgear file|simgear/nasal/lib.c|l=112|t=Source}}
|text = Compares two strings, returning -1 if '''a''' is less than '''b''', 0 if they are identical and 1 if '''a''' is greater than '''b'''.
|param1 = a
|param1text = First string argument for comparison.
|param2 = b
|param2text = Second string argument for comparison.
|example1 = print(cmp("1", "two")); # prints -1
|example2 = print(cmp("string", "string")); # prints 0
|example3 = print(cmp("one", "2")); # prints 1
|example4 = print(cmp("string1", "string2")); # prints -1
}}

=== compile() ===
{{Nasal doc
|syntax = compile(code[, filename]);
|source = {{simgear file|simgear/nasal/lib.c|l=220|t=Source}}
|text = Compiles the specified code string and returns a function object bound to the current lexical context. If there is an error, the function dies, with the argument to {{func link|die()}} being '''filename'''.
|param1 = code
|param1text = String containing Nasal code to be compiled.
|param2 = filename
|param2text = Optional string used for error messages/logging. Defaults to <code><compile></code>
|example1 =
var myCode = 'print("hello");';
var helloFunc = compile(myCode, "myCode");
helloFunc();
|example2text = <code>compile</code> is very convenient to support Nasal loaded from other files. For instance, [[PropertyList XML files]] (such as GUI dialogs) may contain embedded Nasal sections that need to be parsed, processed and compiled. For an example of how to do this, save the below XML code as <tt>''[[$FG_ROOT]]/gui/dialogs/test.xml''</tt>.
<syntaxhighlight lang="xml">
<?xml version="1.0"?>

<PropertyList>

<nasal><![CDATA[
print("You have FlightGear v", getprop("/sim/version/flightgear"));
]]></nasal>

</PropertyList>
</syntaxhighlight>
Now, start FlightGear and execute this code in the [[Nasal Console]].
|example2 =
# Build the path
var FGRoot = getprop("/sim/fg-root");
var filename = "/gui/dialogs/test.xml";
var path = FGRoot ~ filename;

var blob = io.read_properties(path);
var script = blob.getValues().nasal; # Get the nasal string

# Compile the script. We're passing the filename here for better runtime diagnostics
var code = call(func {
compile(script, filename);
}, nil, nil, var compilation_errors = []);

if(size(compilation_errors)){
die("Error compiling code in: " ~ filename);
}

# Invoke the compiled script, equivalent to code();
# We're using call() here to detect errors:
call(code, [], nil, nil, var runtime_errors = []);

if(size(runtime_errors)){
die("Error calling code compiled loaded from: " ~ filename);
}
}}

=== contains() ===
{{Nasal doc
|syntax = contains(hash, key);
|source = {{simgear file|simgear/nasal/lib.c|l=184|t=Source}}
|text = Returns 1 (True) if the hash contains the specified key, or 0 (False) if not.
|param1 = hash
|param1text = The hash to search in.
|param2 = key
|param2text = The scalar to be searched for, contained as a key in the hash.
|example1 =
# Initialize a hash
var hash = {
element: "value"
};
print(contains(hash, "element") ? "Yes" : "No"); # This will print "Yes"
|example2 =
# Initialize a hash
var hash = {
element: "value"
};
print(contains(hash, "element2") ? "Yes" : "No"); # This will print "No"
}}

=== delete() ===
{{Nasal doc
|syntax = delete(hash, key);
|source = {{simgear file|simgear/nasal/lib.c|l=83|t=Source}}
|text = Deletes the key from the hash if it exists. Operationally, this is NOT identical to setting the hash value specified by the key to <code>'''nil'''</code> as the key will stay in the hash (at least for a while). This variant potentially frees storage by deleting the reference to the key and by shrinking the hash. Returns the hash that has been operated on.
|param1 = hash
|param1text = The hash from which to delete the key.
|param2 = key
|param2text = The scalar to be deleted, contained as a key in the hash.
|example1 =
# Initialize the hash
var hash = {
element1: "value1",
element2: "value2"
};
delete(hash, "element1"); # Delete element1
debug.dump(hash); # prints the hash, which is now minus element1
}}

=== die() ===
{{Nasal doc
|syntax = die(error);
|source = {{simgear file|simgear/nasal/lib.c|l=288|t=Source}}
|text = Terminates execution and unwinds the stack. The place and the line will be added to the '''error'''. This invokes the same internal exception handler used for internal runtime errors. Use this to signal fatal errors, or to implement exception handling. The error thrown (including internal runtime errors) can be caught with {{func link|call()}}.
|param1 = error
|param1text = String describing the error.
:{{inote|This parameter is technically optional, but it is highly recommended to use it.}}
|example1 =
print("Will print");
die("Don't go any further!");
print("Won't print"); # Will not be printed because die() stops the process
}}

=== find() ===
{{Nasal doc
|syntax = find(needle, haystack);
|source = {{simgear file|simgear/nasal/lib.c|l=450|t=Source}}
|text = Finds and returns the index of the first occurrence of the string '''needle''' in the string '''haystack''', or -1 if no such occurrence was found.
|param1 = needle
|param1text = String to search for.
|param2 = haystack
|param2text = String to search in.
|example1 = print(find("c", "abcdef")); # prints 2
|example2 = print(find("x", "abcdef")); # prints -1
|example3 = print(find("cd", "abcdef")); # prints 2
}}

=== ghosttype() ===
{{Nasal doc
|syntax = ghosttype(ghost);
|source = {{simgear file|simgear/nasal/lib.c|l=207|t=Source}}
|text = Returns a string containing either a descriptive name of a ghost (a raw C/C++ object), or a unique id (the pointer to the C/C++ <code>naGhostType</code> instance) if no name has been set. Ghost is an acronym that stands for '''G'''arbage-collected '''H'''andle to '''O'''ut'''S'''ide '''T'''hingy.
|param1 = ghost
|param1text = Ghost to return a description for.
|example1 = print(ghosttype(airportinfo())); # prints "airport"
}}

=== id() ===
{{Nasal doc
|syntax = id(object);
|source = {{simgear file|simgear/nasal/lib.c|l=570|t=Source}}
|text = Returns a string containing information on the type and ID of the object provided in the single argument. The information is returned in the form of <code>'''<type>''':'''<id>'''</code>, where '''<type>''' is the type of object, and '''<id>''' is the ID.
|param1 = object
|param1text = Can be either of a string, a vector, a hash, a code, a function, or a ghost.
|example1 = print(id("A")); # prints "str:000000001624A590"
}}

=== int() ===
{{Nasal doc
|syntax = int(number);
|source = {{simgear file|simgear/nasal/lib.c|l=90|t=Source}}
|text = Returns the integer part of the numeric value of the single argument, or <code>'''nil'''</code> if none exists.
|param1 = number
|param1text = Number or string with just a number in it to return an integer from.
|example1 = print(int(23)); # prints "23"
|example2 = print(int(23.123)); # prints "23"
|example3 = debug.dump(int("string")); # prints "nil"
}}

=== keys() ===
{{Nasal doc
|syntax = keys(hash);
|source = {{simgear file|simgear/nasal/lib.c|l=33|t=Source}}
|text = Returns a vector containing the list of keys found in the single hash argument.
|param1 = hash
|param1text = The hash to return the keys from.
|example1 =
# Initialize a hash
var hash = {
element1: "value",
element2: "value"
};
debug.dump(keys(hash)); # print the vector
}}

=== left() ===
{{Nasal doc
|syntax = left(string, length);
|source = {{simgear file|simgear/nasal/lib.c|l=149|t=Source}}
|version = 2.12
|commit = {{simgear commit|bd7163|t=commit}}
|text = Returns a substring of '''string''', starting from the left.
|param1 = string
|param1text = String to return part of.
|param2 = length
|param2text = Integer specifying the length of the substring to return.
|example1 = print(left("string", 2)); # prints "st"
}}

=== num() ===
{{Nasal doc
|syntax = num(number);
|source = {{simgear file|simgear/nasal/lib.c|l=102|t=Source}}
|text = Returns the numerical value of the single string argument, or <code>'''nil'''</code> if none exists.
|param1 = number
|param1text = String with just a number in it to return a number from.
|example1 = print(num("23")); # prints "23"
|example2 = print(num("23.123")); # prints "23.123"
|example3 = debug.dump(num("string")); # prints "nil"
}}

=== pop() ===
{{Nasal doc
|syntax = pop(vector);
|source = {{simgear file|simgear/nasal/lib.c|l=50|t=Source}}
|text = Removes and returns the last element of the single vector argument, or <code>'''nil'''</code> if the vector is empty.
|param1 = vector
|param1text = Vector to remove an element from.
|example1 =
var vector = [1, 2, 3];
pop(vector);
debug.dump(vector); # prints "[1, 2]"
|example2 =
var vector = [1, 2, 3];
debug.dump(pop(vector)); # prints "3"
|example3 =
var vector = [];
debug.dump(pop(vector)); # prints "nil"
}}

=== right() ===
{{Nasal doc
|syntax = right(string, length);
|source = {{simgear file|simgear/nasal/lib.c|l=161|t=Source}}
|version = 2.12
|commit = {{simgear commit|bd7163|t=commit}}
|text = Returns a substring of '''string''', starting from the right.
|param1 = string
|param1text = String to return part of.
|param2 = length
|param2text = Integer specifying the length of the substring to return.
|example1 = print(right("string", 2)); # prints "ng"
}}

=== setsize() ===
{{Nasal doc
|syntax = setsize(vector, size);
|source = {{simgear file|simgear/nasal/lib.c|l=56|t=Source}}
|text = Sets the size of a vector. The first argument specifies a vector, the second a number representing the desired size of that vector. If the vector is currently larger than the specified size, it is truncated. If it is smaller, it is padded with <code>'''nil'''</code> entries. Returns the vector operated upon.
|param1 = vector
|param1text = The vector to be operated on.
|param2 = size
|param2text = The desired size of the vector in number of entries.
|example1 =
var vector = [1, 2, 3]; # Initialize a vector
setsize(vector, 4);
debug.dump(vector); # print the vector
|example2 =
var vector = [1, 2, 3]; # Initialize a vector
setsize(vector, 2);
debug.dump(vector); # print the vector
}}

=== size() ===
{{Nasal doc
|syntax = size(object);
|source = {{simgear file|simgear/nasal/lib.c|l=23|t=Source}}
|text = Returns the size of the single argument. For strings, this is the length in bytes. For vectors, this is the number of elements. For hashes, it is the number of key/value pairs. If the argument is <code>'''nil'''</code> or a number, this error will be thrown: <code>object has no size()</code>.
|param1 = object
|param1text = Object to find the size of. Must be a string, a vector or a hash.
|example1 =
var string = "string";
print(size(string)); # prints "6"
|example2 =
var vector = [1, 2, 3];
print(size(vector)); # prints "3"
|example3 =
var hash = {
element1: "value1",
element2: "value2",
element3: "value3"
};
print(size(hash)); # prints "3"
}}

=== sort() ===
{{Nasal doc
|syntax = sort(vector, function);
|source = {{simgear file|simgear/nasal/lib.c|l=542|t=Source}}
|text = Returns a vector containing the elements in the input '''vector''' sorted in according to the rule given by '''function'''. Implemented with the ANSI C {{func link|qsort()|link=http://www.cplusplus.com/reference/cstdlib/qsort/}}, <code>sort()</code> is stable. This means that if the rules in the first example are used, equal elements in the output vector will appear in the same relative order as they do in the input. It is run in a loop, so '''function''' is run several times.
|param1 = vector
|param1text = Input vector to sort.
|param2 = function
|param2text = Function according to which the elements will be sorted by. It should take two arguments and should return one of 1, 0, or -1.
{{{!}} class="wikitable"
! Return value !! Meaning
{{!-}}
{{!}} less than 0 {{!!}} first argument should go before second argument
{{!-}}
{{!}} 0 {{!!}} first argument equals second argument
{{!-}}
{{!}} greater than 0 {{!!}} first argument should go after second argument
{{!}}}

|example1text = This example sorts elements from smallest to greatest.
|example1 =
var sort_rules = func(a, b){
if(a < b){
return -1; # A should before b in the returned vector
}elsif(a == b){
return 0; # A is equivalent to b
}else{
return 1; # A should after b in the returned vector
}
}
debug.dump(sort([3, 2, 5, 6, 4, 1], sort_rules)); # prints "[1, 2, 3, 4, 5, 6]"
|example2text = This example sorts elements from greatest to smallest.
|example2 =
# Outputs the elements in reverse order (greatest to smallest)
var sort_rules = func(a, b){
if(a < b){
return 1; # -1 in the above example
}elsif(a == b){
return 0;
}else{
return -1; # 1 in the above example
}
}
debug.dump(sort([3, 2, 5, 6, 4, 1], sort_rules)); # prints "[6, 5, 4, 3, 2, 1]"
|example3text = This example sorts a vector of strings (runways for example) from smallest to greatest.
|example3 =
var runways = ["09R","27R","26L","09L","15"];
var rwy = sort(runways,func(a,b) cmp(a,b));
debug.dump(rwy); # prints ['09L','09R','15','26L','27R']
}}

=== split() ===
{{Nasal doc
|syntax = split(delimiter, string);
|source = {{simgear file|simgear/nasal/lib.c|l=460|t=Source}}
|text = Splits the input string into a vector of substrings bounded by occurrences of the delimiter substring.
|param1 = delimiter
|param1text = String that will split the substrings in the returned vector.
|param2 = string
|param2text = String to split up.
|example1 = debug.dump(split("cd", "abcdef")); # prints "['ab', 'ef']"
|example2 = debug.dump(split(".", "3.2.0")); # prints "[3, 2, 0]"
|example3 = debug.dump(split("/", "path/to/file")); # prints "['path', 'to', 'file']"
}}

=== sprintf() ===
{{Nasal doc
|syntax = sprintf(format[, arg[, arg, [...]]]);
|source = {{simgear file|simgear/nasal/lib.c|l=355|t=Source}}
|text = Creates and returns a string formatted using ANSI C {{func link|vsnprintf()|link=http://en.cppreference.com/w/c/io/vfprintf}} <ref>
{{Cite web
|url = http://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/nasal/lib.c#l308
|title = fgdata/simgear/simgear/nasal/lib.c, line 308
|accessdate = October 2015
}}
</ref>. Below is a table of supported format specifiers.
{{{!}} class="wikitable" width="75%"
{{!}}+ %[flags][width][.precision]specifier
! colspan="2" {{!}} Flags
{{!-}}
! Flag !! Output
{{!-}}
{{!}} <code>+</code> {{!!}} Forces to precede the result with a plus or minus sign ('''+''' or '''-''') even for positive numbers. By default, only negative numbers are preceded with a '''-''' sign.
{{!-}}
{{!}} ''space'' {{!!}} Prefixes non-signed numbers with a space.
{{!-}}
{{!}} <code>-</code> {{!!}} Left-align the output of this placeholder (the default is to right-align the output) when the width option is specified.
{{!-}}
{{!}} <code>0</code> {{!!}} Use 0 instead of spaces to pad a field when the width option is specified.
{{!-}}
{{!}} <code>#</code> {{!!}} Used with <code>o</code>, <code>x</code> or <code>X</code> specifiers the value is preceded with <tt>0</tt>, <tt>0x</tt> or <tt>0X</tt> respectively for values different than zero. Used with <code>e</code>, <code>E</code> and <code>f</code>, it forces the written output to contain a decimal point even if no digits would follow. By default, if no digits follow, no decimal point is written. Used with <code>g</code> or <code>G</code> the result is the same as with <code>e</code> or <code>E</code> but trailing zeros are not removed.
{{!-}}
! colspan="2" {{!}} Width
{{!-}}
{{!}} colspan="2" {{!}} Integer specifying the minimum number of characters to be returned. This includes the decimal point and decimal fraction as well as + or - signs.
{{!-}}
! colspan="2" {{!}} Precision
{{!-}}
{{!}} colspan="2" {{!}} Integer preceded by a dot specifying the number of decimal places to be written.
{{!-}}
! colspan="2" {{!}} Specifiers
{{!-}}
! Specifier !! Output
{{!-}}
{{!}} <code>d</code>, <code>i</code> {{!!}} Signed decimal number.
{{!-}}
{{!}} <code>s</code> {{!!}} A string
{{!-}}
{{!}} <code>%</code> {{!!}} Percent (%) character.
{{!-}}
{{!}} <code>c</code> {{!!}} A single character assigned to a character code, the code given in an integer argument. See http://www.asciitable.com/ for a list of supported characters and their codes.
{{!-}}
{{!}} <code>o</code> {{!!}} Unsigned integer as an octal number.
{{!-}}
{{!}} <code>u</code> {{!!}} Unsigned decimal integer.
{{!-}}
{{!}} <code>x</code>, <code>X</code> {{!!}} Unsigned integer as a hexadecimal number. If <code>x</code> is used, any letters in the number are lowercase, while <code>X</code> gives uppercase.
{{!-}}
{{!}} <code>e</code>, <code>E</code> {{!!}} Double value in scientific notation (i.e., ''[-]ddd.ddd'''e'''[+/-]ddd''), with an exponent being denoted by <tt>e</tt> or <tt>E</tt> depending on whether an upper or lowercase is used respectively.
{{!-}}
{{!}} <code>f</code> {{!!}} Floating-point number, in fixed decimal notation, by default with 6 decimal places.
{{!-}}
{{!}} <code>F</code> {{!!}} Appears to be available<ref>
{{Cite web
|url = http://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/nasal/lib.c#l389
|title = fgdata/simgear/simgear/nasal/lib.c, line 389
|accessdate = October 2015
}}
</ref>, but doesn't work.
{{!-}}
{{!}} <code>g</code>, <code>G</code> {{!!}} Double in either normal or exponential notation, whichever is more appropriate for its magnitude. <code>g</code> uses lower-case letters, <code>G</code> uses upper-case letters. This type differs slightly from fixed-point notation in that insignificant zeroes to the right of the decimal point are not included. Also, the decimal point is not included on whole numbers.
{{!}}}

|param1 = format
|param1text = String specifying the format. Can be used with or without a format specifiers. See below for examples.
|param2 = arg
|param2text = Argument specifying a value to replace a format placeholder (such as <code>%d</code>) in the format string. Not required if there are no format specifiers.

|example1 = print(sprintf("%i", 54)); # prints "54"
|example2 = print(sprintf("Pi = %+.10f", math.pi)); # prints "Pi = +3.1415926536"
|example3 =
print(sprintf("%6d", 23)); # prints " 23"
print(sprintf("%06d", 23)); # prints "000023"
|example4 =
var FGVer = getprop("/sim/version/flightgear");
print(sprintf("You have FlightGear v%s", FGVer)); # prints "You have FlightGear v<your version>"
|example5 =
print(sprintf("Hexadecimal 100000 = %X", 100000)); # prints "Hexadecimal 100000 = 186A0"
print(sprintf("Hexadecimal 100000 = %x", 100000)); # prints "Hexadecimal 100000 = 186a0"
|example6 = print(sprintf("Code 65 is %c", 65)); # prints "Code 65 is A"
|example7 =
print(sprintf("%e", 54)); # prints "5.400000e+001"
print(sprintf("%E", 54)); # prints "5.400000E+001"
|example8 = print(sprintf("%o", 54)); # prints "66"
|example9 = print(sprintf("50%% of 100 is %i", 100 / 2)); # prints "50% of 100 is 50"
|example10 =
print(sprintf("%.2f", 1.4)); #prints "1.40"
print(sprintf("%.1f", 1.4)); #prints "1.4"
print(sprintf("% 4.1f", 1.4)); #prints " 1.4"
print(sprintf("%04.1f", 1.4)); #prints "01.4"
print(sprintf("% 6.1f", 1.4)); #prints " 1.4"
print(sprintf("%06.1f", 1.4)); #prints "0001.4"
}}

=== streq() ===
{{Nasal doc
|syntax = streq(a, b);
|source = {{simgear file|simgear/nasal/lib.c|l=129|t=Source}}
|text = Tests the string values of the two arguments for equality. This function is needed because the <code>'''=='''</code> operator (see [[Nasal_Operators#Equality|Nasal Operators]]) tests for numeric equality first. If either or both the arguments are not strings, 0 (False) will be returned. Returns either 0 (False) or 1 (True). {{Note|This function is rarely required in typical code.}}
|param1 = a
|param1text = First argument for testing equality.
|param2 = b
|param2text = Second argument for testing equality.
|example1 = print(streq("0", "0")); # prints "1" (True)
|example2 =
print(0 == 0.0); # prints "1" (True)
print(streq("0", "0.0")); # prints "0" (False)
}}

=== substr() ===
{{Nasal doc
|syntax = substr(string, start [, length]);
|source = {{simgear file|simgear/nasal/lib.c|l=129|t=Source}}
|text = Similar the {{func link|subvec()}}, but operates on strings. Computes and returns a substring. The first argument specifies a string, the second is the index of the start of a substring, the optional third argument specifies a length (the default is to return the rest of the string from the start).
|param1 = string
|param1text = String to return a substring from.
|param2 = start
|param2text = Integer specifying the start of a substring. Negative values specify a position from the end of the string.
|param3 = length
|param3text = Optional argument specifying the length of the substring. Defaults to the end of the string.
|example1 = print(substr("abcde", 1, 3)); # prints "bcd"
|example2 = print(substr("abcde", 1)); # prints "bcde"
|example3 = print(substr("abcde", 2, 1)); # prints "c"
|example4 = print(substr("abcde", -2)); # prints "de"
|example5 = print(substr("abcde", -3, 2)); # prints "cd"
}}

=== subvec() ===
{{Nasal doc
|syntax = subvec(vector, start[, length]);
|source = {{simgear file|simgear/nasal/lib.c|l=63|t=Source}}
|text = Returns a sub-range of a vector. The first argument specifies a vector, the second a starting index, and the optional third argument indicates a length (the default is to the end of the vector).
|param1 = vector
|param1text = The vector to take the sub-vector from.
|param2 = start
|param2text = The starting point of the sub-vector within the given vector.
|param3 = length
|param3text = Optional argument specifying the length of the sub-vector, from the starting point.
'''Notes:'''
* Omitting the ''vector'' and ''start'' arguments is not an error (possibly it should be) but the return value is ''nil''.
* A negative ''start'' argument ''is'' an error. This seems wrong. Perhaps the language designer could comment.
* A value of ''start'' greater than ''size(vector)'' causes an error. A value equal to ''size(vector)'' returns an empty vector.
* If the value of ''length'' is greater than ''size(vector) - start'' then it is ignored. That is, all elements from ''start'' to the end of ''vector'' are returned. If ''length'' is zero then an empty vector is returned. A negative value of ''length'' causes an error.
|example1 =
var vector = [1, 2, 3];
debug.dump(subvec(vector, 0)); # prints "[1, 2, 3]"
|example2 =
var vector = [1, 2, 3];
debug.dump(subvec(vector, 1)); # prints "[2, 3]"
|example3 =
var vector = [1, 2, 3];
debug.dump(subvec(vector, 1, 1)); # prints "[2]"
}}

=== typeof() ===
{{Nasal doc
|syntax = typeof(object);
|source = {{simgear file|simgear/nasal/lib.c|l=193|t=Source}}
|text = Returns a string indicating the whether the object is <code>'''nil'''</code>, a scalar (number or string), a vector, a hash, a function, or a ghost.
|param1 = object
|param1text = Object to return the type of.
|example1 =
var object = nil;
print(typeof(object)); # prints "nil"
|example2 =
var object = "Hello world!";
print(typeof(object)); # prints "scalar"
|example3 =
var object = math.pi;
print(typeof(object)); # prints "scalar"
|example4 =
var object = [1, 2, 3];
print(typeof(object)); # prints "vector"
|example5 =
var object = {};
print(typeof(object)); # prints "hash"
|example6 =
var object = func {};
print(typeof(object)); # prints "func"
|example7 =
var object = airportinfo();
print(typeof(object)); # prints "ghost"
}}



== Extension functions ==
The '''extension functions''' are global functions that have been added to Nasal since its integration into FlightGear. Unlike the core library functions, they are generally specifically designed to interact directly with FlightGear. Extension functions come from three source files:
* {{flightgear file|src/Scripting/NasalPositioned.cxx}}
* {{flightgear file|src/Scripting/NasalSys.cxx}}
* {{fgdata file|Nasal/globals.nas}}

=== abort() ===
{{Nasal doc
|syntax = abort();
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=565|t=Source}}
|text = This function is a wrapper for the C++ {{func link|abort()|link=http://www.cplusplus.com/reference/cstdlib/abort/}} function. It simply aborts FlightGear with an error, which varies depending on the operating system. This function should not really be used; instead, please use the "exit" [[Fgcommands|fgcommand]], which will exit FlightGear more gracefully (see example below).
|example1text = This example will immediately stop FlightGear with an error, such as "FlightGear has stopped working."
|example1 = abort();
|example2text = For exiting FlightGear in a better way, please use the following code:
|example2 = fgcommand("exit");
}}

=== abs() ===
{{Nasal doc
|syntax = abs(number);
|source = {{fgdata file|Nasal/globals.nas|t=Source}}
|text = This simple function returns the {{wikipedia|absolute value|noicon=1}} of the provided number.
|param1 = number
|param1text = This argument is required and should be a number.
|example1 = print(abs(1)); # prints "1"
|example2 = print(abs(-1)); # prints "1"
}}

=== aircraftToCart() ===
This new function in FG 2017.2.1 takes coordinates in aircraft structural coordinate system, and translate them into geocentric coordinates.
Example for (5,6,7):
<syntaxhighlight lang="nasal">
var pos = aircraftToCart({x: -5, y: 6, z: -7});
var coord = geo.Coord.new();
coord.set_xyz(pos.x, pos.y, pos.z);
</syntaxhighlight>
Notice: x and z is inverted sign on purpose.
if you want lat. lon, alt from that, just call: (degrees and meters)

<syntaxhighlight lang="nasal">
coord.lat()
coord.lon()
coord.alt()
</syntaxhighlight>

=== addcommand() ===
{{Nasal doc
|syntax = addcommand(name, code);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=659|t=Source}}
|version = 2.12
|commit = {{flightgear commit|7b663c|t=commit}}
|text = {{see also|Howto:Add new fgcommands to FlightGear}}

This function enables the addition of a new custom [[fgcommands|fgcommand]] to FlightGear from within Nasal. An fgcommand created using this method can be used in exactly the same way as the built-in fgcommands. Also, an fgcommand created via this method will always return True or 1, like all other fgcommands.
|param1 = name
|param1text = This will become the name of the new fgcommand. Must be a string.
|param2 = code
|param2text = The code that will be executed when the fgcommand is run. Must be a function.
|example1text = This example adds a new fgcommand and then runs it. Although it executes a simple {{func link|print()}} statement, any valid Nasal code can be used.
|example1 = addcommand("myFGCmd", func(node) {
print("fgcommand 'myFGCmd' has been run.");
props.dump( node );
});
fgcommand("myFGCmd", props.Node.new({foo:1, bar:2}) );
|example2text = This example demonstrates how parameters are defined in a new fgcommand.
|example2 = addcommand("myFGCmd", func(node){
print(node.getNode("number").getValue()); # prints the value of "number," which is 12
});
fgcommand("myFGCmd", props.Node.new({"number": 12}));
}}

=== airportinfo() ===
{{Nasal doc
|syntax = airportinfo();
airportinfo(type);
airportinfo(id);
airportinfo(lat, lon[, type]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1024|t=Source}}
|text = Function for retrieval of airport, heliport, or seaplane base information. It returns a Nasal ghost; however, its structure is like that of a Nasal hash. The following information is returned:
* '''parents''': A vector containing a hash of various functions to access information about the runway. See {{flightgear file|src/Scripting/NasalPositioned.cxx|l=2659}} for full list.
* '''lon''': Longitude of the location.
* '''lat''': Latitude of the location.
* '''has_metar''': True or false depending whether the airport has a [[METAR]] code defined for it.
* '''elevation''': Elevation of the location in metres.
* '''id''': ICAO code of the airport (or ID of the seaplane base/heliport).
* '''name''': Name of the airport/heliport/seaplane base.
* '''runways'''
** '''<runway name>'''
*** '''id''': Name of runway.
*** '''lat''': Latitude of the runway.
*** '''lon''': Longitude of the runway.
*** '''heading''': Heading of the runway.
*** '''length''': Length of the runway in metres.
*** '''width''': Width of the runway in metres.
*** '''surface''': Runway surface type.
*** '''threshold''': Length of the runway's {{wikipedia|displaced threshold}} in metres. Will return 0 if there is none.
*** '''stopway''': Length of the runway's stopway (the area before the threshold) in metres. Will return 0 if there is none.
*** '''reciprocal''': <code>runway</code> ghost of the reciprocal runway.
*** '''ils_frequency_mhz''': ILS frequency in megahertz.
*** '''ils''': <code>navaid</code> ghost of the ILS transmitter.
* '''helipads'''
** '''<helipad name>'''
*** '''id''': Name of helipad.
*** '''lat''': Latitude of the helipad.
*** '''lon''': Longitude of the helipad.
*** '''heading''': Heading of the helipad.
*** '''length''': Length of the helipad in metres.
*** '''width''': Width of the helipad in metres.
*** '''surface''': Helipad surface type.
* '''taxiways'''
** '''<taxiway name>'''
*** '''id''': Name of taxiway.
*** '''lat''': Latitude of the taxiway.
*** '''lon''': Longitude of the taxiway.
*** '''heading''': Heading of the taxiway.
*** '''length''': Length of the taxiway in metres.
*** '''width''': Width of the taxiway in metres.
*** '''surface''': Taxiway surface type.

Information is extracted in the same way as accessing members of a Nasal hash. For example:
<syntaxhighlight lang="nasal">
# prints to lengths of the runways of the nearest airport in feet and metres
var info = airportinfo();
print("-- Lengths of the runways at ", info.name, " (", info.id, ") --");
foreach(var rwy; keys(info.runways)){
print(rwy, ": ", math.round(info.runways[rwy].length * M2FT), " ft (", info.runways[rwy].length, " m)");
}
</syntaxhighlight>

Note that searches for locations that are a long way away (e.g., the nearest seaplane base to the middle of the Sahara) may cause FlightGear to pause for an amount of time.
|param1 = id
|param1text = The {{wikipedia|International Civil Aviation Organization airport code|ICAO code|noicon=1}} of an airport to retrieve information about.
|param2 = type
|param2text = When this argument is used, the function will return the closest airport of a certain type. Can be one of "heliport," "seaport," or "airport" (default).
: {{inote|Running this function without any parameters is equivalent to this:
: <syntaxhighlight lang="nasal">
airportinfo("airport");
</syntaxhighlight>
}}
|param3 = lat ''and'' lon
|param3text = When these parameters are used, the function will return information on the nearest airport, heliport or seaplane base (depending on the '''type''' parameter) to those coordinates.
|example1 = var info = airportinfo();
print("Nearest airport: ", info.name, " (", info.id, ")"); # prints the name and ICAO code of the nearest airport
|example2 = var info = airportinfo("heliport");
print("Elevation of the nearest heliport: ", math.round(info.elevation * M2FT), " ft"); # prints the elevation and name of the nearest heliport
|example3 = var info = airportinfo("KSQL");
print("-- Runways of ", info.name, " (", info.id, "): --");
foreach(var rwy; keys(info.runways)) {
print(rwy); # prints the runways of KSQL
}
|example4 = var info = airportinfo(37.81909385, -122.4722484);
print("Coordinates of the nearest airport: ", info.lat, ", ", info.lon); # print the name and ICAO of the nearest airport to the Golden Gate Bridge
|example5 = var info = airportinfo(37.81909385, -122.4722484, "seaport");
print("Nearest seaplane base: ", info.name, " (", info.id, ")"); # print the name and ID of the nearest seaplane base to the Golden Gate Bridge
|example6text = This example prints the all information from an <code>airportinfo()</code> call.
|example6 = var info = airportinfo("KSFO");
print(info.name);
print(info.id);
print(info.lat);
print(info.lon);
print(info.has_metar);
print(info.elevation);
foreach(var rwy; keys(info.runways)){
print("-- ", rwy, " --");
print(info.runways[rwy].lat);
print(info.runways[rwy].lon);
print(info.runways[rwy].length);
print(info.runways[rwy].width);
print(info.runways[rwy].heading);
print(info.runways[rwy].stopway);
print(info.runways[rwy].threshold);
}
}}

=== airwaysRoute() ===
{{Nasal doc
|syntax = airwaysRoute(start, end[, type]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1933|t=Source}}
|text = {{see also|Nasal Flightplan}}
This function returns a vector containing waypoints between two given waypoints. The returned waypoints are ghosts, but can be accessed in the same way as a Nasal hash. See [[Nasal Flightplan]] for more information.
|param1 = start
|param1text = Start waypoint, in the form of a waypoint ghost, such as that provided by {{func link|flightplan()}}.
|param2 = end
|param2text = Same as above.
|param3 = type
|param3text = Instructs the function to compute a high level route (when set to "highlevel"), or a low level route (when set to "lowlevel"). Defaults to "highlevel."
|example1text = In the [[route manager]] dialog, add two waypoints to the flightplan, ideally ones that are far apart (tip: use the [[Map]] for this). Then run this code in your Nasal Console.
|example1 = var fp = flightplan();
var start = fp.getWP(0);
var end = fp.getWP(fp.getPlanSize() - 1);
var rt = airwaysRoute(start, end);
foreach(var wp; rt){
print(wp.wp_name); # print the waypoints in the computed route
}
|example2text = Exactly the same as above, but computes a low level path.
|example2 = var fp = flightplan();
var start = fp.getWP(0);
var end = fp.getWP(fp.getPlanSize() - 1);
var rt = airwaysRoute(start, end, "lowlevel");
foreach(var wp; rt){
print(wp.wp_name); # print the waypoints in the computed route
}
}}

=== airway() ===

{{Nasal doc
|syntax = airway(ident [, pos]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=2644|t=Source}}
|text = {{see also|Nasal Flightplan}}
This function returns a ghost containing an airway of a specified id.
|param1 = ident
|param1text = Identifier of airway
|param2 = pos
|param1text = a Positioned ghost (leg, navaid, airport) and so on, passed to the search function.
}}

=== assert() ===
{{Nasal doc
|syntax = assert(condition[, message]);
|source = {{fgdata file|Nasal/globals.nas|t=Source}}
|version = 3.2
|commit = {{fgdata commit|8b16a7|t=commit}}
|text = Returns either true if the condition evaluates as true, or aborts with a {{func link|die()}} call, which can be customised.
|param1 = condition
|param1text = Condition to evaluate.
|param2 = message
|param2text = Optional message that will be used in any {{func link|die()}} call. Defaults to "assertion failed!"
|example1 = var a = 1;
var b = 2;
print(assert(a < b)); # prints "1" (true)
|example2 = var a = 1;
var b = 2;
assert(a > b, 'a is not greater than b'); # aborts with a custom error message
}}

=== carttogeod() ===
{{Nasal doc
|syntax = carttogeod(x, y, z);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=945|t=Source}}
|text = Converts {{wikipedia|ECEF|Earth-centered, Earth-fixed}} coordinates (x, y and z) to {{wikipedia|geodetic coordinates}} (latitude, longitude, and altitude). A vector is returned containing latitude and longitude, both in degrees, and altitude, which is returned in metres above the equatorial radius of Earth as defined by the {{wikipedia|WGS 84}} (6,378,137 metres).<ref>{{simgear file|simgear/math/sg_geodesy.hxx|l=43}}</ref>
|param1 = x
|param1text = Mandatory x-axis value, in metres.
|param2 = y
|param2text = Mandatory y-axis value, in metres.
|param3 = z
|param3text = Mandatory z-axis value, in metres.
|example1 = var (lat, lon, alt) = carttogeod(6378137, 0, 0); # point is the intersection of the prime meridian and equator.
print("Latitude: ", lat); # prints lat, lon and alt, which are all zero, see above
print("Longitude: ", lon);
print("Altitude: ", alt);
}}

=== cmdarg() ===
{{Nasal doc
|private = _cmdarg()
|syntax = cmdarg();
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=513|t=Part 1}} {{!}} {{fgdata file|Nasal/globals.nas|t=Part 2}}
|text = <code>cmdarg()</code> returns the property root of certain types of XML files. These could be nodes in the [[Property Tree]], or temporary and/or non-public nodes outside the Property tree.
It is used by Nasal scripts embedded in XML files. It returns a <code>props.Node</code> object (see {{fgdata file|Nasal/props.nas}}), and you can use all of its methods on the returned value. <code>cmdarg()</code> should only be used in four types/places of XML files:
* Bindings: This is needed so that the value of a joystick's axis can be accessed internally.
* Dialogs: This will return the root of the dialog in the Property Tree. This is useful for dialogs that are created/modified procedurally (e.g. for populating/changing widgets while loading the dialog).
* Embedded Canvases: The Nasal code behind [[Canvas]] windows [[Howto:Adding a canvas to a GUI dialog|embedded in PUI dialogs]] can use it to accessing the root directory of their Canvas.
* Animation XML files: If the animation XML file is used in an AI/MP model, <code>cmdarg()</code> will return the root of the AI model in the <code>/ai/models/</code> directory. Examples: <code>/ai/models/aircraft[3]/</code>, <code>/ai/models/multiplayer[1]/</code>

You should not use <code>cmdarg()</code> in places other than those stated above. Although it won't cause an error, it will return the value of the last legitimate <code>cmdarg()</code> call.

Also, you should not delay <code>cmdarg()</code> using {{func link|maketimer()}}, {{func link|settimer()}} or {{func link|setlistener()}}, because it will return an unrelated property.
|example1 = fgcommand("dialog-show", {"dialog-name": "cmdarg-demo"});
|example1text = <br>This example demonstrates the usage of <code>cmdarg()</code> in a binding. Save the below XML snippet as <tt>[[$FG_ROOT]]/gui/dialogs/cmdarg-demo.xml</tt>. Then run the Nasal snippet below in your [[Nasal Console]]. Upon clicking {{button|Close}}, a message will be printed sowing the root of the binding in the Property Tree.
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>

<PropertyList>

<name>cmdarg-demo</name>
<layout>vbox</layout>

<text>
<label>Click "Close" to activate the demonstration (a message in the console).</label>
</text>

<button>
<legend>Close</legend>
<binding>
<command>nasal</command>
<script>print("Button binding root: '" ~ cmdarg().getPath() ~ "'");</script>
</binding>
<binding>
<command>dialog-close</command>
</binding>
</button>

</PropertyList>
</syntaxhighlight>
|example2text = This example demonstrates the usage of <code>cmdarg()</code> in Nasal code within dialogs. Open <tt>[[$FG_ROOT]]/gui/dialogs/cmdarg-demo.xml</tt> from the previous example, copy & paste the code below, and save it. Then run the same Nasal snippet as the previous example in your Nasal Console. If you click {{button|Click me!}}, the button's label will change to "I've been changed!"
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>

<PropertyList>

<name>cmdarg-demo</name>
<layout>vbox</layout>

<text>
<label>Click "Click me!" to activate the demonstration (the button's label will change).</label>
</text>

<button>
<legend>Click me!</legend>
<binding>
<command>nasal</command>
<script>change_label();</script>
</binding>
</button>

<button>
<legend>Close</legend>
<binding>
<command>dialog-close</command>
</binding>
</button>

<nasal>
<open><![CDATA[
var dlg_root = cmdarg();
var dlg_name = {"dialog-name": "cmdarg-demo"};
var change_label = func {
dlg_root.getNode("button[0]/legend").setValue("I've been changed!");
fgcommand("dialog-close", dlg_name);
fgcommand("dialog-show", dlg_name);
}
]]></open>
</nasal>

</PropertyList>
</syntaxhighlight>
|example3text = For an example of <code>cmdarg()</code> used with Canvas, please see [[Howto:Adding a canvas to a GUI dialog#FGPlot|Howto:Adding a canvas to a GUI dialog]].
}}

=== courseAndDistance() ===
{{Nasal doc
|syntax = courseAndDistance(to);
courseAndDistance(from, to);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1668|t=Source}}
|text = Returns a vector containing the course from one point to another and the distance between them in nautical miles. The course is the initial bearing (see [http://www.movable-type.co.uk/scripts/latlong.html#bearing here]), and is in the range 0–360. Both arguments can be one of:
:* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, <code>taxiway</code>, <code>fix</code>, or <code>waypoint</code> ghost type
:* A hash with ''lat'' and ''lon'' members
:* A geo.Coord object with geodetic coordinates (cartesian coordinates will not be accepted)
|param1 = from
|param1text = Optional parameter defining the from where the function should calculate its results. If the function is given one argument ('''to'''), the aircraft's current position will be used. As well as the argument types as defined above, this argument can be two numbers separated with a comma, as if the function is taking three arguments. See example 5 below.
|param2 = to
|param2text = Like the first parameter, but defines the second point.
|example1text = This example demonstrates the usage of the function with the <code>airport</code> ghost type.
|example1 = var from = airportinfo("KSFO");
var to = airportinfo("KSQL");
var (course, dist) = courseAndDistance(from, to);
print(course); # prints course from KSFO to KSQL
print(dist); # prints distance in nm from KSFO to KSQL
|example2text = This example demonstrates the usage of the function with hashes containing ''lat'' and ''lon''.
|example2 = var from = {lat: 0, lon: 0};
var to = {lat: 1, lon: 1};
var (course, dist) = courseAndDistance(from, to);
print(course);
print(dist);
|example3text = This example demonstrates usage of a geo.Coord object.
|example3 = var from = geo.Coord.new().set_latlon(0, 0);
var to = geo.Coord.new().set_latlon(1, 1);
var (course, dist) = courseAndDistance(from, to);
print(course);
print(dist);
|example4text = This example demonstrates usage of differing parameter types.
|example4 = var from = airportinfo("KSFO");
var to = geo.Coord.new().set_latlon(0, 0);
var (course, dist) = courseAndDistance(from, to);
print(course);
print(dist);
|example5text = The same as above, but the other way round.
|example5 = var to = {lat: 1, lon: 1};
var (course, dist) = courseAndDistance(0, 0, to);
print(course);
print(dist);
|example6text = Usage of just one parameter.
|example6 = var dest = airportinfo("KSQL");
var (course, dist) = courseAndDistance(dest);
print("Turn to heading ", math.round(course), ". You have ", sprintf("%.2f", dist), " nm to go");
}}

=== createFlightplan() ===
{{Nasal doc
|syntax = createFlightplan(path);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=2331|t=Source}}
|text = Creates an empty flightplan object. It accepts one argument, ''path'' passed an absolute path to a .fgfp / .gpx file, it will populate the flightplan with waypoints from the file.
|param1 = path
|param1text = Optional parameter defining the file from which a flightplan will be populated.
|example1 =
var path = getprop("/sim/fg-home") ~ "/Export/test.fgfp";
var flightplan = createFlightplan(path);
debug.dump(flightplan);
}}

=== createDiscontinuity() ===
{{Nasal doc
|syntax = createDiscontinuity();
|text = Returns a <code>waypoint</code> ghost object. A route discontinuity is inserted by an {{abbr|FMS|Flight Management System}} when it is unsure how to connect two waypoints.
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=2045|t=Source}}
|version = 2016.1
|commit = {{flightgear commit|caead6|t=commit}}
}}
=== createViaTo() ===
{{Nasal doc
|syntax = createViaTo(airway, waypoint);
|text = Returns a <code>waypoint</code> ghost object. It represents a route "via '''airway''' to '''waypoint'''".
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=2009|t=Source}}
|version = 2016.1
|commit = {{flightgear commit|caead6|t=commit}}
|param1 = airway
|param1text = The name of an airway.
|param2 = waypoint
|param2text = Must be in the airway and one of:
* The name of a waypoint.
* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, or <code>fix</code> ghost object.
}}
=== createWP() ===
{{Nasal doc
|syntax = createWP(pos, name[, flag]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1964|t=Source}}
|text = Creates a new waypoint ghost object.
|param1 = pos
|param1text = Dictates the position of the new waypoint. It can be one of the following:
:* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, <code>taxiway</code>, <code>fix</code>, or <code>waypoint</code> ghost type
:* A hash with ''lat'' and ''lon'' members
:* A geo.Coord object
:* Two numbers separated by a comma, as if the function is taking three arguments. See example 4 below.
|param2 = name
|param2text = String that will become the name of the new waypoint.
|param3 = flag
|param3text = Optional string that will tell FlightGear what type of waypoint it is. Must be one of "sid," "star," "approach," "missed," or "pseudo."
|example1text = Creates a waypoint directly in front and 1 km away and appends it to the flight plan.
|example1 = var pos = geo.aircraft_position().apply_course_distance(getprop("/orientation/heading-deg"), 1000);
var wp = createWP(pos, "NEWWP");
var fp = flightplan();
fp.appendWP(wp);
|example2 = var pos = geo.aircraft_position().apply_course_distance(getprop("/orientation/heading-deg"), 1000);
var wp = createWP({lat: pos.lat(), lon: pos.lon()}, "NEWWP");
var fp = flightplan();
fp.appendWP(wp);
|example3 = var apt = airportinfo();
var wp = createWP(apt, "NEWWP");
var fp = flightplan();
fp.appendWP(wp);
|example4 = var pos = geo.aircraft_position().apply_course_distance(getprop("/orientation/heading-deg"), 1000);
var wp = createWP(pos.lat(), pos.lon(), "NEWWP");
var fp = flightplan();
fp.appendWP(wp);
|example5text = Creates a new waypoint and adds it to the flight plan. Waypoints of the type "pseudo" are then removed from the flight plan, including the new waypoint. The {{func link|print()}} statements show this.
|example5 = var pos = geo.aircraft_position().apply_course_distance(getprop("/orientation/heading-deg"), 1000);
var wp = createWP(pos, "NEWWP", "pseudo");
var fp = flightplan();
fp.appendWP(wp);
print(fp.getPlanSize());
fp.clearWPType("pseudo");
print(fp.getPlanSize());
}}

=== createWPFrom() ===
{{Nasal doc
|syntax = createWPFrom(object[, flag]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1989|t=Source}}
|text = Creates a new waypoint object from another object.
|param1 = object
|param1text = A ghost object. Must be a ghost type that is one of "airport," "navaid," "runway," or "fix."
|param2 = flag
|param2text = Optional string that will tell FlightGear what type of waypoint it is. Must be one of "sid," "star," "approach," "missed," or "pseudo."
|example1text = Creates a new waypoint and appends it to the flight plan.
|example1 = var apt = airportinfo("KSFO");
var wp = createWPFrom(apt);
var fp = flightplan();
fp.appendWP(wp);
|example2text = Creates a new waypoint and appends it to the flight plan. This way point is then removed; the {{func link|print()}} statements prove this.
|example2 = var apt = airportinfo("KSFO");
var wp = createWPFrom(apt, "pseudo");
print(wp.wp_name);
var fp = flightplan();
fp.appendWP(wp);
print(fp.getPlanSize());
fp.clearWPType("pseudo");
print(fp.getPlanSize());
}}

=== defined() ===
{{Nasal doc
|syntax = defined(symbol);
|source = {{fgdata file|Nasal/globals.nas|t=Source}}
|text = Returns 1 (true) or 0 (false) depending on whether a variable exists.
|param1 = symbol
|param1text = A string that will be what the function searches for.
|example1 = var number = 12;
var check_exist = func {
print("Variable 'number' ", defined("number") == 1 ? "exists" : "does not exist"); # 'number' does exist
print("Variable 'number2' ", defined("number2") == 1 ? "exists" : "does not exist"); # 'number2' does not exist
}
check_exist();
}}

=== directory() ===
{{Nasal doc
|syntax = directory(path);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=572|t=Source}}
|text = Returns a vector containing a list of the folders and files in a given file path or <code>'''nil'''</code> if the path doesn't exist. Hidden folders and files are not added to the vector.
{{inote|The first two elements of the vector will be <code>'.'</code> and <code>'..'</code>. These are for navigating back up the file tree, but have no use in Nasal. They can be safely removed from the vector.}}
|param1 = path
|param1text = Absolute file path.
|example1text = Gets the folders and files in [[$FG_ROOT]], and then removes the extra first two elements (see note above).
|example1 = var dir = directory(getprop("/sim/fg-root")); # get directory
dir = subvec(dir, 2); # strips off the first two elements
debug.dump(dir); # dump the vector
}}

=== fgcommand() ===
{{Nasal doc
|syntax = fgcommand(cmd[, args]);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=456|t=Part 1}} {{!}} {{fgdata file|Nasal/globals.nas|t=Part 2}}
|text = Runs an fgcommand. See also {{readme file|commands}} and [[Bindings]] for more information. See {{flightgear file|src/Main/fg_commands.cxx|l=1425}} for the full list of fgcommands. Note that fgcommands generated by {{func link|addcommand()}} can also be run using this function. Also, the full list of fgcommands depends on the version of FlightGear you have. Returns 1 (true) if the fgcommand succeeded or 0 (false) if it failed.
|param1 = cmd
|param1text = String that is the name of the command that is to be run.
|param2 = args
|param2text = If the fgcommand takes arguments, they are inputted using this argument. Can either be a <code>props.Node</code> object, or a hash (see examples below).
|example1 = fgcommand("null"); # does nothing
|example2 = var args = props.Node.new({'script': 'print("Running fgcommand");'});
if (fgcommand("nasal", args)) { # prints "Running fgcommand" and then one of these print statements
print("Fgcommand succeeded");
} else {
print("Fgcommand encountered a problem");
}
|example3 = var args = { 'dialog-name': 'about' };
fgcommand("dialog-show", args); # shows the 'about' dialog
}}

=== findAirportsByICAO() ===
{{Nasal doc
|syntax = findAirportsByICAO(search[, type]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1096|t=Source}}
|text = Returns a vector containing <code>airport</code> ghost objects which are (by default) airports whose ICAO code matches the search string. The results are sorted by range from closest to furthest.
|param1 = search
|param1text = Search string for the function. Can either be a partial or a full ICAO code.
:{{icaution|The more matches there are for the given code, the longer the function will take. Passing just one character (e.g., "K"), might make FlightGear hang for a certain amount of time.}}
|param2 = type
|param2text = This will narrow the search to airports of a certain type. By default, only airports are searched for. May be one of "airport," "heliport," or "seaport."
|example1 = var apts = findAirportsByICAO("KSF"); # finds all airports matching "KSF"
foreach(var apt; apts){
print(apt.name, " (", apt.id, ")"); # prints them
}
|example2 = var apts = findAirportsByICAO("SP0", "seaport"); # finds all seaplane bases matching "SP0"
foreach(var apt; apts){
print(apt.name, " (", apt.id, ")"); # prints them
}
|example3 = var apt = findAirportsByICAO("XBET"); # one way to check if an airport does exist"
if (size(apt) == 0) {
print("Airport does not exist"); # this one will be printed
} else {
print("Airport does exist");
}
}}

=== findAirportsWithinRange() ===
{{Nasal doc
|syntax = findAirportsWithinRange([pos, ]range[, type]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1066|t=Source}}
|text = Returns a vector of <code>airport</code> ghost object which are (by default) airports that are within a given range of a given position, or the aircraft's current position. The results are sorted by range from closest to furthest.
|param1 = pos
|param1text = Optional position to search around. If not given, the aircraft's current position will be used. Can be one of:
:* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, <code>taxiway</code>, <code>fix</code>, or <code>waypoint</code> ghost type
:* A hash with ''lat'' and ''lon'' members
:* A geo.Coord object
:* Two numbers separated by a comma, as if the function is taking three arguments. Example: <code>findAirportsWithinRange(lat, lon, range, type);</code>.
|param2 = range
|param2text = Mandatory number giving the range in nautical miles within which to search for airports/heliports/seaplane bases.only airports are searched for.
|param3 = type
|param3text = This will narrow the search to airports of a certain type. By default, only airports are searched for. May be one of "airport," "heliport," or "seaport."
|example1text = Searches for airports within 10 nm of [[KSFO]].
|example1 = var pos = airportinfo("KSFO");
var apts = findAirportsWithinRange(pos, 10);
foreach(var apt; apts){
print(apt.name, " (", apt.id, ")");
}
|example2text = Searches for seaplane bases within 15 nm of [[KSFO]].
|example2 = var pos = airportinfo("KSFO");
var apts = findAirportsWithinRange(pos, 15, "seaport");
foreach(var apt; apts){
print(apt.name, " (", apt.id, ")");
}
|example3text = Searches for airports within 10 nm of your current position.
|example3 = var apts = findAirportsWithinRange(10);
foreach(var apt; apts){
print(apt.name, " (", apt.id, ")");
}
}}

=== findFixesByID() ===
{{Nasal doc
|syntax = findFixesByID([pos, ]id);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1627|t=Source}}
|text = Returns a vector containing <code>fix</code> ghost objects matching a given ID, sorted by range from a certain position.
{{inote|Fixes are (usually) also known as waypoints.}}
|param1 = pos
|param1text = Optional position to search around. If not given, the aircraft's current position will be used. Can be one of:
:* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, <code>taxiway</code>, <code>fix</code>, or <code>waypoint</code> ghost type
:* A hash with ''lat'' and ''lon'' members
:* A geo.Coord object
:* Two numbers separated by a comma, as if the function is taking three arguments. Example: <code>findFixesByID(lat, lon, id);</code>.
|param2 = id
|param2text = Full or partial ID of the fix to search for.
:{{inote|1=Inputting a partial ID does not work correctly (see [http://forum.flightgear.org/viewtopic.php?f=30&t=28129 here]). It is best to just input a full ID.}}
|example1 = var fixes = findFixesByID("POGIC");
foreach(var fix; fixes){
print(fix.id, " - lat: ", fix.lat, " {{!}} lon: ", fix.lon); # prints information about POGIC
}
|example2 = var fix = findFixesByID("ZUNAP");
fix = fix[0];
var (course, dist) = courseAndDistance(fix);
print("Turn to heading ", math.round(course), ". You have ", sprintf("%.2f", dist), " nm to go to reach ", fixes[0].id);
}}

=== findNavaidByFrequency() ===
{{Nasal doc
|syntax = findNavaidByFrequency([pos, ]freq[, type]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1547|t=Source}}
|text = Returns a <code>navaid</code> ghost object for a navaid matching a given frequency. If there is more than one navaid with that frequency, the nearest station is returned.
|param1 = pos
|param1text = Optional position to search around. If not given, the aircraft's current position will be used. Can be one of:
:* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, <code>taxiway</code>, <code>fix</code>, or <code>waypoint</code> ghost type
:* A hash with ''lat'' and ''lon'' members
:* A geo.Coord object
:* Two numbers separated by a comma, as if the function is taking three arguments. Example: <code>findNavaidByFrequency(lat, lon, freq, type);</code>.
|param2 = freq
|param2text = Frequency, in megahertz, of the navaid to search for.
|param3 = type
|param3text = This will narrow the search to navaids of a certain type. Defaults to "all." For the full list of accepted type arguments, see {{flightgear file|src/Navaids/positioned.cxx|l=127}}.
|example1 = var navaid = findNavaidByFrequency(11.17);
print("ID: ", navaid.id); # prints info about the navaid
print("Name: ", navaid.name);
print("Latitude: ", navaid.lat);
print("Longitude: ", navaid.lon);
print("Elevation (AMSL): ", navaid.elevation, " m");
print("Type: ", navaid.type);
print("Frequency: ", sprintf("%.3f", navaid.frequency / 1000), " Mhz");
print("Range: ", navaid.range_nm, " nm");
if(navaid.course) print("Course: ", navaid.course);
}}

=== findNavaidsByFrequency() ===
{{Nasal doc
|syntax = findNavaidsByFrequency([pos, ]freq[, type]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1572|t=Source}}
|text = Returns a vector conatining <code>navaid</code> ghost objects for navaids that match a given frequency, sorted from nearest to furthest.
|param1 = pos
|param1text = Optional position to search around. If not given, the aircraft's current position will be used. Can be one of:
:* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, <code>taxiway</code>, <code>fix</code>, or <code>waypoint</code> ghost type
:* A hash with ''lat'' and ''lon'' members
:* A geo.Coord object
:* Two numbers separated by a comma, as if the function is taking three arguments. Example: <code>findNavaidsByFrequency(lat, lon, freq, type);</code>.
|param2 = freq
|param2text = Frequency, in megahertz, of the navaid to search for.
|param3 = type
|param3text = This will narrow the search to navaids of a certain type. Defaults to "all." For the full list of accepted type arguments, see {{flightgear file|src/Navaids/positioned.cxx|l=127}}.
|example1 = var navaids = findNavaidsByFrequency(10.955);
foreach(var navaid; navaids){
print("--");
print("ID: ", navaid.id); # prints info about the navaid
print("Name: ", navaid.name);
print("Latitude: ", navaid.lat);
print("Longitude: ", navaid.lon);
print("Elevation (AMSL): ", navaid.elevation, " m");
print("Type: ", navaid.type);
print("Frequency: ", sprintf("%.3f", navaid.frequency / 1000), " Mhz");
print("Range: ", navaid.range_nm, " nm");
if(navaid.course) print("Course: ", navaid.course);
print("--");
}
}}

=== findNavaidsByID() ===
{{Nasal doc
|syntax = findNavaidsByID([pos, ]id[, type]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1600|t=Source}}
|text = Returns a vector containing <code>navaid</code> ghost objects matching a given ID, sorted by range from a certain position.
|param1 = pos
|param1text = Optional position to search around. If not given, the aircraft's current position will be used. Can be one of:
:* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, <code>taxiway</code>, <code>fix</code>, or <code>waypoint</code> ghost type
:* A hash with ''lat'' and ''lon'' members
:* A geo.Coord object
:* Two numbers separated by a comma, as if the function is taking three arguments. Example: <code>findNavaidsByID(lat, lon, id, type);</code>.
|param2 = id
|param2text = Full or partial ID of the fix to search for.
:{{inote|1=Inputting a partial ID does not work correctly (see [http://forum.flightgear.org/viewtopic.php?f=30&t=28129 here]). It is best to just input a full ID.}}
|param3 = type
|param3text = This will narrow the search to navaids of a certain type. Defaults to "all." For the full list of accepted type arguments, see {{flightgear file|src/Navaids/positioned.cxx|l=127}}.
|example1 = var navaid = findNavaidsByID("MXW");
navaid = navaid[0];
print("ID: ", navaid.id); # prints info about 'MXW' (a VOR station)
print("Name: ", navaid.name);
print("Latitude: ", navaid.lat);
print("Longitude: ", navaid.lon);
print("Elevation (AMSL): ", navaid.elevation, " m");
print("Type: ", navaid.type);
print("Frequency: ", sprintf("%.3f", navaid.frequency / 1000), " Mhz");
print("Range: ", navaid.range_nm, " nm");
}}

=== findNavaidsWithinRange() ===
{{Nasal doc
|syntax = findNavaidsWithinRange([pos, ]range[, type]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1518|t=Source}}
|text = Returns a vector of <code>navaid</code> ghost objects which are within a given range of a given position (by default the aircraft's current position). The results are sorted from closest to furthest.
|param1 = pos
|param1text = Optional position to search around. If not given, the aircraft's current position will be used. Can be one of:
:* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, <code>taxiway</code>, <code>fix</code>, or <code>waypoint</code> ghost type
:* A hash with ''lat'' and ''lon'' members
:* A geo.Coord object
:* Two numbers separated by a comma, as if the function is taking three arguments. Example: <code>findNavaidsWithinRange(lat, lon, range, type);</code>.
|param2 = range
|param2text = Mandatory number giving the range in nautical miles within which to search for navaids. Defaults to "all." For the full list of accepted type arguments, see {{flightgear file|src/Navaids/positioned.cxx|l=127}}.
|param3 = type
|param3text = This will narrow the search to navaids of a certain type.
|example1text = Searches for navaids within 10 nm of [[KSFO]].
|example1 = var pos = airportinfo("KSFO");
var navs = findNavaidsWithinRange(pos, 10);
foreach(var nav; navs){
print(nav.name, " (ID: ", nav.id, ")");
}
|example2text = Searches for navaids within 10 nm of your current position.
|example2 = var navs = findNavaidsWithinRange(10);
foreach(var nav; navs){
print(nav.name, " (ID: ", nav.id, ")");
}
}}

=== finddata() ===
{{Nasal doc
|syntax = finddata(path);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=603|t=Source}}
|text = Takes a relative path and tries to return an absolute one. It works by appending the relative path to some paths and testing to see if they exist. As of FlightGear v3.7, these paths are the TerraSync directory (tested first) and [[$FG_ROOT]].
|param1 = path
|param1text = A relative path as a string.
|example1 = var path = finddata("Aircraft/Generic");
print(path); # prints the absolute path to $FG_ROOT/Aircraft/Generic
|example2 = var path = finddata("Airports");
print(path); # prints the absolute path to <TerraSync dir>/Airports
|example3 = var path = finddata("preferences.xml");
print(path); # prints the absolute path to $FG_ROOT/preferences.xml
}}

=== flightplan() ===
{{Nasal doc
|syntax = flightplan([path]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1738|t=Source}}
|text = {{see also|Nasal Flightplan}}
Returns a flight plan object, either one for the current flight plan, or one loaded from a given path.
|param1 = path
|param1text = Optional path to flight plan XML file.
|example1text = Gets the active flight plan and gets the ID of the current waypoint. Note that this example requires a flight plan to be set in the [[Route Manager]] first.
|example1 = var fp = flightplan();
print(fp.getWP(fp.current).id);
|example2text = Creates a new flight plan from an XML file and prints the IDs of the waypoints. Note that this example requires a flight plan to have been created and saved as <tt>''[[$FG_HOME]]/fp-demo.xml''</tt>.
|example2 = var path = getprop('/sim/fg-home') ~ '/fp-demo.xml';
var fp = flightplan(path);
for(var i = 0; i < fp.getPlanSize(); i += 1){
print(fp.getWP(i).id);
}
}}

=== geodinfo() ===
{{Nasal doc
|syntax = geodinfo(lat, lon[, max_alt]);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=981|t=Source}}
|text = Returns a vector containing two entries or <code>'''nil'''</code> if no information could be obtained because the terrain tile wasn't loaded. The first entry in the vector is the elevation (in meters) for the given point, and the second is a hash with information about the assigned material (as defined in <tt>''[[$FG_ROOT]]/Materials''</tt>), or <code>'''nil'''</code> if there was no material information available (for example, because there is an untextured building at that location). The structure of the hash is as follows (see also {{readme file|materials}}):
* '''light_coverage:''' The coverage of a single point of light in m<sup>2</sup>.
* '''bumpiness:''' Normalized bumpiness factor for the material.
* '''load_resistance:''' The amount of pressure in N/m<sup>2</sup> the material can withstand without deformation.
* '''solid:''' 1 (true) or false (0) depending on whether the material is solid or not.
* '''names:''' Vector of scenery types (usually generated by [[TerraGear]]) that will use this material.
* '''friction_factor:''' Normalized friction factor of the material.
* '''rolling_friction:''' The rolling friction coefficient of the material.

Note that this function is a ''very'' CPU-intensive operation, particularly in FlightGear v2.4 and earlier. It is advised to use this function as little as possible.
|param1 = lat
|param1text = Latitude, inputted as a number.
|param2 = lon
|param2text = Longitude, inputted as a number.
|param3 = max_alt
|param3text = The altitude, in metres, from which the function will begin searching for the height of the terrain. Defaults to 10,000 metres. If the terrain is higher than this argument specifies, <code>'''nil'''</code> will be returned.
|example1text = Dumps information about ground underneath the aircraft.
|example1 = var pos = geo.aircraft_position();
var info = geodinfo(pos.lat(), pos.lon());
debug.dump(info);
|example2text = Prints whether the ground underneath the aircraft is solid or is water.
|example2 = var pos = geo.aircraft_position();
var info = geodinfo(pos.lat(), pos.lon());
if (info != nil and info[1] != nil) {
print("The ground underneath the aircraft is ", info[1].solid == 1 ? "solid." : "water.");
}
}}

=== geodtocart() ===
{{Nasal doc
|syntax = geodtocart(lat, lon, alt);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=962|t=Source}}
|text = Converts {{wikipedia|geodetic coordinates}} (latitude, longitude, and altitude) to {{wikipedia|ECEF|Earth-centered, Earth-fixed}} coordinates (x, y and z). A vector is returned containing x, y, and z in metres. The equatorial radius of earth used is that defined by the {{wikipedia|WGS 84}} (6,378,137 metres). All argument are mandatory.
|param1 = lat
|param1text = Latitude, in degrees.
|param2 = lon
|param2text = Longitude, in degrees.
|param3 = alt
|param3text = Altitude, in metres.
|example1 = var (x, y, z) = geodtocart(0, 0, 0); # point is the intersection of the prime meridian and equator.
print("x: ", x); # prints "x: 6378137"
print("y: ", y); # prints "y: 0"
print("z: ", z); # prints "y: 0"
}}

=== get_cart_ground_intersection() ===
Introduced in 2017.2.1, see [[Terrain Detection]].

=== getprop() ===
{{Nasal doc
|syntax = getprop(path[, path[, ...]]);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=345|t=Source}}
|text = Returns the value of a node in the [[Property Tree]] or <code>'''nil'''</code> if the node does not exist or the value is not a number (NaN).
|param1 = path
|param1text = There needs to be at least one argument, but there is no limit to the maximum amount of arguments that can be given. The arguments will be concatenated together to form a property tree path. The arguments must be strings, but in FlightGear v3.2 onwards, there is also support (added by {{flightgear commit|34ed79}}) for numeric arguments as indices. See example 2 below.
|example1 = print("You have FlightGear v", getprop("/sim/version/flightgear")); # prints FlightGear version
|example2text = Note that the example below will only work in FlightGear 3.2 and above.
|example2 = for(var i = 0; i < 8; i += 1){
print("View #", i + 1, " is named ", getprop("/sim/view", i, "name"));
}
|example3text = Same as above, but is supported by all versions of FlightGear.
|example3 = for(var i = 0; i < 8; i += 1){
print("View #", i + 1, " is named ", getprop("/sim/view[" ~ i ~ "]/name"));
}
}}
==== See also ====
{{note| If you have to read/write the same property multiple times (e.g. in an update loop), it is more efficient to use a node object:
To get a Node rather than its value, use <code>props.globals.getNode()</code> - see [[Nasal_library/props]]. }}

=== greatCircleMove() ===
{{Nasal doc
|syntax = greatCircleMove([pos, ]course, dist);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1681|t=Source}}
|text = Calculates a new set of geodetic coordinates using inputs of course and distance, either from the aircraft's current position (by default) or from another set of coordinates. Returns a hash containing two members, ''lat'' and ''lon'' (latitude and longitude respectively).
|param1 = pos
|param1text = Optional position to calculate from. If not given, the aircraft's current position will be used. Can be one of:
:* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, <code>taxiway</code>, <code>fix</code>, or <code>waypoint</code> ghost object.
:* A hash with ''lat'' and ''lon'' members
:* A <code>geo.Coord</code> object
:* A lat/lon pair, that is, a pair of numbers (latitude followed by longitude) separated by a comma: <code>greatCircleMove(lat,lon, ...)</code>.
|param2 = course
|param2text = Course to new set of coordinates, in degrees (in the range 0–360).
|param3 = dist
|param3text = Distance in nautical miles to the new set of coordinates.
|example1 = var pos = greatCircleMove(0,0, 0, 1);
debug.dump(pos); # print hash with coordinates
|example2 = var fix = findFixesByID("POGIC");
fix = fix[0];
var pos = greatCircleMove(fix, 45, 10);
debug.dump(pos); # print hash with coordinates
}}

=== interpolate() ===
{{Nasal doc
|private = _interpolate()
|syntax = interpolate(prop, value1, time1[, value2, time2[, ...]]);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=522|t=Part 1}} {{!}} {{fgdata file|Nasal/globals.nas|t=Part 2}}
|text = Linearly interpolates a node in the property tree to a given value in a specified time. The value/time pairs will be run one after the other in the order that they are passed to the function. Note that the interpolation will continue even when the simulation is paused.
|param1 = prop
|param1text = String or <code>props.Node</code> object that indicates a node in the property tree to be used.
|param2 = value''n''
|param2text = Target value to change the property to in the set amount of time. This should be a number.
|param3 = time''n''
|param3text = Time in seconds, that will be taken for the interpolation.
|example1text = Paste the code below into the Nasal Console and execute. Then, open the Property Browser and look for the property. Finally, run the code again, and watch the value of the property change.
|example1 = setprop("/test", 0); # (re-)set property
interpolate("/test",
50, 5, # interpolate to 50 in 5 seconds
10, 2, # interpolate to 10 in 2 seconds
0, 5); # interpolate to 0 in 5 seconds
|example2 = # Apply the left brake at 20% per second
var prop = "controls/gear/brake-left";
var dist = 1 - getprop(prop);
if (dist == 1) {
interpolate(prop, 1, dist / 0.2);
}
}}

=== isa() ===
{{Nasal doc
|syntax = isa(object, class);
|source = {{fgdata file|Nasal/globals.nas|t=Source}}
|text = Checks if an object is an instance of, or inherits from, a second object (or class), returning 1 (true) if it is and 0 (false) if otherwise.
|param1 = object
|param1text = Object to check.
|param2 = class
|param2text = Class/object to check that '''object''' inherits from or is an instance of.
|example1 = var coord = geo.Coord.new();
if(isa(coord, geo.Coord)){
print("Variable 'coord' is an instance of class 'geo.Coord'"); # this one will be printed
} else {
print("Variable 'coord' is not an instance of class 'geo.Coord'");
}
|example2 = var coord = geo.Coord.new();
if(isa(coord, props.Node)){
print("Variable 'coord' is an instance of class 'props.Node'");
} else {
print("Variable 'coord' is not an instance of class 'props.Node'"); # this one will be printed
}
|example3text = The example below demonstrates checking of inheritance.
|example3 = var Const = {
constant: 2,
getConst: func {
return me.constant;
}
};

var Add = {
new: func {
return { parents: [Add, Const] };
},

addToConst: func(a){
return a * me.getConst();
}
};

var m = Add.new();
print(m.addToConst(4));

if(isa(m, Add)) print("Variable 'm' is an instance of class 'Add'"); # will be printed
if(isa(m, Const)) print("Variable 'm' is an instance of class 'Const'"); # will also be printed
}}

=== logprint() ===
{{Nasal doc
|syntax = logprint(priority[, msg[, msg[, ...]]]);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=431|t=Source}}
|text = Concatenates a message and logs it with a given priority level. Unlike {{func link|print()}} and {{func link|printlog()}}, message outputted by this function will be logged in your <code>[[Commonly used debugging tools#fgfs.log|fgfs.log]]</code> file as coming from the Nasal file itself rather than from {{flightgear file|src/Scripting/NasalSys.cxx}}.
|param1 = priority
|param1text = Number specifying the priority level of the outputted message:
:{{{!}} class="wikitable"
! Number !! Debug type
{{!-}}
{{!}} 1 {{!!}} Bulk
{{!-}}
{{!}} 2 {{!!}} Debug
{{!-}}
{{!}} 3 {{!!}} Info
{{!-}}
{{!}} 4 {{!!}} Warn
{{!-}}
{{!}} 5 {{!!}} Alert
{{!}}}
|param2 = msg
|param2text = The message. There is no limit to the arguments you give give. They will be concatenated together before logging.
|example1 = # logs the value of pi to three decimal places with log level 3
logprint(3, "pi = ", sprintf("%.3f", math.pi));
|example2 = logprint(5, "Alert! This is an important message!");
}}
{{note|
The following constants have been added to the development branch of FlightGear ("next") and will be releases with FG 2020.1 so you won't have to remember the numbers anymore:

LOG_BULK, LOG_WARN, LOG_DEBUG, LOG_INFO, LOG_ALERT, DEV_WARN, DEV_ALERT }}

=== magvar() ===
{{Nasal doc
|syntax = magvar([pos]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1642|t=Source}}
|text = Returns the {{wikipedia|magnetic variation}} at a given set of coordinates. The table below gives the magnetic model used depending on the version of FlightGear.
{{{!}} class="wikitable"
! FlightGear versions !! Model !! Reference date
{{!-}}
{{!}} 3.6 and above {{!!}} {{wikipedia|World Magnetic Model}} (WMM) 2015 {{!!}} 1 January 2015
{{!-}}
{{!}} 0.9.11-pre1 to 3.4 {{!!}} WMM 2005 {{!!}} 1 January 2005
{{!-}}
{{!}} 0.7.3 to 0.9.10 {{!!}} WMM 2000 {{!!}} 1 January 2000
{{!}}}
|param1 = pos
|param1text = Optional position to calculate from. If not given, the aircraft's current position will be used. Can be one of:
:* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, <code>taxiway</code>, <code>fix</code>, or <code>waypoint</code> ghost object.
:* A hash with ''lat'' and ''lon'' members
:* A <code>geo.Coord</code> object
:* A lat/lon pair, that is, a pair of numbers (latitude followed by longitude) separated by a comma: <code>magvar(lat,lon)</code>.
|example1 = print(magvar(0, 0)); # prints the magnetic variation at 0, 0
}}

=== maketimer() ===
{{Nasal doc
|syntax = maketimer(interval[, self], function);
|source = ''Implemented using the {{API Link|flightgear|class|TimerObj}} class.''<br>{{flightgear file|src/Scripting/NasalSys.cxx|l=90|t=Part 1}} {{!}} {{flightgear file|src/Scripting/NasalSys.cxx|l=533|t=Part 2}}
|version = 2.12
|commit = {{flightgear commit|ab939f|t=commit}}
|text = Returns a timer object containing the following methods and members:
* '''start()''': Starts the timer.
* '''stop()''': Stops the timer.
* '''restart(interval)''': Restarts the timer with the given interval.
* '''singleShot''': Bool showing whether the timer is only to be run once, or continuously until told to stop. Can be both set and read from (see examples).
* '''isRunning''': Read-only bool telling whether the timer is currently running.
* '''simulatedTime''': (FG 2017.1+; {{flightgear commit|0af316|t=commit}}) Bool telling whether the timer is using simulated time (which accounts for pause, etc.). Defaults to false (use real time). Can be both read and set. This cannot be changed while the timer is running.
Unlike {{func link|settimer()}}, which it replaces, <code>maketimer()</code> provides more control over the timer. In addition, it can help reduce memory usage.
|param1 = interval
|param1text = Interval in seconds for the timer.
|param2 = self
|param2text = Optional parameter specifying what any <code>'''me'''</code> references in the function being called will refer to.
|param3 = function
|param3text = Function to be called at the given interval.
|example1 = var timer = maketimer(1, func(){
print("Hello, World!"); # print "Hello, World!" once every second (call timer.stop() to stop it)
});
timer.start();
|example2 = var timer = maketimer(1, math, func(){
print(me.math); # 'me' reference is the 'math' namespace
});
timer.singleShot = 1; # timer will only be run once
timer.start();
|example3 = var timer = maketimer(1, func(){
print("Hello, World!"); # print "Hello, World!" once every second (call timer.stop() to stop it)
});
timer.start();
print(timer.isRunning); # prints 1
|example4text = In the example below, "Hello, World!" will be printed after one second the first time, and after two seconds thereafter.
|example4 = var update = func(){
print("Hello, World!");
timer.restart(2); # restarts the timer with a two second interval
}

var timer = maketimer(1, update);
timer.singleShot = 1;
timer.start();
}}

=== maketimestamp() ===
{{Nasal doc
|syntax = maketimestamp()
|source = ''Implemented using the {{API Link|flightgear|class|TimeStampObj}} class.''<br>{{flightgear file|src/Scripting/NasalSys.cxx|l=214|t=Part 1}} {{!}} {{flightgear file|src/Scripting/NasalSys.cxx|l=589|t=Part 2}}
|version = 2019.2
|commit = {{flightgear commit|7db06300|t=commit}}
|text = Returns a time stamp object to allow high resolution timing of Nasal operations. When created the timer will automatically be stamped. The object has the following methods:
* '''stamp()''': Resets the timing operation. Call this first.
* '''elapsedMSec()''': returns number of milliseconds elapsed since stamp() called. Resolution may vary depending on platform but is usually at least millisecond accuracy.
* '''elapsedUSec()''': returns number of microseconds elapsed since stamp() called. Resolution may vary depending on platform but is usually at least millisecond accuracy.
|
|example1text = In the example below the number of milliseconds elapsed will be printed.
|example1 = var timestamp = maketimestamp();
timestamp.stamp();
print(timestamp.elapsedMSec(), "ms elapsed");
print(timestamp.elapsedMSec(), "ms elapsed");
}}

=== md5() ===
{{Nasal doc
|syntax = md5(string);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=758|t=Source}}
|version = 3.2
|commit = {{flightgear commit|cfbf9e|t=commit}}
|text = Returns a the {{wikipedia|MD5}} hash (as a string) of the inputted string.
|param1 = string
|param1text = String the generate the hash of. Mandatory.
|example1text = The below code should output <code>65a8e27d8879283831b664bd8b7f0ad4</code>.
|example1 = print(md5("Hello, World!"));
}}

=== navinfo() ===
{{Nasal doc
|syntax = navinfo(lat, lon, type, id);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1453|t=Source}}
|text = Returns vector <code>navaid</code> ghost objects matching the given '''type''' and '''id''' or <code>'''nil'''</code> on error.
|param1 = lat ''and'' lon
|param1text = If given, the returned navaids will be put into order of ascending distance from the location.
|param2 = type
|param2text = Narrows the search to the given type. Must be one of "any," "fix," "vor," "ndb," "ils," "dme," or "tacan." Defaults to the equivalent of "any."
|param3 = id
|param3text = ID to search for. Note that, although all the parameters are technically optional, this parameter must be given, otherwise an empty vector will be returned.
|example1 = navinfo("vor"); # returns all VORs
|example2 = navinfo("HAM"); # return all navaids whose names start with "HAM"
|example3 = navinfo("vor", "HAM"); # return all VORs whose names start with "HAM"
|example4 = navinfo(34,48,"vor","HAM"); # return all VORs whose names start with "HAM" and sorted by distance relative to 34°, 48°
}}

=== parse_markdown() ===
{{Nasal doc
|syntax = parse_markdown(markdown);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=745|t=Part 1}} {{!}} {{simgear file|simgear/misc/SimpleMarkdown.cxx|t=Part 2}}
|version = 3.2
|text = Parses a string containing {{wikipedia|Markdown}} and returns the result as a string. As of FlightGear 2016.1, it is just a simple parser, and does the following:
* It strips whitespace from the beginning of the string.
* It supports [http://daringfireball.net/projects/markdown/syntax#p paragraphs and line breaks].
* It collapses whitespace.
* It converts unordered [http://daringfireball.net/projects/markdown/syntax#list lists] to use a bullet character (•). Note that the bullet character is implemented in hexadecimal UTF-8 character bytes (<code>E2 80 A2</code>), as so may not work properly when the being displayed in an encoding other than UTF-8.
|param1 = markdown
|param1text = String containing Markdown to be parsed.
|example1text =
Save the below code as <tt>''[[$FG_ROOT]]/gui/dialogs/test.xml''</tt>, then run the Nasal code below it to open the dialog. To change the markdown to be parsed, simply change the code in the highlighted section, save it, and reload the GUI (<tt>Debug > Reload GUI</tt>).
<syntaxhighlight lang="xml" highlight="41-50">
<?xml version="1.0" encoding="UTF-8"?>

<PropertyList>

<name>test</name>
<layout>vbox</layout>

<group>
<layout>hbox</layout>

<empty>
<stretch>true</stretch>
</empty>

<text>
<label>parse_markdown() test dialog</label>
</text>

<empty>
<stretch>true</stretch>
</empty>

<button>
<legend></legend>
<pref-width>16</pref-width>
<pref-height>16</pref-height>
<binding>
<command>dialog-close</command>
</binding>
</button>

</group>

<canvas>
<name>Canvas plot</name>
<stretch>true</stretch>
<pref-width>400</pref-width>
<pref-height>300</pref-height>
<nasal>
<load><![CDATA[
var text = 'Items:
* apples
* oranges
* pears

Some text.
Some more items:
* apples
* oranges
* pears';

var parsed = parse_markdown(text);

var root_canvas = canvas.get(cmdarg());
root_canvas.setColorBackground(255, 255, 255);
var root = root_canvas.createGroup();

var text_dis = root.createChild("text")
.setText(parsed)
.setTranslation(5, 5)
.setFont("LiberationFonts\LiberationSans-Regular.ttf")
.setFontSize(15)
.setColor(0, 0, 0)
.setDrawMode(canvas.Text.TEXT)
.setAlignment("left-top");
]]></load>
</nasal>
</canvas>

</PropertyList>
</syntaxhighlight>
|example1 = fgcommand("dialog-show", {"dialog-name": "test"});
|example2text = The example below parses Markdown and outputs it in a HTML document. The parsed text is placed in <syntaxhighlight lang="xml" inline><pre></pre></syntaxhighlight> tags. To change the Markdown to be parsed, simply edit the variable <tt>markdown</tt> at the top of the code.
|example2 = <nowiki>var markdown = 'Items:
* apples
* oranges
* pears

Some text.
Some more items:
* apples
* oranges
* pears';

var parsed = parse_markdown(markdown);

debug.dump(parsed);

var path = string.normpath(getprop("/sim/fg-home") ~ '/Export/parse_markdown()-test.html');

var file = io.open(path, "w");

var html = "<!DOCTYPE html>\n\n<html>\n\n<head>\n\t<meta charset=\"UTF-8\">\n\t<title>parse_markdown() test generated by Nasal</title>\n</head>\n\n<body>\n\t<pre>" ~ parsed ~ "</pre>\n</body>\n\n</html>";

io.write(file, html);
io.close(file);
print("Done, file ready for viewing (" ~ path ~ ")");</nowiki>
}}

=== parsexml() ===
{{Nasal doc
|syntax = parsexml(path[, start[, end[, data[, pro_ins]]]]);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=710|t=Source}}
|text = This function is an interface into the built-in [http://expat.sourceforge.net/ Expat XML parser]. The absolute path to the file is returned as string, or <code>'''nil'''</code> is returned on error.
|param1 = path
|param1text = Mandatory absolute path to the XML file to be parsed.
|param2 = start
|param2text = Optional callback function that will be called for every starting tag. The function should take two argument: the tag name and a hash containing attributes.
|param3 = end
|param3text = Optional callback function that will be called for every ending tag. The function should take one argument: the tag name.
|param4 = data
|param4text = Optional callback function that will be called for every piece of data within a set of tags. The function should take one argument: the data as a string.
|param5 = pro_ins
|param5text = Optional callback function that will be called for every {{wikipedia|Processing Instruction|processing instruction}}. The function should take two argument: the target and the data string.
|example1text = Save the below XML code in <tt>''[[$FG_HOME]]/Export/demo.xml''</tt>. Then, execute the Nasal code below in the Nasal Console. The XML will be parsed and each bit of the code will be printed.
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>

<?xml-stylesheet type="text/xsl" href="style.xsl"?>

<foo>
<blah type="string"><![CDATA[ <sender>John Smith</sender> ]]></blah>
<blah2 type="string">Orange & lemons</blah2>
</foo>
</syntaxhighlight>
|example1 = var start = func(name, attr){
print("Starting tag: '", name, "'");
foreach(var a; keys(attr)){
print("\twith attribute ", a, '="', attr[a], '"');
}
}

var end = func(name){
print("Ending tag: '", name, "'");
}

var data = func(data){
print("Data = '", data, "'");
}

var pro_instr = func(target, data){
print("Processing instruction: target = '", target, "', data = '", data, "'");
}

parsexml(getprop("/sim/fg-home") ~ '/Export/demo.xml', start, end, data, pro_instr);
}}

=== print() ===
{{Note|As of 07/2020, we are in the process of slowly deprecating and removing Nasal print() (in fgdata) where possible in favor of log [[#logprint()]] which takes a priority level.

This is part of the goal that we achieve zero output at log-level at alert, and everything shown at ‘warn; is really a warning, not just information.<ref>https://sourceforge.net/p/flightgear/mailman/message/37042224/</ref>}}

{{Nasal doc
|syntax = print(data[, data[, ...]]);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=415|t=Source}}
|text = Concatenates its arguments and then prints it to the terminal and the [[Commonly used debugging tools#fgfs.log|log]]. Note that a newline is automatically added.
|param1 = data
|param1text = Data to print. Only strings and numbers can be printed; other data types will not be. There many be any number of arguments; they will just be concatenated together.
|example1 = print("Just", " a ", "test"); # prints "Just a test"
|example2 = print("pi = ", math.pi); # prints "pi = 3.141592..."
}}

=== printf() ===
{{Nasal doc
|syntax = printf(format[, arg[, arg, [...]]]);
|source = {{fgdata file|Nasal/globals.nas|t=Source}}
|text = Creates and prints a formatted string. For a description of its arguments, see {{func link|sprintf()}} (it is, in fact, implemented using <code>sprintf()</code>).
|example1 = printf("In hexadecimal, 100000 = %X", 186A0); # prints "In hexadecimal, 100000 = 186A0"
}}

=== printlog() ===
{{Nasal doc
|syntax = printlog(level, data[, data[, ...]]);
|source = {{fgdata file|Nasal/globals.nas|t=Source}}
|text = Prints the given message with the given log level. If the log level is higher or equal to <code>/sim/logging/priority</code>, it is printed.
|param1 = level
|param1text = Mandatory log level as a string. Must be one of "none," "bulk," "debug," "info," "warn," or "alert." Note that "none" will mean that the message will never be printed.
|param2 = data
|param2text = Data to be printed. Only strings and numbers will be printed; others will not be. There may be any number of arguments; they will just be concatenated together.
|example1 = printlog("alert", "This is an alert"); # message will be printed
|example2 = printlog("info", "Just informing you about something"); # message will be printed only if log level is set to "info" or less
}}

=== rand() ===
{{Nasal doc
|syntax = rand();
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=554|t=Source}}
|text = Returns a random floating point number between 0 (inclusive) and 1 (exclusive). It takes no arguments.
|example1 = print(rand()); # prints random number
}}

=== registerFlightPlanDelegate() ===
{{Nasal doc
|syntax = registerFlightPlanDelegate(init_func);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1879|t=Source}}
|text = Registers a flight plan delegate. See <tt>''{{fgdata file|Nasal/route_manager.nas|t=$FG_ROOT/Nasal/route_manager.nas}}''</tt> for examples.
|param1 = init_func
|param1text = Initialization function which will be called during FlightGear's startup.
}}
=== removecommand() ===
{{Nasal doc
|syntax = removecommand(cmd);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=668|t=Source}}
|text = Removes the given fgcommand. Returns <code>'''nil'''</code>.
{{caution|This will remove '''any''' [[fgcommands|fgcommand]], even those implemented in C++, so use with caution!}}
|param1 = cmd
|param1text = String specifying the name of the command to remove.
|example1 = addcommand("hello", func(){
print("Hello");
});
fgcommand("hello"); # "Hello" will be printed
removecommand("hello"); # removes it
}}

=== removelistener() ===
{{Nasal doc
|syntax = removelistener(id);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=1384|t=Part 1}} {{!}} {{flightgear file|src/Scripting/NasalSys.cxx|l=506|t=Part 2}}
|text = Removes and deactivates the given listener and returns the number of listeners left or <code>'''nil'''</code> on error.
{{note|It is good practice to remove listeners when they are not required anymore. This prevents the listeners reducing FlightGear's run performance.}}
|param1 = id
|param1text = ID of listener as returned by {{func link|setlistener()}}.
|example1 = var ls = setlistener("/sim/test", func(){
print("Property '/sim/test' has been changed");
});
setprop("/sim/test", "blah"); # trigger listener
var rem = removelistener(ls); # remove listener
print("There are ", rem, " listeners remaining");
}}

=== resolvepath() ===
{{Nasal doc
|syntax = resolvepath(path);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=604|t=Source}}
|text = Takes a relative path as a string and uses [[SimGear]]'s path-resolving framework to return an absolute path as a string. If the path could not be resolved, an empty string is returned. See [[Resolving Paths]] for a detailed description of the algorithm. This function can also be used to check if a file exists.
|param1 = path
|param1text = Relative path to be completed.
|example1 = print(resolvepath("Nasal/globals.nas")); # prints the equivalent of $FG_ROOT/Nasal/globals.nas
|example2 = print(resolvepath("blah")); # prints nothing; could not be resolved
|example3 = var file_path = resolvepath("Aircraft/SenecaII/some-file");
if (file_path != ""){
gui.popupTip("some-file found", 2);
} else {
gui.popupTip("some-file not found", 2);
}
}}

=== setlistener() ===
{{Nasal doc
|syntax = setlistener(node, code[, init[, type]]);
|private = _setlistener()
|source = {{flightgear file|src/Scripting/Nasal|l=499|t=Part 1}} {{!}} {{flightgear file|src/Scripting/Nasal|l=1350|t=Part 2}}<br>''Listener implemented using the {{API Link|flightgear|class|FGNasalListener}} class.''
|text = Creates a listener which will be triggered when the given property is changed (depending on the '''type'''). A unique integer ID is returned; this can later be used as the argument to {{func link|removelistener()}}.
{{note|Listeners are known to be a source of resource leaks. To avoid this, please take measures such as:
* Using {{func link|removelistener()}} when they are not needed any more.
* Using a single initialization listener.
* Avoiding tying listeners to properties that are rapidly updated (e.g., many times per frame).
}}
|param1 = node
|param1text = Mandatory string or <code>props.Node</code> object pointing to a property in the [[Property Tree]].
|param2 = code
|param2text = Mandatory callback function to execute when the listener is triggered. The function can take up to four arguments in the following order:
* '''changed''': a <code>props.Node</code> object pointing to the changed node.
* '''listen''': a <code>props.Node</code> object pointing to the listened-to node. Note that this argument maybe different depending on the '''type'''.
* '''mode''': an integer telling how the listener was triggered. 0 means that the value was changed. 1 means that a child property was added. -1 means that a child property was removed.
* '''is_child''': boolean telling whether '''changed''' is a child property of the listened-to '''node''' or not. 1 (true) if it is, 0 (false) otherwise.
|param3 = init
|param3text = If set to 1 (true), the listener will additionally be triggered when it is created. This argument is optional and defaults to 0 (false).
|param4 = type
|param4text = Integer specifying the listener's behavior. 0 means that the listener will only trigger when the property is changed. 1 means that the trigger will always be triggered when the property is written to. 2 will mean that the listener will be triggered even if child properties are modified. This argument is optional and defaults to 1.
|example1 = var prop = props.globals.initNode("/sim/test", "", "STRING"); # create property
var id = setlistener("/sim/test", func(n){ # create listener
print("Value: ", n.getValue());
});
setprop("/sim/test", "blah"); # trigger listener
removelistener(id); # remove listener
prop.remove(); # remove property
}}

=== setprop() ===
{{Nasal doc
|syntax = setprop(path[, path[, ...]], value);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=385|t=Source}}
|text = Sets the value of a property in the [[Property Tree]]. If the property does not exist, it will be created. Returns 1 (true) on success or 0 (false) if there was an error.
{{note|If you want to remove a property, you will have to use one of the <code>props</code> helpers:
<syntaxhighlight lang="nasal">
props.globals.getNode("foo/bar").remove(); # take out the complete node
props.globals.getNode("foo").removeChild("bar"); # take out a certain child node
</syntaxhighlight>
}}
|param1 = path
|param1text = There needs to be at least one '''path''' argument, but there is no limit to the maximum amount that can be given. They will be concatenated together to form a property tree path. The arguments must be strings, but in FlightGear v3.2 onwards, there also is support (added by {{flightgear commit|34ed79}}) for numeric arguments as indices. See example 2 below.
|param2 = value
|param2text = Value to write to the given property. Must be either a string or a number.
|example1 = setprop("/sim/demo", "This is a demo");
|example2text = Note that the example below will only work in FlightGear 3.2 and above.
|example2 = for(var i = 0; i < 3; i += 1){
setprop("/sim/demo", i, "Demo #" ~ i));
}
|example3text = Same as above, but is supported by all versions of FlightGear.
|example3 = for(var i = 0; i < 3; i += 1){
setprop("/sim/demo[" ~ i ~ "]", "Demo #" ~ i));
}
}}
==== See also ====
{{note| If you have to read/write the same property multiple times (e.g. in an update loop), it is more efficient to use a node object:
To get a Node rather than its value, use <code>props.globals.getNode()</code> - see [[Nasal_library/props]]. }}

=== settimer() ===
{{Nasal doc
|syntax = settimer(function, delta[, realtime]);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=499|t=Part 1}} {{!}} {{flightgear file|src/Scripting/NasalSys.cxx|l=1286|t=Part 2}}
|text = Runs the given function a specified amount of seconds after the current time. Returns <code>'''nil'''</code>.
{{note|Improper use of <code>settimer()</code> may cause resource leaks. It is also highly recommended that the newer {{func link|maketimer()}} should be used instead of this function.}}
|param1 = function
|param1text = Mandatory function that will be called. It may be necessary to enclose code in an anonymous function (see example).
|param2 = delta
|param2text = Mandatory amount of time in seconds after which the function will be called.
|param3 = realtime
|param3text = If 1 (true), "real time" will be used instead of "simulation time." Defaults to 0 (false). Note that if "simulation time" is used, the timer will not run while FlightGear is paused.
|example1 = var myFunc = func(){
print("Hello");
}

settimer(myFunc, 2); # runs myFunc after 2 seconds
|example2 = var sqr = func(a){
return a * a;
}

settimer(func(){
print(sqr(2)); # will print 4 after 2 seconds
}, 2);
}}

=== srand() ===
{{Nasal doc
|syntax = srand();
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=559|t=Source}}
|text = Makes the pseudorandom number generator (see {{func link|rand()}}) generate a new {{wikipedia|random seed|noicon=1}} based on time. Returns 0.
}}
=== systime() ===
{{Nasal doc
|syntax = systime();
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=770|t=Source}}
|text = Returns the {{wikipedia|Unix time}} (seconds since since 00:00:00 UTC, 1/1/1970) as a floating point number with high resolution. This function is useful for benchmarking purposes (see example 2).
{{note|1=High resolution timers under Windows can produce inaccurate or fixed sub-millisecond results.<ref>{{cite web|url=http://forum.flightgear.org/viewtopic.php?f=30&t=29259|title=Nasal: systime() ??!?|author=Necolatis|date=Apr 2nd, 2016}}</ref> This is due to the underlying {{func link|GetSystemTimeAsFileTime()|link=https://msdn.microsoft.com/en-us/library/windows/desktop/ms724397(v=vs.85).aspx}} API call, which depends on hardware availability of suitable high resolution timers. See also [https://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx Acquiring high-resolution time stamps]}}
|example1 = print("Unix time: ", systime()); # prints Unix time
|example2 = var myFunc = func(){
for(var i = 0; i <= 10; i += 1){
print("Interation #", i);
}
}
var t = systime(); # record time
myFunc(); # run function
var t2 = systime(); # record new time
print("myFunc() took ", t2 - t, " seconds"); # print result
}}

=== thisfunc() ===
{{Nasal doc
|syntax = thisfunc();
|source = {{fgdata file|Nasal/globals.nas|t=Source}}
|text = Returns the function from which this function is called. This allows a function to reliably and safely call itself from within a closure.
|example1 = var stringify_vec = func(input){
if (typeof(input) == "scalar"){
return sprintf("%s", input);
} elsif (typeof(input) == "vector") {
if (size(input) == 0) return "[]";
var this = thisfunc();
var buffer = "[";
for(var i = 0; i < size(input); i += 1){
buffer ~= this(input[i]);
if (i == size(input) - 1) {
buffer ~= "]";
} else {
buffer ~= ", ";
}
}
return buffer;
} else {
die("stringify_vec(): Error! Invalid input. Must be a vector or scalar");
}
}

var test_vec = ["a", "b", "c", 1, 2, 3];
debug.dump(stringify_vec(test_vec)); # prints "[a, b, c, 1, 2, 3]"
test_vec = [];
debug.dump(stringify_vec(test_vec)); # prints "[]"
test_vec = {};
debug.dump(stringify_vec(test_vec)); # will throw an error
}}

=== tileIndex() ===
{{Nasal doc
|syntax = tileIndex();
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1720|t=Source}}
|text = Returns the index of the tile at the aircraft's current position as a string. This corresponds to the name of the STG file of the tile. For example, at [[KSFO]], this would be <code>942050</code>, corresponding to <tt>''[[$FG_SCENERY]]/Terrain/w130n30/w123n3/942050.stg''</tt>.
|example1 = print(tileIndex()); # print index
}}

=== tilePath() ===
{{Nasal doc
|syntax = tilePath();
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1712|t=Source}}
|text = Returns the base path of the tile at the aircraft's current position as a string. For example, at KSFO, this would be <code>w130n30/w123n3</code>, corresponding to <tt>''[[$FG_SCENERY]]/Terrain/w130n30/w123n3''</tt>.
|example1 = print(tilePath()); # print path
}}

=== values() ===
{{Nasal doc
|syntax = values(hash);
|source = {{fgdata file|Nasal/globals.nas|t=Source}}
|text = Returns a vector containing the values of the given hash.
|param1 = hash
|param1text = Mandatory hash to get the values of.
|example1 = var hash = {
"a": 1,
"b": 2,
"c": 3
};

foreach(var val; values(hash)){
print(val);
}
|example2text = The below example does exactly the same thing as the above example, but does not use <code>values()</code>:
|example2 = var hash = {
"a": 1,
"b": 2,
"c": 3
};

foreach(var key; keys(hash)){
print(hash[key]);
}
}}

== Extension functions new in FG 2020.1 ==
The following functions have been added to the nasal core library and will be released with FlightGear version 2020.1.
Before the release they are available in the development branch "next".

=== isfunc() ===
Returns 1 if type or argument is a function, otherwise 0.

=== isghost() ===
Returns 1 if type or argument is a ghost, otherwise 0.

=== ishash() ===
Returns 1 if type or argument is a hash, otherwise 0.

=== isint() ===
{{Nasal doc
|syntax = isint(x);
|source = {{simgear file|simgear/nasal/lib.c|t=Source}}
|text = Returns 1 if argument has a numeric value and x == floor(x), e.g. integer.
}}

=== isnum() ===
{{Nasal doc
|syntax = isnum(x);
|source = {{simgear file|simgear/nasal/lib.c|t=Source}}
|text = Returns 1 if typeof(x) is "scalar" and x has a numeric value otherwise 0.
}}

=== isscalar() ===
{{Nasal doc
|syntax = isscalar(x);
|source = {{simgear file|simgear/nasal/lib.c|t=Source}}
|text = Returns 1 if type or argument is a scalar (string or numeric), otherwise (vector, hash, func, ...) it returns 0. This is useful to check if a variable can be converted to string e.g. when useing the string concat operator "~".
|example1 = var a = "foo";
var b=42;
if (isscalar(a) and isscalar(b)) print(a~b);
if (isstr(a)) print("a is a string");
if (isint(b)) print("b is an integer");
# if (isscalar(a))... is equivalent to if (typeof(a) == "scalar")...
}}

=== isstr() ===
Returns 1 if type or argument is a string, otherwise 0.

=== isvec() ===
Returns 1 if type or argument is a vector, otherwise 0.

=== vecindex() ===
{{Nasal doc
|syntax = vecindex(vector, value);
|source = {{simgear file|simgear/nasal/lib.c|t=Source}}
|text = Returns the index of value or nil, if value is not found in vector.
|example1=
var myvector = ["apple", "bananna", "coconut"];
# to check if a vector contains a certain value compare vecindex to nil
if (vecindex(myvector, "apple") != nil) {
print("found apple");
}
# WARNING: this will not work as desired because index is 0
if (vecindex(myvector, "apple")) {
print("found apple");
}

}}

{{note| There is a similar function function contains(hash, key) to check if a hash contains a key (not value!).
It is to be discussed, if contains can/should be extended to support vectors in the above mentioned way. }}

== Variables ==
Various global constants (technically variables) are provided for use in converting between different units. They are all found in {{fgdata file|Nasal/globals.nas|text=$FG_ROOT/Nasal/globals.nas}}.

=== D2R ===
{{Nasal doc
|syntax = var radians = degrees * D2R;
|text = Converts an angle from degrees to radians when multiplied by the angle in degrees. Equal to <code>π / 180</code>.
}}
=== FPS2KT ===
{{Nasal doc
|syntax = var knots = feet_per_second * FPS2KT;
|text = Converts a velocity from feet per second to knots when multiplied by the velocity in feet per second. Approximately equal to 0.5925.
}}
=== FT2M ===
{{Nasal doc
|syntax = var metres = feet * FT2M;
|text = Converts a length from feet to metres when multiplied by the length in feet. Equal to 0.3048.
}}
=== GAL2L ===
{{Nasal doc
|syntax = var litres = gallons * GAL2L;
|text = Converts a volume from US liquid gallons to litres when multiplied by the volume in gallons. Approximately equal to 3.7854.
}}
=== IN2M ===
{{Nasal doc
|syntax = var metres = inches * IN2M;
|text = Converts a length from inches to metres when multiplied by the length in inches. Equal to 0.0254.
}}
=== KG2LB ===
{{Nasal doc
|syntax = var pounds = kilograms * KG2LB;
|text = Converts a mass from kilograms to pounds when multiplied by the mass in kilograms. Approximately equal to 2.2046.
}}
=== KT2FPS ===
{{Nasal doc
|syntax = var feet_per_second = knots * KT2FPS;
|text = Converts a velocity from knots to feet per second when multiplied by the velocity in knots. Approximately equal to 1.6878.
}}
=== KT2MPS ===
{{Nasal doc
|syntax = var metres_per_second = knots * KT2MPS;
|text = Converts a velocity from knots to metres per second when multiplied by the velocity in knots. Approximately equal to 0.5144.
}}
=== L2GAL ===
{{Nasal doc
|syntax = var gallons = litres * L2GAL;
|text = Converts a volume from litres to US liquid gallons when multiplied by the volume in litres. Approximately equal to 0.2642.
}}
=== LB2KG ===
{{Nasal doc
|syntax = var kilograms = pounds * LB2KG;
|text = Converts a mass from pounds to kilograms when multiplied by the mass in pounds. Approximately equal to 0.4536.
}}
=== M2FT ===
{{Nasal doc
|syntax = var feet = metres * M2FT;
|text = Converts a length from metres to feet when multiplied by the length in metres. Approximately equal to 3.2808.
}}
=== M2IN ===
{{Nasal doc
|syntax = var inches = metres * M2IN;
|text = Converts a length from metres to inches when multiplied by the length in metres. Approximately equal to 39.3701.
}}
=== M2NM ===
{{Nasal doc
|syntax = var nautical_miles = metres * M2NM;
|text = Converts a length from metres to nautical miles when multiplied by the length in metres. Approximately equal to 0.00054.
}}
=== MPS2KT ===
{{Nasal doc
|syntax = var knots = metres_per_second * MPS2KT;
|text = Converts a velocity from metres per second to knots when multiplied by the velocity in metres per second. Approximately equal to 1.9438.
}}
=== NM2M ===
{{Nasal doc
|syntax = var metres = nautical_miles * NM2M;
|text = Converts a length from nautical miles to metres when multiplied by the length in nautical miles. Equal to 1,852.
}}
=== R2D ===
{{Nasal doc
|syntax = var degrees = radians * R2D;
|text = Converts an angle from radians to degrees when multiplied by the angle in radians. Equal to <code>180 / π</code>.
}}

{{Appendix}}

{{Nasal namespaces}}

Building using CMake - Windows

2021-12-13T12:59:59Z

Legoboyvdlp: /* Scripted Compilation */

{{Main article|Building Flightgear}}
This article is intended to give an overview of building FlightGear on modern Windows systems. It was created using Windows 10 and VS 2019. It ought to be transferrable to earlier versions of the Windows OS and software.

As FlightGear is now 64-bit only, the guide only describes building on a 64-bit system.

== Required software ==
* [https://cmake.org/download/ CMake for Windows]. Download and install the Windows Win64-x64 Installer.
* [https://visualstudio.microsoft.com/downloads/ Microsoft Visual Studio 2019] (MSVC). The Community version is free. There is no need for the premium versions; none of their features are required to build FlightGear. The C++ compiler will not be installed by default. You either choose this component during installation or after installation by starting MSVC and trying to create a new C++ project. The one to download is "Desktop Development with C++". Make sure to have the last version of the Windows SDK and C++ Compiler checked. As of 08/10/2020, the latest version of the compiler is "MSVC 142 - VS 2019 C++ x64/86 build tools (v14.27)".
* [https://www.qt.io/download-open-source/ Qt5] for the [[Integrated Qt5 Launcher]]. Download the online installer, and choose the version matching your toolchain of Visual Studio e.g. "Qt 5.15.1 --> MSVC 2019 64 bit". Any version past 5.9 will be fine; 5.15 recommended. Leave the default Developer and Designer Tools selection - these are needed for coding and compiling.
* [https://git-scm.com/download/win Git] to keep your build up to date. It also simplifies downloads of components. Optional, but can't recommend it enough!

== Obtaining source ==
{{Main article|FlightGear and Git}}
Throughout this article it is assumed that you have set up git clones of the various source repositories (FlightGear, SimGear, data...).
Using an organized directory (see below) will help significantly.

The commands to run are:

{{code|git clone https://git.code.sf.net/p/flightgear/simgear simgear}}

{{code|git clone https://git.code.sf.net/p/flightgear/flightgear flightgear}}

{{code|git clone https://git.code.sf.net/p/flightgear/fgdata fgdata}}

{{code|git clone https://git.code.sf.net/p/flightgear/windows-3rd-party windows-3rd-party}}

{{code|git clone -b fgfs-osg-36-1 https://github.com/zakalawe/osg.git osg}}

After downloading these, I would suggest assembling a folder structure as below:

== Directory Tree ==
On Windows, assumptions on the directory structure are made to automate the discovery of dependencies. This recommended directory structure is described below. The components can be downloaded from the links above. If you do not use the recommended structure you will need to enter paths by hand and some parts may not input correctly.

Caveat -- spaces in the directory names will cause errors. It is best to make sure there are no spaces in the path anywhere.

<tt>
: FlightGearBuild / </tt> (Main root directory) <tt>
:: fgdata / </tt> (FlightGear data files) <tt>
:: flightgear / </tt> (FlightGear sources) <tt>
:: install / </tt> (Directory where you will install the built binaries to) <tt>
::: launch.bat / </tt> (launch script if desired, see below) <tt>
:: osg / </tt> (OSG sources) <tt>
:: simgear / </tt> (SimGear sources) <tt>
:: windows-3rd-party /
:: build.bat / </tt> (build script, see below) <tt>
:: update.bat / </tt> (update script, see below)

== Building ==
=== Scripted Compilation ===
This script will allow you to build OpenSceneGraph, SimGear and FlightGear automatically.

{{collapsible script
| type = Windows batch file
| title = The <code>build.bat</code> script for configuring and compiling OSG, SG, and FG
| lang = batch
| script =
SET PATH=%PATH%;%ProgramFiles%\CMake\bin
SET QT5SDK64=C:\Qt\5.15.0\msvc2019_64
SET CMAKE_TOOLCHAIN="Visual Studio 16 2019"
SET ROOT_DIR=C:\path\to\FlightGearBuild

md osg-build
md simgear-build
md flightgear-build

cd %ROOT_DIR%\osg-build

cmake %ROOT_DIR%\osg -G %CMAKE_TOOLCHAIN% -A x64 ^
-DACTUAL_3RDPARTY_DIR=%ROOT_DIR%\windows-3rd-party/msvc140/3rdParty.x64 ^
-DCMAKE_RELWITHDEBINFO_POSTFIX:STRING= ^
-DOSG_USE_UTF8_FILENAME:BOOL=ON ^
-DWIN32_USE_MP:BOOL=ON ^
-DCMAKE_INSTALL_PREFIX:PATH=%ROOT_DIR%\install
cmake --build . --config RelWithDebInfo --target INSTALL

cd %ROOT_DIR%\simgear-build
cmake %ROOT_DIR%\simgear -G %CMAKE_TOOLCHAIN% -A x64 ^
-DOSG_FSTREAM_EXPORT_FIXED:BOOL=ON ^
-DCMAKE_INSTALL_PREFIX:PATH=%ROOT_DIR%\install
cmake --build . --config RelWithDebInfo --target INSTALL

cd %ROOT_DIR%\flightgear-build
cmake %ROOT_DIR%\flightgear -G %CMAKE_TOOLCHAIN% -A x64 ^
-DCMAKE_INSTALL_PREFIX:PATH=%ROOT_DIR%\install ^
-DCMAKE_PREFIX_PATH=%QT5SDK64% ^
-DOSG_FSTREAM_EXPORT_FIXED:BOOL=ON

cmake --build . --config RelWithDebInfo --target INSTALL

pause
| show = 1
}}

Before starting to use the script, you need to edit the top few lines of the script. You will have to:

1. Set the path to your CMake installation.

2. Ensure that the path to your QT SDK is correct for your version of MSVC.

3. Ensure your toolchain version matches, e.g. "Visual Studio 16 2019" for MSVC 2019 or "Visual Studio 15 2017" for MSVC 2017.

4. Set ROOT_DIR to the FlightgearBuild folder you created (the above directory structure)

==== Post-compilation: Launching FlightGear ====
'''In the debugger:'''
Open flightgear-build/FlightGear.sln. You can then perform all your development / debugging directly in VS. You normally only need to run build.bat again, if you update SimGear or OSG.

To launch FlightGear from Visual Studio, you can follow the following steps:
The first time only:
# Make sure you set your build type to RelWithDebInfo in the top bar.
# To start with the launcher, click on the small black arrow beside Local Windows Debugger to open 'fgfs debug properties'. Switch to debugging; add {{code|--launcher}} to the 'Command Arguments'. Click Apply and then OK.
# Press the green arrow (Local Windows Debugger) to start up FlightGear.
# The first time you'll have to choose where FGDATA is -- to do this, select the 'fgdata' directory you cloned at the start.

Therafter, simply press the green arrow directly each time you want to start. If there are any local changes, it will recompile; alternatively it will start up directly. It will take a little longer to start as it loads symbols; however you also have the benefit that any segfaults will be caught allowing you to report them!

'''As a standard .exe:'''
NB these instructions overall are intended for setting up for development; there's a slightly more convoluted process for setting up for just plain flying (e.g. taking advantage of new features for aircraft development).

Essentially, Visual Studio doesn't copy in the DLLs into the /bin/ folder. It's also not ideal to manually copy in the DLLS as it can cause all sorts of issues. However, without the DLLs FlightGear won't work; therefore, you need to set the PATH so it knows where to look for them.
This launch script should work, put into your /install/bin/ folder:
{{collapsible script
| type = Windows batch file
| title = The <code>launch.bat</code> script for launching flightgear
| lang = batch
| script =
SET PATH=C:\path\to\FlightGearBuild\install\bin;C:\path\to\FlightGearBuild\windows-3rd-party\msvc140\3rdParty.x64\bin;C:\Qt\5.15.0\msvc2019_64\bin;%PATH%
fgfs.exe --launcher
| show = 1
}}

Adjust the "path\to" references to suit your own personal installation, as well as the QT5 path.

=== Updating ===
To update FlightGear, in general, just run ''git pull'' on the source directories and then re-run the build.bat script -- it will update what it needs to, relatively quickly.

=== Changing the Configuration ===
When the Simgear/FlightGear version numbers change, or you change configuration options (e.g. toggling Compositor, changing OSG versions, changing QT versions) you do have to re-configure in CMake. To do this, it's usually safest to delete the simgear-build and flightgear-build folders and re-run the build.bat script, to ensure the build is clean. There is no need to delete osg-build unless changing OSG version.

In case of problems, most of the time deleting the simgear-build and flightgear-build folders and re-running the build.bat script will be sufficient.

{{building}}
[[fr:compiler flightear avec CMake - Windows]]
[[Category:Windows specific]]
[[Category:Hackathon Materials]]

Building using CMake - Windows

2021-12-12T21:06:12Z

Legoboyvdlp: /* Directory Tree */

{{Main article|Building Flightgear}}
This article is intended to give an overview of building FlightGear on modern Windows systems. It was created using Windows 10 and VS 2019. It ought to be transferrable to earlier versions of the Windows OS and software.

As FlightGear is now 64-bit only, the guide only describes building on a 64-bit system.

== Required software ==
* [https://cmake.org/download/ CMake for Windows]. Download and install the Windows Win64-x64 Installer.
* [https://visualstudio.microsoft.com/downloads/ Microsoft Visual Studio 2019] (MSVC). The Community version is free. There is no need for the premium versions; none of their features are required to build FlightGear. The C++ compiler will not be installed by default. You either choose this component during installation or after installation by starting MSVC and trying to create a new C++ project. The one to download is "Desktop Development with C++". Make sure to have the last version of the Windows SDK and C++ Compiler checked. As of 08/10/2020, the latest version of the compiler is "MSVC 142 - VS 2019 C++ x64/86 build tools (v14.27)".
* [https://www.qt.io/download-open-source/ Qt5] for the [[Integrated Qt5 Launcher]]. Download the online installer, and choose the version matching your toolchain of Visual Studio e.g. "Qt 5.15.1 --> MSVC 2019 64 bit". Any version past 5.9 will be fine; 5.15 recommended. Leave the default Developer and Designer Tools selection - these are needed for coding and compiling.
* [https://git-scm.com/download/win Git] to keep your build up to date. It also simplifies downloads of components. Optional, but can't recommend it enough!

== Obtaining source ==
{{Main article|FlightGear and Git}}
Throughout this article it is assumed that you have set up git clones of the various source repositories (FlightGear, SimGear, data...).
Using an organized directory (see below) will help significantly.

The commands to run are:

{{code|git clone https://git.code.sf.net/p/flightgear/simgear simgear}}

{{code|git clone https://git.code.sf.net/p/flightgear/flightgear flightgear}}

{{code|git clone https://git.code.sf.net/p/flightgear/fgdata fgdata}}

{{code|git clone https://git.code.sf.net/p/flightgear/windows-3rd-party windows-3rd-party}}

{{code|git clone -b fgfs-osg-36-1 https://github.com/zakalawe/osg.git osg}}

After downloading these, I would suggest assembling a folder structure as below:

== Directory Tree ==
On Windows, assumptions on the directory structure are made to automate the discovery of dependencies. This recommended directory structure is described below. The components can be downloaded from the links above. If you do not use the recommended structure you will need to enter paths by hand and some parts may not input correctly.

Caveat -- spaces in the directory names will cause errors. It is best to make sure there are no spaces in the path anywhere.

<tt>
: FlightGearBuild / </tt> (Main root directory) <tt>
:: fgdata / </tt> (FlightGear data files) <tt>
:: flightgear / </tt> (FlightGear sources) <tt>
:: install / </tt> (Directory where you will install the built binaries to) <tt>
::: launch.bat / </tt> (launch script if desired, see below) <tt>
:: osg / </tt> (OSG sources) <tt>
:: simgear / </tt> (SimGear sources) <tt>
:: windows-3rd-party /
:: build.bat / </tt> (build script, see below) <tt>
:: update.bat / </tt> (update script, see below)

== Building ==
=== Scripted Compilation ===
This script will allow you to build OpenSceneGraph, SimGear and FlightGear automatically.

{{collapsible script
| type = Windows batch file
| title = The <code>build.bat</code> script for configuring and compiling OSG, SG, and FG
| lang = batch
| script =
SET PATH=%PATH%;%ProgramFiles%\CMake\bin
SET QT5SDK64=C:\Qt\5.15.0\msvc2019_64
SET CMAKE_TOOLCHAIN="Visual Studio 16 2019"
SET ROOT_DIR=C:\path\to\FlightGearBuild

md osg-build
md simgear-build
md flightgear-build

cd %ROOT_DIR%\osg-build

cmake %ROOT_DIR%\osg -G %CMAKE_TOOLCHAIN% -A x64 ^
-DACTUAL_3RDPARTY_DIR=%ROOT_DIR%\windows-3rd-party/msvc140/3rdParty.x64 ^
-DCMAKE_RELWITHDEBINFO_POSTFIX:STRING= ^
-DOSG_USE_UTF8_FILENAME:BOOL=ON ^
-DWIN32_USE_MP:BOOL=ON ^
-DCMAKE_INSTALL_PREFIX:PATH=%ROOT_DIR%\install
cmake --build . --config RelWithDebInfo --target INSTALL

cd %ROOT_DIR%\simgear-build
cmake %ROOT_DIR%\simgear -G %CMAKE_TOOLCHAIN% -A x64 ^
-DOSG_FSTREAM_EXPORT_FIXED:BOOL=ON ^
-DCMAKE_INSTALL_PREFIX:PATH=%ROOT_DIR%\install
cmake --build . --config RelWithDebInfo --target INSTALL

cd %ROOT_DIR%\flightgear-build
cmake %ROOT_DIR%\flightgear -G %CMAKE_TOOLCHAIN% -A x64 ^
-DCMAKE_INSTALL_PREFIX:PATH=%ROOT_DIR%\install ^
-DCMAKE_PREFIX_PATH=%QT5SDK64% ^
-DOSG_FSTREAM_EXPORT_FIXED:BOOL=ON ^
-DENABLE_COMPOSITOR:BOOL=OFF

cmake --build . --config RelWithDebInfo --target INSTALL

pause
| show = 1
}}

Before starting to use the script, you need to edit the top few lines of the script. You will have to:

1. Set the path to your CMake installation.

2. Ensure that the path to your QT SDK is correct for your version of MSVC.

3. Ensure your toolchain version matches, e.g. "Visual Studio 16 2019" for MSVC 2019 or "Visual Studio 15 2017" for MSVC 2017.

4. Set ROOT_DIR to the FlightgearBuild folder you created (the above directory structure)

==== Post-compilation: Launching FlightGear ====
'''In the debugger:'''
Open flightgear-build/FlightGear.sln. You can then perform all your development / debugging directly in VS. You normally only need to run build.bat again, if you update SimGear or OSG.

To launch FlightGear from Visual Studio, you can follow the following steps:
The first time only:
# Make sure you set your build type to RelWithDebInfo in the top bar.
# To start with the launcher, click on the small black arrow beside Local Windows Debugger to open 'fgfs debug properties'. Switch to debugging; add {{code|--launcher}} to the 'Command Arguments'. Click Apply and then OK.
# Press the green arrow (Local Windows Debugger) to start up FlightGear.
# The first time you'll have to choose where FGDATA is -- to do this, select the 'fgdata' directory you cloned at the start.

Therafter, simply press the green arrow directly each time you want to start. If there are any local changes, it will recompile; alternatively it will start up directly. It will take a little longer to start as it loads symbols; however you also have the benefit that any segfaults will be caught allowing you to report them!

'''As a standard .exe:'''
NB these instructions overall are intended for setting up for development; there's a slightly more convoluted process for setting up for just plain flying (e.g. taking advantage of new features for aircraft development).

Essentially, Visual Studio doesn't copy in the DLLs into the /bin/ folder. It's also not ideal to manually copy in the DLLS as it can cause all sorts of issues. However, without the DLLs FlightGear won't work; therefore, you need to set the PATH so it knows where to look for them.
This launch script should work, put into your /install/bin/ folder:
{{collapsible script
| type = Windows batch file
| title = The <code>launch.bat</code> script for launching flightgear
| lang = batch
| script =
SET PATH=C:\path\to\FlightGearBuild\install\bin;C:\path\to\FlightGearBuild\windows-3rd-party\msvc140\3rdParty.x64\bin;C:\Qt\5.15.0\msvc2019_64\bin;%PATH%
fgfs.exe --launcher
| show = 1
}}

Adjust the "path\to" references to suit your own personal installation, as well as the QT5 path.

=== Updating ===
To update FlightGear, in general, just run ''git pull'' on the source directories and then re-run the build.bat script -- it will update what it needs to, relatively quickly.

=== Changing the Configuration ===
When the Simgear/FlightGear version numbers change, or you change configuration options (e.g. toggling Compositor, changing OSG versions, changing QT versions) you do have to re-configure in CMake. To do this, it's usually safest to delete the simgear-build and flightgear-build folders and re-run the build.bat script, to ensure the build is clean. There is no need to delete osg-build unless changing OSG version.

In case of problems, most of the time deleting the simgear-build and flightgear-build folders and re-running the build.bat script will be sufficient.

{{building}}
[[fr:compiler flightear avec CMake - Windows]]
[[Category:Windows specific]]
[[Category:Hackathon Materials]]

Building using CMake - Windows

2021-12-12T21:05:56Z

Legoboyvdlp: /* Directory Tree */

{{Main article|Building Flightgear}}
This article is intended to give an overview of building FlightGear on modern Windows systems. It was created using Windows 10 and VS 2019. It ought to be transferrable to earlier versions of the Windows OS and software.

As FlightGear is now 64-bit only, the guide only describes building on a 64-bit system.

== Required software ==
* [https://cmake.org/download/ CMake for Windows]. Download and install the Windows Win64-x64 Installer.
* [https://visualstudio.microsoft.com/downloads/ Microsoft Visual Studio 2019] (MSVC). The Community version is free. There is no need for the premium versions; none of their features are required to build FlightGear. The C++ compiler will not be installed by default. You either choose this component during installation or after installation by starting MSVC and trying to create a new C++ project. The one to download is "Desktop Development with C++". Make sure to have the last version of the Windows SDK and C++ Compiler checked. As of 08/10/2020, the latest version of the compiler is "MSVC 142 - VS 2019 C++ x64/86 build tools (v14.27)".
* [https://www.qt.io/download-open-source/ Qt5] for the [[Integrated Qt5 Launcher]]. Download the online installer, and choose the version matching your toolchain of Visual Studio e.g. "Qt 5.15.1 --> MSVC 2019 64 bit". Any version past 5.9 will be fine; 5.15 recommended. Leave the default Developer and Designer Tools selection - these are needed for coding and compiling.
* [https://git-scm.com/download/win Git] to keep your build up to date. It also simplifies downloads of components. Optional, but can't recommend it enough!

== Obtaining source ==
{{Main article|FlightGear and Git}}
Throughout this article it is assumed that you have set up git clones of the various source repositories (FlightGear, SimGear, data...).
Using an organized directory (see below) will help significantly.

The commands to run are:

{{code|git clone https://git.code.sf.net/p/flightgear/simgear simgear}}

{{code|git clone https://git.code.sf.net/p/flightgear/flightgear flightgear}}

{{code|git clone https://git.code.sf.net/p/flightgear/fgdata fgdata}}

{{code|git clone https://git.code.sf.net/p/flightgear/windows-3rd-party windows-3rd-party}}

{{code|git clone -b fgfs-osg-36-1 https://github.com/zakalawe/osg.git osg}}

After downloading these, I would suggest assembling a folder structure as below:

== Directory Tree ==
On Windows, assumptions on the directory structure are made to automate the discovery of dependencies. This recommended directory structure is described below. Clicking the links allows you to download pre-built parts. If you do not use the recommended structure you will need to enter paths by hand and some parts may not input correctly.

Caveat -- spaces in the directory names will cause errors. It is best to make sure there are no spaces in the path anywhere.

<tt>
: FlightGearBuild / </tt> (Main root directory) <tt>
:: fgdata / </tt> (FlightGear data files) <tt>
:: flightgear / </tt> (FlightGear sources) <tt>
:: install / </tt> (Directory where you will install the built binaries to) <tt>
::: launch.bat / </tt> (launch script if desired, see below) <tt>
:: osg / </tt> (OSG sources) <tt>
:: simgear / </tt> (SimGear sources) <tt>
:: windows-3rd-party /
:: build.bat / </tt> (build script, see below) <tt>
:: update.bat / </tt> (update script, see below)

== Building ==
=== Scripted Compilation ===
This script will allow you to build OpenSceneGraph, SimGear and FlightGear automatically.

{{collapsible script
| type = Windows batch file
| title = The <code>build.bat</code> script for configuring and compiling OSG, SG, and FG
| lang = batch
| script =
SET PATH=%PATH%;%ProgramFiles%\CMake\bin
SET QT5SDK64=C:\Qt\5.15.0\msvc2019_64
SET CMAKE_TOOLCHAIN="Visual Studio 16 2019"
SET ROOT_DIR=C:\path\to\FlightGearBuild

md osg-build
md simgear-build
md flightgear-build

cd %ROOT_DIR%\osg-build

cmake %ROOT_DIR%\osg -G %CMAKE_TOOLCHAIN% -A x64 ^
-DACTUAL_3RDPARTY_DIR=%ROOT_DIR%\windows-3rd-party/msvc140/3rdParty.x64 ^
-DCMAKE_RELWITHDEBINFO_POSTFIX:STRING= ^
-DOSG_USE_UTF8_FILENAME:BOOL=ON ^
-DWIN32_USE_MP:BOOL=ON ^
-DCMAKE_INSTALL_PREFIX:PATH=%ROOT_DIR%\install
cmake --build . --config RelWithDebInfo --target INSTALL

cd %ROOT_DIR%\simgear-build
cmake %ROOT_DIR%\simgear -G %CMAKE_TOOLCHAIN% -A x64 ^
-DOSG_FSTREAM_EXPORT_FIXED:BOOL=ON ^
-DCMAKE_INSTALL_PREFIX:PATH=%ROOT_DIR%\install
cmake --build . --config RelWithDebInfo --target INSTALL

cd %ROOT_DIR%\flightgear-build
cmake %ROOT_DIR%\flightgear -G %CMAKE_TOOLCHAIN% -A x64 ^
-DCMAKE_INSTALL_PREFIX:PATH=%ROOT_DIR%\install ^
-DCMAKE_PREFIX_PATH=%QT5SDK64% ^
-DOSG_FSTREAM_EXPORT_FIXED:BOOL=ON ^
-DENABLE_COMPOSITOR:BOOL=OFF

cmake --build . --config RelWithDebInfo --target INSTALL

pause
| show = 1
}}

Before starting to use the script, you need to edit the top few lines of the script. You will have to:

1. Set the path to your CMake installation.

2. Ensure that the path to your QT SDK is correct for your version of MSVC.

3. Ensure your toolchain version matches, e.g. "Visual Studio 16 2019" for MSVC 2019 or "Visual Studio 15 2017" for MSVC 2017.

4. Set ROOT_DIR to the FlightgearBuild folder you created (the above directory structure)

==== Post-compilation: Launching FlightGear ====
'''In the debugger:'''
Open flightgear-build/FlightGear.sln. You can then perform all your development / debugging directly in VS. You normally only need to run build.bat again, if you update SimGear or OSG.

To launch FlightGear from Visual Studio, you can follow the following steps:
The first time only:
# Make sure you set your build type to RelWithDebInfo in the top bar.
# To start with the launcher, click on the small black arrow beside Local Windows Debugger to open 'fgfs debug properties'. Switch to debugging; add {{code|--launcher}} to the 'Command Arguments'. Click Apply and then OK.
# Press the green arrow (Local Windows Debugger) to start up FlightGear.
# The first time you'll have to choose where FGDATA is -- to do this, select the 'fgdata' directory you cloned at the start.

Therafter, simply press the green arrow directly each time you want to start. If there are any local changes, it will recompile; alternatively it will start up directly. It will take a little longer to start as it loads symbols; however you also have the benefit that any segfaults will be caught allowing you to report them!

'''As a standard .exe:'''
NB these instructions overall are intended for setting up for development; there's a slightly more convoluted process for setting up for just plain flying (e.g. taking advantage of new features for aircraft development).

Essentially, Visual Studio doesn't copy in the DLLs into the /bin/ folder. It's also not ideal to manually copy in the DLLS as it can cause all sorts of issues. However, without the DLLs FlightGear won't work; therefore, you need to set the PATH so it knows where to look for them.
This launch script should work, put into your /install/bin/ folder:
{{collapsible script
| type = Windows batch file
| title = The <code>launch.bat</code> script for launching flightgear
| lang = batch
| script =
SET PATH=C:\path\to\FlightGearBuild\install\bin;C:\path\to\FlightGearBuild\windows-3rd-party\msvc140\3rdParty.x64\bin;C:\Qt\5.15.0\msvc2019_64\bin;%PATH%
fgfs.exe --launcher
| show = 1
}}

Adjust the "path\to" references to suit your own personal installation, as well as the QT5 path.

=== Updating ===
To update FlightGear, in general, just run ''git pull'' on the source directories and then re-run the build.bat script -- it will update what it needs to, relatively quickly.

=== Changing the Configuration ===
When the Simgear/FlightGear version numbers change, or you change configuration options (e.g. toggling Compositor, changing OSG versions, changing QT versions) you do have to re-configure in CMake. To do this, it's usually safest to delete the simgear-build and flightgear-build folders and re-run the build.bat script, to ensure the build is clean. There is no need to delete osg-build unless changing OSG version.

In case of problems, most of the time deleting the simgear-build and flightgear-build folders and re-running the build.bat script will be sufficient.

{{building}}
[[fr:compiler flightear avec CMake - Windows]]
[[Category:Windows specific]]
[[Category:Hackathon Materials]]

De/FlightGear Newsletter Juni 2017

2021-08-13T17:56:54Z

Legoboyvdlp: /* FGRUN patch */

{{De/Newsletter-header|2017-06}}
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-header|Neuigkeiten in der Entwicklung}}<br>
[[#FGRUN patch|FGRUN patch]]<br>
{{Newsletter-cover-header|Im Hangar}}<br>
[[#Flugzeugträger|Flugzeugträger]]<br>
| valign="top" width="33%" |
{{Newsletter-cover-header|Szenerie-Abteilung}}<br>
[[#Prag|Prag]]<br>
[[#Helgoland mit OSM Daten|Helgoland mit OSM Daten]]<br>
| valign="top" width="33%" |
{{Newsletter-cover-header|Mitarbeiten}}<br>
[[#Übersetzer gesucht|Übersetzer gesucht]]<br>
[[#FlightGear Logos|FlightGear Logos]]<br>
[[#Screenshots|Screenshots]]<br>
<small>[[#Screenshot des Monats|Screenshot des Monats]]</small>
|}</div>

== Neuigkeiten in der Entwicklung ==
=== FGRUN patch ===
Aufgrund von Komplikationen zwischen FGRun und der neusten FlightGear Version hat [[User:legoboyvdlp]] ein Patch für den alten Launcher geschrieben. Alle Nutzer von FlightGear 2017.3.0, die also lieber den alten [[FlightGear_Launch_Control|FGRun]] Launcher nutzen wollen, sollten sich den Patch von Jonathans [https://drive.google.com/open?id=0ByRqiv5ho2DZSjVRUGd4dDJRNmM|Google Drive] Account herunterladen. Allerdings empfehlen wir allen Nutzern natürlich den neueren [[FlightGear_Qt_launcher|FlightGear Launcher]], der als Bestandteil aller neuen FlightGear Versionen schon seit 2016.4 FGRun offiziell ersetzt.

== Im Hangar ==
===Flugzeugträger===
Karla hat schon vor Maonaten ein 13MB großes vollständiges Blender Model des Flugzeugträgers Nimitz zusammen mit 64MB dazugehörigen Gimp .xcf Dateien der FlightGear community zukommen lassen.
Seither sind mehrere Entwickler damit beschäftigt, Karla's Model für FlightGear nutzbar zu machen. Außerdem wird er an die schon existierenden Flugzuegträgermodelle in der FlightGear-Welt angepasst.

Der originale Post von Karla findet sich im [https://forum.flightgear.org/viewtopic.php?f=5&t=31817 FlightGer Forum]. Hier findest Du auch den neusten Entwicklungsstand.<br>mhab hat außerdem ein [https://gitlab.com/mhab/Flightgear-Carrier-Upgrade Vinson repository auf gitlab] erstellt.

Ein großer Dank geht an Karla, ein weiterer an jeden, der dabei beiträgt.
{{Gallery
|width = 300
|Vinson HD-005.png|mhab's Arbeit an der Vinson
|Vinson HD-008.png|Blick aufs Deck der Vinson
|Truman F14 Elevator-013.png|Truman Elevator}}
== Szenerie-Abteilung ==
=== Prag ===
{{usr|Catalanoic}} hat Gebäude und 3D-Objekte zum Václav Havel Flughafen Prag (LKPR) erstellt und eingebaut. Der Flughafen Prag ist der nächste StandardFlughafen in [[Changelog 2017.3|FlightGear 2017.3]], dessen Daten schon in der Installationsdatei enthalten sind und auf dem man startet, wenn kein Flughafen angegeben wurde.

[[File:Helgoland.jpg|thumb|Die Insel Helgoland mit OSM Daten]]
=== Helgoland mit OSM Daten===
{{usr|D-ECHO}} hat eine neue Scenerie für Helgoland (und Düne) erstellt! Es hat jetzt verbesserte Landclasses, ein besseres Airport Layout und mehr Objekte.
Zur Zeit ist es nur auf github verfügbar: https://github.com/D-ECHO/Helgoland-CustomScenery <br>
Sobald die Arbeit fertig ist soll es auch in Terrasync eingebracht werden.

== Mitarbeiten ==
=== Übersetzer gesucht ===
{|
| [[File:en.gif]]
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, start at [[Help:Translate]].
|-
| [[File:fr.gif]]
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].
|-
| [[File:de.gif]]
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang doch mit [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
| [[File:nl.gif]]
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
| [[File:es.gif]]
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|-
| [[File:cat.gif]]
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].
|-
| [[File:pt.gif]]
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help: Traduzir|Help: Traduzir]].
|-
| [[File:zh.gif]]
| FlightGear 百科仍然需要志愿者将其翻译为各种语言。如果你有兴趣让FlightGear百科支持更多语言, 你可以查看 [[Help:Translate]].
|}

=== FlightGear Logos ===
Solltest Du graphische Elemente für deine FlightGear Website (Hangar, YouTube-Kanal, o.ä.) suchen, wirf doch einen Blick auf die [[FlightGear logos|FlightGear Logos]]. Und falls Du eine künstlerische Ader hast, fühl Dich frei, eigene Designs zu erstellen und hier hochzuladen.

=== Screenshots ===
Das FlightGear-Projekt benötigt ständig Screenshots, welche neue Features seit dem letzten Release zeigen. Diese sollten von hoher Qualität sein, besonders von inhaltlicher und technischer Seite. Dafür wird empfohlen, die besten Graphikfilter zu nutzen ([[:de:Antialiasing|Antialiasing]], Texturenschärfung, etc.). Näheres unter [[:de:Howto:Gute Screenshots machen|Howto:Gute Screenshots machen]].

==== Screenshot des Monats ====
Kandidaten für den besten Screenshot dieses Monats können in [https://forum.flightgear.org/viewtopic.php?f=19&t=32296 diesem] Forum Thread eingereicht werden. Beachte auch die Teilnahmeregeln im [https://forum.flightgear.org/viewtopic.php?f=19&t=32296 ersten Post]. Aus Gründen der Zweckmäßigkeit werden, wenn alle Kandidaten eingereicht wurden, alle Einträge in einem separaten Thread zusammengefasst, wo auch das Voting stattfinden wird. Am Ende des Monats, nach Abschluss des Votings, wird der beste Screenshot in dieser Newsletter präsentiert.

[[Category:De/FlightGear Newsletter|2017 06]]
[[Category:Changes after 2017.2]]

[[en:FlightGear Newsletter June 2017]]

Release plan/Lessons learned

2021-08-13T17:56:43Z

Legoboyvdlp: /* 2016.1 */

{{Release}}
This is a list of '''lessons learned from the previous releases''', things that turned out well and should be kept for the next release as well as thing that didn't turn out so well and should be changed for future releases. Ideally, the [[release plan]] should be updated and augmented so that the lessons learned are incorporated accordingly.

== General ==
{{FGCquote
|1= As mentioned by Curt on previous occasions, one of the more labour intense parts of managing a release consists of the compilation of a comprehensible revision log that lists the major changes / improvements to FlightGear. I would appreciate it if somebody would give a hand in compiling such a list.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/20478104/
| title = <nowiki>[Flightgear-devel] Revision Log / Intended developments</nowiki>
| author = <nowiki>Durk Talsma</nowiki>
| date = Oct 5th, 2008
}}
}}

{{FGCquote
|1= We normally highlight particularly exciting new and improved aircraft, but I have struggled to keep up with the rapid pace of development. Please let me know of any particular aircraft that you think should be included. To qualify they must be in FGDATA, and must have been introduced/improved significantly
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/30366915/
| title = <nowiki>[Flightgear-devel] 2.10.0 Changelog - help required</nowiki>
| author = <nowiki>Stuart Buchanan</nowiki>
| date = Jan 18th, 2013
}}
}}

* I'd instead suggest that aircraft making an incompatible change add a version tag to their data files and discard data files without it. (We could also have a "delete data files on aircraft upgrade" (not core-FG upgrade, aircraft aren't required to have the same release cycle as core FG) *option*, but the aircraft developer should be able to choose whether they want it.)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35441263/
|title = <nowiki> Re: [Flightgear-devel] C172P version in 2016.3.1 broken ASI? </nowiki>
|author = <nowiki> Rebecca N. Palmer </nowiki>
|date = Oct 21st, 2016
|added = Oct 21st, 2016
|script_version = 0.40
}}</ref>

* the best thing would be for aircraft to version their data files individually<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35441430/
|title = <nowiki> Re: [Flightgear-devel] C172P version in 2016.3.1 broken ASI? </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = Oct 21st, 2016
|added = Oct 21st, 2016
|script_version = 0.40
}}</ref>

* FG should save data files also when a user presses the X button in the window decoration, not just when the user goes to File > Exit > Yes<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35440828/
|title = <nowiki> Re: [Flightgear-devel] C172P version in 2016.3.1 broken ASI? </nowiki>
|author = <nowiki> Denk Padje </nowiki>
|date = Oct 20th, 2016
|added = Oct 20th, 2016
|script_version = 0.40
}}</ref>

* When FG initialies itself after the version number has changed, it should either delete old data files (because new aircraft might be incompatible) or somehow migrate the data file (IIRC the issue resolves itself if the user exits via File > Exit > Yes, so possibly FG could load the aircraft, shut it down in order to save a new data file, and then reload new data)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35440828/
|title = <nowiki> Re: [Flightgear-devel] C172P version in 2016.3.1 broken ASI? </nowiki>
|author = <nowiki> Denk Padje </nowiki>
|date = Oct 20th, 2016
|added = Oct 20th, 2016
|script_version = 0.40
}}</ref>

* if an aircraft defines all possible properties in the protocol, it tries to send 14988 bytes per packet, almost 12.5 times the allowed limit! Your idea of sending properties in a round-robin fashion is good IMHO but good MP debugging tools are necessary for aircraft developers.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35441502/
|title = <nowiki> Re: [Flightgear-devel] C172 MP alert on console </nowiki>
|author = <nowiki> Ludovic Brenta </nowiki>
|date = Oct 21st, 2016
|added = Oct 21st, 2016
|script_version = 0.40
}}</ref>

== 2016.3 ==
* I would much prefer we solve this by generating new apt.dat offline and distributing them, rather than ending up with a large number of small apt.dat files, which is not what the maintainers of the main file expect.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35104907/
|title = <nowiki> Re: [Flightgear-devel] apt.dat - add local version ? </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = May 21st, 2016
|added = May 21st, 2016
|script_version = 0.40
}}</ref>

* integration of the maldives scenery took an afternoon to complete. Maybe we can come up with a scripted/automated solution if this should be required again.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35360342/
|title = <nowiki> Re: [Flightgear-devel] Subject: Re: Maldives, once again ;) </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = Sep 10th, 2016
|added = Sep 10th, 2016
|script_version = 0.40
}}</ref> Is there any format this could be submitted which would be easier to incorporate, or is the issue really that the sequence takes too long due to sie? I guess if there's an input format that makes life easier, we could publish it and encourage people to meet it.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35361727/
|title = <nowiki> Re: [Flightgear-devel] Subject: Re: Maldives, once again ;) </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Sep 11th, 2016
|added = Sep 11th, 2016
|script_version = 0.40
}}</ref>
* Regarding the 2016.3.1 RC I've noticed that initialiing subsystems takes a lot longer than in earlier versions of flightgear(1 minute or more compatred to 10 or 15 seconds).<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35362429/
|title = <nowiki> [Flightgear-devel] Boeing 777-200 taking a lot longer during
initializing subsystems in flightgear 2016.3.1 RC </nowiki>
|author = <nowiki> Mihajlo Tomic </nowiki>
|date = Sep 11th, 2016
|added = Sep 11th, 2016
|script_version = 0.40
}}</ref>

* We should probably download a new catalog for each new version upon installation or first run, or at least check the date. I had an out of data catalogue and had to refresh manually.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35362096/
|title = <nowiki> Re: [Flightgear-devel] Release-Candidate 2016.3.1 ready for testing </nowiki>
|author = <nowiki> Richard Harrison </nowiki>
|date = Sep 11th, 2016
|added = Sep 11th, 2016
|script_version = 0.40
}}</ref>

* Are there any remaining changes required to use the new default aircraft catalog: http://mirrors.ibiblio.org/flightgear/ftp/Aircraft/catalog.xml <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35352712/
|title = <nowiki> Re: [Flightgear-devel] Release process 2016.3.1 </nowiki>
|author = <nowiki> Curtis Olson </nowiki>
|date = Sep 7th, 2016
|added = Sep 7th, 2016
|script_version = 0.40
}}</ref>

* The whole "navdb build thing" <ref>{{cite web
|url = {{forum url|p=293163}}
|title = <nowiki> Sqlite errror </nowiki>
|author = <nowiki> WAZZA </nowiki>
|date = Aug 26th, 2016
|added = Aug 26th, 2016
|script_version = 0.40
}}</ref> is proving to be the single most problematic feature added in the last couple of years affecting potentially all users, because unlike most additions, it's not an optional thing, i.e. it must be executed, and is needed for FG to work - given that, it would really make sense exploring to ship a pre-built navdb with future FlightGear releases, or at least factor out the corresponding code so that it can be provided as a standalone executable that is shipped as part of fgfs, so that it can be executed by the installer, without fgfs being affected by it inevitably - that way, troubleshooting related issues should also become much easier, in addition, this separation would facilitate having sync'ed navdbs across multiple instances (think virtual ATC, multiplayer, combat simulation, or even just a fsweekend/linuxTag-like setup). This work would also greatly facilitate turning the navdb into a HLA/IPC-enabled service one day.<ref>{{cite web
|url = {{forum url|p=293128}}
|title = <nowiki> Re: takes a long time to open </nowiki>
|author = <nowiki> Hooray </nowiki>
|date = Aug 25th, 2016
|added = Aug 25th, 2016
|script_version = 0.40
}}</ref>

* would it be possible (for the next release) to put startup defaults/properties in a startup-preferences.xml file and include it in preferences.xml. That would probably make it slightly easier to maintain and may be a start for an automatic update script which automatically generates startup-preferences.xml<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35264900/
|title = <nowiki> Re: [Flightgear-devel] [Flightgear-commitlogs] [FGData] branch next
updated: presets for new default airport SBRJ </nowiki>
|author = <nowiki> Erik Hofman </nowiki>
|date = Aug 6th, 2016
|added = Aug 6th, 2016
|script_version = 0.40
}}</ref>

== 2016.2 ==
=== Catalogs ===
* We need to come up with a solution that doesn’t require me to remember to make a new symlink every time the version number changes<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35104912/
|title = <nowiki> Re: [Flightgear-devel] 2016.2.1 Catalog </nowiki>
|author = <nowiki> James Turner </nowiki>
|date = May 21st, 2016
|added = May 21st, 2016
|script_version = 0.40
}}</ref>, i.e. have a script that checks the version file in fgdata... when that file changes, the catalog symlink is created... if needed also add a new version tag to the catalog file... looking at the current version strings, we're apparently good to go until 2017... which fgdata to look at? perhaps the one that jenkins builds for the release packages? if the symlink already exists, of course do nothing...

=== Model Organization ===
We need to find a better way of organiing models for one of the following releases.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35075151/
|title = <nowiki> Re: [Flightgear-devel] Missing objects - WAS: [Final call for
2016.1.1 "Barcelona" release] </nowiki>
|author = <nowiki> Torsten Dreyer </nowiki>
|date = May 9th, 2016
|added = May 9th, 2016
|script_version = 0.39
}}</ref>

The status which prompted the change was that we had two databases for models - FGData and Scenemodels. At the same time, we had four (at least) use cases for models - static scenery models, shared scenery models, random object models and common models referenced by aircraft. And everything got mixed up somehow.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35075962/
|title = <nowiki> Re: [Flightgear-devel] Missing objects - WAS: [Final call for
2016.1.1 "Barcelona" release] </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = May 10th, 2016
|added = May 10th, 2016
|script_version = 0.39
}}</ref>

== 2016.1 ==
=== Codenames & Standard Airports ===
{{Main article|FlightGear Versioning Scheme based on Airports}}
* {{forum url|p=11381}}
* {{forum url|p=244430|hilit=ksfo+default+release}}
{{FGCquote
|1= part of the discussion was also that the release will be known as 'San Francisco' for the default airport. And that we will change the default airport (and the name) for subsequent releases.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34837768/
| title = <nowiki>Re: [Flightgear-devel] i think 2016.x.x is a bad name</nowiki>
| author = <nowiki>Thorsten Renk</nowiki>
| date = Feb 10th, 2016
}}
}}

{{FGCquote
|1= I feel Gatwick would be a nice place for a start. Schipol, though nice, would negatively disturb Omega's professional ATC. Maiquetia is certainly the most detailed airport in South America, in terms of detail; it is pretty nicely modeled by viveFG. Of course, I wouldn't be too happy about '' my airport '' being full of KSFO people, but then, it would be a nice showcase of what can be done in Blender and WED, as well as Gilberto's beautiful textures. For Asia, Kansai Intl promises to be very nice, but it would be better to wait till at least August, due to the Japan Festival in May. For North America... hmmm... LAX is always there; then there is JFK. The JFK terminal and layout could possibly use some updating; at least, Terminal 4 is incorrect, and I believe some newer taxiways are missing.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34743914/
| title = <nowiki>Re: [Flightgear-devel] Release preparations</nowiki>
| author = <nowiki>legoboyvdlp</nowiki>
| date = Jan 6th, 2016
| added = Jan 6th, 2016
| script_version = 0.23
}}
}}
{{FGCquote
|1= Given the international flavour of our community, I'd suggest somewhere outside of North America for this release, but probably not Frankfurt or one of the airports that regularly hosts serious ATC services. I'm not particularly familiar with what airports have been developed, so I don't have a suggestion to make. A couple of related questions: 1) I assume we are going to include scenery for the selected airport within the release package? 2) The Cessna in-sim tutorials and the cross-country tutorial in The Manual are based around KSFO. Would we want to continue so ship some KSFO scenery with the release to avoid users having to download those areas?
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34746309/
| title = <nowiki>[Flightgear-devel] Airport Choice for 2016.2 (was Re: Release
preparations)</nowiki>
| author = <nowiki>Stuart Buchanan</nowiki>
| date = Jan 7th, 2016
| added = Jan 7th, 2016
| script_version = 0.23
}}
}}

{{FGCquote
|1= To have enough time to prepare this, I'd like to make our first release the "San Francisco" edition.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34744027/
| title = <nowiki>Re: [Flightgear-devel] Release preparations</nowiki>
| author = <nowiki>Torsten Dreyer</nowiki>
| date = Jan 6th, 2016
| added = Jan 6th, 2016
| script_version = 0.23
}}
}}

{{FGCquote
|1= This is definitely becoming one of the most completely modeled locations in FlightGear, guess we should seriously consider making it the default startup location for the next release
|2= {{cite web
| url = {{forum url|p=104646}}
| title = <nowiki>Re: LOWI airport</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Dec 4th, 2010
| added = Dec 4th, 2010
| script_version = 0.23
}}
}}

{{FGCquote
|1= I'm just curious, any significance to using KSFO as a default airport starting or it's just chosen at random?
|2= {{cite web
| url = {{forum url|p=244384}}
| title = <nowiki>Reason for </nowiki>
| author = <nowiki>HJ1AN</nowiki>
| date = May 26th, 2015
| added = May 26th, 2015
| script_version = 0.23
}}
}}

{{FGCquote
|1= <nowiki>I proposed to rotate the default airport each major release to give other airports some exposure. Hence we could use the corresponding airport name as the release name, i.e: 2016.1 ‘Gatwick’ 2016.2 ‘Innsbruck’ 2017.1 ‘Finkenwerder’ 2017.2 ’Schiphol’ .. and so on .. I’m not suggesting to implement this change for 2016.1 of course - it needs some tooling changes to adjust the default scenery which is non-trivial. And no one really seemed that interested last time, so perhaps I am the only person who likes this idea anyway!</nowiki>
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34706595/
| title = <nowiki>Re: [Flightgear-devel] Relesae 3.8</nowiki>
| author = <nowiki>James Turner</nowiki>
| date = Dec 19th, 2015
| added = Dec 19th, 2015
| script_version = 0.23
}}
}}

{{FGCquote
|1= I second that. Over the years FG has seen some pretty dedicated scenery builders at work. It would honor their steady effort to create these great alternatives to KSFO.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34706676/
| title = <nowiki>Re: [Flightgear-devel] Relesae 3.8</nowiki>
| author = <nowiki>Frans de Vre</nowiki>
| date = Dec 19th, 2015
| added = Dec 19th, 2015
| script_version = 0.23
}}
}}

{{FGCquote
|1= <nowiki>+1 on this idea. It nicely addresses several issues.</nowiki>
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34706693/
| title = <nowiki>Re: [Flightgear-devel] Relesae 3.8</nowiki>
| author = <nowiki>Gary Neely</nowiki>
| date = Dec 19th, 2015
| added = Dec 19th, 2015
| script_version = 0.23
}}
}}

{{FGCquote
|1= do like the idea of rotating the default airport and the code naming the release with that airport name. That's pretty clever and cool I think.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34706606/
| title = <nowiki>Re: [Flightgear-devel] Relesae 3.8</nowiki>
| author = <nowiki>Curtis Olson</nowiki>
| date = Dec 19th, 2015
| added = Dec 19th, 2015
| script_version = 0.23
}}
}}

{{FGCquote
|1= It is a cool idea and I think more than a few people liked it last time - the stumbling blocks I remember were the fact that the manual (TM) specifically assumes that you're at KSFO and would have to be re-written - and that it was close to impossible to agree on an airport for us :-)
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34706903/
| title = <nowiki>Re: [Flightgear-devel] Release 3.8</nowiki>
| author = <nowiki>Thorsten Renk</nowiki>
| date = Dec 19th, 2015
| added = Dec 19th, 2015
| script_version = 0.23
}}
}}

{{FGCquote
|1= Yes, that is a neat idea. I suggest to make a 2016.1.1 'San Franciso' in January and start a poll for the location of 2016.2.1. One little detail question: What's the number of the first version in a year? Do we count geek-style/ero-based or natural/one-based (2016.0.1 or 2016.1.1)? I have a tiny tendency towards one-based to start with 2016.1.1 for the release and make current 'next' v2016.0.0.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34710782/
| title = <nowiki>Re: [Flightgear-devel] Release 3.8</nowiki>
| author = <nowiki>Torsten Dreyer</nowiki>
| date = Dec 21st, 2015
}}
}}

== 3.6 ==
=== ChangeLog automation ===
{{FGCquote
|1= There are two manual steps that I usually perform: 1) Generating the latest version of the manual 2) Writing the release note Frankly, updates to the Manual are currently limited to checking that all the menu items are described and incrementing the version number. The latter could be automated by Jenkins I suspect. Writing the release note isn't a massive amount of work, and given that there will be 3 months of logs to check rather than 6, should be a bit less work per-release.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34631381/
| title = <nowiki>Re: [Flightgear-devel] Some thoughts about the release process</nowiki>
| author = <nowiki>Stuart Buchanan</nowiki>
| date = Nov 19th, 2015
}}
}}
{{FGCquote
|1= For the release notes - well, we could prepare some prettyfied git-log if that helps.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34634440/
| title = <nowiki>Re: [Flightgear-devel] Some thoughts about the release process</nowiki>
| author = <nowiki>Torsten Dreyer</nowiki>
| date = Nov 20th, 2015
}}
}}

=== Jenkins (build server) ===
{{FGCquote
|1= Could we have Jenkins continue to build from the release branch after the release is made and copy those to SourceForge as well? That would allow us to easily deliver critical fixes found in a release.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34631381/
| title = <nowiki>Re: [Flightgear-devel] Some thoughts about the release process</nowiki>
| author = <nowiki>Stuart Buchanan</nowiki>
| date = Nov 19th, 2015
}}
}}
{{FGCquote
|1= Jenkins will do the release-number handling anyway. Probably we can just include the version file into the latex compile process?
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34634440/
| title = <nowiki>Re: [Flightgear-devel] Some thoughts about the release process</nowiki>
| author = <nowiki>Torsten Dreyer</nowiki>
| date = Nov 20th, 2015
}}
}}

=== Review & optimize the release plan ? ===
{{FGCquote
|1= You're basically advocating offloading much of the testing to the broad public. In the short term, I agree this is likely to increases the total manpower behind the project. However, it's equally clear that it will decrease release quality - short term at least.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34631380/
| title = <nowiki>Re: [Flightgear-devel] Some thoughts about the release process</nowiki>
| author = <nowiki>Markus Wanner</nowiki>
| date = Nov 19th, 2015
}}
}}

{{FGCquote
|1= My personal experience with relaxed release processes is rather negative. And I don't think release-early-release-often means one shouldn't differentiate between releases of different quality (i.e. beta, RCs, stable). But then again, I'm a Debian Developer. I'm clearly biased.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34631380/
| title = <nowiki>Re: [Flightgear-devel] Some thoughts about the release process</nowiki>
| author = <nowiki>Markus Wanner</nowiki>
| date = Nov 19th, 2015
}}
}}

{{FGCquote
|1= I can barely keep up packaging two releases per year for Debian. I certainly can't do four. So I'd have to decide which ones to pick.[...]I'd appreciate fewer releases with higher quality, rather than the opposite.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34631284/
| title = <nowiki>Re: [Flightgear-devel] Some thoughts about the release process</nowiki>
| author = <nowiki>Markus Wanner</nowiki>
| date = Nov 19th, 2015
}}
}}

{{FGCquote
|1= When we started the release plan, I had much time during summer/winter holidays. If I had to do it again, I would have avoided thoses seasons.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34631277/
| title = <nowiki>Re: [Flightgear-devel] Some thoughts about the release process</nowiki>
| author = <nowiki>Torsten Dreyer</nowiki>
| date = Nov 19th, 2015
}}
}}

{{FGCquote
|1= "Release early, release often" is result of other peoples experience and so is the idea behind "Agile" development where you create something potentially deliverable every 2 weeks. To be honest, I was even thinking about having monthly releases. Given the relative low number of contributors at the moment, I just expected that we'd create subsequent releases with no change but the version number.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34631277/
| title = <nowiki>Re: [Flightgear-devel] Some thoughts about the release process</nowiki>
| author = <nowiki>Torsten Dreyer</nowiki>
| date = Nov 19th, 2015
}}
}}

{{FGCquote
|1= The major flaws I've perceived in the release processes I have witnessed are a) release candidates came out too late, giving barely a week of testing and feedback, not enough time to do fixing b) users not adopting and testing the release candidate with the argument that they'd 'wait for the stable version' c) real life of many people (especially during summer holidays) interfering with the ability to deal with bug reports
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34631200/
| title = <nowiki>Re: [Flightgear-devel] Some thoughts about the release process</nowiki>
| author = <nowiki>Thorsten Renk</nowiki>
| date = Nov 19th, 2015
}}
}}

{{FGCquote
|1= one of the things we've encountered in past release cycles is that it seems like it takes some extra effort (James?) to configure Jenkins to do release candidate builds, and because of that we often haven't had release candidates until very late (i.e. days before the official release, sometimes after.) But if Jenkins can automatically build release candidates, that would be wonderful.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34627418/
| title = <nowiki>Re: [Flightgear-devel] Some thoughts about the release process</nowiki>
| author = <nowiki>Curtis Olson</nowiki>
| date = Nov 17th, 2015
}}
}}

{{FGCquote
|1= Today, thanks to James, Clement and Gene, we have Jenkins that basically creates a complete release after every commit in our source repository. Because of this and because human resources have become more precious than ever, I'd like to discuss a new release plan for FlightGear here.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34627074/
| title = <nowiki>[Flightgear-devel] Some thoughts about the release process</nowiki>
| author = <nowiki>Torsten Dreyer</nowiki>
| date = Nov 17th, 2015
}}
}}

{{FGCquote
|1= The steps required to release a software product are usually quite intense and take a -lot- of time. There were also Northern hemisphere holiday related delays. The release process is ongoing, but patience is required
|2= {{cite web
| url = {{forum url|p=256506}}
| title = <nowiki>Re: FlightGear 3.4/5/6/7 - please help me understand</nowiki>
| author = <nowiki>bugman</nowiki>
| date = Sep 8th, 2015
}}
}}

{{FGCquote
|1= Because creating a release requires that certain people do certain things and that the last show-stopper bugs (e.g. is the Mac build ok now? The Windows build?) have been solved. All by a small number of people (some quite non-interchangeable due to limited access to certain resources) working on their spare time.
|2= {{cite web
| url = {{forum url|p=256513}}
| title = <nowiki>Re: FlightGear 3.4/5/6/7 - please help me understand</nowiki>
| author = <nowiki>AndersG</nowiki>
| date = Sep 8th, 2015
}}
}}

{{FGCquote
|1= there is currently no defined status of 3.6 due to lack of (human) resources. Some of us have thought about refactoring the release schedule due to the fact that a freee around christmas and a release during summer holidays is very unfortunate. So far, there are no clear results from these thoughts available. The entire process is somewhat volatile at the moment. Sorry for any inconvenience that may cause.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34606005/
| title = <nowiki>Re: [Flightgear-devel] Status of Release 3.6</nowiki>
| author = <nowiki>Torsten Dreyer</nowiki>
| date = Nov 9th, 2015
}}
}}

{{FGCquote|1= I just know from other conversations that quite a few people are on holiday. I guess we'll just have to wait. Maybe trying to do a summer release is a bit awkward in the first place and we should reconsider the idea? |2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34402855/ | title = <nowiki>Re: [Flightgear-devel] FGAddon freeze for 3.6?</nowiki> | author = <nowiki>Renk, Thorsten</nowiki> | date = Aug 25th, 2015 }}}}

{{FGCquote
|1= In general, I see there being two fundamental approaches for the approach to the release. First, time based. Target a date and taint that date with a realistic set of hoped for features, what is ready is what is ready. What is not, slips to the next release. Second, feature based. Target a set of features, allowing it to be tainted with a reasonably realistic date. When the features are complete, the release is made. Which is preferred approach for those on the list? Can I suggest a wiki page to provide a focus for burning down issues prior to the release?
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/20544310/
| title = <nowiki>[Flightgear-devel] Towards a release - Re: Revision Log / Intended
developments</nowiki>
| author = <nowiki>Matthew Tippett</nowiki>
| date = Oct 13th, 2008
}}
}}

=== Code names instead of version numbers? ===
{{FGCquote
|1= What happened to the idea of naming releases after an airport/a scenery? I rather liked that
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34742832/
| title = <nowiki>Re: [Flightgear-devel] Release preparations</nowiki>
| author = <nowiki>Thorsten Renk</nowiki>
| date = Jan 6th, 2016
| added = Jan 6th, 2016
| script_version = 0.23
}}
}}

{{FGCquote
|1= Just a cray random thought, perhaps, like many other software we could add a codename for each release. It could be a just-for-fun thing, or you could think of it as a way to divert the attention away from the version number, just in case you don't like the number.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/15646733/
| title = <nowiki>Re: [Flightgear-devel] Informal version number poll</nowiki>
| author = <nowiki>Pigeon</nowiki>
| date = Nov 30th, 2007
}}
}}

{{FGCquote
|1= People also seem to assign expectations to a product based on the way it's version number looks. Commercial companies realie this and try to leverage it to a competitive advantage (my version number is higher or better than your version number!) FlightGear doesn't compete commercially so we don't have to play dumb psychological games with consumers -- we could, we just don't have to if we don't want to.
|2= {{cite web
| url = {{forum url|p=178351}}
| title = <nowiki>Re: the way each version is numbered is confusing</nowiki>
| author = <nowiki>curt</nowiki>
| date = Feb 27th, 2013
}}
}}

{{FGCquote
|1= the accomplishment of switching from 1.x to 2.x and to 3.x still does mean something to many people, not just FG "outsiders" (or new users), but also long-term contributors, as was mentioned by Torsten on the devel list:
http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38888.html
|2= {{cite web
| url = {{forum url|p=178353}}
| title = <nowiki>Re: the way each version is numbered is confusing</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Feb 27th, 2013
}}
}}

{{FGCquote
|1= why not call it flightgear 2013.... and flightgear 2014 ?
|2= {{cite web
| url = {{forum url|p=186390}}
| title = <nowiki>Re: Clouds</nowiki>
| author = <nowiki>Bomber</nowiki>
| date = Jul 7th, 2013
}}
}}

{{FGCquote
|1= the whole major/minor concept is clearly irritating to people not familiar with software development and labeling schemes, which is why software is often versioned using code names or simply years: '''FlightGear 2013-1''' or '''FlightGear 2013-2''', '''FlightGear 2013-ALPHA''' or '''FlightGear 2013-BRAVO'''
|2= {{cite web
| url = {{forum url|p=178334}}
| title = <nowiki>Re: the way each version is numbered is confusing</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Feb 27th, 2013
}}
}}

{{FGCquote
|1= Ultimately, it probably isn't worth the hassle - and we should identify the whole scheme as a bottleneck and come up with something less prone to interpretation and subjective opinions, i.e. having releases in the form of "FlightGear 2013/1" or "FlightGear 2013/2" - or even just code names.
|2= {{cite web
| url = {{forum url|p=185619}}
| title = <nowiki>to put things into perspective ...</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Jun 23rd, 2013
}}
}}

{{FGCquote
|1= "first impressions" would be hugely different if we were to start an orchestrated effort to bundle our most-developed features (aircraft, scenery, addons) together, instead of offering an infinite number of more or less developed options to our end-users.
We have some extremely well-developed aircraft and scenery, such as the Seneca, the 777 - France, LOWI. It would just be a matter of packaging these as "positive examples" for a release - even if that would just be a downstripped "preview" release, it would go a long way to demonstrate what FG is capable of:
{{forum link|p=170522|title=Help needed - market research for FG}}
|2= {{cite web
| url = {{forum url|p=175192}}
| title = <nowiki>Re: Help needed - market research for FG</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Jan 24th, 2013
}}
}}

{{FGCquote
|1= in terms of making some of our more advanced aircraft/airports more prominent. I think I read about this on the wiki:

For instance, we are currently having two releases per year. But we've been using KSFO/c172p as the standard startup settings for many years.

Personally, I would think that it would be a great incentive for aircraft and scenery developers if we could have polls prior to each release phase to determine which airport/aircraft is going to be the defaults for the next release.
For example, just look at all the fantastic work done for LOWI - or amaing aircraft like the Seneca.

I could imagine we could make such work more prominent by changing the defaults for each release accordingly.

And we could then also change our release naming accordingl: FlightGear 3.2 (LOWI/Seneca)
That would go a long way to demonstrate to NEW users that we really have AWESOME scenery and extremely well-developed airports.

The current situation works such that only the "insiders" know about such things, and know how to download/install/configure everything.

And the screen shot competitions that we've had also demonstrate that we have an active community interested in contributing to polls.

So why not use polls AFTER each release to directly determine which aircraft/airport will be featured in the upcoming release?

That would give us plenty of time to focus on the corresponding scenery/aircraft, and to give other contributors a chance to even improve things further.
|2= {{cite web
| url = {{forum url|p=170522}}
| title = <nowiki>Re: Help needed - market research for FG</nowiki>
| author = <nowiki>Hooray</nowiki>
| date = Nov 13th, 2012
}}
}}

=== Scenery versioning ===
{{FGCquote
|1= It is a bit of a mess, Martin had his own way of doing things and didn't really seem to care about or pay attention to the FlightGear release cycle so our numbers got out of sync. I can try to take a look at this over the weekend....
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34565300/
| title = <nowiki>Re: [Flightgear-devel] Scenery versioning</nowiki>
| author = <nowiki>Curtis Olson</nowiki>
| date = Oct 23rd, 2015
}}
}}

{{FGCquote
|1= I'm thinking with things the way they are, pages created and databases mirrored around the world it might be clever after the rebuild of the scenery that will replace the current 2.0 scenery, to go back to the version-of-FG numbers, simply because, like said the enormous work of the past and because that number will always be linked to when the scenery was/is created. I understand that simgear and flightgear are sync'd in such a maner.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34569098/
| title = <nowiki>Re: [Flightgear-devel] Scenery versioning</nowiki>
| author = <nowiki>Ray St. Marie</nowiki>
| date = Oct 26th, 2015
}}
}}

{{FGCquote
|1= unlike FG and SG which have strong dependencies (try compiling FG 3.7 against SG 2.12 and see what happens), the scenery-core dependency is much weaker - FG 3.7 will actually run fine with the scenery from 2.12 (that would be World Scenery 1.0.1 I guess). So there's no need to update the scenery version number when it really hasn't changed, and scenery versioning can reflect actual re-builds for clarity.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34569211/
| title = <nowiki>Re: [Flightgear-devel] Scenery versioning</nowiki>
| author = <nowiki>Thorsten Renk</nowiki>
| date = Oct 26th, 2015
}}
}}

== 3.4 ==
=== PUI fonts affected by features using effects/shaders (Rembrandt/ALS) ===
{{Note|Also see {{Issue|1730}} }}
{{FGCquote
|I notice that the first item in flightgear menus is missing if I use the property sim "--prop:/sim/rendering/multi-samples{{=}}3",
|{{cite web |url={{forum url|p=237489}}
|title=<nowiki>Missing label menus if /rendering/multi-samples is enabled</nowiki>
|author=<nowiki>Curtis</nowiki>
|date=<nowiki>Wed Apr 01</nowiki>
}}
}}

{{FGCquote
|This is something to do with the builtin bitmapped font and shaders as it affects me when I have either rembrandt or ALS turned on;
If you change the gui current style in either preferences or autosave to 0 it'll use a real font which fixes it mostly (there are still certain elements in the GUI such as MP Pilot list that use the builtin font)
|{{cite web |url={{forum url|p=237617}}
|title=<nowiki>Re: Missing label menus if /rendering/multi-samples is enabl</nowiki>
|author=<nowiki>Richard</nowiki>
|date=<nowiki>Thu Apr 02</nowiki>
}}
}}

=== Scenery not loading ===
{{FGCquote
|it just says "Loading Scenery" and doesnt load.
|{{cite web |url={{forum url|p=234640}}
|title=<nowiki>Why is my Flightgear still saying Loading Scenery?</nowiki>
|author=<nowiki>JackT44</nowiki>
|date=<nowiki>Mon Mar 09</nowiki>
}}
}}

=== Selecting Parking Positions ===
{{FGCquote
|not able to choose under menue Select an Airport /Aircraft Position /Parking<br/>
an exist Parkposition.<br/>
<br/>
For example, select the airport EDDF. Under Aircraft Position you choose Parking positions. Set the cursor in the yellow case and you got the<br/>
announcement " Parking position not found ".
|{{cite web |url={{forum url|p=234563}}
|title=<nowiki>3.4. Selecting airports...Aircraft Position...</nowiki>
|author=<nowiki>D-ABBA</nowiki>
|date=<nowiki>Sun Mar 08</nowiki>
}}
}}

=== Qt5/Mac launcher debate ===
{{FGCquote
|Related to Qt, I can say that up to now - as far as I can tell - only a simple replacement for the Mac Launcher has been introduced. This is not related to the internal user interface of FlightGear, at least for now. If, how and when the internal gui can leverage Qt is under investigation and in such an early state that those responsible preferred to not announce anything yet. If this ever happens, this will be discussed on the mailing list
|{{cite web |url={{forum url|p=229563}}
|title=<nowiki>Re: FlightGear GUI hell: PUI, Canvas GUI, Mongoose, </nowiki>
|author=<nowiki>Torsten</nowiki>
|date=<nowiki>Sun Jan 11</nowiki>
}}
}}

=== Mid-term Project Goals? ===
{{FGCquote
|Has FlightGear got a list of goals for 5-10 years? How about making or adding to it?
|{{cite web |url={{forum url|p=229633}}
|title=<nowiki>5-10 Year Goals?</nowiki>
|author=<nowiki>legoboyvdlp</nowiki>
|date=<nowiki>Tue Jan 13</nowiki>
}}
}}

{{FGCquote
|One of my observations as an observer with just enough knowledge to understand the situation, from a distance, is that it would be extremely helpful for this project to come to some kind of a consensuses. This free-for-all is confusing and counter productive. Even if a few, or many, core developers know what is going on and are in lockstep, it is very disheartening to contemplate helping or contributing to anything "major" as you have the appearance of no consensuses.
I see advertisements for needed help everywhere I look, but many are not willing to spend significant time on anything that may be in vain.
|{{cite web |url={{forum url|p=231383}}
|title=<nowiki>Re: Aircraft center: </nowiki>
|author=<nowiki>wlbragg</nowiki>
|date=<nowiki>Thu Feb 05</nowiki>
}}
}}

{{FGCquote
|Following on from the recent discussions about git/svn and attribution on the -devellist, and discussions about the structure and the future of the project on the forum, the group of developers who get together on a weekly Google Hangout organized by Curt realized that we would benefit from a more detailed policy document and roadmap than the high level statement available at [http://www.flightgear.org/about/ http://www.flightgear.org/about/].<br/>
<br/>
There is a draft document circulating on the -devel list ([http://sourceforge.net/p/flightgear/mailman/message/34183645/ http://sourceforge.net/p/flightgear/mailman/message/34183645/]). If you'd like to comment and take part in the discussion, please subscriber to the -devel list
| {{cite web
| url = {{forum url|p=246162}}
| title = <nowiki>FlightGear Policy and Roadmap Documents</nowiki>
| author = <nowiki>stuart</nowiki>
| date = Jun 8th, 2015
}}
}}

=== FlightGear on 32 bit Windows ===
{{FGCquote
|The point I am getting at is we have a ton of 32 bit windows users trying to download and run FlightGear. Out of the box with the startup defaults that pretty much doesn't work right now. This is leading to a ton of bug reports, a ton of frustrated new users, and a general perception that FlightGear is a POS that isn't worth messing with.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33353889/
|title=<nowiki>Re: [Flightgear-devel] FlightGear on low (<=4GB) memory systems</nowiki>
|author=<nowiki>Curtis Olson</nowiki>
|date=<nowiki>2015-02-05</nowiki>
}}
}}

=== FileSelection on Windows hidden by fullscreen Window ===
{{FGCquote
|In FG 3.4 (full screen mode) I wondered what happens when I try to set e.g. the '''Screenshot Directory''' ?
the new and nice designed Fileselection box is just not displayed, because it is hidden below the full screened FG main window ...

|{{cite web |url={{forum url|p=234056}}
|title=<nowiki>FG 3.4 Windows: File Selection Box</nowiki>
|author=<nowiki>mhab</nowiki>
|date=<nowiki>Wed Mar 04</nowiki>
}}
}}

=== No LOD for aircraft previews in fgrun causing lag ===
{{FGCquote
|Models (and liveries) take some time to load, if the model (livery,...) is very detailed, that time may be substantial. That's all there is to it. Just wait it out. (When I ask the launcher to get me a preview of the Vostok for instance, I get a 5 second freeze. Given the vertex count of the beast, I'm not surprised.)
(In principle, we could load a simplified 3d model in the launcher, but I doubt it would be worth the trouble asking people to provide that).
|{{cite web |url={{forum url|p=227686}}
|title=<nowiki>Re: Flight Gear not responding</nowiki>
|author=<nowiki>Thorsten</nowiki>
|date=<nowiki>Sun Dec 21</nowiki>
}}
}}

=== Broken FGCom cleanup triggers crashrpt during process termination ===
{{FGCquote
|Shut off FGcom, no more need to report constantly.
|{{cite web |url={{forum url|p=232207}}
|title=<nowiki>SOLVED: Re: FG3.2 wants to always send error report</nowiki>
|author=<nowiki>clrCoda</nowiki>
|date=<nowiki>Mon Feb 16</nowiki>
}}
}}

=== repare_ground_cache(): scenery_available returns false ===
{{FGCquote
|A fortunate coincidence, I have just experienced this, too and was able to<br/>
gather some logging.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33555237/
|title=<nowiki>Re: [Flightgear-devel] prepare_ground_cache(): scenery_available
returns false</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2015-03-06</nowiki>
}}
}}

=== Crash due to corrupt NavDB ===
{{FGCquote
|at least on my 10.7 build, I’m seeing an issue with the nav-cache not initialising. This is actually good, because it gives me a way, finally, to trace down the ‘nav-cache never initialises’ bug that some folks have reported. But it will take a little time. Since the same binary works perfectly on my 10.10 box, I assume it’s something /very/ subtle, probably uninitialised memory or some tiny change in zlib’s gzread functions (since we use the system Zlib library which hence could be different between 10.7 and 10.10).
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33457470/
|title=<nowiki>Re: [Flightgear-devel] Release 3.4.0 is coming</nowiki>
|author=<nowiki>James Turner</nowiki>
|date=<nowiki>2015-02-18</nowiki>
}}
}}

{{FGCquote
|Is this a fresh "clean" install or are you installing it after 3.2?<br/>
If after 3.2 try renaming <br/>
C:\Users\USERNAME\AppData\Roaming\flightgear.org to C:\Users\USERNAME\AppData\Roaming\flightgear.BAK<br/>
Then restart FG and let it rebuild all cache. You will have to setup your configuration again.
|{{cite web |url={{forum url|p=232502}}
|title=<nowiki>Re: 3.4 </nowiki>
|author=<nowiki>wlbragg</nowiki>
|date=<nowiki>Thu Feb 19</nowiki>
}}
}}

{{FGCquote
|there's currently a bug in FG 3.2 (under investigation) that makes the simulator crash when you upgrade from FG 3.0 to 3.2, and it seems FG 3.2 crashes even before writing to the log.
|{{cite web |url={{forum url|p=228177}}
|title=<nowiki>Re: Problems getting FG running</nowiki>
|author=<nowiki>elgaton</nowiki>
|date=<nowiki>Fri Dec 26</nowiki>
}}
}}

=== Instant Crashes ===
{{FGCquote
|FlightGear 3.4.0 Fails after initializing subsystems and then I received a crash report<br/>
with other data.<br/>
3.4.0 RC1 and 2 also failed
|{{cite web |url={{forum url|p=232565}}
|title=<nowiki>FlightGear 3.4.0 Fails after initializing subsystems</nowiki>
|author=<nowiki>matt1717don</nowiki>
|date=<nowiki>Thu Feb 19</nowiki>
}}
}}

{{FGCquote
|It gets to "Loading Navigation (something)" then crashes. As opposed to, essentially, flashing up for a split second like it does with Terrasync enabled.<br/>
<br/>
<br/>
EDIT: With the minimal startup profile -> still crashes!
|{{cite web |url={{forum url|p=233363}}
|title=<nowiki>Re: 3.4.0 instantly crashes</nowiki>
|author=<nowiki>Figaro</nowiki>
|date=<nowiki>Fri Feb 27</nowiki>
}}
}}

=== Route Manager Crash/freezing ===
{{FGCquote
|The only problem is that the route manager crash every time I want to open it. Thats the same problem I had with FG 3.2
|{{cite web |url={{forum url|p=234167}}
|title=<nowiki>Re: Flightgear 3.4 on Yosemite</nowiki>
|author=<nowiki>Niki</nowiki>
|date=<nowiki>Thu Mar 05</nowiki>
}}
}}

{{FGCquote
|I have problems with route manager, fg just freezes every time I try to use route manager. On every aircraft
|{{cite web |url={{forum url|p=237179}}
|title=<nowiki> </nowiki>
|author=<nowiki>VladimirZ</nowiki>
|date=<nowiki>Sun Mar 29</nowiki>
}}
}}

=== Multithreading Issue ===
{{FGCquote
|Looks like a multi threading issue to me. When I run FlightGear with multiple screens and multiple cameras, the highes threading mode for OpenSceneGraph that works reliable is '''CullDrawThreadPerContext''' while the '''CullThreadPerCameraDrawThreadPerContext''' quickly leads to a crash.
|{{cite web |url={{forum url|p=228282}}
|title=<nowiki>Re: Error when trying to run FlightGear with three monitors</nowiki>
|author=<nowiki>Torsten</nowiki>
|date=<nowiki>Sun Dec 28</nowiki>
}}
}}

=== Intel GPU Support ===
{{FGCquote
|Has any dev tried to disable their nvidia card and use their built-in intel GPU for once?
|{{cite web |url={{forum url|p=218382}}
|title=<nowiki>Re: 3.2rc1 Overall impression</nowiki>
|author=<nowiki>onox</nowiki>
|date=<nowiki>Sat Sep 13</nowiki>
}}
}}

=== More widespread testing ===
{{FGCquote
|We could be using our most talented, experience sim pilots to produce more of the necessary tests during release candidates rather than after release. <br/>
<br/>
There has to be a way to have a stable release AND a testing suite of the release candidate that co-exist in order to be the helpers we would like to be.
|{{cite web |url={{forum url|p=231852}}
|title=<nowiki>Re: RC 3.4</nowiki>
|author=<nowiki>clrCoda</nowiki>
|date=<nowiki>Wed Feb 11</nowiki>
}}
}}

{{FGCquote
|ideally, people doing such flights regularly would provide a corresponding "fgtape" file using a standard aircraft and get this committed to $FG_ROOT into some kind of "Tests" directory containing pre-recorded flights for doing regression testing in an automated fashion. The thing to keep in mind here is that those among us able (and willing) to troubleshoot such issues are most unlikely to ever actually use FlightGear like this, which certainly includes Zakalawe. Thorsten recently also mentioned that he'll typically just start up FlightGear a few dozen of times using a simple aircraft to test things, without really doing any "real" flying at all. So there are certainly a number of use-cases that aren't getting much attention unfortunately.<br/>
Which is why it would be a good idea for people to provide flight recorder tapes covering use-cases they care about, and get those committed to fgroot (fgdata) - so that we can grow a library of useful flights to do regression testing - as long as those flights are using standard aircraft and features, they should also be useful for people entirely new to FlightGear.
|{{cite web |url={{forum url|p=233211}}
|title=<nowiki>Re: 3.4 and the pain begins ...</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Thu Feb 26</nowiki>
}}
}}

=== legacy GUI Z-ordering issue (PUI) ===
{{FGCquote
|if i have the radio dialogue (F12) and the map dialogue (CTRL-M) open with one overlapping the other, when i release my left mouse button on the top dialogue in a position over a portion of the lower dialogue, the lower one will pop to the top
|{{cite web |url={{forum url|p=233315}}
|title=<nowiki>GUI dialog box Z-ordering</nowiki>
|author=<nowiki>wkitty42</nowiki>
|date=<nowiki>Thu Feb 26</nowiki>
}}
}}

{{FGCquote
|Dialog z-ordering (fighting?) is my biggest annoyance with the current GUI
|{{cite web |url={{forum url|p=233595}}
|title=<nowiki>Re: GUI dialog box Z-ordering</nowiki>
|author=<nowiki>Johan G</nowiki>
|date=<nowiki>Sun Mar 01</nowiki>
}}
}}

=== ALS impact on PUI styles for ATI/AMD cards ===
{{FGCquote
|There are a lot topics concerning AMD graphic cards with flickering problems, but that seems not to match with the issue i have. Maybe there is someone who has or had the same problem and could solve it.
|{{cite web |url={{forum url|p=234492}}
|title=<nowiki>No Text displayed when using ALS</nowiki>
|author=<nowiki>Solid</nowiki>
|date=<nowiki>Sun Mar 08</nowiki>
}}
}}

{{FGCquote
|When I use either of Rembrandt or Atmospheric Light Scattering, some of the text in the menus disappear, with various bits of text disappearing then reappearing every second
|{{cite web |url={{forum url|p=201328}}
|title=<nowiki>Corrupt textures when using Rembrandt or ALS</nowiki>
|author=<nowiki>Stevy</nowiki>
|date=<nowiki>Thu Feb 20</nowiki>
}}
}}

{{FGCquote
|n the HUD (windows, menus), labels tend to be clipped. You can see this, on the previous image, in the rendering options window.<br/>
And that's more visible when I enable the atmospheric light scattering
|{{cite web |url={{forum url|p=202508}}
|title=<nowiki>Flightgear doesn't use 100% of the workload and Fonts bug</nowiki>
|author=<nowiki>Saga</nowiki>
|date=<nowiki>Tue Mar 04</nowiki>
}}
}}

{{FGCquote
|I've succeed to partially circumvent the problem (not solved it). Menu, windows are displayed well unlike labels directly displayed on the screen like "Airspeed exceed vne". You must change the style of the gui in data/preferences.xml
|{{cite web |url={{forum url|p=207870}}
|title=<nowiki>Re: Flightgear doesn't use 100% of the workload and GUI clip</nowiki>
|author=<nowiki>Saga</nowiki>
|date=<nowiki>Fri May 02</nowiki>
}}
}}

{{FGCquote
|JUST CHANGE THE 1 to a 2 in<br/>
<br/>
/FGROOT/preferences.xml
|{{cite web |url={{forum url|p=218196}}
|title=<nowiki>For people with amd graphics </nowiki>
|author=<nowiki>cain071546</nowiki>
|date=<nowiki>Wed Sep 10</nowiki>
}}
}}

{{FGCquote
|the fact to just change the font seems to solve the bug (just for some labels). I've spotted a font which don't provoke it (lucida.txf)
|{{cite web |url={{forum url|p=212615}}
|title=<nowiki>Re: Flightgear doesn't use 100% of the workload and GUI clip</nowiki>
|author=<nowiki>Saga</nowiki>
|date=<nowiki>Sun Jun 15</nowiki>
}}
}}

=== Release Schedule ===
{{FGCquote
|I cannot guarantee for this to be the case in the future, nor is it even likely to happen again. Thus, if the release cycles of Ubuntu and FlightGear stays the same, I fear the next newest FlightGear won't make it into the newest Ubuntu release.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33458290/
|title=<nowiki>Re: [Flightgear-devel] Release 3.4.0 is coming</nowiki>
|author=<nowiki>Markus Wanner</nowiki>
|date=<nowiki>2015-02-18</nowiki>
}}
}}

=== Updating "Catalog Metadata" version, vars and data paths ===
Something that appears to have fallen through the cracks is the Experimental Aircraft Center Catalog creation and version update. Need to implement some automatic feature to handle these type of routine version updates.

=== Windows: Installer Issues ===
{{FGCquote
|Today I installed FlightGear on a 32 bit windows laptop that had an<br/>
existing v3.2 install already loaded. I ran into several issues that I<br/>
would consider suboptimal and so I'm posting them here for discussion and<br/>
possible improvement.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33348310/
|title=<nowiki>[Flightgear-devel] FlightGear 3.4 RC1 (Windows) feedback</nowiki>
|author=<nowiki>Curtis Olson</nowiki>
|date=<nowiki>2015-02-04</nowiki>
}}
}}

{{FGCquote
|The installer came up and wanted to install FlightGear-3.4.0 into<br/>
FlightGear-3.2.0's folder. I had to manually switch this to<br/>
FlightGear-3.4.0. I don't think it should work like this, should it? If<br/>
we are going to install into FlightGear-v<anything> shouldn't we make sure<br/>
it's the right number?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33348310/
|title=<nowiki>[Flightgear-devel] FlightGear 3.4 RC1 (Windows) feedback</nowiki>
|author=<nowiki>Curtis Olson</nowiki>
|date=<nowiki>2015-02-04</nowiki>
}}
}}

{{FGCquote
| If I don't choose any aircraft at all, the default comes up as the C172<br/>
with a 2D panel. Again is that really what we want? Is it time to<br/>
deprecate the 2d panel version? Also the way the launcher window is<br/>
constructed, the information saying this is a 2d panel version is off the<br/>
screen so had to go to the bottom and scroll side to side to see it. I<br/>
imagine a lot of first time users wouldn't think or know to do this?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33348310/
|title=<nowiki>[Flightgear-devel] FlightGear 3.4 RC1 (Windows) feedback</nowiki>
|author=<nowiki>Curtis Olson</nowiki>
|date=<nowiki>2015-02-04</nowiki>
}}
}}

{{FGCquote
|Again, without selecting any airport, the launcher chose 17CL for me<br/>
which is some random little bitty strip I don't even know where. Wouldn't<br/>
we want to start in SFO? Wasn't that always our intent?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33348310/
|title=<nowiki>[Flightgear-devel] FlightGear 3.4 RC1 (Windows) feedback</nowiki>
|author=<nowiki>Curtis Olson</nowiki>
|date=<nowiki>2015-02-04</nowiki>
}}
}}

{{FGCquote
|FlightGear 3.4 is essentially unusable on a 32 bit windows system<br/>
outside of very remote/simple areas with no scenery. Should we consider<br/>
seeing if we can just abort the installer on a 32 bit system and quit<br/>
pretending like maybe it should work? It just doesn't so we could save<br/>
users with 32 bit systems a whole lot of time if we just bail out of the<br/>
installer. Is there any reason we shouldn't at least list a 64 bit system<br/>
as a minimum requirement now for FlightGear?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33348310/
|title=<nowiki>[Flightgear-devel] FlightGear 3.4 RC1 (Windows) feedback</nowiki>
|author=<nowiki>Curtis Olson</nowiki>
|date=<nowiki>2015-02-04</nowiki>
}}
}}

{{FGCquote
|I seem to recall that there was some work on reducing the memory footprint<br/>
of FlightGear. Did any of those changes make it into the 3.4 branch?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33348310/
|title=<nowiki>[Flightgear-devel] FlightGear 3.4 RC1 (Windows) feedback</nowiki>
|author=<nowiki>Curtis Olson</nowiki>
|date=<nowiki>2015-02-04</nowiki>
}}
}}

=== Updating Dependencies ===
* Updating the SG/FG source trees for dependencies (JSBSim, OpenSceneGraph etc) should be done right at the beginning of the new release cycle, or at least be closely coordinated.

=== Bugfix releases ===
* {{thumbs down}} In case a serious bug is found, there should be a process in place to create and distribute a bugfix release as soon as possible.
--[[User:Elgaton|Elgaton]] ([[User talk:Elgaton|talk]]) 05:31, 16 March 2015 (EDT)

== 3.2 ==
* {{thumbs down}} The release should not be announced ''only'' on the main web page. It should also be announced on the following places:
** The official forum
** The developer list
** The newsletter

: As things turned out this time around, most of our users seem unaware that a new version have been released.

: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 19:33, 18 October 2014 (UTC)

=== {{thumbs down}}Advice users to delete residual settings from previous versions. ===
After upgrading to 3.2 on Windows 7, I struggled with strange rendering, misbehaving TerraSync and endless crash on load until I found out that the old 3.0 settings were still there in the Roaming folder. After simply deleting this folder ( ''C:\Users\USERNAME\AppData\Roaming\flightgear.org\'' ), and reinstalling FlightGear, I think, there was never any more trouble and everything worked perfectly.
--[[User:Jarl Arntzen|Jarl Arntzen]] ([[User talk:Jarl Arntzen|talk]]) 19:03, 22 November 2014 (UTC)

== 3.0 ==
=== JSBSim Sync ===
{{cquote|<nowiki>One point that might be worth considering is whether we want to update JSBSim now or not. OTOH one consequence of updating is that there might be need to adjust some FDM configurations (I have no clear picture what has changed in JSBSim/CVS since the last update and therefore the size of that risk).
Otherwise we leave the update to post-3.0.0. </nowiki><ref>{{cite web
|url=http://sourceforge.net/p/flightgear/mailman/message/31762311/
|title=<nowiki>Release preparations - feature freeze starts today</nowiki>|author=<nowiki>Anders Gidenstam</nowiki>|date=<nowiki>2013-12-17 21:15:58</nowiki>}}</ref>|<nowiki>Anders Gidenstam</nowiki>}}

{{cquote|<nowiki>I did not see this coming (feature freeze) and, yes, there are some important changes in JSBSim that should be updated. I need to merge some offline changes into JSBSim CVS first, though.</nowiki><ref>{{cite web
|url=http://sourceforge.net/p/flightgear/mailman/message/31762311/
|title=<nowiki>Release preparations - feature freeze starts today</nowiki>|author=<nowiki>Jon S. Berndt</nowiki>|date=<nowiki>2013-12-17 21:15:58</nowiki>}}</ref>|<nowiki>Jon S. Berndt</nowiki>}}

{{cquote|<nowiki>I Guess it's too late to integrate the latest JSBSim code now?</nowiki><ref>{{cite web
|url=http://sourceforge.net/p/flightgear/mailman/message/31856512/
|title=<nowiki>Release preparations: version number is now 3.0.0</nowiki>|author=<nowiki>Erik Hofman</nowiki>|date=<nowiki>2014-01-17 10:27:53</nowiki>}}</ref>|<nowiki>Erik Hofman</nowiki>}}

<references/>

=== Merge Request Handling ===
{{cquote|<nowiki>Fact is, merge requests do get ignored most of the time, unless you know one of the active developers. I had a merge request pending for three months to update my own code in the tree, not touching anything else. It wasn't downright rejected, but was ignored for enough time for me to start working on
something else. Hence I'm not posting any more merge requests and instead I'm keeping my own separate tree (let's not call it fork, since I'm the only
user). Though I admit, sometimes it's a major pain to keep up with changes in the main tree.</nowiki><ref>{{cite web
|url=http://sourceforge.net/p/flightgear/mailman/message/31754689/
|title=<nowiki>osgEarth integration into FG 3.0</nowiki>|author=<nowiki>Adrian Musceac</nowiki>|date=<nowiki>2013-12-16 06:12:12</nowiki>}}</ref>|<nowiki>Adrian Musceac</nowiki>}}

{{cquote|<nowiki>I can sympathize with the developers. I do know they have their personal agendas, limited time, and a lot to do without having to bother
with external users's whining. On the other hand, I can't be expected to babysit my merge requests too much either since I'm in the same position (I do
contribute to other projects as well, and have my own to contend with). I think the best way would be to asign a developer by drawing straws every
month, and whoever loses gets to look at merge requests on Gitorious and make at least one comment (looks good/ugly code/don't like your nickname etc.).
Having one year old merge requests without even one comment is unacceptable in my opinion, no matter which excuses can be provided.</nowiki><ref>{{cite web
|url=http://sourceforge.net/p/flightgear/mailman/message/31754689/
|title=<nowiki>osgEarth integration into FG 3.0</nowiki>|author=<nowiki>Adrian Musceac</nowiki>|date=<nowiki>2013-12-16 06:12:12</nowiki>}}</ref>|<nowiki>Adrian Musceac</nowiki>}}

{{cquote|<nowiki>People get busy and miss things. If someone sits quietly for a year on a
commit request, they've got nobody to blame other than themselves.

I agree that some kind of scheduled review process should be put in place
- things shouldn't fall through the cracks if it can be avoided. </nowiki><ref>{{cite web
|url=http://sourceforge.net/p/flightgear/mailman/message/31757710/
|title=<nowiki>osgEarth integration into FG 3.0</nowiki>|author=<nowiki>GeneB</nowiki>|date=<nowiki>2013-12-16 17:25:37</nowiki>}}</ref>|<nowiki>GeneB</nowiki>}}

{{cquote|<nowiki>I agree pretty much entirely - not commenting one merge requests for
such a long time
is a Bad Thing, and indeed discourages contribution. I like the idea
of having a rota
of people responsible to at least reviewing merge requests. At
present I'm discouraged
from reviewing merge requests because I don't feel qualified to do so
in many areas,
but I could easily provide at least some useful feedback.</nowiki><ref>{{cite web
|url=http://sourceforge.net/p/flightgear/mailman/message/31762420/
|title=<nowiki>osgEarth integration into FG 3.0</nowiki>|author=<nowiki>Stuart Buchanan</nowiki>|date=<nowiki>2013-12-17 21:53:24</nowiki>}}</ref>|<nowiki> Stuart Buchanan</nowiki>}}

<references/>

=== Distribution ===
* Seed torrents once the release is out

== 2.12 ==
'''Release postponed''':

Due to real life constraints and the low number of active core developers, we've hit a fluctuation where pretty much everyone is occupied with
something else at the moment. As everybody seems to be caught in some real life trouble, we can't see a better way to get the release out than delaying it for a while.
Also, it seems that it will take longer than usual to address any issues found in the RCs. Thus, we have agreed to postpone the upcoming FlightGear 2.12 release by a month, to provide sufficient time to handle release candidates and process end-user feedback. <ref>http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40568.html</ref>
<references/>

'''Distribution:'''
* we should make sure to seed torrents once the release is out {{forum link|p=190780}} {{forum link|t=20987}} {{forum link|t=21058}}

'''RCs:'''
* we should try to get out release candidates earlier to give testers a chance to actually run the RCs [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40522.html]

{{cquote|<nowiki>could we generate a full installation RC package for testing? It would make it easier for testers not familiar with Git to use it, and would be quite
handy for people like myself who do their development on Linux, but have Windows systems available for testing but without the git infrastructure or the time to download the entire git fgdata repository.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40608.html|title=<nowiki>Re: [Flightgear-devel] 2.12 is branched</nowiki>|author=<nowiki>Stuart Buchanan</nowiki>|date=<nowiki>Wed, 21 Aug 2013 07:29:32 -0700</nowiki>}}</ref>|<nowiki>Stuart Buchanan</nowiki>}}

{{cquote|<nowiki>Jenkins only does what it's told by the scripts (mostly in fgmeta besides the CMake files) - so we're still at the mercy of missing files in the
installer description and so on - I didn't yet automate a 'smoke test'[1] on Jenkins, since that would mean keeping a clean environment to run test
installs, and involve several expensive operations since we'd be launching the sim. That's all doable but requires VMs and more energy than I have. In general
I've been hoping to get enough people using the nightly builds that an automated smoke-test would be unnecessary but that's probably optimistic</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40609.html|title=<nowiki>Re: [Flightgear-devel] 2.12 is branched</nowiki>|author=<nowiki>James Turner</nowiki>|date=<nowiki>Wed, 21 Aug 2013 07:52:59 -0700</nowiki>}}</ref>|<nowiki>James Turner</nowiki>}}

{{cquote|<nowiki>MSVC has a very powerful source view level debugging, but at present this fails in some auto-generated ctor/dtor
code before it reaches 'main()' so can not be used ;=((.

In the Debug build 'new' is replaced with a 'new_dbg' which deliberately fills the allocation with 0xcc...
so if a person does NOT initialize ALL variables simple dtor code like 'if (buf) delete buf;' crashes.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40615.html|title=<nowiki>Re: [Flightgear-devel] 2.12 is branched</nowiki>|author=<nowiki>Geoff McLane</nowiki>|date=<nowiki>Wed, 21 Aug 2013 10:04:18 -0700</nowiki>}}</ref>|<nowiki>Geoff McLane</nowiki>}}

'''FGData:'''
* {{getstart source|view=commit|commit=4b0ee648b59e9456d0f653b432a10305560cce0b|text=Stuart's PDF generator in bin/makereadmepdf.pl should be run as part of the installer creation process}}.
* Once again, some users were asking for a more lightweight/essential FGData distribution {{forum link|t=20716}}
* Some users reported broken sound configurations for a number of aircraft due to stereo files {{forum link|t=20332}}
* We still keep seeing issues due to aircraft developers contributing resources with files, file names, paths that would break support on OS with case-sensitive OS or a different locale, it would make sense to add some form of automated/scripted validation during startup to detect such issues, without requiring a manual review, possibly through [[Catalog metadata]] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40407.html] {{forum link|p=185963|hilit=xml+french}} [https://code.google.com/p/flightgear-bugs/issues/detail?id=1158] [{{gitorious merge request|proj=fg|repo=fgdata|mr=224|full=1}}]

'''Usability/GUI:'''
* the menubar is increasingly getting a little cluttered, especially the "debug" entry - given the inflexibility of PUI, this also means that there are usability issues, because certain menu items are only accessible with a certain minimal screen resolution, other items cannot be accessed easily. A short term suggestion made, was moving all "Reload X" items into a dedicated "reload" menu, and moving tools to a separate "tools" menu, so help reduce the size of the debug menu {{forum link|p=186615|hilit=cluttered}} {{forum link|p=186742|hilit=reload+menu}}

'''Core:'''
* A few users reported issues that seemed possibly related to aggressive compiler optimizations, exposing the cmake/build flags via the property tree would seem like a good idea {{forum link|p=193138|hilit=funroll}}
* Some windows users reported that TerraSync would only work for them in 32-bit compatibility mode {{forum link|p=191789}}
* Providing support to new users would be greatly simplified if we could expose debug related info via the property tree, i.e. to ensure that OSG/SG/FG were not built in DEBUG mode {{forum link|p=191627}}
* We should look into exposing OSG plugin information via the help/about dialog, i.e. writing the info the property tree [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40859.html]
* There we still some reports about "SQLite API abuse", presumably due to non-English characters in installation paths,maybe the installer could check paths prior to installation? {{forum link|p=189083}}
* We kept seeing SQLite/NavDB Cache related bug reports {{forum link|p=191552}} {{Issue|1227}}
* Like it used to be the case with detailed log files, most end users are usually very willing to help, but unable to provide backtraces - reconsider adding google breakpad support {{forum link|p=188017}}
* under some circumsances, initial navcache/POI processing took up to 10 minutes, even on powerful Linux boxes with plenty of horsepower and RAM using just the default settings {{forum link|p=187417}}
* the way we are incrementing version numbers in SG_SRC/FG_SRC and FGDATA seems to be causing issues ("base package check failed"), which were reported already during the last release cycles (all the way back to 2.8), even one core developer reported the issue during the 2.10 cycle (many people affected by this seem to be using brisa's download & compile script, but it doesn't appear to be Linux-specific, it also seems to happen on Windows). It seems fgdata version is 2.12 while the SG/FG source trees in next were still looking for 2.11 - could be also because of cmake caching, and the cache not being updated properly once certain files are touched in SG/FG source, still investigating... {{forum link|p=186647}} {{forum link|t=20467}}. The problem seems to be {{forum link|p=186942|text=this}}.
* some rendering issues related to OSG 3.1.9 were reported [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40390.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40422.html] [{{simgear source|view=commit|commit=5320d0ecaa696eb2712598879a15ae505bb65e4f|full=1}}] [http://photos.mxchange.org/?d=albums/Flightgear-Flight-Simulator/screenshots-master/bugs]
* it would probably be a good idea to explicitly check for the latest supported OSG version in our SG/FG CMakeLists.txt, to ensure that people do not build FG against OSG versions that are not yet supported, with some option to override/disable the check (for developers) [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40352.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40431.html]
* while the delayed tile loading is a big improvement in the responsiveness, delayed loading of models caused issues for helicopter pilots, because they could no longer start on buildings - it might be better to make the new behavior property-configurable through a prop switch, so that helicopters could override the setting during startup in their aircraft-set.xml file [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40421.html]

'''Version numbering:'''
{{cquote|There was already a couple of people on IRC confused that 2.12 is different to 2.1.2 (since minor version numbers > 9 are something of a rarity in many people's perception).<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40339.html|title=<nowiki>Re: [Flightgear-devel] reminder: entering feature freeze now</nowiki>|author=James Turner|date=Mon, 24 Jun 2013 14:15:00 -0700}}</ref>|James Turner}}

{{cquote|Give our release pattern is date scheduled, an Ubuntu style numbering scheme would actually make more sense, but a bit more effort to move too.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40339.html|title=<nowiki>Re: [Flightgear-devel] reminder: entering feature freeze now</nowiki>|author=James Turner|date=Mon, 24 Jun 2013 14:15:00 -0700}}</ref>|James Turner}}

{{cquote|Externally, 3.0 is going to be considered a bigger deal than 2.12.0.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40357.html|title=<nowiki>Re: [Flightgear-devel] reminder: entering feature freeze now</nowiki>|author=Stuart Buchanan|date=Tue, 25 Jun 2013 14:48:56 -0700}}</ref>|Stuart Buchanan}}

{{cquote|I suggest that we zero-pad the minor release digit after 3.0.0 so we have 3.02, 3.04 etc. to reduce confusion if we reach double digits.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40357.html|title=<nowiki>Re: [Flightgear-devel] reminder: entering feature freeze now</nowiki>|author=Stuart Buchanan|date=Tue, 25 Jun 2013 14:48:56 -0700}}</ref>|Stuart Buchanan}}

{{cquote|many computer systems sort file names in ascii order, many people don't seem to pay careful attention to where the decimal points are placed, etc.

Once we clear past the 2.10, 2.12, etc. series, I'd like to go back to keeping things single digits in the major and minor version numbers and when we run out of a single digits bump up the major number (so 3.8.x -> 4.0.x). Number are numbers, but this one confused a lot more people than I expected it would or should so maybe it's good to be sensitive to that after we clear the 2.x series of versions.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40358.html|title=<nowiki>Re: [Flightgear-devel] reminder: entering feature freeze now</nowiki>|author=Curtis Olson|date=Tue, 25 Jun 2013 14:59:08 -0700}}</ref>|Curtis Olson}}

{{cquote|That sounds OK to me, as it would imply a full release every 2.5 years, give a clear flag ahead of time when we're nearing a major release, and save having these discussions in the future. For reference, with the current plan there will be 4 years between 2.0.0 (Feb 2010) was and 3.0.0 (Feb 2014). <ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40437.html|title=<nowiki>Re: [Flightgear-devel] reminder: entering feature freeze now</nowiki>|author=Stuart Buchanan|date=Mon, 08 Jul 2013 14:42:16 -0700}}</ref>|Stuart Buchanan}}

{{cquote|<nowiki>I've set the version files on 'next' to be 2.99, on the assumption the next release will be 3.0 as discussed.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40481.html|title=<nowiki>[Flightgear-devel] 2.12 is branched</nowiki>|author=<nowiki>James Turner</nowiki>|date=<nowiki>Wed, 17 Jul 2013 12:39:56 -0700</nowiki>}}</ref>|<nowiki>James Turner</nowiki>}}

'''Backwards Compatibility:'''
{{cquote|I think I sensible step in that case is to keep 3.0 as backward compatible (in terms of Aircraft APIs) with 2.12 as possible, which mostly means my resisting the urge to clean up legacy stuff :)

Obviously it's tricky to offer a 100% guarantee, but I don't have anything planned for 3.0 that will require aircraft changes - I'm sure new technologies
such as state machines, knob/slider animations and tooltips will mature and gain some new features but hopefully aircraft developers will be able to work
against 2.12 with confidence that things will work the same in 3.0<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40366.html|title=<nowiki>Re: [Flightgear-devel] reminder: entering feature freeze now</nowiki>|author=James Turner|date=Wed, 26 Jun 2013 02:49:00 -0700}}</ref>|James Turner}}

{{cquote|It's a bit tricky because I haven't had much feedback from aircraft developers about the new APIs (since they aren't in 2.10), but once 2.12 ships we would want to keep them compatible, so fingers crossed the current design is sensible <ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40366.html|title=<nowiki>Re: [Flightgear-devel] reminder: entering feature freeze now</nowiki>|author=James Turner|date=Wed, 26 Jun 2013 02:49:00 -0700}}</ref>|James Turner}}

== 2.10 ==
'''!!! NOTE: None of these issues have been incorporated into the release plan yet !!!'''
* '''FlightGear Core related ''':
** a number of users reported segfaults related to the new flight recorder system [https://code.google.com/p/flightgear-bugs/issues/detail?id=1023] {{forum link|p=181414}}
** the [[Scripted_Compilation_on_Linux_Debian/Ubuntu| download & compile]] script in fgmeta should be updated for each release {{forum link|p=180879}}
** {{Thumbs up}} It is great news if you are able to crank out full installers right from Jenkins. That will save me a bunch of downloading and hours of uploading for every new release candidate [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39781.html].
** But it might be a good idea to create a script that will distribute the new builds to the various mirrors. That way I'm less likely to throttle the build server to 10k/sec [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39782.html]
** we could also automatically seed them in BitTorrent, on a Linux box and use "btmakemetafile" which I use here to generate those update packages on [http://mxchange.org:23456/ the tracker] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39783.html]
** {{Improve Release Plan|perform a sync with JSBSim sources before the feature freeze}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40179.html].
** {{Improve Release Plan|decide early on if/when navdata can be updated}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39280.html]
** {{Improve Release Plan|merge requests that didn't make it into the previous release should probably be handled early during the upcoming release cycle}}
** {{Improve Release Plan|distro-specific repositories should probably be updated, too}} {{forum link|p=174943}}
** {{Improve Release Plan|the "FlightGear & friends" SuseStudio images should probably be also updated for each release cycle }}[http://susestudio.com/a/sBTdmU/flightgear-friends--2]
** every now and then, people raise the issue of the major/minor version numbering scheme being a little confusing to people not familiar with software development, thinking that 2.8 must be newer/better/more recent than 2.11 - using code names or release dates instead was suggested {{forum link|t=19255}}
** there are usually reviews posted on blogs, forums etc after each release - we should specifically collect links to those and evaluate all opinions [http://forum.avsim.net/topic/400897-my-experience-with-flightgear-210/] [http://forum.avsim.net/topic/399809-fg-210-most-certainly-a-new-era-of-fg/]
** {{Improve Release Plan|the release plan should be augmented for the sub-release procedures }}[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39710.html]
** there were a number of navcache/SQLite related issues reported via the issue tracker and the forum/devel list [https://code.google.com/p/flightgear-bugs/issues/detail?id=894] {{forum link|p=175690}} [http://code.google.com/p/flightgear-bugs/issues/detail?id=1055]
** a little irritation/frustration was caused due to the conflicting review statements concerning the new radio propagation code [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38905.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38825.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg33692.html] - some of this boiled down to coding style related issues, highlighting the fact that different core developers have different "coding styles" and requirements when reviewing merge requests, because we still lack an official "FlightGear coding style guide" [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38958.html]
** according to Windows users, the installer created by jenkins could use some optimizations {{forum link|t=19745}}
** a number of Windows7/Windows8 users reported issues that needed a "force 32/64 bit" workaround during startup {{forum link|p=182923}} {{forum link|p=182759}} {{forum link|p=182724}}
** {{Improve Release Plan|new GUI widgets, new fgcommands and new Nasal APIs should ideally be documented prior the release, at least through updated README files, preferably also through the wiki}}

* '''Better bug reports and troubleshooting''':
** show HLA/OpenRTI availability {{fixed since|release=2.11+}} [{{flightgear source|view=commit|commit=c61583de5daddaa901ff52562645fac3f04dd225|full=1}}]
** add a string property with list of startup arguments used by the user, for use in the about dialog
** add a property specifying if the binary is 32/64 bit for use in the about dialog (to check if segfaults are related to 32bit RAM limits)
** add a property specifying the CMAKE_BUILD_TYPE variable used during compilation, for use in the about dialog (debug, release, RelWithDbgInfo) [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40311.html]
** show the threading mode in use in the about dialog
** show average frame rate and frame spacing in about dialog
** add a property specifying how much physical RAM is detected (to see if people are running out of RAM) {{forum link|p=164936|hilit=swapping}}
** is there a portable ARB/WGL extension to determine the amount of dedicated VRAM available ?
** try to detect Intel GPUs and Mesa drivers ? (some of the more common issues were related to Intel/Mesa)

* '''Changelog / Release Announcement''':
** {{Thumbs up}} Walking through the list of "lessons learned" as part of the "Upcoming release" announcement was useful [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38749.html]
** {{Improve Release Plan|Probably it would be even better to directly process all "lessons learned" items and improve the release plan after each release accordingly}}
** To get to the 3.0 goal sometime in the near future, it's probably a good idea to [[FlightGear 3.0 backlog|create a backlog of open items in the wiki and link the release plan document to that]]. As usual, we don't have to be perfect for a new major release number. But the new features being the reason for the new major number should work reasonably correct. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38888.html] (also see [[:Category:Developer Plans]])
** {{Thumbs up}} Posting the link to the changelog for the upcoming release helped writing the changelog early, this should also be done for the [[Hardware Recommendations]] and [[Notebooks known to run FlightGear]] pages probably?
** {{Thumbs up}} The changelog can be easily written by using "git log", searching the issue tracker and by going through the last 6 newsletters published since the previous release. It might make sense to explicitly add a "ChangeLog" message to important commits, so that the Changelog can be compiled more easily ?
** Alternatively, request developers to add major changes also to $FG_SRC/ChangeLog again (last updated in 2001)?
** {{Improve Release Plan|for the web-based release announcement, it would be helpful to have screen shots or even youtube videos to demonstrate new features - get the community involved EARLY}}
** {{Improve Release Plan|it may make sense to also allow artwork contributors to contribute new splash screen images for use in the upcoming release. The screen shot contest should provide plenty of options}} {{forum link|t=16795}}.
** {{Improve Release Plan|a screenshot/banner contest should be held early on, so that we can use the images for our promo work-NOT after the release}} {{forum link|t=19220}}
** {{Improve Release Plan|for the changelog we should early on invite volunteers to help translate it, useful for the release promotion}}
** {{Improve Release Plan|having dedicated promo videos sounds like a good idea}}, see {{forum link|t=19158}} [[Howto:Creating FlightGear Promo Videos]]
** The RC announcement should also contain links to 1) the issue tracker and 2) the RC subforum [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39222.html]
** Using wiki tagging, we could ensure that we can also tag our wiki documentation after each release, so that we can provide older versions of our docs for old FG versions {{forum link|p=170735|hilit=wiki+tagging}}
** various files in $FG_ROOT haven't been updated in YEARS, either update them in the future, or just get rid of them: THANKS, NEWS, ChangeLog etc

* '''Shaders''':
** the ATI viewport hack didn't seem enabled in the RCs, as reported by a number of users on the forum {{forum link|p=176549}}
** the ATI viewport hack should only be enabled by default if ATI/AMD hardware is detected [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39900.html] {{forum link|p=176183|hilit=viewport}} {{gitorious merge request|proj=fg|repo=fgdata|mr=190|full=1}}]
** we should probably try to detect if software emulated OpenGL is in use (i.e. using Mesa) and show a corresponding warning {{forum link|type=search|keywords=libtxc_dxtn}}
** texture compression should be disabled by default {{forum link|p=175123}} {{forum link|p=177902}} {{forum link|p=177983}} {{forum link|p=178307}} {{forum link|p=180049}}
** {{Thumbs up}} lowering the default shader level to 1 improved compatibility for older/underpowered systems [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39189.html]
** but there were still '''many''' users reporting issues like crashes/segfaults during startup, that seemed affected by changing graphics settings {{forum link|p=181033}}
** we should make sure that the default shader level (and related shaders!) works for all common setups, including ATI/AMD cards (Mac!) and Intel GPUs
** {{Improve Release Plan|GLSL shaders and effects should be treated like core code, and should be tested on different platforms before being enabled by default (i.e. signed-off by people using NVIDIA, ATI/AMD, Intel)}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39120.html]
** {{Improve Release Plan|modified shaders should be tested with other shader-related features to prevent breakage }} {{forum link|p=175583}} (there might be a way to automate this a litle by catching GLSL compiler errors?)
** to address all the intel GPU related issues, we may want to show an info dialog on computers where /sim/rendering/gl-vendor contains "intel" as a substring and provide an option to disable all shaders {{forum link|p=175774}}
** we probably need a separate article detailing GLSL coding requirements to ensure that portable constructs are used [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39278.html] so that problematic shaders are not just identified at the end of the release cycle

* '''Installer''':
** The installer should be updated to show a warning regarding TerraSync update time {{forum link|p=175779}}
** When Flightgear releases a new version, can the staff create a way for the average computer users to install a new version without doing anything to the old version but still use the terrain files from the older version? {{forum link|p=175762}}
** I believe Fred intentionally chose to use the same registry key from one version to the next. Thus if you install a new version over the top of an existing version it will end up in the same path under C:\<PF> [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39246.html]

* '''FGData related (Base Package)''':
** accessibility of README files in $FG_ROOT/Docs should be improved for our Win/Mac users {{forum link|t=19725}} {{fixed since|release=2.11+}} (by Stuart)
** aircraft included in the base package should not require DDS support {{forum link|p=183549}}
** a bunch of Intel GPU related issues were tracked down to be related to texture dimensions beyond 512x512 not being supported, suggested workarounds are mentioned at [http://code.google.com/p/flightgear-bugs/issues/detail?id=1100#c2]
** "Funny how the 172P doesn't have it (crash detection via limits.nas). It is something like a default aircraft for the sim, isn't it? Which aircraft are considered the most "finished"?" {{forum link|p=180157}}
** " I'm a bit confused by all the aircraft models in various stages of completion. Even the install package comes with some below-par and alpha stage models. Is there a compiled list of aircraft that are considered "well done"?" {{forum link|p=180196}}
** The default set of airplanes in FG should be the absolute best of the best, simply because that's what a new user is going to be exposed to for their first time. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39609.html]
** Language files should be synced between English and other languages, so translators can work on them before the release ;-)
** the {{flightgear source|path=scripts/python/nasal_api_doc.py|text=nasal_api_doc.py}} script in $FG_SRC/scripts/python should be run as part of the release process, to create an updated doc file for [[$FG_ROOT]]/Docs and ship it with each release {{forum link|t=15133}}
** {{Improve Release Plan|New/updated Nasal scripts contributed to the base package should be checked to properly support important features like simulator reset, this also applies to Nasal scripts used by aircraft, Nasal scripts that fail these criteria, end up breaking existing features! }}[https://code.google.com/p/flightgear-bugs/issues/detail?id=956] (also see [[Release:Aircraft Selection Criteria]])
** {{Thumbs up}} regarding aircraft included in the release: "I must stress usefulness of the Autostart feature, present in most aircraft not running at startup. It keeps frustration away from those who just want to enjoy the flight . (Please note that I actually agree with aircraft being shut down at startup, as long as autostart is present, or the starting procedure is trivially doable by just trying what you see in the cockpit.) " {{forum link|p=175117}} (also see [[Release:Aircraft Selection Criteria]])
** {{Thumbs up}} also, it would apparently make sense to provide tutorials for the default aircraft: "At first startup, I noticed the "Need help? use help->tutorials" message, and because I had no idea how to start up the plane (it would be just plain try and fail, than try something else), I did just that and started some basic tutorials. I wouldn't say going through the tutorials was frustrating, but they were quite boring and I was eager to get in the air as soon as possible." {{forum link|t=16795}} (also see [[Release:Aircraft Selection Criteria]])
** "I discovered however, that there can be some problems on Linux about the planes (eg. some versions of the L39 Albatros undergoing several improvements lately). The problems can be caused by Linux being case sensitive about file paths (Windows is not), and I suspect, more models could suffer from some developers not knowing that. It's easy to fix if you know about the problem, but it would better be done on the developer side, as you never know if the smoke is just not implemented or missing due to this. Not to mention how lengthy it would be to go through more aircraft..." {{forum link|t=16795}}
** Docs: Relevant FlightGear paths should ideally not be "hard-coded" in the manual, but rather also configured via the build system, i.e. using cmake, so that the FG/SG cmake configuration can be shared, to automatically update the correct paths without requiring manual maintenance {{forum link|p=180119}}

* '''Usability''':
** the huge number of ads placed on the official website, and the non-intuitive layout of the website caused quite some irritation, not only among new users, but also among seasoned long-time contributors - flightgear.org has been repeatedly described as leaving the impression of even being a "scam" {{forum link|t=18863}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39533.html]
** {{Thumbs down}} A little downside is how the FGcom is done as a standalone program just cooperating with FG itself. It took me some fiddling with the settings for about two hours to get it working, but again installation was simply done from repos (FGcom and than FGcomGui as well). {{forum link|t=16795}} (this is planned [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38057.html]) {{fixed since|release=2.99+}}
** {{Thumbs down}} Most likely because of the Intel graphics, I suffered for a long time from a problem with aircraft models (and some ground textures too) being black or missing some parts (see my post in an older thread complaining about similar problem). I solved it by adding a command line option turning off texture compression. {{forum link|t=16795}} (also see [[Release:Aircraft Selection Criteria]])

** We should probably add a new menu to the menubar for our online resources (wiki, forum, issue tracker, FAQ) so that people more easily find important resources just by selecting them from a menu.


* '''Release Candidates''':
** a number of users reported crashes, for better debugging support, consider linking in Google BreakPad (cross platform stack traces) {{forum link|p=176669}}
** Release Candidates should probably have a higher default logging level while writing everything to a log file that can be easily shared via the issue tracker/forums, so that end users can provide better bug reports.
** some users reported "OpenGL out of memory" and "out of space" errors when testing the RCs, we may want to link in a leak detector library or simply add BoehmGC - which is used by Mozilla to track leaking subsystems (a runtime log is created and dumped at process termination), that way non-developers could provide better leak reports. {{forum link|t=17114}} {{forum link|p=163132}} {{forum link|p=171329}}
** How about having a test run a week or two in advance, just to make sure we can indeed produce release installers for Win+Mac - and then release the first RC on December 17th/18th or 19th [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38765.html]
** We've already got a fairly extensive lead-in time for the release. More testers on more platforms would seem to be the answer. Perhaps we should advertize for testers of those platforms that aren't adequately covered by developers running git? Making a complete package available, not just the binaries would help, as testers wouldn't need to be git-aware. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38764.html]
** {{Improve Release Plan|The main area to improve is to distribute release candidates for all platforms earlier - preferably starting immediately after the freeze. That would already give us more time for testing - without extending the actual freeze period.}}[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38765.html]
** {{Improve Release Plan|aircraft packages should be prepared prior to the official release date: "For the 2.8 release I didn't start making aircraft download packages (or uploading them to the ftp servers) until after the official release date which was a mistake"}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39227.html]
** {{Improve Release Plan|RC's should probably be built with [[Built-in Profiler]] support enabled}} {{forum link|p=175689}}.
** {{Improve Release Plan|When releasing RC's do not limit them to Win/Mac binaries, but also create source snapshots so that distros can already work on the next package versions.}}
** {{Improve Release Plan|For RC's it might make sense to distribute binaries with debugging symbols included}} and [[Built-in Profiler|profiling support enabled]], so that people can more easily provide useful bug reports, or even backtraces.
** Also, many end users still prefer using the forum for making bug reports and don't use the issue tracker - it might help to add a link (button) to the issue tracker to the about dialog or maybe even directly to the help menu ("Report an issue") (same for wiki/troubleshooting/faq ?)
** {{Improve Release Plan|it might make sense to give wider exposure to our RCs, i.e. via the newsletter - possibly by adjusting the release schedule}}
** actually, it would even seem better to use our [[Release promotion]] checklist to send out an "Upcoming Release" announcement 4-6 weeks prior to the actual release, so that all the flightsim websites can notify their users to participate in RC beta testing.
** a number of forum users reported that the RC/release mirrors were a real bottleneck, and that downloading the 800MB RC installer would often take 2-3 hours (using torrents instead was suggested)
** it also seemed that a number of users had issues related to their browser corrupting the huge image download {{forum link|p=176087}} (website should suggest to use a download manager instead!)
** so reducing the size of the installer (i.e. base package) would seem like another good idea to give our RCs wider exposure, for example by focusing only on 2-3 aircraft
** certain reported issues were really tricky to reproduce, we may want to provide an option to export crucial runtime settings to an XML file that can be easily shared with other testers/developers, or even extend the new flight recorder/replay tape system accordingly {{forum link|p=176023}}
** it might be good if the forum release-candidates announcement mentions that tests and bug-reports should be done with a clean install of the release-candidate, with no third-party data used in tests.

* '''Build related''':
* A normal Linux user has practically no chance to get last stable on his box running if it isn't in his distro - a normal Windows user gets everything nice and streamlined. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38817.html]
* According to the issue tracker there were 3-5 different contributors who provided C++ patches that didn't end up reviewed/merged, which caused some irritation.

== 2.8 ==
* {{Thumbs down}} Lack of stress-testing: A number of users reported severe memory growth issues (with fgfs consuming as much as 14gb of RAM), many directly related to new features, such as random buildings: {{forum link|p=160747|hilit=vegetation}} {{forum link|t=17249}} {{forum link|p=163829}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38007.html] These could have probably been identified earlier by running FG for extended periods of time, and testing the shipped aircraft with the default KSFO scenery, and new features such as random buildings enabled.
* {{Thumbs down}} Lack of graceful feature scaling: Several users with old graphics cards reported not being able to run FG 2.8 without crashing during startup, because the FG defaults didn't scale for old hardware {{forum link|t=17308}}
* {{Thumbs down}} According to noaa.gov it seems that the NOAA metar source got phased out in 04/2012 and moved to a new URL[http://weather.noaa.gov/weather/coded.html], some users reported issues related to this {{forum link|p=165784|hilit=metar}}. However, the metar URL is currently hard-coded in the fgfs/metar source code - in addition, the default format is no longer a plain text dump [http://www.aviationweather.gov/adds/metars/]. It would make sense to make the URL a string property that can be put into preferences.xml and then use a Nasal listener to parse the resulting XML/HTML and set a plain text property instead, that can be processed by the existing metar code.
* {{Thumbs down}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38113.html Broken OSX downloads]
* {{Thumbs down}} {{forum link|p=165841|text=the OSX 10.8 release and code signing caused some irritation}}
* {{Thumbs down}} {{forum link|p=166062|text=After the 2.8 release a number of users on the forums reported seeing GLSL related errors, because some of the 2.8 shaders used GLSL features only supported by more recent GLSL compilers/drivers - it would probably make sense to test all shader settings on all 3 platforms and check if they cause any errors (and "backport" shaders as necessary). Apple/Mac OSX seems to be more problematic}}
* {{Thumbs down}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38121.html Microsoft Redistributables were apparently not shipped with the Windows installer ?]
* {{Thumbs down}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38089.html The changelog should be written as early as possible]
* The code freeze could probably be lifted for patches that are not normally enabled/used by any default code paths (or shipped aircraft) in a FlightGear release. This probably involves Nasal extension functions, fgcommands, telnet commands, but also custom hard coded instruments or instrumentation-related APIs (think Canvas). Basically, whenever there's no chance to break a release by committing a certain patch, because the code path will not be executed by default without explicitly enabling it. For 2.8, this also meant that the Nasal [[Canvas]] API could not be included due to the code freeze, which however wasn't used by any systems or aircraft - so that there would have been zero chance for breakage [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37622.html] {{forum link|p=165413}}.
* The wiki contains a number of resources to help new users with hardware decisions, such as [[Hardware Recommendations]] [[Notebooks known to run FlightGear]] and [[Supported Video Cards]] - these should probably be updated for each release several weeks in advance.

== 2.6 ==
* {{Thumbs up}} feature freeze in general
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.
* {{Thumbs down}} feature freeze for aircraft
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.
* {{Thumbs down}} switching to a new version of supporting libraries like OSG.
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.
* {{Thumbs down}} manual creation of release candidates and the release binaries
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.
* {{Thumbs down}} release date/time frame
*: It took several days to release all the subparts. Might be better to upload all files and pages to hidden folders and publish them all at once (or at least within a couple of hours). That'll have several advantages:
*:* no big difference between releases for the various OS.
*:* the website will switch to the new release state quickly. With 2.6.0, the aircraft page was published before the setup. The release announcement was published even later.

{{Appendix}}

[[Category:Core developer documentation]]
[[Category:FlightGear]]
[[Category:Release plans]]

Changelog 2018.3

2021-08-13T17:56:18Z

Legoboyvdlp: /* 2018.3.3 point release */

{{changelogs|prev=2018.2|next=2019.1}}
Available in: [[Changelog_2018.3|English]], [[Zh/2018.3|Chinese]].<br />

Please help us translate in other languages!

----<noinclude>
[[Category:Undocumented templates]]
</noinclude>

The FlightGear development team is delighted to announce the v2018.3 release of FlightGear, the free, open-source flight simulator. This new version contains many exciting new features, enhancements and bugfixes including usability improvements to the launcher, improved scenery for Hawaii and the Arctic island of Jan Mayan, Italian, Chinese and Russian translations, better visuals for AI and MP aircraft.

Founded in 1997, FlightGear is developed by a worldwide group of volunteers, brought together by a shared ambition to create the most realistic flight simulator possible that is free to use, modify and distribute. FlightGear is used all over the world by desktop flight simulator enthusiasts, for research in universities and for interactive exhibits in museums.

FlightGear features more than 400 aircraft, a worldwide scenery database, a multiplayer environment, detailed sky modeling, a flexible and open aircraft modeling system, varied networking options, multiple display support, a powerful scripting language, and an open architecture. Best of all, being open-source, the simulator is owned by the community and everyone is encouraged to contribute.

Download FlightGear v2018.3 for free from [http://www.flightgear.org/ FlightGear.org].

FlightGear - Fly Free!

== Usability ==
* Flightplan loading within the launcher.
* Chinese, Russian and Italian translations for the launcher and UI
* Improved support for the state of the aircraft depending on starting location - cold and dark on the ramp, engine running ready for take-off on the runway, or in cruise flight.

== Input ==
* Improved joystick configuration and binding options.

== AI / Multiplayer ==
* Multiple Levels of Detail (LoD) for MP and AI aircraft. To improve performance, low-detail models are used when the viewer is far from the MP aircraft.
* Fallback models to display in the case where a viewer does not have the MP aircraft installed.
* Many improvements to AI models including new liveries, timetabled movements

== Graphics ==
* Support for retrieving Canvas images over HTTP. This is a useful feature for displaying instruments like a PFD, ND, EICAS or any MFD externally from the FlightGear 3D main window in a separate window or on a separate monitor, computer or a mobile device. See [[Read_canvas_image_by_HTTP]] for more information.
* Improved cloud rendering with stronger Mie scattering on cloud fringes, improved scattering on cirrus clouds
* Reset: wipe the Effect UniformCache

== Scenery ==
* Improved scenery for Hawaii, the default location for this release.
* New scenery for Jan Mayen, situated northeast of Iceland. Including the active volcano of Beerenberg (2277m).

== JSBSim ==
* The feature fail_hardover of the <actuator> component was not giving the correct output in some occurences when clipmax was smaller in absolute value than clipmin.
* Tables CORNERING_COEFF could not be used for BOGEY contact points.
* Bug fixes for JSBSim atmosphere model at very high altitudes
* Fixed PID integration with the 3rd order Adams-Bashforth was inccorect.
* The fail_stuck property of sensors (accelerometers, magnetometers, gyro, etc.) without a <lag> element was setting the output to zero instead of sticking to the last output value.
* When a sensor was stuck, the drift, gain, bias and quantization of the last output before being stuck were ignored.
* Fixed the Calibrated Air Speed (CAS) computations for supersonic velocities
* Fixed the Nlf (Normal load factor) sign
* Nlf can now be specified as an initial condition via the property ic/targetNlf
* Added blocking sockets to the input features
* Added a property to piston engines to get the AFR (Air to Fuel Ratio)
* Added conversion from m/s to ft/s
* Restored the initial conditions for engines running (-1 means all engines)

== Significant Aircraft Updates ==
* "Metadata" has been added to many aircraft, making it easier to find new exciting aircraft to fly using the launcher, whether you are interested in aircraft from the 1920s or twin engined business jets.
* B-25 : Various bug fixes and minor improvements
* Cessna 172 : Improved cockpit, interior lighting.
* Citation II : New panels, radio instruments. Complete remodeling of the electric system, with accurate bus voltage, circuit breakers. System test knob implemented.
* F4U : new FDM
* F-14 : V1.8. Improved flight model, particularly in a low-speed regime. Improved cockpit.
* F-15 : V1.8. Updated flight model, particularly armament mass location. Performance optimizations. Autopilot improvements.
* F-16 : v3.0. Store options. New liveries. Radar performance optimizations. Autopilot and system improvements. FDM fixes.
* Saab 37 Viggen : Version 4.313. Various updates, particularly to radar and armament models.
* Seneca II: Long range tanks, interior lighting,
* SpaceShuttle : Milestone-10. Improved interior (including furry velcro), launch guidance and orbital plane targeting, more realistic OMS burn procedures, expanded systems including circuit breaker simulation and failure modeling.
* 777: Our flagship airliner now fully supports checklists, allowing you to learn everything about the aircraft from within the simulator. Full support to auto-push was also implemented. Bug fixes and minor improvements.

== Other ==
* [[FG1000]] glass panel display, inspired by moving map devices like the the Garmin G1000
* Improved Replay handling of AI aircraft and carriers - judge your own carrier landings.
* KC-130 tanker aircraft for air-to-air refueling
* Flightplan GPX import now supports elevation values.
* TACAN: Add support for setting TACAN by frequency

== 2018.3.2 point release ==
* Chinese font support for the splash screen / tips, and some updated Chinese translations
* C172P bug fixes
* fixed crash on certain AMD 64-bit systems relating to SSE intrinsics and memory alignment
* fixed crash loading flightplans saved from LittleNavMap with non-sequential waypoint indices
* tolerate missing runways parsing Navigraph procedures, so current cycle can be used at more airports
* use Ref versions of osgDB methods to avoid crashes, especially after long flights
* fix a NaN in the sky rendering code at extreme orbital altitudes
* set default values of some position properties for consistency with the rest (affected C172 tie-down mode)
* fix JSBSim wheel-spin down regression

== 2018.3.3 point release ==
* Avoid crash on Cmd-Q exit of the app on macOS
* JSBSim bug fixes
* Fix for route-path when leg 0 is not a runway
* Improve parsing of apt.dat header
* Prevent a segfault when parsing malformed nav.dat files
* Fix crash loading a flight-plan
* Tolerate missing runways parsing procedures
* Change screenshot filename to have date time
* Split up SIMD support in ENABLE_SIMD which enables sse2 support for the compiler and ENABLE_SIMD_CODE which enables the hand crafted SIMD math functions which defaults to OFF now since compilers have catched up on generating optimized vectorized SIMD code.
* Add some /sim/presets properties to setDefaults
* LOD: Multiplayer fix
* PID integration with the 3rd order Adams-Bashforth was inccorect.
* The fail_stuck property of sensors (accelerometers, magnetometers, gyro, etc.) without a <lag> element was setting the output to zero instead of sticking to the last output value. Thanks to legoboyvdlp for the bug report.
* When a sensor was stuck, the drift, gain, bias and quantization of the last output before being stuck were ignored. Thanks to Dennis J. Linse for the bug report.
* Bug fixes for JSBSim atmosphere model at very high altitudes
* Fix an inverted flag in Radar calculation
* Fix crash on Ctrl-V in PUI
* Fix for jumping view when right-dragging
* Bug fix for JSBSim.
* Switch to new stable-2018 catalog for the release
* Flight-plan: improve GPX loading
* Change CAVOK visibility to 9999.0 metres

== 2018.3.4 point release ==
* Launcher: fix aircraft switching on update
* METAR fix
* All start from parking position with no ground net
* [security] Prevent buffer overrun.
* Arrival procedure routing fixes
* Avoid a warning when inserting nil into a FP

== 2018.3.5 point release ==
* Joystick initialization fixes
* Fixes for JSB trimming
* [JSBSim] The sign of the XZ inertia has been fixed in the property inertia/ixz-slug_ft2 (was just an output error, the correct XZ inertia was used internally).
* Tweaking macOS HID code to avoid a Catalina crash

== 2018.3.6 point release ==
* Fix crash on first run on macOS due to Gatekeeper
* Fix missing file menu on macOS when using Dutch localization
* Add Ctrl-F shortcut to launcher to Fly!
* Improve launcher aircraft searching

== Footnotes ==
<references/>

[[Category:Changes after 2018.2]]
[[Category:FlightGear changelogs]]
[[Zh:2018.3]]

MD-80

2021-08-13T17:56:06Z

Legoboyvdlp: /* The Team */ remove personal data

{{:{{PAGENAME}}/info}}

This is an accurate, and complex recreation of the McDonnell Douglas MD-80 by [[User:Octal450|Josh Davidson (Octal450)]]

== MD-80 Overview ==

Includes:
* MD-82 (JT8D-217A)

See the right InfoBox for the Repository, or Download. <u>Remember to rename the aircraft's folder to "MD-80"</u>.

== The Team ==
* Flight Dynamics: Josh Davidson (Octal450)
* Systems: Josh Davidson (Octal450)
* Instruments: Josh Davidson (Octal450), legoboyvdlp, Gary Neely (Buckaroo), chad3006
* 3D/Textures: Gary Neely (Buckaroo), legoboyvdlp

== Credits ==
Thank you to the following people for their contributions to this project!
* Necolatis: Help on the MFD System
* Various others: Liveries, Some Code, Some 3D Models, Some Textures

== Aircraft help ==
{| class="keytable"
! Key !! Function
|-
| {{key press|1}}
| Show Captains View
|-
| {{key press|2}}
| Show First Officers View
|-
| {{key press|3}}
| Show Overhead View
|-
| {{key press|4}}
| Show Forward Pedestal View
|-
| {{key press|5}}
| Show Aft Pedestal View
|-
| {{key press|6}}
| Show FGCP Panel View
|-
| {{key press|F1}}
| Disengage/Decrease Reverse Thrust
|-
| {{key press|F2}}
| Engage/Increase Reverse Thrust
|-
| {{key press|C}}
| Reset Current View
|-
| {{key press|E}}
| Set Idle Thrust
|-
| {{key press|F}}
| Set Full Thrust
|-
| {{key press|DEL}}
| Toggle Thrust Reversers
|-
| {{key press|CTRL|B}}
| Cycle Spoilers
|-
| {{key press|Shift|B}}
| Toggle Parking Brake
|-
| {{key press|CTRL|D}}
| Disconnect Autothrottle
|-
| {{key press|Shift|D}}
| Disconnect Autopilot
|-
| {{key press|CTRL|G}}
| Takeoff/Go Around Button
|}

{{MDouglas}}

[[Category:Airliners]]

Release: Airport Selection Criteria

2021-08-13T17:55:04Z

Legoboyvdlp:

{{Stub}}
{{Release}}

== Intro ==
{{FGCquote
|1= As we have never changed our default startup before, we should have some time for preparing the data. Would it be possible to have a decision by end of March? That would give us 6 weeks until the next release date, mid of May.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34868405/
| title = <nowiki>Re: [Flightgear-devel] After the release is before the next
release...</nowiki>
| author = <nowiki>Torsten Dreyer</nowiki>
| date = Feb 20th, 2016
| added = Feb 20th, 2016
| script_version = 0.25
}}
}}

{{FGCquote
|1= If we want to name the next release after a different airport, we should decide now what airport this is going to be, get the airport in shape, get maybe the relevant manual pages written and get prepared. The way I see it, it'd be a terrific way for scenery developers to showcase their efforts - you've worked long and hard to make an airport and its surroundings shine - use it to impress everyone who fires up FG for the first time! The procedure I would suggest is that we first spread the word, then that airport developers (or anyone else who wants to attract users to his region of the world) makes a proposal with 2-3 screenshots outlining how the airport and the scenery look, and then we can vote (or Curt can pick one if we're too lay to vote, or I can pick one,...) I've seen Hamza's work - so we could pick a startup in the Middle East for a change. In the forum there's work on Heathrow - Jonathan, are you interested? There's been some compelling work on Rio as well. Anyone else? Please speak now, and you may be the one naming the next release :-)
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34865050/
| title = <nowiki>[Flightgear-devel] After the release is before the next release...</nowiki>
| author = <nowiki>Thorsten Renk</nowiki>
| date = Feb 19th, 2016
| added = Feb 19th, 2016
| script_version = 0.25
}}
}}

{{FGCquote
|1= I think the proposal/vote might be good to run on the forum. I expect there are various scenery developers who don't monitor the -devel mailing list and the wider user-base of the forum may know of "hidden gems" those on this list might miss. It would also perhaps encourage a wider group of people to participate in improving the scenery. Regarding manual updates, I'm not sure there's massive value in re-writing the tutorials etc. for each new location. It would a lot of work, and the San Francisco scenery is just a download/terrasync away. Of course, it would be nice to have a well documented VFR tutorial flight as part of the release, if only to introduce virtual fliers to the area. But that can be done as an additon to The Manual, or on the wiki or main website.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34866730/
| title = <nowiki>Re: [Flightgear-devel] After the release is before the next
release...</nowiki>
| author = <nowiki>Stuart Buchanan</nowiki>
| date = Feb 19th, 2016
| added = Feb 19th, 2016
| script_version = 0.25
}}
}}

== Status ==
{{FGCquote
|1= The plan is to query the community for a new default location, to be determined within the next three weeks.
'''...then''' the devel community tries to make it work from there (or not)

'''...then''' we need user feedback on what doesn't work

'''...then''' we can do lessons learned
and then we start it all over - or not. So please don't discuss the process right now - such discussions won't do anything right now because we have no data either way - just focus on finding a location.
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=276840#p276840
| title = <nowiki>Re: Help us find the next default airport!</nowiki>
| author = <nowiki>Thorsten</nowiki>
| date = Feb 20th, 2016
| added = Feb 20th, 2016
| script_version = 0.25
}}
}}
== Background ==
{{FGCquote
|1= part of the discussion was also that the release will be known as 'San Francisco' for the default airport. And that we will change the default airport (and the name) for subsequent releases.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34837768/
| title = <nowiki>Re: [Flightgear-devel] i think 2016.x.x is a bad name</nowiki>
| author = <nowiki>Thorsten Renk</nowiki>
| date = Feb 10th, 2016
}}
}}

{{FGCquote
|1= I think (anyone please chime in if this is incomplete) this'd need:
* an airport well-supplied with 3d models for terminals
* an appealing regional texture scheme around
* possibly definitions for AI traffic (?) - I'm not a user myself...
* someone to add some instructions to 'The Manual' which right now refers to KSFO (?)

I hope we can really base the future versioning scheme on scenery object contributor's proposal to showcase their projects. So i 2016.x.x sounds like a bad name, how does 'FG 2016 Jeddah' sound?
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34837768/
| title = <nowiki>Re: [Flightgear-devel] i think 2016.x.x is a bad name</nowiki>
| author = <nowiki>Thorsten Renk</nowiki>
| date = Feb 10th, 2016
}}
}}

== XML based Default Airport ==
{{FGCquote
|1= I do agree that it should be xml based;
nevertheless, in a seperate file perhaps, called
init.preferences.xml (with warnings not to change it at your
own risk!)

Since this job will have to be done every 3 months or so it makes sense to do it via one file, instead of
'working through this mess'.
|2= {{cite web
| url = http://permalink.gmane.org/gmane.games.flightgear.devel/81126
| title = <nowiki>Re: [Flightgear-devel] initial aircraft position when no location specified</nowiki>
| author = <nowiki>legoboyvdlp</nowiki>
| date = Mar 29th 2016
}}
}}
== Default Starting Position with no airport or lat/lon ==

Consider starting at a parking position on the ramp, not
on a runway or the center of the field!
Even if 3 planes start on top of each other, it is easy to
disconnect MP and taxi.
== Checklist ==

== Roadmap ==
* Update multiplayer defaults, settings and instructions
* Update tutorials (possibly in a scripted/automated fashion)
* Update AI scenarios
* Update preferences.xml
* Update the manual
* Update the wiki
* Develop airport procedures (SID/STAR), as appropriate
* Submit missing fixes around the airport, especially RNAV approach fixes
* Add parking positions
* Check local radio frequencies (ATIS, VOR, NDB, ILS)
* Verify ILS parameters (heading, glideslope, lat/lon)

== Lessons learnt ==

[[Category: Release]]

General Dynamics F-16 Fighting Falcon/info

2021-08-13T17:54:46Z

Legoboyvdlp: Remove personal data

<includeonly>{{infobox aircraft
| name = General Dynamics F-16 Fighting Falcon
| hangar = fgaddon
| aircraft = f16
| image = F-16C KLSV.jpg
| image2 = F-16C Cockpit.png
| alt2 = {{LangSwitch
| en = F-16CG Cockpit view
| de = F-16CG cockpit aussicht
}}
| type = Military aircraft/Attack aircraft/Fighter aircraft
| config = Retractable gear aircraft
| propulsion = Single-engine jet
| manufacturer = General Dynamics/Lockheed
| authors = Erik Hofman/Pensacola/Martin "Pegasus" Schmitt/Nikolai V. Chr./J Maverick 16/Richard Harrison/Josh Davidson/Martien Van Der P./Gary Brown/Justin Nicholson/legoboyvdlp/Timi/Enrico Castaldi
| fdm = JSBSim
| fgname1 = f16-block-10
| fgname2 = f16-block-20
| fgname3 = f16-block-30
| fgname4 = f16-block-32
| fgname5 = f16-block-40
| fgname6 = f16-block-42
| fgname7 = f16-block-50
| fgname8 = f16-block-52
| fgname9 = f16-block-60
| fgname10 = f16-simplified
| fgname11 = YF-16
| status-fdm = 5
| status-systems = 4
| status-cockpit = 4
| status-model = 4
| ready = airrefuel/canvas/checklist
| liverydbid = 20
| license = GPLv2+
| forumtid = 2003
| navbar = 1
}}
</includeonly><noinclude>
This is the aircraft infobox subpage of the [[General Dynamics F-16 Fighting Falcon]].
[[Category:Aircraft infobox documentation]]
</noinclude>

CH750/info

2021-08-13T17:54:33Z

Legoboyvdlp: Remove personal data

<includeonly>{{infobox aircraft
| name = Zenith Air CH750 STOL
| image = CH750_at_dawn.jpg
| alt = The CH750 at dawn
| image2 = CH750_Cockpit.jpg
| alt2 = The CH750 cockpit
| hangar = fgaddon
| aircraft = CH750STOL
| type = Civil aircraft/Civil utility aircraft
| config = High wing aircraft/Fixed gear aircraft
| propulsion = Propeller aircraft/Single-engine aircraft
| manufacturer = Zenith Air
| authors = hydroz.net (X-Plane model used as 3d base for this aircraft)/Legoboyvdlp/D-ECHO
| fdm = JSBSim
| fgname = CH750
| status-fdm = 1
| status-systems = 3
| status-cockpit = 4
| status-model = 3
| wikipedia = Zenith_STOL_CH_701
| navbar = 1
}}</includeonly><noinclude>
This is the aircraft infobox subpage of the [[CH750]].
[[Category:Aircraft infobox documentation]]
</noinclude>

MD-80/info

2021-08-13T17:54:21Z

Legoboyvdlp: Remove personal data

<includeonly>{{infobox aircraft
| name = McDonnell Douglas MD-80
| hangar = Octal450
| aircraft = MD-80
| image = MD-80.png
| alt = The MD-80
| type = Airliner
| config = Low wing aircraft/Monoplane aircraft/Retractable gear aircraft/Tricycle landing gear aircraft
| propulsion = Twinjet
| manufacturer = McDonnell Douglas
| authors = Josh Davidson (Octal450)/Gary Neely (Buckaroo)/ legoboyvdlp
| fdm = JSBsim
| status-fdm = 4
| status-systems = 2
| status-cockpit = 3
| status-model = 4
| navbar = 1
| ready = canvas
| forumtid = 38797
}}</includeonly><noinclude>
This is the aircraft infobox subpage of the [[MD-80]].
[[Category:Aircraft infobox documentation]]
</noinclude>

Pottier P130 UltraLight/info

2021-08-13T17:54:01Z

Legoboyvdlp: Personal data removal

<includeonly>{{infobox aircraft
| name = Pottier P130UL Coccinelle
| hangar = fgaddon
| aircraft = P130UL
| type = Ultralight aircraft
| config = High wing aircraft
| propulsion = Propeller aircraft
| manufacturer = Jean Pottier
| author1 = {{usr|Legoboyvdlp}}
| author2 = {{usr|D-ECHO}}
| author3 = Hydroz.net (3D model)
| fdm = JSBSim
| fgname = p130ul
| status-fdm = 1
| status-systems = 0
| status-cockpit = 3
| status-model = 1
| navbar = 1
}}</includeonly><noinclude>
This is the aircraft infobox subpage of the [[Pottier P130 UltraLight]].
[[Category:Aircraft infobox documentation]]
</noinclude>

Bombardier CSeries/info

2021-08-12T21:08:07Z

Legoboyvdlp: remove full name

<includeonly>
{{infobox aircraft
| name = C-Series
| image = CS300IRL.jpg
| alt = CS300 departing CYUL (IRL)
| type = Civil aircraft/Airliner/Regional Airliner
| config = Retractable gear aircraft
| propulsion = Twinjet
| manufacturer = Bombardier Aerospace
| author1 = ACJZA
| author2 = Joshua Davidson (Octal450)
| author3 = legoboyvdlp
| author4 = D-ECHO
| author5 = Suleman Siddiqui (Pakistan-1)
| author6 = Gabriel Hernandez (YV3399)
| author7 = Israel Hernandez (IAHM-COL)
| author8 = Wesley Ou (C-FWES)
| fdm = YASim
| fgname = CS100/CS300
| status = dev

| ready = canvas/checklist/tutorials
| devel-website = https://github.com/Next-Level-Simulations/CSeries
| devel-repo = https://github.com/Next-Level-Simulations/CSeries
| download = https://github.com/Next-Level-Simulations/CSeries
| forumtid = 19859
| navbar = 1
| navbarlevel =
}}</includeonly><noinclude>
This is the aircraft infobox subpage of the [[{{#titleparts:{{PAGENAME}}|1}}]].
[[Category:Aircraft infobox documentation]]
</noinclude>

Canvas Nasal API

2021-06-17T17:57:12Z

Legoboyvdlp: /* get */ Explain that you can fetch the character size

{{Template:Canvas Navigation}}

Canvas consist of a class with various nestable classes (elements).

See inside the current (Git) API {{fgdata source|Nasal/canvas/api.nas|text=here}} and {{simgear source|simgear/canvas/|text=here}}.

'''For the Canvas GUI API see [[Canvas GUI API]]'''

== Canvas ==
For constructor see: [[Howto:Add_a_2D_canvas_instrument_to_your_aircraft#Initialize_a_Canvas|Initialize a Canvas]]
=== addPlacement ===
{{Note|It is possible to place a canvas on models in the scene. Tom has not tested if it also works for MP/AI aircraft but it should. The placement in scenery objects needs a different placement type to select also the model it should be placed on. For scenery objects a special placement exists:
<syntaxhighlight lang="nasal">
var placement = { "module-id": _module_id, type: "scenery-object", <normal placement parameters like eg. node> }</syntaxhighlight>
'_module_id' is a special variable which is only set in scenery object <load> handlers.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35093833/
|title = <nowiki> Re: [Flightgear-devel] Canvas in dynamically loaded scene models </nowiki>
|author = <nowiki> Thomas Geymayer </nowiki>
|date = May 17th, 2016
|added = May 17th, 2016
|script_version = 0.40
}}</ref>
}}

See: [[Howto:Add_a_2D_canvas_instrument_to_your_aircraft#Place_it_somewhere_on_your_aircraft|Place a Canvas]]

=== setColorBackground ===
'''Parameters:''' (r, g, b, a)

Fills the background of the entire canvas with the supplied color.
=== createGroup ===
'''Parameters:''' ()

'''Parameters:''' (name)

'''Returns:''' Group

Create a new group under this Canvas. Supplying name is optional.
=== getPath ===
'''Parameters:''' ()

?
=== del ===
'''Parameters:''' ()

Deletes this Canvas.
=== wrapCanvas ===
'''Parameters:''' ()

?
=== get ===
'''Parameters:''' (name)

'''Returns:''' Canvas

Returns the canvas with the specified name.

Possible settings

* character-size - font size
* character-aspect-ratio - font aspect ratio
* ... please contribute and expand this list!

=== set ===
'''Parameters:''' (setting, value)

Not sure all the below settings can be used after initialization.

Settings can be:

"name" string

"size" vector of size 2 with ints

"view" vector of size 2 with ints

"mipmapping" bool

"additive-blend" bool

"coverage-samples" int

"color-samples" int

"freeze" bool

"render-always" bool

"update" bool

=== parsesvg ===
'''Parameters:''' (group, file)

'''Parameters:''' (group, file, font-mapper)

See: [[Howto:Use_SVG_inside_a_Canvas|SVG inside a Canvas]]
== Element ==
Note that in each element there are 2 transformation matrices. The first will be applied first, then the second.

=== set ===
'''Parameters:''' (key, value)

''Key = "z-index":''

Default value = 0

Minimum value = 0

Integer value indicates the explicit Z sort order, highest on top. If this is not set, elements that are added later gets drawn on top.
Notice that if you have for example two paths inside their own groups, and you want to order those paths in relation to each other, its on their groups you should call this method, not on the paths themselves.

FG 2.10.0.3: Elements added after z-index has been set will overrule it. (fix is in GIT)

''Key = "blend-source":''

''Key = "blend-destination":''

''Key = "blend-source-rgb":''

''Key = "blend-destination-rgb":''

''Key = "blend-source-alpha":''

''Key = "blend-destination-alpha":''

These are blending operations, they determine how a texel is drawn based on what your current element want to draw (source) and what is already drawn at this texel (destination).

For example for the 2 first listed keys, the formula is ''output_color = (blend_source * src_color) + (blend_destination * dst_color).''

The value for the keys can be one of: (string)

''zero, one, dst-color, src-color, one-minus-dst-color, one-minus-src-color, src-alpha, dst-alpha, one-minus-dst-alpha, one-minus-src-alpha, src-alpha-saturate''

You can see the formulas [[https://web.cs.ship.edu/~djmoon/cg/cg-notes/cg-ogl-blending.pdf here]]

With a little creativity these can be used for many things, like creating custom clipping geometry and other stuff.

NOTICE: Blending does NOT work for paths. They are confirmed to work with text and images though.

=== update ===
'''Parameters:''' ()

Normally an element gets updated in the next frame. Calling this will make it update in the current frame.
Note that visibility methods do get updated in the current frame.
=== getVisible ===
'''Parameters:''' ()

'''Returns:''' visible

Returns 0 if not visible, 1 if visible.
=== setVisible ===
'''Parameters:''' ()

'''Parameters:''' (visible)

Sets if this element should be visible. 0 sets it not visible, 1 visible. No parameters sets it visible.
=== show ===
'''Parameters:''' ()

Sets the element visible.
=== hide ===
'''Parameters:''' ()

Sets the element not visible.
=== toggleVisibility ===
'''Parameters:''' ()

Toggles if element should be visible.
=== setGeoPosition ===
'''Parameters:''' (lat, lon)

Sets the geographic coordinates for a map element. Parent element must be of type "map".

'''Example:''' setGeoPosition(37.615223, -122.389978)

Places element at [[San Francisco International Airport]].

=== createTransform ===
createTransform creates a new matrix on top of the existing matrix stack. A while ago I've added an example for a HUD built using the Canvas to the wiki: [[Canvas HUD]]
It doesn't use SVG but manually creates everything instead. As loading an SVG should basically do the same than handcrafting icons there shouldn't be much of a difference.

'''Parameters:''' ()

'''Parameters:''' ([a, b, c, d, e, f])

'''Return:''' The new (second) transform

Creates a new (second) transformation matrix for this element. No parameters will create a default identity matrix transform. Otherwise supply a 6 element vector for the matrix:

{| class="wikitable"
|-
| a || b || c
|-
| d || e || f
|-
| 0 || 0 || 1
|}

You should probably change the order of creating the transforms for pitch and roll as normally one would rotate first and then move according to roll and then move according to pitch up and down. Keep in mind that rotations always happens around the origin of the local coordinate frame of the object being rotated. For a rotation around another point you would need to move the object first until the center coincides with the local origin then rotate and afterwards move back. Instead of applying three transformations there exists a shortcut to pass the center of rotation as second argument to setRotation.

To further shorten the code an especially to allow rotating objects imported from SVG there exists setRotation also for canvas Elements (not only Transformation) and additionally setCenter which instead of passing the center as an argument sets the center which is being used while calling setRotation on this element. setCenter only affects setRotation of this not object but not for any matrix added with createTransform. If you set the center of rotation in Inkscape (switch to rotate mode and drag the cross to the center of rotation) it is automatically loaded with setCenter so you just need to call setRotation and automatically get a rotation around the correct center.

You don't need to care about tf[0] being reserved as it only reserves the index 0 and doesn't affect anything if not used. createTransform creates a new matrix with the next unused index starting at 1 (0 is reserved). If you later call setRotation directly on an element a new Transform will be created but this time using tf[0] to ensure it is applied before all other matrices and therefore rotating the object around its own center before being moved around.

For the HUD I'd set the rotation center correctly inside Inkscape and later on just call ladder.setRotation to rotate for changes in the roll angle. Afterwards create a Transform and use setTranslate for changes in pitch angle.

=== setTranslation ===
'''Parameters:''' (x, y)

Translates the element. The translation is set on the second transform.
=== setRotation ===
'''Parameters:''' (x, y)

Rotates the element around the center. The rotation is set on the first transform.

setRotation really just combines a rotation with two translations -> translate(-center[0], -center[1]) * rotate * translate(center[0], center[1])

You can also have a look in the property browser and check the bounding box (/canvas/by-index/texture[i]/[group[j]+]/path[j]/bounding-box) and use its coordinates to determine the correct center of rotation.

=== setScale ===
'''Parameters:''' (x, y)

Scales the element. The scale is set on the second transform.
=== getScale ===
'''Parameters:''' ()

'''Return:''' 2 element vector [x,y]

Returns the scale of this element.
=== setColorFill ===
'''Parameters:''' (r, g, b)

'''Parameters:''' (r, g, b, a)

Sets the color/alpha to be used as fill value. If you do not want the element to be filled, do not call this method.
=== getBoundingBox ===
'''Parameters:''' ()

'''Returns:''' [minX, minY, maxX, maxY]

Returns the bounds of the element.
=== updateCenter ===
'''Parameters:''' ()

Sets the center to be the center of the boundingbox in relation to the elements position in its parent.
=== setCenter ===
'''Parameters:''' (x, y)

Sets the center of the element that is used for rotation.
=== getCenter ===
'''Parameters:''' ()

Gets the center of the element.

== Group ==
Inherits from Element.
=== set ===
'''Parameters:''' (key, value)

''key = "clip"''
{{Note|
{{FGCquote
|1= Scaling or any other type of transformation or changing the coordinates of individual points is definitely more efficient than clipping (which requires to change the OpenGL clip planes for every rendered object with a different clipping rectangle).
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=277062#p277062
| title = <nowiki>Re: Space Shuttle</nowiki>
| author = <nowiki>TheTom</nowiki>
| date = Feb 21st, 2016
| added = Feb 21st, 2016
| script_version = 0.25
}}
}}
}}

Makes a clipping bounds for the group, only what is inside the clipping bounds will be shown.

It uses same coordinate format as [http://www.w3.org/TR/CSS21/visufx.html#clipping Clipping]

'''Example:''' my_grp.set("clip", "rect(62px, 587px, 262px, 437px)"); # top,right,bottom,left

''key = "clip-frame"''

Sets the coordinate system to be used for clip coordinates.

Can be canvas.Element.GLOBAL (the default value), canvas.Element.PARENT or canvas.Element.LOCAL

Notice that if set to local or parent and there is a rotation is play, the clipping wont rotate properly, it will move around and scale instead.

''key = "font"''

Sets the default font.

'''Example:''' my_group.set("font", "LiberationFonts/LiberationMono-Regular.ttf");

''key = "stroke"''

?

''key = "fill"''

?

=== setDouble ===
'''Parameters:''' (key, value)

''key = "character-aspect-ration"''

?

''key = "character-size"''

?

=== createChild ===
'''Parameters:''' (type)

'''Parameters:''' (type, name)

'''Returns:''' Element

Creates a child element under this Group. Name can be supplied. Type can be "text", "group", "path", "image", "map".
Return an Element of the particular type specified.
=== createChildren ===
'''Parameters:''' (type, count)

'''Returns:''' [Element]

Creates a number of child elements under this Group. Return a vector of Elements of the particular type specified.
=== getChildren ===
'''Parameters:''' ()

'''Returns:''' [Element]

Returns all the child elements of this group.
=== getElementById ===
'''Parameters:''' (name)

'''Returns:''' Element

Returns the first found child element with the specified name.
=== removeAllChildren ===
'''Parameters:''' ()

Removes all the child elements from this group.
== Text ==
Inherits from Element.

=== enableUpdate ===

Enables the updateText() method for a text element.

=== setText ===
'''Parameters:''' (text)

Sets the text to be displayed.

=== updateText ===
'''Parameters:''' (text)

The setText method internally writes the text string into a property node. If the method is run inside an update loop (as usually done for displays), setText writes the property regardless of whether the text has actually changed in the last update cycle. For complicated displays, this may cause a lot of unnecessary property I/O slowing down the simulation.

To improve this, updateText() keeps a Nasal variable record of the last text that has been written and writes the property only if the text has changed. Since this record needs to be allocated, the method requires to call enableUpdate() once before using it.

Note also that updateText() and setText() should not be both used on the same text element (updateText() will not register any changes made to the property string by any other means).

=== setAlignment ===
'''Parameters:''' (alignment)

Sets how the text should be aligned with its position.

Full list:
* left-top
* left-center
* left-bottom
* center-top
* center-center
* center-bottom
* right-top
* right-center
* right-bottom
* left-baseline
* center-baseline
* right-baseline
* left-bottom-baseline
* center-bottom-baseline
* right-bottom-baseline

=== setFontSize ===
'''Parameters:''' (size, aspectRatio)

Sets the size and aspectRatio of the font. AspectRatio is the Ratio between character height and width. Default aspectRatio is 1.
=== setFont ===
'''Parameters:''' (fontName)

Sets the font to be used. See [[$FG_ROOT]]/Fonts for list of fonts.

=== setDrawMode ===
'''Parameters:''' (mode)

Sets the drawing mode. You can use the values below and add those you need.

'''Text.TEXT:''' Draws the text

'''Text.BOUNDINGBOX:''' Draws the boundingbox

'''Text.FILLEDBOUNDINGBOX:''' Draws the filled boundingbox

'''Text.ALIGNMENT:''' Draws a cross where the element position is

'''Example:''' my_text.setDrawMode(Text.TEXT + Text.BOUNDINGBOX);
=== setPadding ===
Sets bounding box padding

=== setMaxWidth ===
?
=== setColor ===
'''Parameters:''' (r, g, b)

'''Parameters:''' (r, g, b, a)

Sets the color the text should be drawn in.
=== setColorFill ===
'''Parameters:''' (r, g, b)

'''Parameters:''' (r, g, b, a)

Sets the color the text background should be drawn in.

== Path ==
Inherits from Element.

A path is similar to drawing with a pen on paper. The move and moveTo methods represent lifting the pen from the paper and moving to a new position. The drawing methods like lineTo would then be seen as starting from the current position of the pen. Therefore offcouse the order the methods is called in, is important.
=== pop_front ===
'''Parameters:''' ()

Remove first segment
=== pop_back ===
'''Parameters:''' ()

Remove last segment
=== getNumSegments ===
'''Parameters:''' ()

Get the number of segments
=== reset ===
'''Parameters:''' ()

Remove all existing path data
=== moveTo ===
'''Parameters:''' (x, y)

Moves the position to an new absolute position.
=== move ===
'''Parameters:''' (x, y)

Moves the position to a new relative position from the current.
=== lineTo ===
'''Parameters:''' (x, y)

Draws a line to specified position.
=== line ===
'''Parameters:''' (x, y)

Draws a line to specified relative position.
=== horizTo ===
'''Parameters:''' (x)

Draws a horizontal line to specified position.
=== horiz ===
'''Parameters:''' (x)

Draws a horizontal line to specified relative position.
=== vertTo ===
'''Parameters:''' (y)

Draws a vertical line to specified position.
=== vert ===
'''Parameters:''' (y)

Draws a vertical line to specified relative position.
=== quadTo ===
'''Parameters:''' (x0, y0, x1, y1)

Draws quadratic Bézier curve.
=== quad ===
'''Parameters:''' (x0, y0, x1, y1)

Draws quadratic Bézier curve. Relative coordinates.
=== squadTo ===
'''Parameters:''' (x, y)

Draws smooth quadratic Bézier curve.
=== squad ===
'''Parameters:''' (x, y)

Draws smooth quadratic Bézier curve. Relative coordinates.
=== cubicTo ===
'''Parameters:''' (x0, y0, x1, y1, x2, y2)

Draws cubic Bézier curve.
=== cubic ===
'''Parameters:''' (x0, y0, x1, y1, x2, y2)

Draws cubic Bézier curve. Relative coordinates.
=== scubicTo ===
'''Parameters:''' (x, y, x2, y2)

Add a smooth cubic Bézier curve
=== scubic ===
'''Parameters:''' (x, y)

Add a smooth cubic Bézier curve. Relative coordinates.
=== rect ===
'''Parameters:''' (x, y, w, h, cfg = nil)

cfg: Optional settings (eg. {"border-top-radius": 5}, {"border-bottom-radius": 5}, {"border-radius": 5}, {"border-bottom-right-radius": 5} or {"border-left-radius": 5})

Add a (rounded) rectangle to the path

=== square ===
''' available on next, expected release 2019.1 '''

'''Parameters:''' (x, y, length, cfg = nil)

alias for rect(x, y, length, length, cfg)

Add a (rounded) square to the path

=== arcSmallCCWTo ===
=== arcSmallCCW ===
=== arcSmallCWTo ===
=== arcSmallCW ===
'''Parameters:''' (xRadius, yRadius,0,xEnd,yEnd)

Draws an arc with the specified radii, up to the specified end point. The end point is relative to the starting point.

To draw half a circle with radius 20 around the origin:
.moveTo(-20,0)
.arcSmallCW(20,20,0,40,0);

To draw a circle with radius 20 around the origin:
.moveTo(-20,0)
.arcSmallCW(20,20,0,40,0)
.arcSmallCW(20,20,0,-40,0);

=== arcLargeCCWTo ===
=== arcLargeCCW ===
=== arcLargeCWTo ===
=== arcLargeCW ===

Drawing arcs examples :
[[File:Canvas arc.png|thumb|Canvas arc draw examples]]
<syntaxhighlight lang="nasal">
var fpv = group.createChild("group", "FPV");

fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,255,1)")
.moveTo(100, 100).arcSmallCCW(50, 50, 0, 50, 50);
fpv.createChild("path").setStrokeLineWidth(4) .set("stroke", "rgba(255,0,255,1)")
.moveTo(300, 100).arcSmallCCW(50, 50, 0, 100, 0);
fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,255,1)")
.moveTo(500, 100).arcSmallCCW(50, 50, 0, 50, -50);

fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(55,0,255,1)")
.moveTo(100, 300).arcSmallCW(50, 50, 0, 50, 50);
fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(55,0,255,1)")
.moveTo(300, 300).arcSmallCW(50, 50, 0, 100, 0);
fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(55,0,255,1)")
.moveTo(500, 300).arcSmallCW(50, 50, 0, 50, -50);

fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,55,1)")
.moveTo(100, 500).arcLargeCCW(50, 50, 0, 50, 50);
fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,55,1)")
.moveTo(300, 500).arcLargeCCW(50, 50, 0, 100, 0);
fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,55,1)")
.moveTo(500, 500).arcLargeCCW(50, 50, 0, 50, -50);

fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,55,1)")
.moveTo(100, 500).arcLargeCCW(50, 50, 0, 50, 50);
fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,55,1)")
.moveTo(300, 500).arcLargeCCW(50, 50, 0, 100, 0);
fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,55,1)")
.moveTo(500, 500).arcLargeCCW(50, 50, 0, 50, -50);

fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,55,1)")
.moveTo(100, 700).arcLargeCW(50, 50, 0, 50, 50);
fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,55,1)")
.moveTo(300, 700).arcLargeCW(50, 50, 0, 100, 0);
fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,5
</syntaxhighlight>

=== ellipse ===
''' available on next, expected release 2019.1 '''

'''Parameters:''' (rx, ry, cx = nil, cy = nil)

rx, ry are the radii of the ellipse
cx, cy is optional for the center coordinates

Add an ellipse to the path

=== circle ===
''' available on next, expected release 2019.1 '''

'''Parameters:''' (r, cx, cy)

alias for ellipse(r, r, cx, cy), cx, cy optional for center coordinates

Add a circle to the path.

=== close ===
'''Parameters:''' ()

Close the path (implicit lineTo to first point of path)
=== setColor ===
'''Parameters:''' (r, g, b)

'''Parameters:''' (r, g, b, a)

Sets the color of the drawn path
=== setColorFill ===
'''Parameters:''' (r, g, b)

'''Parameters:''' (r, g, b, a)

Calling this will make the path get filled in the specified color. For example if you draw a 'V' and fill it, the fill area will be a triangle inside the 'V'.
=== setStrokeLineWidth ===
'''Parameters:''' (width)

The width of the path.
=== setStrokeLineJoin ===
'''Parameters:''' (type)

Set stroke linejoin. Type can be "miter", "round" or "bevel".

[[File:Stroke join.png|Canvas stroke join]]

=== setStrokeLineCap ===
'''Parameters:''' (type)

Caps the path. Type can be "butt", "round" or "square".

[[File:Stroke cap.png|Canvas stroke cap]]

=== setStrokeDashArray ===
'''Parameters:''' (pattern)

Make dashed path. Pattern is a vector of alternating dash and gap lengths. Lines drawn will follow this pattern.

'''Example:''' my_path.setStrokeDashArray([10, 20, 10, 20, 10]);

=== setData ===

'''Parameters:''' (cmds, points)

Re-sets the data structure for a plot. cmds is an array containing the draw commands (integers, but they can be referenced via canvas.Path.VG_LINE_TO or canvas.Path.VG_MOVE_TO etc.) and points an array containing the associated points to which the curve is to be drawn in the form [x1, y1, x2, y2,...].

'''Example:''' my_path.setData([2, 4], [10, 20, 10, 40]);

See addSegment for list of commands.

=== setDataGeo ===
'''Parameters:''' (cmds, points)

Same as setData(), just for GPS coords. See addSegmentGeo() for details.

Parent element must be of type "map".

=== addSegment ===
'''Parameters:''' (cmd, coords)

Add a path segment.

Cmd can for example be canvas.Path.VG_MOVE_TO

Coords is a vector with the numbers/coordinates that the command needs.

See this list of all commands and how many coords they require.

VG_CLOSE_PATH: 0,
VG_MOVE_TO: 2,
VG_MOVE_TO_ABS: 2,
VG_MOVE_TO_REL: 2,
VG_LINE_TO: 2,
VG_LINE_TO_ABS: 2,
VG_LINE_TO_REL: 2,
VG_HLINE_TO: 1,
VG_HLINE_TO_ABS: 1,
VG_HLINE_TO_REL: 1,
VG_VLINE_TO: 1,
VG_VLINE_TO_ABS: 1,
VG_VLINE_TO_REL: 1,
VG_QUAD_TO: 4,
VG_QUAD_TO_ABS: 4,
VG_QUAD_TO_REL: 4,
VG_CUBIC_TO: 6,
VG_CUBIC_TO_ABS: 6,
VG_CUBIC_TO_REL: 6,
VG_SQUAD_TO: 2,
VG_SQUAD_TO_ABS: 2,
VG_SQUAD_TO_REL: 2,
VG_SCUBIC_TO: 4,
VG_SCUBIC_TO_ABS: 4,
VG_SCUBIC_TO_REL: 4,
VG_SCCWARC_TO: 5,
VG_SCCWARC_TO_ABS: 5,
VG_SCCWARC_TO_REL: 5,
VG_SCWARC_TO: 5,
VG_SCWARC_TO_ABS: 5,
VG_SCWARC_TO_REL: 5,
VG_LCCWARC_TO: 5,
VG_LCCWARC_TO_ABS: 5,
VG_LCCWARC_TO_REL: 5,
VG_LCWARC_TO: 5,
VG_LCWARC_TO_ABS: 5,
VG_LCWARC_TO_REL: 5,

=== addSegmentGeo ===
'''Parameters:''' (cmd, coords)

Add a path segment.

Cmd can for example be canvas.Path.VG_MOVE_TO

Coords is a vector with the numbers/coordinates that the command needs in GPS format.

The coords can for example be "E32.45" for latitude and "N45.34" for longitude. If an 'S' or 'W' is seen instead of E or N, the sign is flipped.

See addSegment for list of commands.

Parent element must be of type "map".

== Map ==
Inherits from Element.

Class for a group element on a canvas with possibly geographic positions which automatically get projected according to the specified projection.
Each map consists of an arbitrary number of layers (canvas groups)
=== del ===
'''Parameters:''' ()

Deletes the Map instance.
=== setController ===
'''Parameters:''' (controller)

A controller needs to inherit from Map.Controller
=== addLayer ===
'''Parameters:''' (factory, type_arg=nil, priority=nil, style=nil, opts=nil, visible=1)

Each layer is some kind of data to be rendered - there’s all the built in layers but WXR, TERRain or anything else specific to the acft would be another layer.
=== getLayer ===
'''Parameters:''' (type_arg)

Returns the layer corresponding to the argument type.
=== setRange ===
'''Parameters:''' (range)

This sets the display range of the map in NM.
=== getRange ===
'''Parameters:''' ()

Get current range setting
=== setPos ===
'''Parameters:''' (lat, lon, hdg=nil, range=nil, alt=nil)

This is the center of the map (very often the aircraft position, except in something special such as PLAN mode). Hdg sets the up direction (could be north, track, heading and true vs magnetic depending on the aircraft)

=== getPos ===
'''Parameters:''' ()

Returns vector with lat, lon, heading, range and altitude
=== getLat ===
'''Parameters:''' ()

Returns position latitude.
=== getLon ===
'''Parameters:''' ()

Returns position longitude.
=== getHdg ===
'''Parameters:''' ()

Return current 'up' heading.
=== getAlt ===
'''Parameters:''' ()

Returns current altitude setting in feet.
=== getRange ===
'''Parameters:''' ()

Returns current range setting.
=== getLatLon ===
'''Parameters:''' ()

Returns the center position of the map as a vector with lat and lon
=== getPosCoord ===
'''Parameters:''' ()

Returns the center position of the map as a geo.Coord

N.B.: This always returns the same geo.Coord object,
so its values can and will change at any time (call
update() on the coord to ensure it is up-to-date,
which basically calls this method again).
=== update ===
'''Parameters:''' (predicate=nil)

Update each layer on this Map. Predicate is a function that takes a layer as argument and returns true if that layer should be updated. If predicate is not supplied, all layers will be updated.
=== See also ===
[[Canvas_Maps|Canvas Maps]] and [[Canvas_Map_API|Canvas Map API]]

== Image ==
Inherits from Element.

See: [[Canvas_Image|Canvas Image]]

Changelog 2020.3

2021-06-16T12:44:23Z

Legoboyvdlp: /* 2020.3.8 */ 2020.3.9

{{changelogs|prev=2020.1|next=2022.1}}

Available in: [[Changelog_2020.3|English]], [[Zh/2020.3|Chinese]]

Please help us translate into other languages!

----
The FlightGear development team is delighted to announce the v2020.3 LTS release of FlightGear, the free, open-source flight simulator. This is the second Long Term Support release for FlightGear, since the project changed to offering both Long Term Support releases, and more cutting-edge Preview releases. This release represents the culmination of two years of development effort by a worldwide group of volunteers, brought together by a shared ambition to create the most realistic flight simulator possible that is free to use, modify and distribute. FlightGear is used all over the world by desktop flight simulator enthusiasts, for research in universities and for interactive exhibits in museums.

Major enhancements since the v2020.3 LTS include:
* a developer preview of the upcoming Compositor graphical rendering framework as a separate pre-built binary,
* enhancements to both the JSBSim and YASim flight dynamics models
* DDS texture caching to reduce load times
* faster loading and more memory efficient buildings
* improved aircraft carrier support

Additionally 30 completely new aircraft have been added to the official hangar, and a further 71 have received major updates.

{{Disclaimer|id=final-fixed-function-release}}

Founded in 1997, FlightGear features more than 700 aircraft, a worldwide scenery database, a multiplayer environment, detailed sky modelling, a flexible and open aircraft modelling system, varied networking options, multiple display support, a powerful scripting language, and an open architecture. Best of all, being open-source, the simulator is owned by the community and everyone is encouraged to contribute.

FlightGear - Fly Free!

----

== Launcher ==
* Addition of a welcome screen on first launch, providing helpful information to first time users.
* Aircraft can now be marked as Favourites, and filtered, making it easier to see find your favourite aircraft out of the hundreds available.
* The launcher now supports aircraft carriers, including selecting a carrier and setting a start position.
* {{key press|Ctrl|F}} shortcut for when you just want to Fly!
* Improved support for helipads and seaports, including detection of current aircraft type.
* Numerous bugfixes and stability improvements, in particular for the aircraft and addons tabs.

== Graphics ==
* To provide a developer preview, the [[Compositor]] renderer is included as part of this release. It provides a fully XML-configurable multi-pass rendering pipeline that is compatible with ALS and includes clustered shading.
* Support for DDS Texture Cache, improving loading times for texture files.
* Star visibility is configurable based on magnitude of star and atmospheric conditions.
* Use of non-directional point sprites as a fallback for drivers that do not support triangles of point sprites is now supported by setting <code>/rendering/triangle-directional-lights=false</code>.
* A new Tower AGL view has been added. This is similar to Tower View, except that it keeps both the aircraft and the ground immediately below the aircraft in view, zooming and panning smoothly as the aircraft moves. Good for viewing landings.
* Improved airport grass textures
* Implemented tidal movement for littoral areas.
* Updated regional material definitions for California, Asia, Northern Brazil, Iceland, Jan Mayen island.
* Active volcanoes - Katla, Eyjafjallajokull, Surtsey.
* Instanced-based random and OpenStreetMap buildings, improving performance and graphical quality significantly.
* Improvements to the Wingflex Shader.
* Users may enable/disable the pilot model from the View Options dialog.

== JSBSim ==
* Added the ability to set up the starter and acceleration times of a turbine (parameters <code><n1spinup></code>, <code><n2spinup></code>, <code><n1startrate></code>, <code><n2startrate></code>).
* The <code><integrator></code> filter can now be reset to 0.0 by setting its <code><trigger></code> property to a negative value.
* The integration scheme of the <code><integrator></code> filter can now be chosen among <code>rect</code> (Euler), <code>trap</code> (Trapezoidal), <code>ab2</code> (2nd order Adams-BashForth) and <code>ab3</code> (3rd order Adams-Bashforth)
* The following functions can now be used in <code><function></code>: <code>floor</code>, <code>ceil</code> and <code>fmod</code>. Their functionalities are the same than the corresponding C/C++ functions.
* <code><function></code> now checks the number of its arguments.
* New system component linear_actuator
* Export the fuel density to the property tree
* Added cyclic clipping for FCS components
* Added the ability to control the turbine engines spin down factor
* [Backward compatibility breakage] Gyros are now measuring rotation rates instead of rotational accelerations. Gyros that measure rotational accelerations do not exist in the real world.
* Output properties of flight control elements are no longer tied. This saves a lot of spurious warning messages and allows direct references of the same properties among several flight controls.
* Water vapor in the atmosphere is now managed through its mass fraction rather than its partial pressure. The former being the physical quantity that is conserved when pressure and temperature vary.
* Check that there are at least 3 contacts before trying to trim on ground.
* Added optional transmission of the simulation time for FG UDP interface
* The existence of the property that is used for table independent vars is now checked during execution rather than when the XML definition is parsed. This relaxes the order in which filters, table and more generally flight controls need to be declared in the XML definition files.
* Electric engines RPM is now exported in UDP sockets.
* The parameter <code><ignitionn2></code> now affects N2 rather than N1.
* A warning is now given when max < min in a <code><clipto></code> rather than throwing an exception
* Added the ability to log properties in a CSV file with the new fgfs executable argument <code>--jsbsim-output-directive-file</code>

== YASim ==
* Ground friction (stiction) changes
* Support for transonic flow effects.
* Control initial gear state directly by setting <code>/fdm/yasim/respect-external-gear-state=true</code>, rather then YASim settings this depending on whether the aircraft is in the air or on the ground.
* Electric engines are now supported.

== Weather and Environment ==
* Increased turbulence will be encountered near active volcanoes.
* Configurable METAR URL.
* METAR strings are decoded and displayed in a human-readable form in the weather dialog.

== Carriers ==
* Two new carrier-specific starting options are supported in the launcher: <code>carrier-takeoff</code> and <code>carrier-approach</code>.
* A new <code>--carrier-position</code> command-line argument has been added. This can be used to select the aircraft start position on an aircraft carrier. Either a catapult (e.g. <code>cat-1</code>), a parking position (e.g. <code>park-1</code>), on final approach on the FLOLS (<code>flols</code>) or abeam the carrier (<code>abeam</code>).
* MPCarrier can now be detected by the GUI even if not available on startup. To enable this feature set <code>/sim/mp-carriers/auto-attach=true</code>.

== AI ==
* New fgcommands <code>add-aiobject</code> and <code>remove-aiobject</code> for adding/removing objects to the AI subsystem.
* New AI aircraft, including 747 Freighter, CRJ900, SR-71, Saab 340.
* Numerous updates to AI traffic schedules and airline liveries.
* Space Shuttle TAEM and approach at KEDW scenario.
* Accurate Britten-Norman Islander performance data, from an Islander pilot.

== Multiplayer ==
* Connection to VATSIM via swift is now available via the GUI.
* FGCom now supports both COM1 and COM2, as well as volume settings.
* The views defined by the user's aircraft (Pilot view, Helicopter view, Tower view etc) can now be used with multiplayer aircraft. Viewing a particular multiplayer aircraft is done by clicking in the Pilot List dialogue's "view' column (see the "Multiplayer/Pilot List" menu).
* <code>--disable-hold-short</code> option which allows the user to force a start on the runway when multiplayer is enabled. This option should be used with caution - it can give other pilots and ATC a nasty fright to find an aircraft materialize on the runway!
* Support for recording multiplayer data

== Nasal Scripting ==
* Configurable load order for core Nasal modules.
* Improvements and bug fixes to Emesary, the messaging interface.
* Improvements to the core libraries.
* Garbage collection improvements to reduce frame stuttering
* Re-loadable Nasal modules
* Canvas EFIS framework
* New methods in Canvas Image to set colors of pixels in the image.

== Aircraft ==
* FG1000 Glass Panel improvements include user-configurable VFR transponder codes, volume controls, new fascia, UI is now resizeable, support for custom SVG files (e.g. for a G500). The FG1000 is now available on the Cessna 182T, J3 Cub, Diamond DA40.
* Improved glider vario instrument.
* New Aircraft:
** Airbus A320 - airliner
** Alisport Silent2Electro - glider with electric sustainer motor
** Bombardier Q400 DHC8-402 - shorthaul turboprop airliner
** Breguet Atlantic BR 1150 - long-range maritime patrol aircraft
** Cessna 140 - GA aircraft
** Cessna 208B Caravan - short range passenger, freighter and utility aircraft
** Cirrus SR22T - GA aircraft
** Diamond DA40 NG - GA aircraft, including FG1000 glass panel cockpit
** Diamond DA62 Twinstar- Twin engine GA aircraft
** Diamond HK36 Super Dimona - motorglider
** Dornier DO 28 Skyservant - Twin engine STOL utility aircraft
** Douglas TBD Devastator - WWII Torpedo bomber
** Draco Wilga - turboprop taildragger bush plane
** Fokker T.V - twin engine bomber
** Glasfluegel H201B Standard Libelle - glider
** Grumman F11-Tiger - carrier-based fighter
** Grumman HU-16A Albatross - twin engine amphibian
** Petliakov PE-8 (Ant-42/TB-7) - WWII bomber
** Piper PA28-161 Warrior II - GA aircraft
** Pipistrel Alpha Electro - electric training aircraft
** Pipistrel Taurus Electro G2.5 - glider with electric sustainer motor
** Rolladen Schneider LS8sc neo - standard glider with electric sustainer motor
** Robin DR400 Ecoflyer - GA Aircraft
** Scheibe Bergfalke II/55 - training glider
** Schempp-Hirth Arcus S - high performance glider
** Schleicher Ka6(CR) "Rhoensegler" - training glider
** SEPECAT Jaguar GR.1 - jet attack aircraft
** SUMPAC - Human powered airplane
** Supermarine Swift - jet fighter
** Yak 52 - training aircraft
* Major updates to over 70 aircraft. Including 737-100, 737-300, 777, A-26-Invader, AR-234, ASG29, ASK13, ASK21, Aero-Commander, Aichi-D3A, B-17, B-24-Liberator, B-25, Bombardier-415, CH750STOL, CRJ700-family, Cessna-208-Caravan, Cessna Citation II, Cessna-L19, Cirrus-SR22, Concorde, DO-228, DO-335, Diamond-Da40, Diamond-Da42, Dragonfly, Embraer-ERJ-145, F-15, Fairchild-Metroliner, Falcon-50, Fokker-S-11, Fw200, H4-Hercules, Harrier-GR3, Horten-Ho-IX, Hughes-XF11, J3Cub, JA37, JAS39-Gripen, Jaguar, LS4, Lancair-235, Lionceau, Lockheed-NF104A, Lockheed-P38, ME-262, Mirage-2000, MirageIV, Northrop-xb35, PC-12, Piaggio-P166, Piper-PA-28, Potez-630, R44, Ryan-Navion, SIAI-Marchetti-SF.260, Socata-ST10, SpaceShuttle, Starship, Tecnam-P2006T, UH-1, Yak-18T, Zlin-50lx, an24b, bluebird, c182s, dhc1, f-14b, f16.

== Miscellaneous ==
* Updated Chinese, Dutch, French, German, Italian, Polish and Slovak translations.
* Map dialog displays heliports and allows configurable cursor key panning
* Faster Terrasync: Download a tarball of airport information on first start and only check for updates every 24 hours rather than every simulator run.
* GPS fly-by mode
* Sentry.io integration to provide centralized crash reporting.
* Change screenshot filename to have date and time
* New thread safe particle manager -- should reduce random crashes around particles.

=Updates since 2020.1=
Changes since the 2020.1 preview release include:
* Various launcher improvements including a Welcome screen and a keyboard shortcut (Ctrl+F) to Fly!
* Improved regional definitions for California, Iceland and Northern Brazil and better grass textures.
* Implemented tidal movement for littoral areas.
* New AI model for the 747 Freighter, and numerous AI livery and traffic updates.
* Updates to the FG1000 glass panel display including configurable VFR transponder codes, volume controls, a new fascia, resizeable UI and support for custom SVG files.
* A hangar full of new aircraft: HU-16A-Albatross, LS8, Embraer-ERJ-145, Cessna 208B Caravan, PZL 104 wilga 2000 Draco, Scheibe Bergfalke, Taurus, f16, Dornier Do 28 Skyservant, Petliakov Pe 8 (Ant 42/DB 7), Grumman F.11 Tiger
* Updates to a large number of aircraft including CRJ700, Dragonfly, Mirage 2000, Jaguar GR1, H4 Hercules, JA37, Supermarine Swift, A320, Cirrus-SR22, Cessna Citation, J3Cub
* Updated Chinese, Dutch, French, German, Italian, Polish and Slovak translations.
* Faster Terrasync: Download a tarball of airport information on first start and only check for updates every 24 hours rather than every simulator run.
* GPS fly-by mode
* Sentry.io integration to provide centralized crash reporting.
* New thread safe particle manager -- should reduce random crashes around particles.

=Updates since 2020.3.0=

As 2020.3 is a long term supported release, there are ongoing bug-fixes and small improvements happening, based on user feedback and automatic reporting of crashes and issues. Significant fixes are listed below:

==2020.3.1==
* Add help page to the launcher
* Fix handling of helipads at heliports
* Migrate installed aircraft packages, when migrating to the new stable catalog
* TerraSync: improve startup performance on Windows

==2020.3.2==
* TerraSync waits for Models to be completely sync-ed, to avoid missing models when starting
* First-run screen: add a 'scroll to the bottom' hint icon
* Tides fixes from Erik Hofman
* Use nicer scrollbar for the launcher, fixes some issue with long aircraft lists
* Support Apt.dat v1000 comm frequencies
* Fix an ATC crash when repositioning
* Many translations fixes identified by Michael Danilov
* Greatly improve the Brazilian cerradio areas (near SBMQ)
* Russian translation updates
* Iceland materials fixes

==2020.3.3==
* Fix accidental mouse picks while using a right-mouse-drag to look around
* Fix the download location we recommend in the 'setup root' dialog

==2020.3.4==
* Handle more METAR strings correctly, including wind sensor failures
* Fix airmass velocity being applied to sub-models twice (eg, when dropping payloads in a cross-wind)
* Fix crash on shutdown in the properties code
* Spanish translation updates
* Disable flights to EGEL to avoid crashes in traffic code

==2020.3.5==
* Change default Windows download location to %USERS%\FlightGear\Downloads, to avoid problems with Windows Defender blocking un-trusted applications from writing to Documents, which was the previous location.
* Fix a crash when returning to FlightGear from another application and scrolling or clicking
* Avoid crashing with UIUC-based aircraft such as the Wright Flyer
* Fix a crash on macOS when a joystick failed to open
* Update the macOS application icon
* Fix Nasal crash on reset
* Canvas: allow anisotropic filtering
* Larger, improved moon texture
* UFO speed goes to 11
* Fix taxiway markings disappearing in specific graphics settings

==2020.3.6==
* Fixed crash downloading the default aircraft catalog
* Fix a hang starting at scenery in the ocean
* Fix incorrect sky & cockpit rendering with certain METAR values
* Add getting-started hints to the launcher (English only for now)
* Fix Shuttle AI scenarios
* Improvements to flight-planning mode
* Sun / moon scaling fixes
* Fix initial position of submodels
* macOS: warn if running with app translocation
* Windows: detect missing OpenGL drivers
* Fix UIUC FDM crashes
* Fix crash with invalid view numbers
* Catch FDM NaN errors more gracefully
* KAP-140 approach mode improvements
* Traffic+AI livery updates

== 2020.3.7 ==

* Enable OSM2City buildings via TerraSync for the whole planet
* C172 bug-fixes and updates
* Improved regional material definitions for Europe, California
* Allow chat box to be re-positioned
* Fix crashes related to particle systems
* Fix selection of time-zone around Beijing
* Fix display of non-Latin1 strings in Canvas displays
* Fix Multi-player mode runway-start logic to select hold-short position correctly
* macOS: fix crash on text with certain fonts
* Fix launcher language selection when the UI language include a script specifier (eg zh-Hans-CN)
* Fix aircraft-id property when loading from a hangar ( https://sourceforge.net/p/flightgear/codetickets/2502/ )
* Improve checks for out-of-date Intel Graphics drivers on Windows

== 2020.3.8 ==

* Fix behaviour of <code><local></code> particle systems
* Fix autumn tree appearance

== 2020.3.9 ==

* Fix crash in Swift
* Corrections to MP protocol timing
* Correct URL to FGData
* Fix bug in cache reload dialog
* Improvements to ATC dialog to display frequencies with 3 decimal places correctly

== References ==
{{Appendix}}

[[Category:FlightGear changelogs‎]]
[[Zh:2020.3]]

Nasal library

2021-06-16T10:46:38Z

Legoboyvdlp: /* sprintf() */ I learned that it includes + or - signs

{{Nasal Navigation|nocat=1}}
This page documents the global '''library functions and variables''' of FlightGear's built-in scripting language, [[Nasal]]. This includes ''[[#Core library functions|core library functions]]'', which were included in Nasal before its integration into FlightGear, the ''[[#Extension functions|extension functions]]'', which have been subsequently added, and are specifically designed for FlightGear, and the ''[[#variables|global variables]]'', which are conversion variables, added with extension functions, for converting between units. The relevant folders in [[Git]] are:
* {{flightgear file|src/Scripting}}
* {{simgear file|simgear/nasal}}

All these functions and variables are in the global namespace, that is, they are directly accessible (e.g., one can call <syntaxhighlight lang="nasal" inline>magvar()</syntaxhighlight> instead of <syntaxhighlight lang="nasal" inline>namespace.magvar()</syntaxhighlight>). However, if a namespace must be used, <code>globals</code> is the correct namespace, but using it is not recommended. For a more complete explanation, see [[Nasal Namespaces in-depth]].

{{tip|Copy & paste the examples into your [[Nasal Console]] and execute them to see what they do.|width=70%}}

== Core library functions ==
This is the list of the basic '''core library functions.''' Most of these functions were part of the original Nasal library (before its integration in to FlightGear), while some have been added or changed over time. See also:
* http://plausible.org/nasal/lib.html ([http://web.archive.org/web/20101010094553/http://plausible.org/nasal/lib.html archive])
* {{simgear file|simgear/nasal/lib.c}} ([http://sourceforge.net/p/flightgear/simgear/ci/next/log/?path=/simgear/nasal/lib.c history])

=== append() ===
{{Nasal doc
|syntax = append(vector, element[, element[, ...]]);
|source = {{simgear file|simgear/nasal/lib.c|l=42|t=Source}}
|text = This function appends, or adds, the given element(s) to the end of the vector given in the first argument. Returns the vector operated on.
|param1 = vector
|param1text = The vector to which the arguments will be appended.
|param2 = element
|param2text = An element to be added to the vector.
|example1 =
var vector = [1, 2, 3]; # Initialize the vector
append(vector, 4); # Append the number 4 to the end of the vector
debug.dump(vector); # Print the contents of the vector
|example2 =
var vector = [1, 2, 3]; # Initialize the vector
append(vector, 4, 5, 6); # Append the numbers 4, 5, and 6 to the end of the vector
debug.dump(vector); # Print the contents of the vector
}}

=== bind() ===
{{Nasal doc
|syntax = bind(function, locals[, outer_scope]);
|source = {{simgear file|simgear/nasal/lib.c|l=502|t=Source}}
|text = This creates a new function object. A function in Nasal is three things: the actual code, a hash/namespace of local variables available to the function namespace, and the closure object of that namespace. These correspond to the three arguments respectively.
|param1 = function
|param1text = Function to evaluate.
|param2 = locals
|param2text = Hash containing values that will become the namespace (first closure) for the function.
|param3 = outer_scope
|param3text = Optional function which is bound to the next closure. This can be bound to yet another, making a linked list.
|example1 = # This is a namespace/hash with a single member, named "key," which is initialized to 12
var Namespace = {
key: 12
};

# This is different namespace/hash containing a function
# dividing a variable "key" (which is unavailable/nil in this namespace) by 2
var AnotherNamespace = {
ret: func {
key /= 2;
}
};

# To see that key is not available, try to call AnotherNamespace.ret() first
call(AnotherNamespace.ret, [], nil, nil, var errors = []);
if(size(errors)){
print("Key could not be divided/resolved!");
debug.printerror(errors);
}

# Associate the AnotherNamespace.ret() function with the first namespace
# so that "key" is now available
var function = bind(AnotherNamespace.ret, Namespace);

# Invoke the new function
function();

# Print out the value of Namespace.key
# It was changed to 12 from 6 by AnotherNamespace.ret()
print(Namespace.key);
}}

=== call() ===
{{Nasal doc
|syntax = call(func[, args[, me[, locals[, error]]]);
|source = {{simgear file|simgear/nasal/lib.c|l=247|t=Source}}
|text = Calls the given function with the given arguments and returns the result. This function is very useful as it allows much more control over function calls and catches any errors or {{func link|die()}} calls that would normally trigger run-time errors cancelling execution of the script otherwise.
|param1 = func
|param1text = Function to execute.
|param2 = args
|param2text = Vector containing arguments to give to the called function.
|param3 = me
|param3text = <code>'''me'''</code> reference for the function call (i.e., for method calls). If given, this will override any <code>'''me'''</code> value existing in the namespace (locals argument).
|param4 = locals
|param4text = A hash with key/value pairs that will be available to the called function, typically used as the namespace for the function to be called.
|param5 = error
|param5text = A vector to append errors to. If the called function generates an error, the error, place, and line will be written to this. These errors can be printed using {{func link|printerror()|debug}}.
|example1 =
# prints "Called from call()"
call(func {
print("Called from call()");
});
|example2 =
# prints "a = 1 : b = 2
call(func(a, b){
print("a = ", a, " : b = ", b);
},
[1, 2]
);
|example3 =
var Hash = {
new: func {
var m = { parents: [Hash] };

m.el1 = "string1";
m.el2 = "string2";

return m;
}
};

# prints "me.el1 = string1", then "me.el2 = string2" on the next line
call(func(a, b){
print("me.el", a, " = ", me["el" ~ a]);
print("me.el", b, " = ", me["el" ~ b]);
},
[1, 2],
Hash.new()
);
|example4 =
# prints the value of math.pi
call(func {
print(pi);
}, nil, nil,
math
);
|example5 =
call(func {
print(math.ip); # math.ip doesn't exist
}, nil, nil, nil,
var errs = []
);
debug.printerror(errs); # The error is caught and printed using debug.printerror()
}}

=== caller() ===
{{Nasal doc
|syntax = caller([level]);
|source = {{simgear file|simgear/nasal/lib.c|l=404|t=Source}}
|text = Returns a vector containing a record from the current call stack. The level numbering starts from the currently executing function (level 0). Level 1 (the default) is the caller of the current function, and so on.

The result is a four-element vector containing '''[0]''' a hash of local variables, '''[1]''' the function object, '''[2]''' the full source file name (incl. path) and '''[3]''' the line number.
|param1 = level
|param1text = Optional integer specifying the stack level to return a result from. Defaults to 1 (i.e. the caller of the currently executing function).
|example1 =
var myFunction = func(a, b){
debug.dump(caller(0)[0]); # prints a hash of local variables, including arguments a and b
return 2 * 2;
};

print("2 x 2 = ", myFunction(2, 2));
|example2 =
var get_arg_value = func(){
print("Argument to myFunc = ", caller(1)[0]['a']); # print the value of myFunc's single argument, using caller()
};

var myFunc = func(a){
get_arg_value();
};

myFunc(3);
|example3text = This is a real example taken from {{fgdata file|Nasal/canvas/MapStructure.nas}}. Function <code>r()</code> (above the TODOs) returns a hash with the key/value pairs as per its arguments. For example, something like this is returned: <code>{ name: "<name>", vis: 1, zindex: nil }</code>.
|example3 =
var MapStructure_selfTest = func() {
var temp = {};
temp.dlg = canvas.Window.new([600,400],"dialog");
temp.canvas = temp.dlg.createCanvas().setColorBackground(1,1,1,0.5);
temp.root = temp.canvas.createGroup();
var TestMap = temp.root.createChild("map");
TestMap.setController("Aircraft position");
TestMap.setRange(25); # TODO: implement zooming/panning via mouse/wheel here, for lack of buttons :-/
TestMap.setTranslation(
temp.canvas.get("view[0]")/2,
temp.canvas.get("view[1]")/2
);
var r = func(name,vis=1,zindex=nil) return caller(0)[0];
# TODO: we'll need some z-indexing here, right now it's just random
# TODO: use foreach/keys to show all layers in this case by traversing SymbolLayer.registry direclty ?
# maybe encode implicit z-indexing for each lcontroller ctor call ? - i.e. preferred above/below order ?
foreach(var type; [r('TFC',0),r('APT'),r('DME'),r('VOR'),r('NDB'),r('FIX',0),r('RTE'),r('WPT'),r('FLT'),r('WXR'),r('APS'), ] )
TestMap.addLayer(factory: canvas.SymbolLayer, type_arg: type.name,
visible: type.vis, priority: type.zindex,
);
}; # MapStructure_selfTest
}}

=== chr() ===
{{Nasal doc
|syntax = chr(code);
|source = {{simgear file|simgear/nasal/lib.c|l=175|t=Source}}
|text = Returns a character as per the single argument. Extended ASCII is supported (see http://www.asciitable.com/ for a list of supported characters), although this may vary between different systems. For a list of the most commonly used characters, see the {{wikipedia|ASCII#ASCII printable code chart|ASCII printable code chart}} ('''Dec''' column). The following table lists supported control characters, along with their equivalent control characters in Nasal strings. {{Note|In Nasal, only strings enclosed with double-quotes (<code>"string"</code>) supports control chracters. Strings in single quotes (<code>'string'</code>) do not.}}
{{{!}} class="wikitable"
! Code !! Name !! Equivalent to
{{!-}}
{{!}} 10 {{!!}} {{Wikipedia|Newline}} {{!!}} <code>\n</code>
{{!-}}
{{!}} 9 {{!!}} {{Wikipedia|Tab key#Tab characters|Horizontal tab}} {{!!}} <code>\t</code>
{{!-}}
{{!}} 13 {{!!}} {{Wikipedia|Carriage return}} {{!!}} <code>\r</code>
{{!}}}
|param1 = code
|param1text = Integer character code for the desired glyph.
|example1 = print("Code 65 = ", chr(65)); # prints "Code 65 = A"
|example2text = This example displays all of the characters in a list, in the format <code>Code '''n''' = >'''char'''<</code>, '''n''' being the index, and '''char''' being the character.
|example2 =
for(var i = 0; i <= 255; i += 1){
print("Code ", i, " = >", chr(i), "<");
}
}}

=== closure() ===
{{Nasal doc
|syntax = closure(func[, level]);
|source = {{simgear file|simgear/nasal/lib.c|l=421|t=Source}}
|text = Returns the hash table containing the lexical namespace of the given function. The level numbering start with level 0 being the namespace of '''func'''.
|param1 = func
|param1text = Function to evaluate.
|param2 = level
|param2text = Optional integer specifying the scope level. Defaults to 0 (the namespace of '''func''').
|example1 =
var get_math_e = func {
return e; # return the value of math.e
}

var myFunction = bind(get_math_e, math); # bind get_math_e to the math namespace, so that math.e is immediately available to get_math_e
debug.dump(closure(myFunction)); # print the namespace of get_math_e

print(myFunction());
}}

=== cmp() ===
{{Nasal doc
|syntax = cmp(a, b);
|source = {{simgear file|simgear/nasal/lib.c|l=112|t=Source}}
|text = Compares two strings, returning -1 if '''a''' is less than '''b''', 0 if they are identical and 1 if '''a''' is greater than '''b'''.
|param1 = a
|param1text = First string argument for comparison.
|param2 = b
|param2text = Second string argument for comparison.
|example1 = print(cmp("1", "two")); # prints -1
|example2 = print(cmp("string", "string")); # prints 0
|example3 = print(cmp("one", "2")); # prints 1
|example4 = print(cmp("string1", "string2")); # prints -1
}}

=== compile() ===
{{Nasal doc
|syntax = compile(code[, filename]);
|source = {{simgear file|simgear/nasal/lib.c|l=220|t=Source}}
|text = Compiles the specified code string and returns a function object bound to the current lexical context. If there is an error, the function dies, with the argument to {{func link|die()}} being '''filename'''.
|param1 = code
|param1text = String containing Nasal code to be compiled.
|param2 = filename
|param2text = Optional string used for error messages/logging. Defaults to <code><compile></code>
|example1 =
var myCode = 'print("hello");';
var helloFunc = compile(myCode, "myCode");
helloFunc();
|example2text = <code>compile</code> is very convenient to support Nasal loaded from other files. For instance, [[PropertyList XML files]] (such as GUI dialogs) may contain embedded Nasal sections that need to be parsed, processed and compiled. For an example of how to do this, save the below XML code as <tt>''[[$FG_ROOT]]/gui/dialogs/test.xml''</tt>.
<syntaxhighlight lang="xml">
<?xml version="1.0"?>

<PropertyList>

<nasal><![CDATA[
print("You have FlightGear v", getprop("/sim/version/flightgear"));
]]></nasal>

</PropertyList>
</syntaxhighlight>
Now, start FlightGear and execute this code in the [[Nasal Console]].
|example2 =
# Build the path
var FGRoot = getprop("/sim/fg-root");
var filename = "/gui/dialogs/test.xml";
var path = FGRoot ~ filename;

var blob = io.read_properties(path);
var script = blob.getValues().nasal; # Get the nasal string

# Compile the script. We're passing the filename here for better runtime diagnostics
var code = call(func {
compile(script, filename);
}, nil, nil, var compilation_errors = []);

if(size(compilation_errors)){
die("Error compiling code in: " ~ filename);
}

# Invoke the compiled script, equivalent to code();
# We're using call() here to detect errors:
call(code, [], nil, nil, var runtime_errors = []);

if(size(runtime_errors)){
die("Error calling code compiled loaded from: " ~ filename);
}
}}

=== contains() ===
{{Nasal doc
|syntax = contains(hash, key);
|source = {{simgear file|simgear/nasal/lib.c|l=184|t=Source}}
|text = Returns 1 (True) if the hash contains the specified key, or 0 (False) if not.
|param1 = hash
|param1text = The hash to search in.
|param2 = key
|param2text = The scalar to be searched for, contained as a key in the hash.
|example1 =
# Initialize a hash
var hash = {
element: "value"
};
print(contains(hash, "element") ? "Yes" : "No"); # This will print "Yes"
|example2 =
# Initialize a hash
var hash = {
element: "value"
};
print(contains(hash, "element2") ? "Yes" : "No"); # This will print "No"
}}

=== delete() ===
{{Nasal doc
|syntax = delete(hash, key);
|source = {{simgear file|simgear/nasal/lib.c|l=83|t=Source}}
|text = Deletes the key from the hash if it exists. Operationally, this is NOT identical to setting the hash value specified by the key to <code>'''nil'''</code> as the key will stay in the hash (at least for a while). This variant potentially frees storage by deleting the reference to the key and by shrinking the hash. Returns the hash that has been operated on.
|param1 = hash
|param1text = The hash from which to delete the key.
|param2 = key
|param2text = The scalar to be deleted, contained as a key in the hash.
|example1 =
# Initialize the hash
var hash = {
element1: "value1",
element2: "value2"
};
delete(hash, "element1"); # Delete element1
debug.dump(hash); # prints the hash, which is now minus element1
}}

=== die() ===
{{Nasal doc
|syntax = die(error);
|source = {{simgear file|simgear/nasal/lib.c|l=288|t=Source}}
|text = Terminates execution and unwinds the stack. The place and the line will be added to the '''error'''. This invokes the same internal exception handler used for internal runtime errors. Use this to signal fatal errors, or to implement exception handling. The error thrown (including internal runtime errors) can be caught with {{func link|call()}}.
|param1 = error
|param1text = String describing the error.
:{{inote|This parameter is technically optional, but it is highly recommended to use it.}}
|example1 =
print("Will print");
die("Don't go any further!");
print("Won't print"); # Will not be printed because die() stops the process
}}

=== find() ===
{{Nasal doc
|syntax = find(needle, haystack);
|source = {{simgear file|simgear/nasal/lib.c|l=450|t=Source}}
|text = Finds and returns the index of the first occurrence of the string '''needle''' in the string '''haystack''', or -1 if no such occurrence was found.
|param1 = needle
|param1text = String to search for.
|param2 = haystack
|param2text = String to search in.
|example1 = print(find("c", "abcdef")); # prints 2
|example2 = print(find("x", "abcdef")); # prints -1
|example3 = print(find("cd", "abcdef")); # prints 2
}}

=== ghosttype() ===
{{Nasal doc
|syntax = ghosttype(ghost);
|source = {{simgear file|simgear/nasal/lib.c|l=207|t=Source}}
|text = Returns a string containing either a descriptive name of a ghost (a raw C/C++ object), or a unique id (the pointer to the C/C++ <code>naGhostType</code> instance) if no name has been set. Ghost is an acronym that stands for '''G'''arbage-collected '''H'''andle to '''O'''ut'''S'''ide '''T'''hingy.
|param1 = ghost
|param1text = Ghost to return a description for.
|example1 = print(ghosttype(airportinfo())); # prints "airport"
}}

=== id() ===
{{Nasal doc
|syntax = id(object);
|source = {{simgear file|simgear/nasal/lib.c|l=570|t=Source}}
|text = Returns a string containing information on the type and ID of the object provided in the single argument. The information is returned in the form of <code>'''<type>''':'''<id>'''</code>, where '''<type>''' is the type of object, and '''<id>''' is the ID.
|param1 = object
|param1text = Can be either of a string, a vector, a hash, a code, a function, or a ghost.
|example1 = print(id("A")); # prints "str:000000001624A590"
}}

=== int() ===
{{Nasal doc
|syntax = int(number);
|source = {{simgear file|simgear/nasal/lib.c|l=90|t=Source}}
|text = Returns the integer part of the numeric value of the single argument, or <code>'''nil'''</code> if none exists.
|param1 = number
|param1text = Number or string with just a number in it to return an integer from.
|example1 = print(int(23)); # prints "23"
|example2 = print(int(23.123)); # prints "23"
|example3 = debug.dump(int("string")); # prints "nil"
}}

=== keys() ===
{{Nasal doc
|syntax = keys(hash);
|source = {{simgear file|simgear/nasal/lib.c|l=33|t=Source}}
|text = Returns a vector containing the list of keys found in the single hash argument.
|param1 = hash
|param1text = The hash to return the keys from.
|example1 =
# Initialize a hash
var hash = {
element1: "value",
element2: "value"
};
debug.dump(keys(hash)); # print the vector
}}

=== left() ===
{{Nasal doc
|syntax = left(string, length);
|source = {{simgear file|simgear/nasal/lib.c|l=149|t=Source}}
|version = 2.12
|commit = {{simgear commit|bd7163|t=commit}}
|text = Returns a substring of '''string''', starting from the left.
|param1 = string
|param1text = String to return part of.
|param2 = length
|param2text = Integer specifying the length of the substring to return.
|example1 = print(left("string", 2)); # prints "st"
}}

=== num() ===
{{Nasal doc
|syntax = num(number);
|source = {{simgear file|simgear/nasal/lib.c|l=102|t=Source}}
|text = Returns the numerical value of the single string argument, or <code>'''nil'''</code> if none exists.
|param1 = number
|param1text = String with just a number in it to return a number from.
|example1 = print(num("23")); # prints "23"
|example2 = print(num("23.123")); # prints "23.123"
|example3 = debug.dump(num("string")); # prints "nil"
}}

=== pop() ===
{{Nasal doc
|syntax = pop(vector);
|source = {{simgear file|simgear/nasal/lib.c|l=50|t=Source}}
|text = Removes and returns the last element of the single vector argument, or <code>'''nil'''</code> if the vector is empty.
|param1 = vector
|param1text = Vector to remove an element from.
|example1 =
var vector = [1, 2, 3];
pop(vector);
debug.dump(vector); # prints "[1, 2]"
|example2 =
var vector = [1, 2, 3];
debug.dump(pop(vector)); # prints "3"
|example3 =
var vector = [];
debug.dump(pop(vector)); # prints "nil"
}}

=== right() ===
{{Nasal doc
|syntax = right(string, length);
|source = {{simgear file|simgear/nasal/lib.c|l=161|t=Source}}
|version = 2.12
|commit = {{simgear commit|bd7163|t=commit}}
|text = Returns a substring of '''string''', starting from the right.
|param1 = string
|param1text = String to return part of.
|param2 = length
|param2text = Integer specifying the length of the substring to return.
|example1 = print(right("string", 2)); # prints "ng"
}}

=== setsize() ===
{{Nasal doc
|syntax = setsize(vector, size);
|source = {{simgear file|simgear/nasal/lib.c|l=56|t=Source}}
|text = Sets the size of a vector. The first argument specifies a vector, the second a number representing the desired size of that vector. If the vector is currently larger than the specified size, it is truncated. If it is smaller, it is padded with <code>'''nil'''</code> entries. Returns the vector operated upon.
|param1 = vector
|param1text = The vector to be operated on.
|param2 = size
|param2text = The desired size of the vector in number of entries.
|example1 =
var vector = [1, 2, 3]; # Initialize a vector
setsize(vector, 4);
debug.dump(vector); # print the vector
|example2 =
var vector = [1, 2, 3]; # Initialize a vector
setsize(vector, 2);
debug.dump(vector); # print the vector
}}

=== size() ===
{{Nasal doc
|syntax = size(object);
|source = {{simgear file|simgear/nasal/lib.c|l=23|t=Source}}
|text = Returns the size of the single argument. For strings, this is the length in bytes. For vectors, this is the number of elements. For hashes, it is the number of key/value pairs. If the argument is <code>'''nil'''</code> or a number, this error will be thrown: <code>object has no size()</code>.
|param1 = object
|param1text = Object to find the size of. Must be a string, a vector or a hash.
|example1 =
var string = "string";
print(size(string)); # prints "6"
|example2 =
var vector = [1, 2, 3];
print(size(vector)); # prints "3"
|example3 =
var hash = {
element1: "value1",
element2: "value2",
element3: "value3"
};
print(size(hash)); # prints "3"
}}

=== sort() ===
{{Nasal doc
|syntax = sort(vector, function);
|source = {{simgear file|simgear/nasal/lib.c|l=542|t=Source}}
|text = Returns a vector containing the elements in the input '''vector''' sorted in according to the rule given by '''function'''. Implemented with the ANSI C {{func link|qsort()|link=http://www.cplusplus.com/reference/cstdlib/qsort/}}, <code>sort()</code> is stable. This means that if the rules in the first example are used, equal elements in the output vector will appear in the same relative order as they do in the input. It is run in a loop, so '''function''' is run several times.
|param1 = vector
|param1text = Input vector to sort.
|param2 = function
|param2text = Function according to which the elements will be sorted by. It should take two arguments and should return one of 1, 0, or -1.
{{{!}} class="wikitable"
! Return value !! Meaning
{{!-}}
{{!}} less than 0 {{!!}} first argument should go before second argument
{{!-}}
{{!}} 0 {{!!}} first argument equals second argument
{{!-}}
{{!}} greater than 0 {{!!}} first argument should go after second argument
{{!}}}

|example1text = This example sorts elements from smallest to greatest.
|example1 =
var sort_rules = func(a, b){
if(a < b){
return -1; # A should before b in the returned vector
}elsif(a == b){
return 0; # A is equivalent to b
}else{
return 1; # A should after b in the returned vector
}
}
debug.dump(sort([3, 2, 5, 6, 4, 1], sort_rules)); # prints "[1, 2, 3, 4, 5, 6]"
|example2text = This example sorts elements from greatest to smallest.
|example2 =
# Outputs the elements in reverse order (greatest to smallest)
var sort_rules = func(a, b){
if(a < b){
return 1; # -1 in the above example
}elsif(a == b){
return 0;
}else{
return -1; # 1 in the above example
}
}
debug.dump(sort([3, 2, 5, 6, 4, 1], sort_rules)); # prints "[6, 5, 4, 3, 2, 1]"
|example3text = This example sorts a vector of strings (runways for example) from smallest to greatest.
|example3 =
var runways = ["09R","27R","26L","09L","15"];
var rwy = sort(runways,func(a,b) cmp(a,b));
debug.dump(rwy); # prints ['09L','09R','15','26L','27R']
}}

=== split() ===
{{Nasal doc
|syntax = split(delimiter, string);
|source = {{simgear file|simgear/nasal/lib.c|l=460|t=Source}}
|text = Splits the input string into a vector of substrings bounded by occurrences of the delimiter substring.
|param1 = delimiter
|param1text = String that will split the substrings in the returned vector.
|param2 = string
|param2text = String to split up.
|example1 = debug.dump(split("cd", "abcdef")); # prints "['ab', 'ef']"
|example2 = debug.dump(split(".", "3.2.0")); # prints "[3, 2, 0]"
|example3 = debug.dump(split("/", "path/to/file")); # prints "['path', 'to', 'file']"
}}

=== sprintf() ===
{{Nasal doc
|syntax = sprintf(format[, arg[, arg, [...]]]);
|source = {{simgear file|simgear/nasal/lib.c|l=355|t=Source}}
|text = Creates and returns a string formatted using ANSI C {{func link|vsnprintf()|link=http://en.cppreference.com/w/c/io/vfprintf}} <ref>
{{Cite web
|url = http://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/nasal/lib.c#l308
|title = fgdata/simgear/simgear/nasal/lib.c, line 308
|accessdate = October 2015
}}
</ref>. Below is a table of supported format specifiers.
{{{!}} class="wikitable" width="75%"
{{!}}+ %[flags][width][.precision]specifier
! colspan="2" {{!}} Flags
{{!-}}
! Flag !! Output
{{!-}}
{{!}} <code>+</code> {{!!}} Forces to precede the result with a plus or minus sign ('''+''' or '''-''') even for positive numbers. By default, only negative numbers are preceded with a '''-''' sign.
{{!-}}
{{!}} ''space'' {{!!}} Prefixes non-signed numbers with a space.
{{!-}}
{{!}} <code>-</code> {{!!}} Left-align the output of this placeholder (the default is to right-align the output) when the width option is specified.
{{!-}}
{{!}} <code>0</code> {{!!}} Use 0 instead of spaces to pad a field when the width option is specified.
{{!-}}
{{!}} <code>#</code> {{!!}} Used with <code>o</code>, <code>x</code> or <code>X</code> specifiers the value is preceded with <tt>0</tt>, <tt>0x</tt> or <tt>0X</tt> respectively for values different than zero. Used with <code>e</code>, <code>E</code> and <code>f</code>, it forces the written output to contain a decimal point even if no digits would follow. By default, if no digits follow, no decimal point is written. Used with <code>g</code> or <code>G</code> the result is the same as with <code>e</code> or <code>E</code> but trailing zeros are not removed.
{{!-}}
! colspan="2" {{!}} Width
{{!-}}
{{!}} colspan="2" {{!}} Integer specifying the minimum number of characters to be returned. This includes the decimal point and decimal fraction as well as + or - signs.
{{!-}}
! colspan="2" {{!}} Precision
{{!-}}
{{!}} colspan="2" {{!}} Integer preceded by a dot specifying the number of decimal places to be written.
{{!-}}
! colspan="2" {{!}} Specifiers
{{!-}}
! Specifier !! Output
{{!-}}
{{!}} <code>d</code>, <code>i</code> {{!!}} Signed decimal number.
{{!-}}
{{!}} <code>s</code> {{!!}} A string
{{!-}}
{{!}} <code>%</code> {{!!}} Percent (%) character.
{{!-}}
{{!}} <code>c</code> {{!!}} A single character assigned to a character code, the code given in an integer argument. See http://www.asciitable.com/ for a list of supported characters and their codes.
{{!-}}
{{!}} <code>o</code> {{!!}} Unsigned integer as an octal number.
{{!-}}
{{!}} <code>u</code> {{!!}} Unsigned decimal integer.
{{!-}}
{{!}} <code>x</code>, <code>X</code> {{!!}} Unsigned integer as a hexadecimal number. If <code>x</code> is used, any letters in the number are lowercase, while <code>X</code> gives uppercase.
{{!-}}
{{!}} <code>e</code>, <code>E</code> {{!!}} Double value in scientific notation (i.e., ''[-]ddd.ddd'''e'''[+/-]ddd''), with an exponent being denoted by <tt>e</tt> or <tt>E</tt> depending on whether an upper or lowercase is used respectively.
{{!-}}
{{!}} <code>f</code> {{!!}} Floating-point number, in fixed decimal notation, by default with 6 decimal places.
{{!-}}
{{!}} <code>F</code> {{!!}} Appears to be available<ref>
{{Cite web
|url = http://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/nasal/lib.c#l389
|title = fgdata/simgear/simgear/nasal/lib.c, line 389
|accessdate = October 2015
}}
</ref>, but doesn't work.
{{!-}}
{{!}} <code>g</code>, <code>G</code> {{!!}} Double in either normal or exponential notation, whichever is more appropriate for its magnitude. <code>g</code> uses lower-case letters, <code>G</code> uses upper-case letters. This type differs slightly from fixed-point notation in that insignificant zeroes to the right of the decimal point are not included. Also, the decimal point is not included on whole numbers.
{{!}}}

|param1 = format
|param1text = String specifying the format. Can be used with or without a format specifiers. See below for examples.
|param2 = arg
|param2text = Argument specifying a value to replace a format placeholder (such as <code>%d</code>) in the format string. Not required if there are no format specifiers.

|example1 = print(sprintf("%i", 54)); # prints "54"
|example2 = print(sprintf("Pi = %+.10f", math.pi)); # prints "Pi = +3.1415926536"
|example3 =
print(sprintf("%6d", 23)); # prints " 23"
print(sprintf("%06d", 23)); # prints "000023"
|example4 =
var FGVer = getprop("/sim/version/flightgear");
print(sprintf("You have FlightGear v%s", FGVer)); # prints "You have FlightGear v<your version>"
|example5 =
print(sprintf("Hexadecimal 100000 = %X", 100000)); # prints "Hexadecimal 100000 = 186A0"
print(sprintf("Hexadecimal 100000 = %x", 100000)); # prints "Hexadecimal 100000 = 186a0"
|example6 = print(sprintf("Code 65 is %c", 65)); # prints "Code 65 is A"
|example7 =
print(sprintf("%e", 54)); # prints "5.400000e+001"
print(sprintf("%E", 54)); # prints "5.400000E+001"
|example8 = print(sprintf("%o", 54)); # prints "66"
|example9 = print(sprintf("50%% of 100 is %i", 100 / 2)); # prints "50% of 100 is 50"
|example10 =
print(sprintf("%.2f", 1.4)); #prints "1.40"
print(sprintf("%.1f", 1.4)); #prints "1.4"
print(sprintf("% 4.1f", 1.4)); #prints " 1.4"
print(sprintf("%04.1f", 1.4)); #prints "01.4"
print(sprintf("% 6.1f", 1.4)); #prints " 1.4"
print(sprintf("%06.1f", 1.4)); #prints "0001.4"
}}

=== streq() ===
{{Nasal doc
|syntax = streq(a, b);
|source = {{simgear file|simgear/nasal/lib.c|l=129|t=Source}}
|text = Tests the string values of the two arguments for equality. This function is needed because the <code>'''=='''</code> operator (see [[Nasal_Operators#Equality|Nasal Operators]]) tests for numeric equality first. If either or both the arguments are not strings, 0 (False) will be returned. Returns either 0 (False) or 1 (True). {{Note|This function is rarely required in typical code.}}
|param1 = a
|param1text = First argument for testing equality.
|param2 = b
|param2text = Second argument for testing equality.
|example1 = print(streq("0", "0")); # prints "1" (True)
|example2 =
print(0 == 0.0); # prints "1" (True)
print(streq("0", "0.0")); # prints "0" (False)
}}

=== substr() ===
{{Nasal doc
|syntax = substr(string, start [, length]);
|source = {{simgear file|simgear/nasal/lib.c|l=129|t=Source}}
|text = Similar the {{func link|subvec()}}, but operates on strings. Computes and returns a substring. The first argument specifies a string, the second is the index of the start of a substring, the optional third argument specifies a length (the default is to return the rest of the string from the start).
|param1 = string
|param1text = String to return a substring from.
|param2 = start
|param2text = Integer specifying the start of a substring. Negative values specify a position from the end of the string.
|param3 = length
|param3text = Optional argument specifying the length of the substring. Defaults to the end of the string.
|example1 = print(substr("abcde", 1, 3)); # prints "bcd"
|example2 = print(substr("abcde", 1)); # prints "bcde"
|example3 = print(substr("abcde", 2, 1)); # prints "c"
|example4 = print(substr("abcde", -2)); # prints "de"
|example5 = print(substr("abcde", -3, 2)); # prints "cd"
}}

=== subvec() ===
{{Nasal doc
|syntax = subvec(vector, start[, length]);
|source = {{simgear file|simgear/nasal/lib.c|l=63|t=Source}}
|text = Returns a sub-range of a vector. The first argument specifies a vector, the second a starting index, and the optional third argument indicates a length (the default is to the end of the vector).
|param1 = vector
|param1text = The vector to take the sub-vector from.
|param2 = start
|param2text = The starting point of the sub-vector within the given vector.
|param3 = length
|param3text = Optional argument specifying the length of the sub-vector, from the starting point.
'''Notes:'''
* Omitting the ''vector'' and ''start'' arguments is not an error (possibly it should be) but the return value is ''nil''.
* A negative ''start'' argument ''is'' an error. This seems wrong. Perhaps the language designer could comment.
* A value of ''start'' greater than ''size(vector)'' causes an error. A value equal to ''size(vector)'' returns an empty vector.
* If the value of ''length'' is greater than ''size(vector) - start'' then it is ignored. That is, all elements from ''start'' to the end of ''vector'' are returned. If ''length'' is zero then an empty vector is returned. A negative value of ''length'' causes an error.
|example1 =
var vector = [1, 2, 3];
debug.dump(subvec(vector, 0)); # prints "[1, 2, 3]"
|example2 =
var vector = [1, 2, 3];
debug.dump(subvec(vector, 1)); # prints "[2, 3]"
|example3 =
var vector = [1, 2, 3];
debug.dump(subvec(vector, 1, 1)); # prints "[2]"
}}

=== typeof() ===
{{Nasal doc
|syntax = typeof(object);
|source = {{simgear file|simgear/nasal/lib.c|l=193|t=Source}}
|text = Returns a string indicating the whether the object is <code>'''nil'''</code>, a scalar (number or string), a vector, a hash, a function, or a ghost.
|param1 = object
|param1text = Object to return the type of.
|example1 =
var object = nil;
print(typeof(object)); # prints "nil"
|example2 =
var object = "Hello world!";
print(typeof(object)); # prints "scalar"
|example3 =
var object = math.pi;
print(typeof(object)); # prints "scalar"
|example4 =
var object = [1, 2, 3];
print(typeof(object)); # prints "vector"
|example5 =
var object = {};
print(typeof(object)); # prints "hash"
|example6 =
var object = func {};
print(typeof(object)); # prints "func"
|example7 =
var object = airportinfo();
print(typeof(object)); # prints "ghost"
}}



== Extension functions ==
The '''extension functions''' are global functions that have been added to Nasal since its integration into FlightGear. Unlike the core library functions, they are generally specifically designed to interact directly with FlightGear. Extension functions come from three source files:
* {{flightgear file|src/Scripting/NasalPositioned.cxx}}
* {{flightgear file|src/Scripting/NasalSys.cxx}}
* {{fgdata file|Nasal/globals.nas}}

=== abort() ===
{{Nasal doc
|syntax = abort();
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=565|t=Source}}
|text = This function is a wrapper for the C++ {{func link|abort()|link=http://www.cplusplus.com/reference/cstdlib/abort/}} function. It simply aborts FlightGear with an error, which varies depending on the operating system. This function should not really be used; instead, please use the "exit" [[Fgcommands|fgcommand]], which will exit FlightGear more gracefully (see example below).
|example1text = This example will immediately stop FlightGear with an error, such as "FlightGear has stopped working."
|example1 = abort();
|example2text = For exiting FlightGear in a better way, please use the following code:
|example2 = fgcommand("exit");
}}

=== abs() ===
{{Nasal doc
|syntax = abs(number);
|source = {{fgdata file|Nasal/globals.nas|t=Source}}
|text = This simple function returns the {{wikipedia|absolute value|noicon=1}} of the provided number.
|param1 = number
|param1text = This argument is required and should be a number.
|example1 = print(abs(1)); # prints "1"
|example2 = print(abs(-1)); # prints "1"
}}

=== aircraftToCart() ===
This new function in FG 2017.2.1 takes coordinates in aircraft structural coordinate system, and translate them into geocentric coordinates.
Example for (5,6,7):
<syntaxhighlight lang="nasal">
var pos = aircraftToCart({x: -5, y: 6, z: -7});
var coord = geo.Coord.new();
coord.set_xyz(pos.x, pos.y, pos.z);
</syntaxhighlight>
Notice: x and z is inverted sign on purpose.
if you want lat. lon, alt from that, just call: (degrees and meters)

<syntaxhighlight lang="nasal">
coord.lat()
coord.lon()
coord.alt()
</syntaxhighlight>

=== addcommand() ===
{{Nasal doc
|syntax = addcommand(name, code);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=659|t=Source}}
|version = 2.12
|commit = {{flightgear commit|7b663c|t=commit}}
|text = {{see also|Howto:Add new fgcommands to FlightGear}}

This function enables the addition of a new custom [[fgcommands|fgcommand]] to FlightGear from within Nasal. An fgcommand created using this method can be used in exactly the same way as the built-in fgcommands. Also, an fgcommand created via this method will always return True or 1, like all other fgcommands.
|param1 = name
|param1text = This will become the name of the new fgcommand. Must be a string.
|param2 = code
|param2text = The code that will be executed when the fgcommand is run. Must be a function.
|example1text = This example adds a new fgcommand and then runs it. Although it executes a simple {{func link|print()}} statement, any valid Nasal code can be used.
|example1 = addcommand("myFGCmd", func(node) {
print("fgcommand 'myFGCmd' has been run.");
props.dump( node );
});
fgcommand("myFGCmd", props.Node.new({foo:1, bar:2}) );
|example2text = This example demonstrates how parameters are defined in a new fgcommand.
|example2 = addcommand("myFGCmd", func(node){
print(node.getNode("number").getValue()); # prints the value of "number," which is 12
});
fgcommand("myFGCmd", props.Node.new({"number": 12}));
}}

=== airportinfo() ===
{{Nasal doc
|syntax = airportinfo();
airportinfo(type);
airportinfo(id);
airportinfo(lat, lon[, type]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1024|t=Source}}
|text = Function for retrieval of airport, heliport, or seaplane base information. It returns a Nasal ghost; however, its structure is like that of a Nasal hash. The following information is returned:
* '''parents''': A vector containing a hash of various functions to access information about the runway. See {{flightgear file|src/Scripting/NasalPositioned.cxx|l=2659}} for full list.
* '''lon''': Longitude of the location.
* '''lat''': Latitude of the location.
* '''has_metar''': True or false depending whether the airport has a [[METAR]] code defined for it.
* '''elevation''': Elevation of the location in metres.
* '''id''': ICAO code of the airport (or ID of the seaplane base/heliport).
* '''name''': Name of the airport/heliport/seaplane base.
* '''runways'''
** '''<runway name>'''
*** '''id''': Name of runway.
*** '''lat''': Latitude of the runway.
*** '''lon''': Longitude of the runway.
*** '''heading''': Heading of the runway.
*** '''length''': Length of the runway in metres.
*** '''width''': Width of the runway in metres.
*** '''surface''': Runway surface type.
*** '''threshold''': Length of the runway's {{wikipedia|displaced threshold}} in metres. Will return 0 if there is none.
*** '''stopway''': Length of the runway's stopway (the area before the threshold) in metres. Will return 0 if there is none.
*** '''reciprocal''': <code>runway</code> ghost of the reciprocal runway.
*** '''ils_frequency_mhz''': ILS frequency in megahertz.
*** '''ils''': <code>navaid</code> ghost of the ILS transmitter.
* '''helipads'''
** '''<helipad name>'''
*** '''id''': Name of helipad.
*** '''lat''': Latitude of the helipad.
*** '''lon''': Longitude of the helipad.
*** '''heading''': Heading of the helipad.
*** '''length''': Length of the helipad in metres.
*** '''width''': Width of the helipad in metres.
*** '''surface''': Helipad surface type.
* '''taxiways'''
** '''<taxiway name>'''
*** '''id''': Name of taxiway.
*** '''lat''': Latitude of the taxiway.
*** '''lon''': Longitude of the taxiway.
*** '''heading''': Heading of the taxiway.
*** '''length''': Length of the taxiway in metres.
*** '''width''': Width of the taxiway in metres.
*** '''surface''': Taxiway surface type.

Information is extracted in the same way as accessing members of a Nasal hash. For example:
<syntaxhighlight lang="nasal">
# prints to lengths of the runways of the nearest airport in feet and metres
var info = airportinfo();
print("-- Lengths of the runways at ", info.name, " (", info.id, ") --");
foreach(var rwy; keys(info.runways)){
print(rwy, ": ", math.round(info.runways[rwy].length * M2FT), " ft (", info.runways[rwy].length, " m)");
}
</syntaxhighlight>

Note that searches for locations that are a long way away (e.g., the nearest seaplane base to the middle of the Sahara) may cause FlightGear to pause for an amount of time.
|param1 = id
|param1text = The {{wikipedia|International Civil Aviation Organization airport code|ICAO code|noicon=1}} of an airport to retrieve information about.
|param2 = type
|param2text = When this argument is used, the function will return the closest airport of a certain type. Can be one of "heliport," "seaport," or "airport" (default).
: {{inote|Running this function without any parameters is equivalent to this:
: <syntaxhighlight lang="nasal">
airportinfo("airport");
</syntaxhighlight>
}}
|param3 = lat ''and'' lon
|param3text = When these parameters are used, the function will return information on the nearest airport, heliport or seaplane base (depending on the '''type''' parameter) to those coordinates.
|example1 = var info = airportinfo();
print("Nearest airport: ", info.name, " (", info.id, ")"); # prints the name and ICAO code of the nearest airport
|example2 = var info = airportinfo("heliport");
print("Elevation of the nearest heliport: ", math.round(info.elevation * M2FT), " ft"); # prints the elevation and name of the nearest heliport
|example3 = var info = airportinfo("KSQL");
print("-- Runways of ", info.name, " (", info.id, "): --");
foreach(var rwy; keys(info.runways)) {
print(rwy); # prints the runways of KSQL
}
|example4 = var info = airportinfo(37.81909385, -122.4722484);
print("Coordinates of the nearest airport: ", info.lat, ", ", info.lon); # print the name and ICAO of the nearest airport to the Golden Gate Bridge
|example5 = var info = airportinfo(37.81909385, -122.4722484, "seaport");
print("Nearest seaplane base: ", info.name, " (", info.id, ")"); # print the name and ID of the nearest seaplane base to the Golden Gate Bridge
|example6text = This example prints the all information from an <code>airportinfo()</code> call.
|example6 = var info = airportinfo("KSFO");
print(info.name);
print(info.id);
print(info.lat);
print(info.lon);
print(info.has_metar);
print(info.elevation);
foreach(var rwy; keys(info.runways)){
print("-- ", rwy, " --");
print(info.runways[rwy].lat);
print(info.runways[rwy].lon);
print(info.runways[rwy].length);
print(info.runways[rwy].width);
print(info.runways[rwy].heading);
print(info.runways[rwy].stopway);
print(info.runways[rwy].threshold);
}
}}

=== airwaysRoute() ===
{{Nasal doc
|syntax = airwaysRoute(start, end[, type]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1933|t=Source}}
|text = {{see also|Nasal Flightplan}}
This function returns a vector containing waypoints between two given waypoints. The returned waypoints are ghosts, but can be accessed in the same way as a Nasal hash. See [[Nasal Flightplan]] for more information.
|param1 = start
|param1text = Start waypoint, in the form of a waypoint ghost, such as that provided by {{func link|flightplan()}}.
|param2 = end
|param2text = Same as above.
|param3 = type
|param3text = Instructs the function to compute a high level route (when set to "highlevel"), or a low level route (when set to "lowlevel"). Defaults to "highlevel."
|example1text = In the [[route manager]] dialog, add two waypoints to the flightplan, ideally ones that are far apart (tip: use the [[Map]] for this). Then run this code in your Nasal Console.
|example1 = var fp = flightplan();
var start = fp.getWP(0);
var end = fp.getWP(fp.getPlanSize() - 1);
var rt = airwaysRoute(start, end);
foreach(var wp; rt){
print(wp.wp_name); # print the waypoints in the computed route
}
|example2text = Exactly the same as above, but computes a low level path.
|example2 = var fp = flightplan();
var start = fp.getWP(0);
var end = fp.getWP(fp.getPlanSize() - 1);
var rt = airwaysRoute(start, end, "lowlevel");
foreach(var wp; rt){
print(wp.wp_name); # print the waypoints in the computed route
}
}}

=== airway() ===

{{Nasal doc
|syntax = airway(ident [, pos]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=2644|t=Source}}
|text = {{see also|Nasal Flightplan}}
This function returns a ghost containing an airway of a specified id.
|param1 = ident
|param1text = Identifier of airway
|param2 = pos
|param1text = a Positioned ghost (leg, navaid, airport) and so on, passed to the search function.
}}

=== assert() ===
{{Nasal doc
|syntax = assert(condition[, message]);
|source = {{fgdata file|Nasal/globals.nas|t=Source}}
|version = 3.2
|commit = {{fgdata commit|8b16a7|t=commit}}
|text = Returns either true if the condition evaluates as true, or aborts with a {{func link|die()}} call, which can be customised.
|param1 = condition
|param1text = Condition to evaluate.
|param2 = message
|param2text = Optional message that will be used in any {{func link|die()}} call. Defaults to "assertion failed!"
|example1 = var a = 1;
var b = 2;
print(assert(a < b)); # prints "1" (true)
|example2 = var a = 1;
var b = 2;
assert(a > b, 'a is not greater than b'); # aborts with a custom error message
}}

=== carttogeod() ===
{{Nasal doc
|syntax = carttogeod(x, y, z);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=945|t=Source}}
|text = Converts {{wikipedia|ECEF|Earth-centered, Earth-fixed}} coordinates (x, y and z) to {{wikipedia|geodetic coordinates}} (latitude, longitude, and altitude). A vector is returned containing latitude and longitude, both in degrees, and altitude, which is returned in metres above the equatorial radius of Earth as defined by the {{wikipedia|WGS 84}} (6,378,137 metres).<ref>{{simgear file|simgear/math/sg_geodesy.hxx|l=43}}</ref>
|param1 = x
|param1text = Mandatory x-axis value, in metres.
|param2 = y
|param2text = Mandatory y-axis value, in metres.
|param3 = z
|param3text = Mandatory z-axis value, in metres.
|example1 = var (lat, lon, alt) = carttogeod(6378137, 0, 0); # point is the intersection of the prime meridian and equator.
print("Latitude: ", lat); # prints lat, lon and alt, which are all zero, see above
print("Longitude: ", lon);
print("Altitude: ", alt);
}}

=== cmdarg() ===
{{Nasal doc
|private = _cmdarg()
|syntax = cmdarg();
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=513|t=Part 1}} {{!}} {{fgdata file|Nasal/globals.nas|t=Part 2}}
|text = <code>cmdarg()</code> returns the property root of certain types of XML files. These could be nodes in the [[Property Tree]], or temporary and/or non-public nodes outside the Property tree.
It is used by Nasal scripts embedded in XML files. It returns a <code>props.Node</code> object (see {{fgdata file|Nasal/props.nas}}), and you can use all of its methods on the returned value. <code>cmdarg()</code> should only be used in four types/places of XML files:
* Bindings: This is needed so that the value of a joystick's axis can be accessed internally.
* Dialogs: This will return the root of the dialog in the Property Tree. This is useful for dialogs that are created/modified procedurally (e.g. for populating/changing widgets while loading the dialog).
* Embedded Canvases: The Nasal code behind [[Canvas]] windows [[Howto:Adding a canvas to a GUI dialog|embedded in PUI dialogs]] can use it to accessing the root directory of their Canvas.
* Animation XML files: If the animation XML file is used in an AI/MP model, <code>cmdarg()</code> will return the root of the AI model in the <code>/ai/models/</code> directory. Examples: <code>/ai/models/aircraft[3]/</code>, <code>/ai/models/multiplayer[1]/</code>

You should not use <code>cmdarg()</code> in places other than those stated above. Although it won't cause an error, it will return the value of the last legitimate <code>cmdarg()</code> call.

Also, you should not delay <code>cmdarg()</code> using {{func link|maketimer()}}, {{func link|settimer()}} or {{func link|setlistener()}}, because it will return an unrelated property.
|example1 = fgcommand("dialog-show", {"dialog-name": "cmdarg-demo"});
|example1text = <br>This example demonstrates the usage of <code>cmdarg()</code> in a binding. Save the below XML snippet as <tt>[[$FG_ROOT]]/gui/dialogs/cmdarg-demo.xml</tt>. Then run the Nasal snippet below in your [[Nasal Console]]. Upon clicking {{button|Close}}, a message will be printed sowing the root of the binding in the Property Tree.
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>

<PropertyList>

<name>cmdarg-demo</name>
<layout>vbox</layout>

<text>
<label>Click "Close" to activate the demonstration (a message in the console).</label>
</text>

<button>
<legend>Close</legend>
<binding>
<command>nasal</command>
<script>print("Button binding root: '" ~ cmdarg().getPath() ~ "'");</script>
</binding>
<binding>
<command>dialog-close</command>
</binding>
</button>

</PropertyList>
</syntaxhighlight>
|example2text = This example demonstrates the usage of <code>cmdarg()</code> in Nasal code within dialogs. Open <tt>[[$FG_ROOT]]/gui/dialogs/cmdarg-demo.xml</tt> from the previous example, copy & paste the code below, and save it. Then run the same Nasal snippet as the previous example in your Nasal Console. If you click {{button|Click me!}}, the button's label will change to "I've been changed!"
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>

<PropertyList>

<name>cmdarg-demo</name>
<layout>vbox</layout>

<text>
<label>Click "Click me!" to activate the demonstration (the button's label will change).</label>
</text>

<button>
<legend>Click me!</legend>
<binding>
<command>nasal</command>
<script>change_label();</script>
</binding>
</button>

<button>
<legend>Close</legend>
<binding>
<command>dialog-close</command>
</binding>
</button>

<nasal>
<open><![CDATA[
var dlg_root = cmdarg();
var dlg_name = {"dialog-name": "cmdarg-demo"};
var change_label = func {
dlg_root.getNode("button[0]/legend").setValue("I've been changed!");
fgcommand("dialog-close", dlg_name);
fgcommand("dialog-show", dlg_name);
}
]]></open>
</nasal>

</PropertyList>
</syntaxhighlight>
|example3text = For an example of <code>cmdarg()</code> used with Canvas, please see [[Howto:Adding a canvas to a GUI dialog#FGPlot|Howto:Adding a canvas to a GUI dialog]].
}}

=== courseAndDistance() ===
{{Nasal doc
|syntax = courseAndDistance(to);
courseAndDistance(from, to);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1668|t=Source}}
|text = Returns a vector containing the course from one point to another and the distance between them in nautical miles. The course is the initial bearing (see [http://www.movable-type.co.uk/scripts/latlong.html#bearing here]), and is in the range 0–360. Both arguments can be one of:
:* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, <code>taxiway</code>, <code>fix</code>, or <code>waypoint</code> ghost type
:* A hash with ''lat'' and ''lon'' members
:* A geo.Coord object
|param1 = from
|param1text = Optional parameter defining the from where the function should calculate its results. If the function is given one argument ('''to'''), the aircraft's current position will be used. As well as the argument types as defined above, this argument can be two numbers separated with a comma, as if the function is taking three arguments. See example 5 below.
|param2 = to
|param2text = Like the first parameter, but defines the second point.
|example1text = This example demonstrates the usage of the function with the <code>airport</code> ghost type.
|example1 = var from = airportinfo("KSFO");
var to = airportinfo("KSQL");
var (course, dist) = courseAndDistance(from, to);
print(course); # prints course from KSFO to KSQL
print(dist); # prints distance in nm from KSFO to KSQL
|example2text = This example demonstrates the usage of the function with hashes containing ''lat'' and ''lon''.
|example2 = var from = {lat: 0, lon: 0};
var to = {lat: 1, lon: 1};
var (course, dist) = courseAndDistance(from, to);
print(course);
print(dist);
|example3text = This example demonstrates usage of a geo.Coord object.
|example3 = var from = geo.Coord.new().set_latlon(0, 0);
var to = geo.Coord.new().set_latlon(1, 1);
var (course, dist) = courseAndDistance(from, to);
print(course);
print(dist);
|example4text = This example demonstrates usage of differing parameter types.
|example4 = var from = airportinfo("KSFO");
var to = geo.Coord.new().set_latlon(0, 0);
var (course, dist) = courseAndDistance(from, to);
print(course);
print(dist);
|example5text = The same as above, but the other way round.
|example5 = var to = {lat: 1, lon: 1};
var (course, dist) = courseAndDistance(0, 0, to);
print(course);
print(dist);
|example6text = Usage of just one parameter.
|example6 = var dest = airportinfo("KSQL");
var (course, dist) = courseAndDistance(dest);
print("Turn to heading ", math.round(course), ". You have ", sprintf("%.2f", dist), " nm to go");
}}

=== createFlightplan() ===
{{Nasal doc
|syntax = createFlightplan(path);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=2331|t=Source}}
|text = Creates an empty flightplan object. It accepts one argument, ''path'' passed an absolute path to a .fgfp / .gpx file, it will populate the flightplan with waypoints from the file.
|param1 = path
|param1text = Optional parameter defining the file from which a flightplan will be populated.
|example1 =
var path = getprop("/sim/fg-home") ~ "/Export/test.fgfp";
var flightplan = createFlightplan(path);
debug.dump(flightplan);
}}

=== createDiscontinuity() ===
{{Nasal doc
|syntax = createDiscontinuity();
|text = Returns a <code>waypoint</code> ghost object. A route discontinuity is inserted by an {{abbr|FMS|Flight Management System}} when it is unsure how to connect two waypoints.
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=2045|t=Source}}
|version = 2016.1
|commit = {{flightgear commit|caead6|t=commit}}
}}
=== createViaTo() ===
{{Nasal doc
|syntax = createViaTo(airway, waypoint);
|text = Returns a <code>waypoint</code> ghost object. It represents a route "via '''airway''' to '''waypoint'''".
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=2009|t=Source}}
|version = 2016.1
|commit = {{flightgear commit|caead6|t=commit}}
|param1 = airway
|param1text = The name of an airway.
|param2 = waypoint
|param2text = Must be in the airway and one of:
* The name of a waypoint.
* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, or <code>fix</code> ghost object.
}}
=== createWP() ===
{{Nasal doc
|syntax = createWP(pos, name[, flag]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1964|t=Source}}
|text = Creates a new waypoint ghost object.
|param1 = pos
|param1text = Dictates the position of the new waypoint. It can be one of the following:
:* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, <code>taxiway</code>, <code>fix</code>, or <code>waypoint</code> ghost type
:* A hash with ''lat'' and ''lon'' members
:* A geo.Coord object
:* Two numbers separated by a comma, as if the function is taking three arguments. See example 4 below.
|param2 = name
|param2text = String that will become the name of the new waypoint.
|param3 = flag
|param3text = Optional string that will tell FlightGear what type of waypoint it is. Must be one of "sid," "star," "approach," "missed," or "pseudo."
|example1text = Creates a waypoint directly in front and 1 km away and appends it to the flight plan.
|example1 = var pos = geo.aircraft_position().apply_course_distance(getprop("/orientation/heading-deg"), 1000);
var wp = createWP(pos, "NEWWP");
var fp = flightplan();
fp.appendWP(wp);
|example2 = var pos = geo.aircraft_position().apply_course_distance(getprop("/orientation/heading-deg"), 1000);
var wp = createWP({lat: pos.lat(), lon: pos.lon()}, "NEWWP");
var fp = flightplan();
fp.appendWP(wp);
|example3 = var apt = airportinfo();
var wp = createWP(apt, "NEWWP");
var fp = flightplan();
fp.appendWP(wp);
|example4 = var pos = geo.aircraft_position().apply_course_distance(getprop("/orientation/heading-deg"), 1000);
var wp = createWP(pos.lat(), pos.lon(), "NEWWP");
var fp = flightplan();
fp.appendWP(wp);
|example5text = Creates a new waypoint and adds it to the flight plan. Waypoints of the type "pseudo" are then removed from the flight plan, including the new waypoint. The {{func link|print()}} statements show this.
|example5 = var pos = geo.aircraft_position().apply_course_distance(getprop("/orientation/heading-deg"), 1000);
var wp = createWP(pos, "NEWWP", "pseudo");
var fp = flightplan();
fp.appendWP(wp);
print(fp.getPlanSize());
fp.clearWPType("pseudo");
print(fp.getPlanSize());
}}

=== createWPFrom() ===
{{Nasal doc
|syntax = createWPFrom(object[, flag]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1989|t=Source}}
|text = Creates a new waypoint object from another object.
|param1 = object
|param1text = A ghost object. Must be a ghost type that is one of "airport," "navaid," "runway," or "fix."
|param2 = flag
|param2text = Optional string that will tell FlightGear what type of waypoint it is. Must be one of "sid," "star," "approach," "missed," or "pseudo."
|example1text = Creates a new waypoint and appends it to the flight plan.
|example1 = var apt = airportinfo("KSFO");
var wp = createWPFrom(apt);
var fp = flightplan();
fp.appendWP(wp);
|example2text = Creates a new waypoint and appends it to the flight plan. This way point is then removed; the {{func link|print()}} statements prove this.
|example2 = var apt = airportinfo("KSFO");
var wp = createWPFrom(apt, "pseudo");
print(wp.wp_name);
var fp = flightplan();
fp.appendWP(wp);
print(fp.getPlanSize());
fp.clearWPType("pseudo");
print(fp.getPlanSize());
}}

=== defined() ===
{{Nasal doc
|syntax = defined(symbol);
|source = {{fgdata file|Nasal/globals.nas|t=Source}}
|text = Returns 1 (true) or 0 (false) depending on whether a variable exists.
|param1 = symbol
|param1text = A string that will be what the function searches for.
|example1 = var number = 12;
var check_exist = func {
print("Variable 'number' ", defined("number") == 1 ? "exists" : "does not exist"); # 'number' does exist
print("Variable 'number2' ", defined("number2") == 1 ? "exists" : "does not exist"); # 'number2' does not exist
}
check_exist();
}}

=== directory() ===
{{Nasal doc
|syntax = directory(path);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=572|t=Source}}
|text = Returns a vector containing a list of the folders and files in a given file path or <code>'''nil'''</code> if the path doesn't exist. Hidden folders and files are not added to the vector.
{{inote|The first two elements of the vector will be <code>'.'</code> and <code>'..'</code>. These are for navigating back up the file tree, but have no use in Nasal. They can be safely removed from the vector.}}
|param1 = path
|param1text = Absolute file path.
|example1text = Gets the folders and files in [[$FG_ROOT]], and then removes the extra first two elements (see note above).
|example1 = var dir = directory(getprop("/sim/fg-root")); # get directory
dir = subvec(dir, 2); # strips off the first two elements
debug.dump(dir); # dump the vector
}}

=== fgcommand() ===
{{Nasal doc
|syntax = fgcommand(cmd[, args]);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=456|t=Part 1}} {{!}} {{fgdata file|Nasal/globals.nas|t=Part 2}}
|text = Runs an fgcommand. See also {{readme file|commands}} and [[Bindings]] for more information. See {{flightgear file|src/Main/fg_commands.cxx|l=1425}} for the full list of fgcommands. Note that fgcommands generated by {{func link|addcommand()}} can also be run using this function. Also, the full list of fgcommands depends on the version of FlightGear you have. Returns 1 (true) if the fgcommand succeeded or 0 (false) if it failed.
|param1 = cmd
|param1text = String that is the name of the command that is to be run.
|param2 = args
|param2text = If the fgcommand takes arguments, they are inputted using this argument. Can either be a <code>props.Node</code> object, or a hash (see examples below).
|example1 = fgcommand("null"); # does nothing
|example2 = var args = props.Node.new({'script': 'print("Running fgcommand");'});
if (fgcommand("nasal", args)) { # prints "Running fgcommand" and then one of these print statements
print("Fgcommand succeeded");
} else {
print("Fgcommand encountered a problem");
}
|example3 = var args = { 'dialog-name': 'about' };
fgcommand("dialog-show", args); # shows the 'about' dialog
}}

=== findAirportsByICAO() ===
{{Nasal doc
|syntax = findAirportsByICAO(search[, type]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1096|t=Source}}
|text = Returns a vector containing <code>airport</code> ghost objects which are (by default) airports whose ICAO code matches the search string. The results are sorted by range from closest to furthest.
|param1 = search
|param1text = Search string for the function. Can either be a partial or a full ICAO code.
:{{icaution|The more matches there are for the given code, the longer the function will take. Passing just one character (e.g., "K"), might make FlightGear hang for a certain amount of time.}}
|param2 = type
|param2text = This will narrow the search to airports of a certain type. By default, only airports are searched for. May be one of "airport," "heliport," or "seaport."
|example1 = var apts = findAirportsByICAO("KSF"); # finds all airports matching "KSF"
foreach(var apt; apts){
print(apt.name, " (", apt.id, ")"); # prints them
}
|example2 = var apts = findAirportsByICAO("SP0", "seaport"); # finds all seaplane bases matching "SP0"
foreach(var apt; apts){
print(apt.name, " (", apt.id, ")"); # prints them
}
|example3 = var apt = findAirportsByICAO("XBET"); # one way to check if an airport does exist"
if (size(apt) == 0) {
print("Airport does not exist"); # this one will be printed
} else {
print("Airport does exist");
}
}}

=== findAirportsWithinRange() ===
{{Nasal doc
|syntax = findAirportsWithinRange([pos, ]range[, type]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1066|t=Source}}
|text = Returns a vector of <code>airport</code> ghost object which are (by default) airports that are within a given range of a given position, or the aircraft's current position. The results are sorted by range from closest to furthest.
|param1 = pos
|param1text = Optional position to search around. If not given, the aircraft's current position will be used. Can be one of:
:* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, <code>taxiway</code>, <code>fix</code>, or <code>waypoint</code> ghost type
:* A hash with ''lat'' and ''lon'' members
:* A geo.Coord object
:* Two numbers separated by a comma, as if the function is taking three arguments. Example: <code>findAirportsWithinRange(lat, lon, range, type);</code>.
|param2 = range
|param2text = Mandatory number giving the range in nautical miles within which to search for airports/heliports/seaplane bases.only airports are searched for.
|param3 = type
|param3text = This will narrow the search to airports of a certain type. By default, only airports are searched for. May be one of "airport," "heliport," or "seaport."
|example1text = Searches for airports within 10 nm of [[KSFO]].
|example1 = var pos = airportinfo("KSFO");
var apts = findAirportsWithinRange(pos, 10);
foreach(var apt; apts){
print(apt.name, " (", apt.id, ")");
}
|example2text = Searches for seaplane bases within 15 nm of [[KSFO]].
|example2 = var pos = airportinfo("KSFO");
var apts = findAirportsWithinRange(pos, 15, "seaport");
foreach(var apt; apts){
print(apt.name, " (", apt.id, ")");
}
|example3text = Searches for airports within 10 nm of your current position.
|example3 = var apts = findAirportsWithinRange(10);
foreach(var apt; apts){
print(apt.name, " (", apt.id, ")");
}
}}

=== findFixesByID() ===
{{Nasal doc
|syntax = findFixesByID([pos, ]id);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1627|t=Source}}
|text = Returns a vector containing <code>fix</code> ghost objects matching a given ID, sorted by range from a certain position.
{{inote|Fixes are (usually) also known as waypoints.}}
|param1 = pos
|param1text = Optional position to search around. If not given, the aircraft's current position will be used. Can be one of:
:* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, <code>taxiway</code>, <code>fix</code>, or <code>waypoint</code> ghost type
:* A hash with ''lat'' and ''lon'' members
:* A geo.Coord object
:* Two numbers separated by a comma, as if the function is taking three arguments. Example: <code>findFixesByID(lat, lon, id);</code>.
|param2 = id
|param2text = Full or partial ID of the fix to search for.
:{{inote|1=Inputting a partial ID does not work correctly (see [http://forum.flightgear.org/viewtopic.php?f=30&t=28129 here]). It is best to just input a full ID.}}
|example1 = var fixes = findFixesByID("POGIC");
foreach(var fix; fixes){
print(fix.id, " - lat: ", fix.lat, " {{!}} lon: ", fix.lon); # prints information about POGIC
}
|example2 = var fix = findFixesByID("ZUNAP");
fix = fix[0];
var (course, dist) = courseAndDistance(fix);
print("Turn to heading ", math.round(course), ". You have ", sprintf("%.2f", dist), " nm to go to reach ", fixes[0].id);
}}

=== findNavaidByFrequency() ===
{{Nasal doc
|syntax = findNavaidByFrequency([pos, ]freq[, type]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1547|t=Source}}
|text = Returns a <code>navaid</code> ghost object for a navaid matching a given frequency. If there is more than one navaid with that frequency, the nearest station is returned.
|param1 = pos
|param1text = Optional position to search around. If not given, the aircraft's current position will be used. Can be one of:
:* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, <code>taxiway</code>, <code>fix</code>, or <code>waypoint</code> ghost type
:* A hash with ''lat'' and ''lon'' members
:* A geo.Coord object
:* Two numbers separated by a comma, as if the function is taking three arguments. Example: <code>findNavaidByFrequency(lat, lon, freq, type);</code>.
|param2 = freq
|param2text = Frequency, in megahertz, of the navaid to search for.
|param3 = type
|param3text = This will narrow the search to navaids of a certain type. Defaults to "all." For the full list of accepted type arguments, see {{flightgear file|src/Navaids/positioned.cxx|l=127}}.
|example1 = var navaid = findNavaidByFrequency(11.17);
print("ID: ", navaid.id); # prints info about the navaid
print("Name: ", navaid.name);
print("Latitude: ", navaid.lat);
print("Longitude: ", navaid.lon);
print("Elevation (AMSL): ", navaid.elevation, " m");
print("Type: ", navaid.type);
print("Frequency: ", sprintf("%.3f", navaid.frequency / 1000), " Mhz");
print("Range: ", navaid.range_nm, " nm");
if(navaid.course) print("Course: ", navaid.course);
}}

=== findNavaidsByFrequency() ===
{{Nasal doc
|syntax = findNavaidsByFrequency([pos, ]freq[, type]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1572|t=Source}}
|text = Returns a vector conatining <code>navaid</code> ghost objects for navaids that match a given frequency, sorted from nearest to furthest.
|param1 = pos
|param1text = Optional position to search around. If not given, the aircraft's current position will be used. Can be one of:
:* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, <code>taxiway</code>, <code>fix</code>, or <code>waypoint</code> ghost type
:* A hash with ''lat'' and ''lon'' members
:* A geo.Coord object
:* Two numbers separated by a comma, as if the function is taking three arguments. Example: <code>findNavaidsByFrequency(lat, lon, freq, type);</code>.
|param2 = freq
|param2text = Frequency, in megahertz, of the navaid to search for.
|param3 = type
|param3text = This will narrow the search to navaids of a certain type. Defaults to "all." For the full list of accepted type arguments, see {{flightgear file|src/Navaids/positioned.cxx|l=127}}.
|example1 = var navaids = findNavaidsByFrequency(10.955);
foreach(var navaid; navaids){
print("--");
print("ID: ", navaid.id); # prints info about the navaid
print("Name: ", navaid.name);
print("Latitude: ", navaid.lat);
print("Longitude: ", navaid.lon);
print("Elevation (AMSL): ", navaid.elevation, " m");
print("Type: ", navaid.type);
print("Frequency: ", sprintf("%.3f", navaid.frequency / 1000), " Mhz");
print("Range: ", navaid.range_nm, " nm");
if(navaid.course) print("Course: ", navaid.course);
print("--");
}
}}

=== findNavaidsByID() ===
{{Nasal doc
|syntax = findNavaidsByID([pos, ]id[, type]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1600|t=Source}}
|text = Returns a vector containing <code>navaid</code> ghost objects matching a given ID, sorted by range from a certain position.
|param1 = pos
|param1text = Optional position to search around. If not given, the aircraft's current position will be used. Can be one of:
:* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, <code>taxiway</code>, <code>fix</code>, or <code>waypoint</code> ghost type
:* A hash with ''lat'' and ''lon'' members
:* A geo.Coord object
:* Two numbers separated by a comma, as if the function is taking three arguments. Example: <code>findNavaidsByID(lat, lon, id, type);</code>.
|param2 = id
|param2text = Full or partial ID of the fix to search for.
:{{inote|1=Inputting a partial ID does not work correctly (see [http://forum.flightgear.org/viewtopic.php?f=30&t=28129 here]). It is best to just input a full ID.}}
|param3 = type
|param3text = This will narrow the search to navaids of a certain type. Defaults to "all." For the full list of accepted type arguments, see {{flightgear file|src/Navaids/positioned.cxx|l=127}}.
|example1 = var navaid = findNavaidsByID("MXW");
navaid = navaid[0];
print("ID: ", navaid.id); # prints info about 'MXW' (a VOR station)
print("Name: ", navaid.name);
print("Latitude: ", navaid.lat);
print("Longitude: ", navaid.lon);
print("Elevation (AMSL): ", navaid.elevation, " m");
print("Type: ", navaid.type);
print("Frequency: ", sprintf("%.3f", navaid.frequency / 1000), " Mhz");
print("Range: ", navaid.range_nm, " nm");
}}

=== findNavaidsWithinRange() ===
{{Nasal doc
|syntax = findNavaidsWithinRange([pos, ]range[, type]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1518|t=Source}}
|text = Returns a vector of <code>navaid</code> ghost objects which are within a given range of a given position (by default the aircraft's current position). The results are sorted from closest to furthest.
|param1 = pos
|param1text = Optional position to search around. If not given, the aircraft's current position will be used. Can be one of:
:* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, <code>taxiway</code>, <code>fix</code>, or <code>waypoint</code> ghost type
:* A hash with ''lat'' and ''lon'' members
:* A geo.Coord object
:* Two numbers separated by a comma, as if the function is taking three arguments. Example: <code>findNavaidsWithinRange(lat, lon, range, type);</code>.
|param2 = range
|param2text = Mandatory number giving the range in nautical miles within which to search for navaids. Defaults to "all." For the full list of accepted type arguments, see {{flightgear file|src/Navaids/positioned.cxx|l=127}}.
|param3 = type
|param3text = This will narrow the search to navaids of a certain type.
|example1text = Searches for navaids within 10 nm of [[KSFO]].
|example1 = var pos = airportinfo("KSFO");
var navs = findNavaidsWithinRange(pos, 10);
foreach(var nav; navs){
print(nav.name, " (ID: ", nav.id, ")");
}
|example2text = Searches for navaids within 10 nm of your current position.
|example2 = var navs = findNavaidsWithinRange(10);
foreach(var nav; navs){
print(nav.name, " (ID: ", nav.id, ")");
}
}}

=== finddata() ===
{{Nasal doc
|syntax = finddata(path);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=603|t=Source}}
|text = Takes a relative path and tries to return an absolute one. It works by appending the relative path to some paths and testing to see if they exist. As of FlightGear v3.7, these paths are the TerraSync directory (tested first) and [[$FG_ROOT]].
|param1 = path
|param1text = A relative path as a string.
|example1 = var path = finddata("Aircraft/Generic");
print(path); # prints the absolute path to $FG_ROOT/Aircraft/Generic
|example2 = var path = finddata("Airports");
print(path); # prints the absolute path to <TerraSync dir>/Airports
|example3 = var path = finddata("preferences.xml");
print(path); # prints the absolute path to $FG_ROOT/preferences.xml
}}

=== flightplan() ===
{{Nasal doc
|syntax = flightplan([path]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1738|t=Source}}
|text = {{see also|Nasal Flightplan}}
Returns a flight plan object, either one for the current flight plan, or one loaded from a given path.
|param1 = path
|param1text = Optional path to flight plan XML file.
|example1text = Gets the active flight plan and gets the ID of the current waypoint. Note that this example requires a flight plan to be set in the [[Route Manager]] first.
|example1 = var fp = flightplan();
print(fp.getWP(fp.current).id);
|example2text = Creates a new flight plan from an XML file and prints the IDs of the waypoints. Note that this example requires a flight plan to have been created and saved as <tt>''[[$FG_HOME]]/fp-demo.xml''</tt>.
|example2 = var path = getprop('/sim/fg-home') ~ '/fp-demo.xml';
var fp = flightplan(path);
for(var i = 0; i < fp.getPlanSize(); i += 1){
print(fp.getWP(i).id);
}
}}

=== geodinfo() ===
{{Nasal doc
|syntax = geodinfo(lat, lon[, max_alt]);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=981|t=Source}}
|text = Returns a vector containing two entries or <code>'''nil'''</code> if no information could be obtained because the terrain tile wasn't loaded. The first entry in the vector is the elevation (in meters) for the given point, and the second is a hash with information about the assigned material (as defined in <tt>''[[$FG_ROOT]]/Materials''</tt>), or <code>'''nil'''</code> if there was no material information available (for example, because there is an untextured building at that location). The structure of the hash is as follows (see also {{readme file|materials}}):
* '''light_coverage:''' The coverage of a single point of light in m<sup>2</sup>.
* '''bumpiness:''' Normalized bumpiness factor for the material.
* '''load_resistance:''' The amount of pressure in N/m<sup>2</sup> the material can withstand without deformation.
* '''solid:''' 1 (true) or false (0) depending on whether the material is solid or not.
* '''names:''' Vector of scenery types (usually generated by [[TerraGear]]) that will use this material.
* '''friction_factor:''' Normalized friction factor of the material.
* '''rolling_friction:''' The rolling friction coefficient of the material.

Note that this function is a ''very'' CPU-intensive operation, particularly in FlightGear v2.4 and earlier. It is advised to use this function as little as possible.
|param1 = lat
|param1text = Latitude, inputted as a number.
|param2 = lon
|param2text = Longitude, inputted as a number.
|param3 = max_alt
|param3text = The altitude, in metres, from which the function will begin searching for the height of the terrain. Defaults to 10,000 metres. If the terrain is higher than this argument specifies, <code>'''nil'''</code> will be returned.
|example1text = Dumps information about ground underneath the aircraft.
|example1 = var pos = geo.aircraft_position();
var info = geodinfo(pos.lat(), pos.lon());
debug.dump(info);
|example2text = Prints whether the ground underneath the aircraft is solid or is water.
|example2 = var pos = geo.aircraft_position();
var info = geodinfo(pos.lat(), pos.lon());
if (info != nil and info[1] != nil) {
print("The ground underneath the aircraft is ", info[1].solid == 1 ? "solid." : "water.");
}
}}

=== geodtocart() ===
{{Nasal doc
|syntax = geodtocart(lat, lon, alt);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=962|t=Source}}
|text = Converts {{wikipedia|geodetic coordinates}} (latitude, longitude, and altitude) to {{wikipedia|ECEF|Earth-centered, Earth-fixed}} coordinates (x, y and z). A vector is returned containing x, y, and z in metres. The equatorial radius of earth used is that defined by the {{wikipedia|WGS 84}} (6,378,137 metres). All argument are mandatory.
|param1 = lat
|param1text = Latitude, in degrees.
|param2 = lon
|param2text = Longitude, in degrees.
|param3 = alt
|param3text = Altitude, in metres.
|example1 = var (x, y, z) = geodtocart(0, 0, 0); # point is the intersection of the prime meridian and equator.
print("x: ", x); # prints "x: 6378137"
print("y: ", y); # prints "y: 0"
print("z: ", z); # prints "y: 0"
}}

=== get_cart_ground_intersection() ===
Introduced in 2017.2.1, see [[Terrain Detection]].

=== getprop() ===
{{Nasal doc
|syntax = getprop(path[, path[, ...]]);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=345|t=Source}}
|text = Returns the value of a node in the [[Property Tree]] or <code>'''nil'''</code> if the node does not exist or the value is not a number (NaN).
|param1 = path
|param1text = There needs to be at least one argument, but there is no limit to the maximum amount of arguments that can be given. The arguments will be concatenated together to form a property tree path. The arguments must be strings, but in FlightGear v3.2 onwards, there is also support (added by {{flightgear commit|34ed79}}) for numeric arguments as indices. See example 2 below.
|example1 = print("You have FlightGear v", getprop("/sim/version/flightgear")); # prints FlightGear version
|example2text = Note that the example below will only work in FlightGear 3.2 and above.
|example2 = for(var i = 0; i < 8; i += 1){
print("View #", i + 1, " is named ", getprop("/sim/view", i, "name"));
}
|example3text = Same as above, but is supported by all versions of FlightGear.
|example3 = for(var i = 0; i < 8; i += 1){
print("View #", i + 1, " is named ", getprop("/sim/view[" ~ i ~ "]/name"));
}
}}
==== See also ====
{{note| If you have to read/write the same property multiple times (e.g. in an update loop), it is more efficient to use a node object:
To get a Node rather than its value, use <code>props.globals.getNode()</code> - see [[Nasal_library/props]]. }}

=== greatCircleMove() ===
{{Nasal doc
|syntax = greatCircleMove([pos, ]course, dist);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1681|t=Source}}
|text = Calculates a new set of geodetic coordinates using inputs of course and distance, either from the aircraft's current position (by default) or from another set of coordinates. Returns a hash containing two members, ''lat'' and ''lon'' (latitude and longitude respectively).
|param1 = pos
|param1text = Optional position to calculate from. If not given, the aircraft's current position will be used. Can be one of:
:* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, <code>taxiway</code>, <code>fix</code>, or <code>waypoint</code> ghost object.
:* A hash with ''lat'' and ''lon'' members
:* A <code>geo.Coord</code> object
:* A lat/lon pair, that is, a pair of numbers (latitude followed by longitude) separated by a comma: <code>greatCircleMove(lat,lon, ...)</code>.
|param2 = course
|param2text = Course to new set of coordinates, in degrees (in the range 0–360).
|param3 = dist
|param3text = Distance in nautical miles to the new set of coordinates.
|example1 = var pos = greatCircleMove(0,0, 0, 1);
debug.dump(pos); # print hash with coordinates
|example2 = var fix = findFixesByID("POGIC");
fix = fix[0];
var pos = greatCircleMove(fix, 45, 10);
debug.dump(pos); # print hash with coordinates
}}

=== interpolate() ===
{{Nasal doc
|private = _interpolate()
|syntax = interpolate(prop, value1, time1[, value2, time2[, ...]]);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=522|t=Part 1}} {{!}} {{fgdata file|Nasal/globals.nas|t=Part 2}}
|text = Linearly interpolates a node in the property tree to a given value in a specified time. The value/time pairs will be run one after the other in the order that they are passed to the function. Note that the interpolation will continue even when the simulation is paused.
|param1 = prop
|param1text = String or <code>props.Node</code> object that indicates a node in the property tree to be used.
|param2 = value''n''
|param2text = Target value to change the property to in the set amount of time. This should be a number.
|param3 = time''n''
|param3text = Time in seconds, that will be taken for the interpolation.
|example1text = Paste the code below into the Nasal Console and execute. Then, open the Property Browser and look for the property. Finally, run the code again, and watch the value of the property change.
|example1 = setprop("/test", 0); # (re-)set property
interpolate("/test",
50, 5, # interpolate to 50 in 5 seconds
10, 2, # interpolate to 10 in 2 seconds
0, 5); # interpolate to 0 in 5 seconds
|example2 = # Apply the left brake at 20% per second
var prop = "controls/gear/brake-left";
var dist = 1 - getprop(prop);
if (dist == 1) {
interpolate(prop, 1, dist / 0.2);
}
}}

=== isa() ===
{{Nasal doc
|syntax = isa(object, class);
|source = {{fgdata file|Nasal/globals.nas|t=Source}}
|text = Checks if an object is an instance of, or inherits from, a second object (or class), returning 1 (true) if it is and 0 (false) if otherwise.
|param1 = object
|param1text = Object to check.
|param2 = class
|param2text = Class/object to check that '''object''' inherits from or is an instance of.
|example1 = var coord = geo.Coord.new();
if(isa(coord, geo.Coord)){
print("Variable 'coord' is an instance of class 'geo.Coord'"); # this one will be printed
} else {
print("Variable 'coord' is not an instance of class 'geo.Coord'");
}
|example2 = var coord = geo.Coord.new();
if(isa(coord, props.Node)){
print("Variable 'coord' is an instance of class 'props.Node'");
} else {
print("Variable 'coord' is not an instance of class 'props.Node'"); # this one will be printed
}
|example3text = The example below demonstrates checking of inheritance.
|example3 = var Const = {
constant: 2,
getConst: func {
return me.constant;
}
};

var Add = {
new: func {
return { parents: [Add, Const] };
},

addToConst: func(a){
return a * me.getConst();
}
};

var m = Add.new();
print(m.addToConst(4));

if(isa(m, Add)) print("Variable 'm' is an instance of class 'Add'"); # will be printed
if(isa(m, Const)) print("Variable 'm' is an instance of class 'Const'"); # will also be printed
}}

=== logprint() ===
{{Nasal doc
|syntax = logprint(priority[, msg[, msg[, ...]]]);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=431|t=Source}}
|text = Concatenates a message and logs it with a given priority level. Unlike {{func link|print()}} and {{func link|printlog()}}, message outputted by this function will be logged in your <code>[[Commonly used debugging tools#fgfs.log|fgfs.log]]</code> file as coming from the Nasal file itself rather than from {{flightgear file|src/Scripting/NasalSys.cxx}}.
|param1 = priority
|param1text = Number specifying the priority level of the outputted message:
:{{{!}} class="wikitable"
! Number !! Debug type
{{!-}}
{{!}} 1 {{!!}} Bulk
{{!-}}
{{!}} 2 {{!!}} Debug
{{!-}}
{{!}} 3 {{!!}} Info
{{!-}}
{{!}} 4 {{!!}} Warn
{{!-}}
{{!}} 5 {{!!}} Alert
{{!}}}
|param2 = msg
|param2text = The message. There is no limit to the arguments you give give. They will be concatenated together before logging.
|example1 = # logs the value of pi to three decimal places with log level 3
logprint(3, "pi = ", sprintf("%.3f", math.pi));
|example2 = logprint(5, "Alert! This is an important message!");
}}
{{note|
The following constants have been added to the development branch of FlightGear ("next") and will be releases with FG 2020.1 so you won't have to remember the numbers anymore:

LOG_BULK, LOG_WARN, LOG_DEBUG, LOG_INFO, LOG_ALERT, DEV_WARN, DEV_ALERT }}

=== magvar() ===
{{Nasal doc
|syntax = magvar([pos]);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1642|t=Source}}
|text = Returns the {{wikipedia|magnetic variation}} at a given set of coordinates. The table below gives the magnetic model used depending on the version of FlightGear.
{{{!}} class="wikitable"
! FlightGear versions !! Model !! Reference date
{{!-}}
{{!}} 3.6 and above {{!!}} {{wikipedia|World Magnetic Model}} (WMM) 2015 {{!!}} 1 January 2015
{{!-}}
{{!}} 0.9.11-pre1 to 3.4 {{!!}} WMM 2005 {{!!}} 1 January 2005
{{!-}}
{{!}} 0.7.3 to 0.9.10 {{!!}} WMM 2000 {{!!}} 1 January 2000
{{!}}}
|param1 = pos
|param1text = Optional position to calculate from. If not given, the aircraft's current position will be used. Can be one of:
:* An <code>airport</code>, <code>navaid</code>, <code>runway</code>, <code>taxiway</code>, <code>fix</code>, or <code>waypoint</code> ghost object.
:* A hash with ''lat'' and ''lon'' members
:* A <code>geo.Coord</code> object
:* A lat/lon pair, that is, a pair of numbers (latitude followed by longitude) separated by a comma: <code>magvar(lat,lon)</code>.
|example1 = print(magvar(0, 0)); # prints the magnetic variation at 0, 0
}}

=== maketimer() ===
{{Nasal doc
|syntax = maketimer(interval[, self], function);
|source = ''Implemented using the {{API Link|flightgear|class|TimerObj}} class.''<br>{{flightgear file|src/Scripting/NasalSys.cxx|l=90|t=Part 1}} {{!}} {{flightgear file|src/Scripting/NasalSys.cxx|l=533|t=Part 2}}
|version = 2.12
|commit = {{flightgear commit|ab939f|t=commit}}
|text = Returns a timer object containing the following methods and members:
* '''start()''': Starts the timer.
* '''stop()''': Stops the timer.
* '''restart(interval)''': Restarts the timer with the given interval.
* '''singleShot''': Bool showing whether the timer is only to be run once, or continuously until told to stop. Can be both set and read from (see examples).
* '''isRunning''': Read-only bool telling whether the timer is currently running.
* '''simulatedTime''': (FG 2017.1+; {{flightgear commit|0af316|t=commit}}) Bool telling whether the timer is using simulated time (which accounts for pause, etc.). Defaults to false (use real time). Can be both read and set. This cannot be changed while the timer is running.
Unlike {{func link|settimer()}}, which it replaces, <code>maketimer()</code> provides more control over the timer. In addition, it can help reduce memory usage.
|param1 = interval
|param1text = Interval in seconds for the timer.
|param2 = self
|param2text = Optional parameter specifying what any <code>'''me'''</code> references in the function being called will refer to.
|param3 = function
|param3text = Function to be called at the given interval.
|example1 = var timer = maketimer(1, func(){
print("Hello, World!"); # print "Hello, World!" once every second (call timer.stop() to stop it)
});
timer.start();
|example2 = var timer = maketimer(1, math, func(){
print(me.math); # 'me' reference is the 'math' namespace
});
timer.singleShot = 1; # timer will only be run once
timer.start();
|example3 = var timer = maketimer(1, func(){
print("Hello, World!"); # print "Hello, World!" once every second (call timer.stop() to stop it)
});
timer.start();
print(timer.isRunning); # prints 1
|example4text = In the example below, "Hello, World!" will be printed after one second the first time, and after two seconds thereafter.
|example4 = var update = func(){
print("Hello, World!");
timer.restart(2); # restarts the timer with a two second interval
}

var timer = maketimer(1, update);
timer.singleShot = 1;
timer.start();
}}

=== maketimestamp() ===
{{Nasal doc
|syntax = maketimestamp()
|source = ''Implemented using the {{API Link|flightgear|class|TimeStampObj}} class.''<br>{{flightgear file|src/Scripting/NasalSys.cxx|l=214|t=Part 1}} {{!}} {{flightgear file|src/Scripting/NasalSys.cxx|l=589|t=Part 2}}
|version = 2019.2
|commit = {{flightgear commit|7db06300|t=commit}}
|text = Returns a time stamp object to allow high resolution timing of Nasal operations. When created the timer will automatically be stamped. The object has the following methods:
* '''stamp()''': Resets the timing operation. Call this first.
* '''elapsedMSec()''': returns number of milliseconds elapsed since stamp() called. Resolution may vary depending on platform but is usually at least millisecond accuracy.
* '''elapsedUSec()''': returns number of microseconds elapsed since stamp() called. Resolution may vary depending on platform but is usually at least millisecond accuracy.
|
|example1text = In the example below the number of milliseconds elapsed will be printed.
|example1 = var timestamp = maketimestamp();
timestamp.stamp();
print(timestamp.elapsedMSec(), "ms elapsed");
print(timestamp.elapsedMSec(), "ms elapsed");
}}

=== md5() ===
{{Nasal doc
|syntax = md5(string);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=758|t=Source}}
|version = 3.2
|commit = {{flightgear commit|cfbf9e|t=commit}}
|text = Returns a the {{wikipedia|MD5}} hash (as a string) of the inputted string.
|param1 = string
|param1text = String the generate the hash of. Mandatory.
|example1text = The below code should output <code>65a8e27d8879283831b664bd8b7f0ad4</code>.
|example1 = print(md5("Hello, World!"));
}}

=== navinfo() ===
{{Nasal doc
|syntax = navinfo(lat, lon, type, id);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1453|t=Source}}
|text = Returns vector <code>navaid</code> ghost objects matching the given '''type''' and '''id''' or <code>'''nil'''</code> on error.
|param1 = lat ''and'' lon
|param1text = If given, the returned navaids will be put into order of ascending distance from the location.
|param2 = type
|param2text = Narrows the search to the given type. Must be one of "any," "fix," "vor," "ndb," "ils," "dme," or "tacan." Defaults to the equivalent of "any."
|param3 = id
|param3text = ID to search for. Note that, although all the parameters are technically optional, this parameter must be given, otherwise an empty vector will be returned.
|example1 = navinfo("vor"); # returns all VORs
|example2 = navinfo("HAM"); # return all navaids whose names start with "HAM"
|example3 = navinfo("vor", "HAM"); # return all VORs whose names start with "HAM"
|example4 = navinfo(34,48,"vor","HAM"); # return all VORs whose names start with "HAM" and sorted by distance relative to 34°, 48°
}}

=== parse_markdown() ===
{{Nasal doc
|syntax = parse_markdown(markdown);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=745|t=Part 1}} {{!}} {{simgear file|simgear/misc/SimpleMarkdown.cxx|t=Part 2}}
|version = 3.2
|text = Parses a string containing {{wikipedia|Markdown}} and returns the result as a string. As of FlightGear 2016.1, it is just a simple parser, and does the following:
* It strips whitespace from the beginning of the string.
* It supports [http://daringfireball.net/projects/markdown/syntax#p paragraphs and line breaks].
* It collapses whitespace.
* It converts unordered [http://daringfireball.net/projects/markdown/syntax#list lists] to use a bullet character (•). Note that the bullet character is implemented in hexadecimal UTF-8 character bytes (<code>E2 80 A2</code>), as so may not work properly when the being displayed in an encoding other than UTF-8.
|param1 = markdown
|param1text = String containing Markdown to be parsed.
|example1text =
Save the below code as <tt>''[[$FG_ROOT]]/gui/dialogs/test.xml''</tt>, then run the Nasal code below it to open the dialog. To change the markdown to be parsed, simply change the code in the highlighted section, save it, and reload the GUI (<tt>Debug > Reload GUI</tt>).
<syntaxhighlight lang="xml" highlight="41-50">
<?xml version="1.0" encoding="UTF-8"?>

<PropertyList>

<name>test</name>
<layout>vbox</layout>

<group>
<layout>hbox</layout>

<empty>
<stretch>true</stretch>
</empty>

<text>
<label>parse_markdown() test dialog</label>
</text>

<empty>
<stretch>true</stretch>
</empty>

<button>
<legend></legend>
<pref-width>16</pref-width>
<pref-height>16</pref-height>
<binding>
<command>dialog-close</command>
</binding>
</button>

</group>

<canvas>
<name>Canvas plot</name>
<stretch>true</stretch>
<pref-width>400</pref-width>
<pref-height>300</pref-height>
<nasal>
<load><![CDATA[
var text = 'Items:
* apples
* oranges
* pears

Some text.
Some more items:
* apples
* oranges
* pears';

var parsed = parse_markdown(text);

var root_canvas = canvas.get(cmdarg());
root_canvas.setColorBackground(255, 255, 255);
var root = root_canvas.createGroup();

var text_dis = root.createChild("text")
.setText(parsed)
.setTranslation(5, 5)
.setFont("LiberationFonts\LiberationSans-Regular.ttf")
.setFontSize(15)
.setColor(0, 0, 0)
.setDrawMode(canvas.Text.TEXT)
.setAlignment("left-top");
]]></load>
</nasal>
</canvas>

</PropertyList>
</syntaxhighlight>
|example1 = fgcommand("dialog-show", {"dialog-name": "test"});
|example2text = The example below parses Markdown and outputs it in a HTML document. The parsed text is placed in <syntaxhighlight lang="xml" inline><pre></pre></syntaxhighlight> tags. To change the Markdown to be parsed, simply edit the variable <tt>markdown</tt> at the top of the code.
|example2 = <nowiki>var markdown = 'Items:
* apples
* oranges
* pears

Some text.
Some more items:
* apples
* oranges
* pears';

var parsed = parse_markdown(markdown);

debug.dump(parsed);

var path = string.normpath(getprop("/sim/fg-home") ~ '/Export/parse_markdown()-test.html');

var file = io.open(path, "w");

var html = "<!DOCTYPE html>\n\n<html>\n\n<head>\n\t<meta charset=\"UTF-8\">\n\t<title>parse_markdown() test generated by Nasal</title>\n</head>\n\n<body>\n\t<pre>" ~ parsed ~ "</pre>\n</body>\n\n</html>";

io.write(file, html);
io.close(file);
print("Done, file ready for viewing (" ~ path ~ ")");</nowiki>
}}

=== parsexml() ===
{{Nasal doc
|syntax = parsexml(path[, start[, end[, data[, pro_ins]]]]);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=710|t=Source}}
|text = This function is an interface into the built-in [http://expat.sourceforge.net/ Expat XML parser]. The absolute path to the file is returned as string, or <code>'''nil'''</code> is returned on error.
|param1 = path
|param1text = Mandatory absolute path to the XML file to be parsed.
|param2 = start
|param2text = Optional callback function that will be called for every starting tag. The function should take two argument: the tag name and a hash containing attributes.
|param3 = end
|param3text = Optional callback function that will be called for every ending tag. The function should take one argument: the tag name.
|param4 = data
|param4text = Optional callback function that will be called for every piece of data within a set of tags. The function should take one argument: the data as a string.
|param5 = pro_ins
|param5text = Optional callback function that will be called for every {{wikipedia|Processing Instruction|processing instruction}}. The function should take two argument: the target and the data string.
|example1text = Save the below XML code in <tt>''[[$FG_HOME]]/Export/demo.xml''</tt>. Then, execute the Nasal code below in the Nasal Console. The XML will be parsed and each bit of the code will be printed.
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>

<?xml-stylesheet type="text/xsl" href="style.xsl"?>

<foo>
<blah type="string"><![CDATA[ <sender>John Smith</sender> ]]></blah>
<blah2 type="string">Orange & lemons</blah2>
</foo>
</syntaxhighlight>
|example1 = var start = func(name, attr){
print("Starting tag: '", name, "'");
foreach(var a; keys(attr)){
print("\twith attribute ", a, '="', attr[a], '"');
}
}

var end = func(name){
print("Ending tag: '", name, "'");
}

var data = func(data){
print("Data = '", data, "'");
}

var pro_instr = func(target, data){
print("Processing instruction: target = '", target, "', data = '", data, "'");
}

parsexml(getprop("/sim/fg-home") ~ '/Export/demo.xml', start, end, data, pro_instr);
}}

=== print() ===
{{Note|As of 07/2020, we are in the process of slowly deprecating and removing Nasal print() (in fgdata) where possible in favor of log [[#logprint()]] which takes a priority level.

This is part of the goal that we achieve zero output at log-level at alert, and everything shown at ‘warn; is really a warning, not just information.<ref>https://sourceforge.net/p/flightgear/mailman/message/37042224/</ref>}}

{{Nasal doc
|syntax = print(data[, data[, ...]]);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=415|t=Source}}
|text = Concatenates its arguments and then prints it to the terminal and the [[Commonly used debugging tools#fgfs.log|log]]. Note that a newline is automatically added.
|param1 = data
|param1text = Data to print. Only strings and numbers can be printed; other data types will not be. There many be any number of arguments; they will just be concatenated together.
|example1 = print("Just", " a ", "test"); # prints "Just a test"
|example2 = print("pi = ", math.pi); # prints "pi = 3.141592..."
}}

=== printf() ===
{{Nasal doc
|syntax = printf(format[, arg[, arg, [...]]]);
|source = {{fgdata file|Nasal/globals.nas|t=Source}}
|text = Creates and prints a formatted string. For a description of its arguments, see {{func link|sprintf()}} (it is, in fact, implemented using <code>sprintf()</code>).
|example1 = printf("In hexadecimal, 100000 = %X", 186A0); # prints "In hexadecimal, 100000 = 186A0"
}}

=== printlog() ===
{{Nasal doc
|syntax = printlog(level, data[, data[, ...]]);
|source = {{fgdata file|Nasal/globals.nas|t=Source}}
|text = Prints the given message with the given log level. If the log level is higher or equal to <code>/sim/logging/priority</code>, it is printed.
|param1 = level
|param1text = Mandatory log level as a string. Must be one of "none," "bulk," "debug," "info," "warn," or "alert." Note that "none" will mean that the message will never be printed.
|param2 = data
|param2text = Data to be printed. Only strings and numbers will be printed; others will not be. There may be any number of arguments; they will just be concatenated together.
|example1 = printlog("alert", "This is an alert"); # message will be printed
|example2 = printlog("info", "Just informing you about something"); # message will be printed only if log level is set to "info" or less
}}

=== rand() ===
{{Nasal doc
|syntax = rand();
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=554|t=Source}}
|text = Returns a random floating point number between 0 (inclusive) and 1 (exclusive). It takes no arguments.
|example1 = print(rand()); # prints random number
}}

=== registerFlightPlanDelegate() ===
{{Nasal doc
|syntax = registerFlightPlanDelegate(init_func);
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1879|t=Source}}
|text = Registers a flight plan delegate. See <tt>''{{fgdata file|Nasal/route_manager.nas|t=$FG_ROOT/Nasal/route_manager.nas}}''</tt> for examples.
|param1 = init_func
|param1text = Initialization function which will be called during FlightGear's startup.
}}
=== removecommand() ===
{{Nasal doc
|syntax = removecommand(cmd);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=668|t=Source}}
|text = Removes the given fgcommand. Returns <code>'''nil'''</code>.
{{caution|This will remove '''any''' [[fgcommands|fgcommand]], even those implemented in C++, so use with caution!}}
|param1 = cmd
|param1text = String specifying the name of the command to remove.
|example1 = addcommand("hello", func(){
print("Hello");
});
fgcommand("hello"); # "Hello" will be printed
removecommand("hello"); # removes it
}}

=== removelistener() ===
{{Nasal doc
|syntax = removelistener(id);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=1384|t=Part 1}} {{!}} {{flightgear file|src/Scripting/NasalSys.cxx|l=506|t=Part 2}}
|text = Removes and deactivates the given listener and returns the number of listeners left or <code>'''nil'''</code> on error.
{{note|It is good practice to remove listeners when they are not required anymore. This prevents the listeners reducing FlightGear's run performance.}}
|param1 = id
|param1text = ID of listener as returned by {{func link|setlistener()}}.
|example1 = var ls = setlistener("/sim/test", func(){
print("Property '/sim/test' has been changed");
});
setprop("/sim/test", "blah"); # trigger listener
var rem = removelistener(ls); # remove listener
print("There are ", rem, " listeners remaining");
}}

=== resolvepath() ===
{{Nasal doc
|syntax = resolvepath(path);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=604|t=Source}}
|text = Takes a relative path as a string and uses [[SimGear]]'s path-resolving framework to return an absolute path as a string. If the path could not be resolved, an empty string is returned. See [[Resolving Paths]] for a detailed description of the algorithm. This function can also be used to check if a file exists.
|param1 = path
|param1text = Relative path to be completed.
|example1 = print(resolvepath("Nasal/globals.nas")); # prints the equivalent of $FG_ROOT/Nasal/globals.nas
|example2 = print(resolvepath("blah")); # prints nothing; could not be resolved
|example3 = var file_path = resolvepath("Aircraft/SenecaII/some-file");
if (file_path != ""){
gui.popupTip("some-file found", 2);
} else {
gui.popupTip("some-file not found", 2);
}
}}

=== setlistener() ===
{{Nasal doc
|syntax = setlistener(node, code[, init[, type]]);
|private = _setlistener()
|source = {{flightgear file|src/Scripting/Nasal|l=499|t=Part 1}} {{!}} {{flightgear file|src/Scripting/Nasal|l=1350|t=Part 2}}<br>''Listener implemented using the {{API Link|flightgear|class|FGNasalListener}} class.''
|text = Creates a listener which will be triggered when the given property is changed (depending on the '''type'''). A unique integer ID is returned; this can later be used as the argument to {{func link|removelistener()}}.
{{note|Listeners are known to be a source of resource leaks. To avoid this, please take measures such as:
* Using {{func link|removelistener()}} when they are not needed any more.
* Using a single initialization listener.
* Avoiding tying listeners to properties that are rapidly updated (e.g., many times per frame).
}}
|param1 = node
|param1text = Mandatory string or <code>props.Node</code> object pointing to a property in the [[Property Tree]].
|param2 = code
|param2text = Mandatory callback function to execute when the listener is triggered. The function can take up to four arguments in the following order:
* '''changed''': a <code>props.Node</code> object pointing to the changed node.
* '''listen''': a <code>props.Node</code> object pointing to the listened-to node. Note that this argument maybe different depending on the '''type'''.
* '''mode''': an integer telling how the listener was triggered. 0 means that the value was changed. 1 means that a child property was added. -1 means that a child property was removed.
* '''is_child''': boolean telling whether '''changed''' is a child property of the listened-to '''node''' or not. 1 (true) if it is, 0 (false) otherwise.
|param3 = init
|param3text = If set to 1 (true), the listener will additionally be triggered when it is created. This argument is optional and defaults to 0 (false).
|param4 = type
|param4text = Integer specifying the listener's behavior. 0 means that the listener will only trigger when the property is changed. 1 means that the trigger will always be triggered when the property is written to. 2 will mean that the listener will be triggered even if child properties are modified. This argument is optional and defaults to 1.
|example1 = var prop = props.globals.initNode("/sim/test", "", "STRING"); # create property
var id = setlistener("/sim/test", func(n){ # create listener
print("Value: ", n.getValue());
});
setprop("/sim/test", "blah"); # trigger listener
removelistener(id); # remove listener
prop.remove(); # remove property
}}

=== setprop() ===
{{Nasal doc
|syntax = setprop(path[, path[, ...]], value);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=385|t=Source}}
|text = Sets the value of a property in the [[Property Tree]]. If the property does not exist, it will be created. Returns 1 (true) on success or 0 (false) if there was an error.
{{note|If you want to remove a property, you will have to use one of the <code>props</code> helpers:
<syntaxhighlight lang="nasal">
props.globals.getNode("foo/bar").remove(); # take out the complete node
props.globals.getNode("foo").removeChild("bar"); # take out a certain child node
</syntaxhighlight>
}}
|param1 = path
|param1text = There needs to be at least one '''path''' argument, but there is no limit to the maximum amount that can be given. They will be concatenated together to form a property tree path. The arguments must be strings, but in FlightGear v3.2 onwards, there also is support (added by {{flightgear commit|34ed79}}) for numeric arguments as indices. See example 2 below.
|param2 = value
|param2text = Value to write to the given property. Must be either a string or a number.
|example1 = setprop("/sim/demo", "This is a demo");
|example2text = Note that the example below will only work in FlightGear 3.2 and above.
|example2 = for(var i = 0; i < 3; i += 1){
setprop("/sim/demo", i, "Demo #" ~ i));
}
|example3text = Same as above, but is supported by all versions of FlightGear.
|example3 = for(var i = 0; i < 3; i += 1){
setprop("/sim/demo[" ~ i ~ "]", "Demo #" ~ i));
}
}}
==== See also ====
{{note| If you have to read/write the same property multiple times (e.g. in an update loop), it is more efficient to use a node object:
To get a Node rather than its value, use <code>props.globals.getNode()</code> - see [[Nasal_library/props]]. }}

=== settimer() ===
{{Nasal doc
|syntax = settimer(function, delta[, realtime]);
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=499|t=Part 1}} {{!}} {{flightgear file|src/Scripting/NasalSys.cxx|l=1286|t=Part 2}}
|text = Runs the given function a specified amount of seconds after the current time. Returns <code>'''nil'''</code>.
{{note|Improper use of <code>settimer()</code> may cause resource leaks. It is also highly recommended that the newer {{func link|maketimer()}} should be used instead of this function.}}
|param1 = function
|param1text = Mandatory function that will be called. It may be necessary to enclose code in an anonymous function (see example).
|param2 = delta
|param2text = Mandatory amount of time in seconds after which the function will be called.
|param3 = realtime
|param3text = If 1 (true), "real time" will be used instead of "simulation time." Defaults to 0 (false). Note that if "simulation time" is used, the timer will not run while FlightGear is paused.
|example1 = var myFunc = func(){
print("Hello");
}

settimer(myFunc, 2); # runs myFunc after 2 seconds
|example2 = var sqr = func(a){
return a * a;
}

settimer(func(){
print(sqr(2)); # will print 4 after 2 seconds
}, 2);
}}

=== srand() ===
{{Nasal doc
|syntax = srand();
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=559|t=Source}}
|text = Makes the pseudorandom number generator (see {{func link|rand()}}) generate a new {{wikipedia|random seed|noicon=1}} based on time. Returns 0.
}}
=== systime() ===
{{Nasal doc
|syntax = systime();
|source = {{flightgear file|src/Scripting/NasalSys.cxx|l=770|t=Source}}
|text = Returns the {{wikipedia|Unix time}} (seconds since since 00:00:00 UTC, 1/1/1970) as a floating point number with high resolution. This function is useful for benchmarking purposes (see example 2).
{{note|1=High resolution timers under Windows can produce inaccurate or fixed sub-millisecond results.<ref>{{cite web|url=http://forum.flightgear.org/viewtopic.php?f=30&t=29259|title=Nasal: systime() ??!?|author=Necolatis|date=Apr 2nd, 2016}}</ref> This is due to the underlying {{func link|GetSystemTimeAsFileTime()|link=https://msdn.microsoft.com/en-us/library/windows/desktop/ms724397(v=vs.85).aspx}} API call, which depends on hardware availability of suitable high resolution timers. See also [https://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx Acquiring high-resolution time stamps]}}
|example1 = print("Unix time: ", systime()); # prints Unix time
|example2 = var myFunc = func(){
for(var i = 0; i <= 10; i += 1){
print("Interation #", i);
}
}
var t = systime(); # record time
myFunc(); # run function
var t2 = systime(); # record new time
print("myFunc() took ", t2 - t, " seconds"); # print result
}}

=== thisfunc() ===
{{Nasal doc
|syntax = thisfunc();
|source = {{fgdata file|Nasal/globals.nas|t=Source}}
|text = Returns the function from which this function is called. This allows a function to reliably and safely call itself from within a closure.
|example1 = var stringify_vec = func(input){
if (typeof(input) == "scalar"){
return sprintf("%s", input);
} elsif (typeof(input) == "vector") {
if (size(input) == 0) return "[]";
var this = thisfunc();
var buffer = "[";
for(var i = 0; i < size(input); i += 1){
buffer ~= this(input[i]);
if (i == size(input) - 1) {
buffer ~= "]";
} else {
buffer ~= ", ";
}
}
return buffer;
} else {
die("stringify_vec(): Error! Invalid input. Must be a vector or scalar");
}
}

var test_vec = ["a", "b", "c", 1, 2, 3];
debug.dump(stringify_vec(test_vec)); # prints "[a, b, c, 1, 2, 3]"
test_vec = [];
debug.dump(stringify_vec(test_vec)); # prints "[]"
test_vec = {};
debug.dump(stringify_vec(test_vec)); # will throw an error
}}

=== tileIndex() ===
{{Nasal doc
|syntax = tileIndex();
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1720|t=Source}}
|text = Returns the index of the tile at the aircraft's current position as a string. This corresponds to the name of the STG file of the tile. For example, at [[KSFO]], this would be <code>942050</code>, corresponding to <tt>''[[$FG_SCENERY]]/Terrain/w130n30/w123n3/942050.stg''</tt>.
|example1 = print(tileIndex()); # print index
}}

=== tilePath() ===
{{Nasal doc
|syntax = tilePath();
|source = {{flightgear file|src/Scripting/NasalPositioned.cxx|l=1712|t=Source}}
|text = Returns the base path of the tile at the aircraft's current position as a string. For example, at KSFO, this would be <code>w130n30/w123n3</code>, corresponding to <tt>''[[$FG_SCENERY]]/Terrain/w130n30/w123n3''</tt>.
|example1 = print(tilePath()); # print path
}}

=== values() ===
{{Nasal doc
|syntax = values(hash);
|source = {{fgdata file|Nasal/globals.nas|t=Source}}
|text = Returns a vector containing the values of the given hash.
|param1 = hash
|param1text = Mandatory hash to get the values of.
|example1 = var hash = {
"a": 1,
"b": 2,
"c": 3
};

foreach(var val; values(hash)){
print(val);
}
|example2text = The below example does exactly the same thing as the above example, but does not use <code>values()</code>:
|example2 = var hash = {
"a": 1,
"b": 2,
"c": 3
};

foreach(var key; keys(hash)){
print(hash[key]);
}
}}

== Extension functions new in FG 2020.1 ==
The following functions have been added to the nasal core library and will be released with FlightGear version 2020.1.
Before the release they are available in the development branch "next".

=== isfunc() ===
Returns 1 if type or argument is a function, otherwise 0.

=== isghost() ===
Returns 1 if type or argument is a ghost, otherwise 0.

=== ishash() ===
Returns 1 if type or argument is a hash, otherwise 0.

=== isint() ===
{{Nasal doc
|syntax = isint(x);
|source = {{simgear file|simgear/nasal/lib.c|t=Source}}
|text = Returns 1 if argument has a numeric value and x == floor(x), e.g. integer.
}}

=== isnum() ===
{{Nasal doc
|syntax = isnum(x);
|source = {{simgear file|simgear/nasal/lib.c|t=Source}}
|text = Returns 1 if typeof(x) is "scalar" and x has a numeric value otherwise 0.
}}

=== isscalar() ===
{{Nasal doc
|syntax = isnum(x);
|source = {{simgear file|simgear/nasal/lib.c|t=Source}}
|text = Returns 1 if type or argument is a scalar (string or numeric), otherwise (vector, hash, func, ...) it returns 0. This is useful to check if a variable can be converted to string e.g. when useing the string concat operator "~".
|example1 = var a = "foo";
var b=42;
if (isscalar(a) and isscalar(b)) print(a~b);
if (isstr(a)) print("a is a string");
if (isint(b)) print("b is an integer");
# if (isscalar(a))... is equivalent to if (typeof(a) == "scalar")...
}}

=== isstr() ===
Returns 1 if type or argument is a string, otherwise 0.

=== isvec() ===
Returns 1 if type or argument is a vector, otherwise 0.

=== vecindex() ===
{{Nasal doc
|syntax = vecindex(vector, value);
|source = {{simgear file|simgear/nasal/lib.c|t=Source}}
|text = Returns the index of value or nil, if value is not found in vector.
|example1=
var myvector = ["apple", "bananna", "coconut"];
# to check if a vector contains a certain value compare vecindex to nil
if (vecindex(myvector, "apple") != nil) {
print("found apple");
}
# WARNING: this will not work as desired because index is 0
if (vecindex(myvector, "apple")) {
print("found apple");
}

}}

{{note| There is a similar function function contains(hash, key) to check if a hash contains a key (not value!).
It is to be discussed, if contains can/should be extended to support vectors in the above mentioned way. }}

== Variables ==
Various global constants (technically variables) are provided for use in converting between different units. They are all found in {{fgdata file|Nasal/globals.nas|text=$FG_ROOT/Nasal/globals.nas}}.

=== D2R ===
{{Nasal doc
|syntax = var radians = degrees * D2R;
|text = Converts an angle from degrees to radians when multiplied by the angle in degrees. Equal to <code>π / 180</code>.
}}
=== FPS2KT ===
{{Nasal doc
|syntax = var knots = feet_per_second * FPS2KT;
|text = Converts a velocity from feet per second to knots when multiplied by the velocity in feet per second. Approximately equal to 0.5925.
}}
=== FT2M ===
{{Nasal doc
|syntax = var metres = feet * FT2M;
|text = Converts a length from feet to metres when multiplied by the length in feet. Equal to 0.3048.
}}
=== GAL2L ===
{{Nasal doc
|syntax = var litres = gallons * GAL2L;
|text = Converts a volume from US liquid gallons to litres when multiplied by the volume in gallons. Approximately equal to 3.7854.
}}
=== IN2M ===
{{Nasal doc
|syntax = var metres = inches * IN2M;
|text = Converts a length from inches to metres when multiplied by the length in inches. Equal to 0.0254.
}}
=== KG2LB ===
{{Nasal doc
|syntax = var pounds = kilograms * KG2LB;
|text = Converts a mass from kilograms to pounds when multiplied by the mass in kilograms. Approximately equal to 2.2046.
}}
=== KT2FPS ===
{{Nasal doc
|syntax = var feet_per_second = knots * KT2FPS;
|text = Converts a velocity from knots to feet per second when multiplied by the velocity in knots. Approximately equal to 1.6878.
}}
=== KT2MPS ===
{{Nasal doc
|syntax = var metres_per_second = knots * KT2MPS;
|text = Converts a velocity from knots to metres per second when multiplied by the velocity in knots. Approximately equal to 0.5144.
}}
=== L2GAL ===
{{Nasal doc
|syntax = var gallons = litres * L2GAL;
|text = Converts a volume from litres to US liquid gallons when multiplied by the volume in litres. Approximately equal to 0.2642.
}}
=== LB2KG ===
{{Nasal doc
|syntax = var kilograms = pounds * LB2KG;
|text = Converts a mass from pounds to kilograms when multiplied by the mass in pounds. Approximately equal to 0.4536.
}}
=== M2FT ===
{{Nasal doc
|syntax = var feet = metres * M2FT;
|text = Converts a length from metres to feet when multiplied by the length in metres. Approximately equal to 3.2808.
}}
=== M2IN ===
{{Nasal doc
|syntax = var inches = metres * M2IN;
|text = Converts a length from metres to inches when multiplied by the length in metres. Approximately equal to 39.3701.
}}
=== M2NM ===
{{Nasal doc
|syntax = var nautical_miles = metres * M2NM;
|text = Converts a length from metres to nautical miles when multiplied by the length in metres. Approximately equal to 0.00054.
}}
=== MPS2KT ===
{{Nasal doc
|syntax = var knots = metres_per_second * MPS2KT;
|text = Converts a velocity from metres per second to knots when multiplied by the velocity in metres per second. Approximately equal to 1.9438.
}}
=== NM2M ===
{{Nasal doc
|syntax = var metres = nautical_miles * NM2M;
|text = Converts a length from nautical miles to metres when multiplied by the length in nautical miles. Equal to 1,852.
}}
=== R2D ===
{{Nasal doc
|syntax = var degrees = radians * R2D;
|text = Converts an angle from radians to degrees when multiplied by the angle in radians. Equal to <code>180 / π</code>.
}}

{{Appendix}}

{{Nasal namespaces}}

Aircraft tester list

2021-02-18T17:32:43Z

Legoboyvdlp: -

This is a list of '''aircraft testers''' using using the procedures laid out in [[Aircraft testing checklist]] to validate that aircraft below are compatible with a FlightGear version.

{| class="wikitable sortable"
|-
! Aircraft !! Tester(s) !! Remarks
|-
| 737NGs || James Turner ||
|-
| 757 || James Turner||
|-
| A300 || J Redpath||
|-
| A320-200 || J Redpath|| [NB - upstream github repo for issues]
|-
| A340-600 || J Redpath||
|-
| A380 || J Redpath||
|-
| A6M2 Zero || Stuart Buchanan ||
|-
| Aerostar-700 || James Turner ||
|-
| B1900D || James Turner ||
|-
| CH-53E || Richard H. ||
|-
| CRJ700 family || Henning, Daniel ||
|-
| Cap 10C || Scott ||
|-
| Cessna 208B Caravan || James Turner ||
|-
| DR400 || Scott ||
|-
| DaSH || Wayne Bragg||
|-
| F-14 || Richard H. || Willing to reassign upon request to those with experience of this aircraft
|-
| F-15 || Richard H. || Willing to reassign upon request to those with experience of this aircraft
|-
| F-16 || Stuart ||
|-
| F6F - Hellcat || Keith ||
|-
| F-86 || J Redpath ||
|-
| Fokker 100 || J Redpath ||
|-
| Grob || Scott ||
|-
| Hansa Jet || Adrian S. ||
|-
| Jaguar || Richard ||
|-
| Junkers JU-52 || James Turner ||
|-
| hunter || Stuart ||
|-
| J3Cub || Wayne Bragg||
|-
| Lionceau || Scott ||
|-
| p51d || Stuart ||
|-
| SUMPAC || Wayne Bragg||
|-
| Skyvan || Keith ||
|-
| Socata || Scott ||
|-
| seahawk || Stuart ||
|-
| wrightFlyer || Stuart ||
|-
| tu154b || Gaétan Allaert ||
|-
| Pilatus PC-9M || vanosten ||
|-
|}

[[Category:Aircraft enhancement]]

Aircraft tester list

2021-02-18T17:32:28Z

Legoboyvdlp: -

This is a list of '''aircraft testers''' using using the procedures laid out in [[Aircraft testing checklist]] to validate that aircraft below are compatible with a FlightGear version.

{| class="wikitable sortable"
|-
! Aircraft !! Tester(s) !! Remarks
|-
| 737NGs || James Turner ||
|-
| 757 || James Turner||
|-
| A300 || J Redpath||
|-
| A320-200 || J Redpath|| [NB - upstream github repo for issues]
|-
| A340-600 || J Redpath||
|-
| A380 || J Redpath||
|-
| A6M2 Zero || Stuart Buchanan ||
|-
| Aerostar-700 || James Turner ||
|-
| B1900D || James Turner ||
|-
| CH-53E || Richard H. ||
|-
| CRJ700 family || Henning, Daniel ||
|-
| Cap 10C || Scott ||
|-
| Cessna 208B Caravan || James Turner ||
|-
| DR400 || Scott ||
|-
| DaSH || Wayne Bragg||
|-
| F-14 || Richard H. || Willing to reassign upon request to those with experience of this aircraft
|-
| F-15 || Richard H. || Willing to reassign upon request to those with experience of this aircraft
|-
| F-16 || Stuart ||
|-
| F6F - Hellcat || Keith ||
|-
| F-86 || Jonathan Redpath ||
|-
| Fokker 100 || Jonathan Redpath ||
|-
| Grob || Scott ||
|-
| Hansa Jet || Adrian S. ||
|-
| Jaguar || Richard ||
|-
| Junkers JU-52 || James Turner ||
|-
| hunter || Stuart ||
|-
| J3Cub || Wayne Bragg||
|-
| Lionceau || Scott ||
|-
| p51d || Stuart ||
|-
| SUMPAC || Wayne Bragg||
|-
| Skyvan || Keith ||
|-
| Socata || Scott ||
|-
| seahawk || Stuart ||
|-
| wrightFlyer || Stuart ||
|-
| tu154b || Gaétan Allaert ||
|-
| Pilatus PC-9M || vanosten ||
|-
|}

[[Category:Aircraft enhancement]]

File:SOTM 2019-12 Caribbean Island by Madbyte70.jpg

2021-02-01T22:14:21Z

Legoboyvdlp:

=={{int:filedesc}}==
{{Information
|description={{en|1=SOTM 2019-12:}}
|date=2019-12-31
|source=SOTM 2019-12
|author=X
|permission=
|other versions=
}}

=={{int:license-header}}==
{{cc-by-sa-4.0}}

[[Category:Screenshot of the month]]
[[Category:Screenshot of the month/2019-12]]
[[Category:Screenshot_of_the_year/2019]]

File:SOTM 2019-11 Boulon Woods patrol by LesterBoffo.jpg

2021-02-01T22:14:12Z

Legoboyvdlp:

=={{int:filedesc}}==
{{Information
|description={{en|1=SOTM 2019-11:}}
|date=2019-11-30
|source=SOTM 2019-11
|author=X
|permission=
|other versions=
}}

=={{int:license-header}}==
{{cc-by-sa-4.0}}

[[Category:Screenshot of the month]]
[[Category:Screenshot of the month/2019-11]]
[[Category:Screenshot_of_the_year/2019]]

File:SOTM 2019-09 Firing at Dawn by GinGin.jpg

2021-02-01T22:13:49Z

Legoboyvdlp:

=={{int:filedesc}}==
{{Information
|description={{en|1=SOTM 2019-09: Firing at Dawn by GinGin}}
|date=2019-09-30
|source=SOTM 2019-09
|author=X
|permission=
|other versions=
}}

=={{int:license-header}}==
{{cc-by-sa-4.0}}

[[Category:Screenshot of the month]]
[[Category:Screenshot of the month/2019-09]]
[[Category:Screenshots of Earthview]]
[[Category:Space_Shuttle_screenshots]]
[[Category:Screenshots_at_high_settings]]
[[Category:Screenshots_at_high_settings/2019]]
[[Category:Screenshots_at_high_settings/sotm]]
[[Category:Screenshot_of_the_year/2019]]

File:SOTM 2019-08 Low Landing by sidi762.jpg

2021-02-01T22:13:40Z

Legoboyvdlp:

=={{int:filedesc}}==
{{Information
|description={{en|1=SOTM 2019-08: Low Landing by sidi762}}
|date=2019-08-31
|source=SOTM 2019-08
|author=X
|permission=
|other versions=
}}

=={{int:license-header}}==
{{cc-by-sa-4.0}}

[[Category:Screenshot of the month]]
[[Category:Screenshot of the month/2019-08]]
[[Category:Screenshot_of_the_year/2019]]

File:SOTM 2019-07 Sunset Sortie in the Alps by J-Maverick 16.jpg

2021-02-01T22:13:29Z

Legoboyvdlp:

=={{int:filedesc}}==
{{Information
|description={{en|1=SOTM 2019-07: Sunset Sortie in the Alps by J-Maverick 16}}
|date=2019-07-31
|source=SOTM 2019-07
|author=X
|permission=
|other versions=
}}

=={{int:license-header}}==
{{cc-by-sa-4.0}}

[[Category:Screenshot of the month]]
[[Category:Screenshot of the month/2019-07]]
[[Category:Screenshot_of_the_year/2019]]

File:SOTM 2019-06 Stormy Singapore by sidi762.jpg

2021-02-01T22:12:54Z

Legoboyvdlp:

=={{int:filedesc}}==
{{Information
|description={{en|1=SOTM 2019-06: Stormy Singapore by sidi762}}
|date=2019-06-30
|source=SOTM 2019-06
|author=sidi762
|permission=
|other versions=
}}

=={{int:license-header}}==
{{cc-by-sa-4.0}}

[[Category:Screenshot of the month|2019 06]]
[[Category:Screenshot of the month/2019-06]]
[[Category:Screenshots_at_high_settings]]
[[Category:Screenshots_at_high_settings/2019]]
[[Category:Screenshots_at_high_settings/sotm]]
[[Category:Boeing 777 screenshots]]
[[Category:Screenshot_of_the_year/2019]]

File:SOTM 2019-06 Ice and fire by vnts.jpg

2021-02-01T22:12:50Z

Legoboyvdlp:

=={{int:filedesc}}==
{{Information
|description={{en|1=SOTM 2019-06: Ice and fire by vnts}}
|date=2019-06-28
|source=SOTM June 2019
|author=vnts
|permission=
|other versions=
}}

=={{int:license-header}}==
{{cc-by-sa-4.0}}

[[Category:Screenshot of the month|2019 06]]
[[Category:Screenshot of the month/2019-06]]
[[Category:Screenshots of volcanoes]]
[[Category:Screenshots_at_high_settings]]
[[Category:Screenshots_at_high_settings/2019]]
[[Category:Screenshots of scenery in Sicily]]
[[Category:Bell 412 screenshots]]
[[Category:Screenshots_at_high_settings/sotm]]
[[Category:Screenshot_of_the_year/2019]]

File:SOTM-May19.jpg

2021-02-01T22:12:18Z

Legoboyvdlp:

=={{int:filedesc}}==
{{Information
|description={{en|1=New Aviatik to Colmar Sud by LesterBoffo}}
|date=2019-06-01
|source=SOTM Contest
|author=LesterBoffo
|permission=
|other versions=
}}

=={{int:license-header}}==
{{cc-by-sa-4.0}}

[[Category:Screenshot of the month|2019 05]]
[[Category:Screenshot of the month/2019-05]]
[[Category:Screenshot_of_the_year/2019]]

File:SOTM 2019-04 Space Sauna by GinGin.jpg

2021-02-01T22:11:58Z

Legoboyvdlp:

=={{int:filedesc}}==
{{Information
|description={{en|1=Space Sauna by GinGin}}
|date=2019-04-30
|source=SOTM April 2019
|author=GinGin
|permission=
|other versions=
}}

=={{int:license-header}}==
{{cc-by-sa-4.0}}

[[Category:Screenshot of the month|2019 04]]
[[Category:Screenshot of the month/2019-04]]
[[Category:Screenshots of Earthview]]
[[Category:Space_Shuttle_screenshots]]
[[Category:Screenshots_at_high_settings]]
[[Category:Screenshots_at_high_settings/2019]]
[[Category:Screenshots_at_high_settings/sotm]]
[[Category:Screenshot_of_the_year/2019]]

File:SOTM-Mar19.jpg

2021-02-01T22:11:36Z

Legoboyvdlp:

=={{int:filedesc}}==
{{File information
|description = {{en|1=Dawn Trip over Madrid by StuartC}}
|date =
|source =
|author =
|other versions =
|other fields =
}}

=={{int:license-header}}==
{{self|cc-by-sa-4.0}}

[[Category:Screenshot of the month|2019 03]]
[[Category:Screenshot of the month/2019-03]]
[[Category:Screenshots_at_high_settings]]
[[Category:Screenshots_at_high_settings/2019]]
[[Category:Screenshots of scenery with OSM2City output]]
[[Category:Aérospatiale/Westland Gazelle screenshots]]
[[Category:Screenshots of scenery in Spain]]
[[Category:Screenshots_at_high_settings/sotm]]
[[Category:Screenshot_of_the_year/2019]]

File:SOTM-Feb19.jpg

2021-02-01T22:11:15Z

Legoboyvdlp:

=={{int:filedesc}}==
{{Information
|description={{en|1=Scramble, Scramble by legoboyvdlp}}
|date=2019-03-07
|source={{own}}
|author=[[User:Legoboyvdlp|Legoboyvdlp]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-4.0}}

[[Category:Screenshot of the month|2019 02]]
[[Category:Screenshot of the month/2019-02]]
[[Category:Screenshot_of_the_year/2019]]

File:SOTM-Jan19.jpg

2021-02-01T22:10:33Z

Legoboyvdlp: SOTY

=={{int:filedesc}}==
{{Information
|description={{en|1=Rising Around Wales by StuartC}}
|date=2019-02-04
|source=SOTM contest
|author=StuartC
|permission=
|other versions=
}}

=={{int:license-header}}==
{{cc-by-sa-4.0}}

[[Category:Screenshot of the month|2019 01]]
[[Category:Screenshot of the month/2019-01]]
[[Category:Screenshots_at_high_settings]]
[[Category:Screenshots_at_high_settings/2019]]
[[Category:Screenshots_at_high_settings/sotm]]
[[Category:Robinson_R44_screenshots]]
[[Category:Screenshot_of_the_year/2019]]

Category:Screenshot of the year/2019

2021-02-01T22:09:48Z

Legoboyvdlp: Created page with "See {{forum link|title=Voting for the SOTY of 2019|t=36740}}."

See {{forum link|title=Voting for the SOTY of 2019|t=36740}}.

Category:Screenshot of the month/2019-12

2021-02-01T22:08:36Z

Legoboyvdlp:

See {{forum link|title=Submit your screenshot for the SOTM of December 2019|t=36643}} and {{forum link|title=Voting for the SOTM of December 2019|t=36702}}.
[[Category:Screenshot of the month]]

Category:Screenshot of the month/2019-11

2021-02-01T22:08:02Z

Legoboyvdlp:

See {{forum link|title=Submit your screenshot for the SOTM of November 2019|t=36496}} and {{forum link|title=Voting for the SOTM of November 2019|t=36616}}.
[[Category:Screenshot of the month]]

Category:Screenshot of the month

2021-02-01T22:07:29Z

Legoboyvdlp:

{{en|Category with winners of the ''Screenshot of the Month'' contests from April 2011 to April 2012, and since June 2015.}}

{|class="wikitable" style="text-align: center"
! Date
! Screenshot submission
! Vote
! Subcategory
|-
| 2019-01
| {{forum link|title=Submit your screenshot for the SOTM of January!|t=35229}}
| {{forum link|title=Voting for the SOTM January|t=35303}}
| [[:Category:Screenshot of the month/2019-01]]
|-
| 2019-02
| {{forum link|title=Submit your Screenshot for February's SOTM!|t=35319}}
| {{forum link|title=Voting for the SOTM|t=35413}}
| [[:Category:Screenshot of the month/2019-02]]
|-
| 2019-03
| {{forum link|title=Submit your screenshot for the SOTM of March|t=35436}}
| {{forum link|title=Voting for the SOTM|t=35554}}
| [[:Category:Screenshot of the month/2019-03]]
|-
| 2019-04
| {{forum link|title=Submit your screenshot for the SOTM of April|t=35574}}
| {{forum link|title=Voting for the SOTM|t=35720}}
| [[:Category:Screenshot of the month/2019-04]]
|-
| 2019-05
| {{forum link|title=Submit your screenshot for the SOTM of May|t=35746}}
| {{forum link|title=Voting for the SOTM of May|t=35880}}
| [[:Category:Screenshot of the month/2019-05]]
|-
| 2019-06
| {{forum link|title=Submit your screenshot for the SOTM of June!|t=35903}}
| {{forum link|title=Vote for the SOTM of June|t=36046}}
| [[:Category:Screenshot of the month/2019-06]]
|-
| 2019-07
| {{forum link|title=Submit your screenshot for the SOTM of July|t=36088}}
| {{forum link|title=Vote for the SOTM July 2019|t=36149}}
| [[:Category:Screenshot of the month/2019-07]]
|-
| 2019-08
| {{forum link|title=Submit your screenshot for the SOTM of August!|t=36188}}
| {{forum link|title=Vote for the SOTM August 2019|t=36265}}
| [[:Category:Screenshot of the month/2019-08]]
|-
| 2019-09
| {{forum link|title=Submit your screenshot for SOTM of September|t=36316}}
| {{forum link|title=Voting for the SOTM September|t=36361}}
| [[:Category:Screenshot of the month/2019-09]]
|-
| 2019-10
| - no contest -
|
|
|-
| 2019-11
| {{forum link|title=Submit your screenshot for the SOTM of November 2019|t=36496}}
| {{forum link|title=Voting for the SOTM of November 2019|t=36616}}
| [[:Category:Screenshot of the month/2019-11]]
|-
| 2019-12
| {{forum link|title=Submit your screenshot for the SOTM of December 2019|t=36643}}
| {{forum link|title=Voting for the SOTM of December 2019|t=36702}}
| [[:Category:Screenshot of the month/2019-12]]
|-
| 2019 SOTY
| - Used previous month's winners -
| {{forum link|title=Voting for the SOTY of 2019|t=36740}}
| [[:Category:Screenshot of the year/2019]]
|}

[[Category:FlightGear screenshots]]

Category:Screenshot of the month/2019-09

2021-02-01T22:06:12Z

Legoboyvdlp:

See {{forum link|title=Submit your screenshot for SOTM of September|t=36316}} and {{forum link|title=Voting for the SOTM September|t=36361}}.
[[Category:Screenshot of the month]]