Release:Aircraft Selection Criteria

From FlightGear wiki
Jump to: navigation, search

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.

Selection criteria

Suggested criteria include:

Development criteria

Aircraft should:

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:

In addition:

  • Aircraft must fully support simulator resets, such that the location can be easily changed

Miscellaneous criteria

Aircraft should:

In addition:

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):

Cquote1.png 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
Cquote2.png
  1. ThorstenB (Tue, 20 Mar 2012 13:52:37 -0700). [Flightgear-devel] Performance issue with sim reset vs Nasal.

Related content