Release:Aircraft Selection Criteria
| Note This page is out of date, as aircraft other than the c172 and ufo are no longer included in FGData. |
The idea here is to come up with a list of aircraft selection criteria that we can use to more easily decide what aircraft shall be included in the base package of an upcoming release, based on end user usability, and based on providing a consistent and satisfying experience to people who may be completely new to FlightGear or even flight simulators in general.
For each upcoming release, we usually have a poll concerning the aircraft to be included in the release, this is normally based on an aircraft's development status, and recent developments/improvements.
Increasingly, it's getting obvious that some features are particularly important to end users, such as for example autostart, tutorials and checklists. Unfortunately, we have a number of well-developed aircraft, that "break" existing functionality, such as resetting the simulator, or repositioning the aircraft. In addition, there are new features like Rembrandt that require additional compatibility work. At the moment, we unfortunately provide an inconsistent experience because of various incompatibilities between different aircraft and features found in FG.
| Release process |
|---|
Selection criteria
Suggested criteria include:
Development criteria
Aircraft should:
- Have at least one aircraft-specific splash screen
- Have an active developer/maintainer, or be sufficiently "complete" (early-production)
- Be using the scheme for aircraft status indication
- Not use depreciated properties. See Aircraft maintenance.
Portability criteria
- Shaders should be optional and not required/enabled by default
- Aircraft must work for all common GPUs, not just NVIDIA/ATI (AMD), but also Intel. In essence DDS and texture compression should be OPTIONAL!
- Aircraft should work with the default rendering scheme, not only just Rembrandt/ALS!
Usability criteria
Aircraft should:
- Have an aircraft-specific help dialog
- Come with aircraft-specific docs and packaged according to Standard aircraft structure [1]
- Support/provide a weight & balance dialog
- Ideally have localized help dialogs/checklists (not just English).
Also see Aircraft deployment and Catalog metadata (not yet relevant as of 2013)
Feature criteria
Aircraft should:
- Have a sound configuration
- Provide a custom flight recorder config file
- Support limits.nas (see Howto:Define limits) and failures.nas
- support in-air startups (for now: repositioning/relocating the aircraft at runtime)
- Have integrated aircraft-specific checklist
- Have autostart support using Aircraft Checklists
- Have aircraft-specific tutorials using the tutorial system
- should use the FGCamera script for custom camera views [2]
In addition:
- Aircraft must fully support simulator resets, such that the location can be easily changed
Miscellaneous criteria
Aircraft should:
- Have Rembrandt support
- Have immatriculation support
- Support livery over MP
- Support dual Control, if applicable
- Either implement, override or disable the default autopilot menu, if applicable
- Support carriers and/or air-to-air refueling, if applicable
In addition:
- Airliners should implement pushback and jetways, Ramp Marshall support.
- Aircraft should preferably have support for complementary features like FGPanel, and multi-instance setups (master/slave) using the Generic Protocol
Aircraft Validation
Before new or updated aircraft (or Nasal code like local weather or Bombable) is added to the base package, we should do a stress-test that re-initializes and repositions a couple of times and track how the new or updated code is dealing with it (number of identical callbacks registered, in essence timers and/or listeners, garbage collection stuff etc):
|
I noticed an ugly issue with many of our Nasal modules. Not sure if
that's a result of changed behaviour years ago, or it's just a common
copy & paste issue that just wasn't noticed so far.
Problem is, lot's of Nasal modules listen to the property
/sim/signals/fdm-initialized
to trigger some initialization code. It's fine to do so. However,
modules need to be aware that this signal triggers on _every_ simulator
reset. So, the connected code executes every time you hit Shift-ESC, use
the "Relocate-in-air" or "Relocate-on-ground" dialogs.
We had plenty of places were init code connected to
"/sim/signals/fdm-initialized" installed a fresh set of listeners or
started another timer-driven update loop. This results in performance
degrading with every sim reset.
Anyway, if you ever wondered why performance is so bad with FG2.0-2.6
(not sure about earlier versions) after resetting the sim or relocating
the aircraft multiple times, you now know why ;-).[1] — ThorstenB
|
|
- ↑ ThorstenB (Tue, 20 Mar 2012 13:52:37 -0700). [Flightgear-devel] Performance issue with sim reset vs Nasal.