FGFS Todo

From wiki.flightgear.org

Jump to: navigation, search
Image:Cleanup.png This article may require cleanup to meet the wiki's quality standards. Please improve this article if you can..


Contents

1.0 Todo List

This is a list of issues that should preferably be addressed before a FlightGear 1.0 release, so this is not meant to become a list of feature requests, it is only about things that can be considered to be crucial for a serious 1.0 version, for example obvious bugs or unnecessary shortcomings (i.e. annoyances) that should not be part of a 1.0 release.

Feel free to add whatever issues you have encountered and that you feel need to be addressed for a 1.0 release, however please keep in mind, that this list is not about feature requests!

Please note: if you intend to work on any of these items, please make sure to first subscribe to the FlightGear Devel mailing list to discuss your plans in detail, alternatively you may also want to check out the FlightGear IRC channel.

Related Mailing List Discussions

Suggestions so far (mainly collected from the mailing lists and by no means meant to be complete or mandatory):

Critical

  • Replace Astro code, so that there are not any licensing issues that may prevent FG from being included with linux distributions
  • Fix the startup issues encountered on some Win32 systems since 0.9.9 is out
  • All JSBSim aircraft that are included in the standard base package by default should probably be ported over to the new JSB 2.0 syntax, so that they actually work with the latest FG version, likewise we should probably convert those aircraft that can be downloaded from flightgear.org?
  • Fix big endianess related issues with nasal interpreter
  • Introduce 6 week code freeze before release (or use CVS tags/branches to separate new code from release code)
  • Conduct 3 week pre-release testing phase, so that people get actually the chance to try the pre-releases and provide feedback about potential issues
  • Official announcement at flightgear.org and its mailing lists about the pre-release phase to inform people soon enough, announcement at freshmeat.net or sourceforge might also be a good idea.
  • Basic BTS (bug tracking system) - this will be required during the pre-release test phase for 1.0 so that there is an intuitive and simple way for users to provide feedback (without having to subscribe to mailing lists in order to report their problems). Alternatively, a simple web based forum such as phpBB might already be sufficient for this purpose and much more accessible for the majority of users.
  • review all relevant user level documentation at least 5 weeks before planned release, so that inconsistencies can be identified and dealt with accordingly
  • There is meanwhile a decent amount of documentation available for FlightGear, however most of it is not easily accessible because it is pretty widely spread over various different places, it would be good if we could start to collect all these resources and make them all part of one comprehensive manual, or at least put the links to all docs on flightgear.org
  • Currently, setting winds (direction/speed) without using 3 digits, will crash FlightGear This doesn't happen in the CVS snapshot of 2007-08-23.
  • saving and loading flights doesn't seem to work properly, see mailing list discussions (devel) from march 2006

Convenience

  • Make aircraft switchable at runtime (given that more and more logics in aircrafts are implemented using Nasal, part of this effort may also involve considering to put aircraft/session-specific Nasal scripts into a special module/context (i.e. "aircraft" or "session") which could automatically be purged upon changing/reloading an aircraft, in order to simplify the housekeeping process-instead of having to manually keep track of which scripts are used in certain scopes and may need to be reset or deleted from the ctx) (Note: this is being separately discussed at FlightGear Sessions
  • Make aircraft relocatable (as requested by C. Olson in [1] respectively [2])
  • Some localizers have a co-located DME so that they also provide distance information when an ILS is tuned in, however this does currently not seem to work in FlightGear as of 03/2008 CVS/HEAD, this doesn't seem to be a problem anymore (tested using various ILS), in any way this might have be an aircraft-specific issue, i.e. because of a not completely implemented panel?
  • during replay animations are not properly saved/replayed (flaps, gear, ailerons, thrust reversers, etc.) - the aircraft is displayed in the last active configuration during all the replay
  • Repositioning an arbitrary aircraft multiple times in a row during a session (using the menu) results eventually in a segfault
  • Fix the load/save flight? facilities so that they work properly with all standard (base package) aircraft in various phases of flight (on ground, in flight)
  • local animations are automatically applied to all multiplayer aircraft
  • Unify JSBSim and YASim properties, so that frontends for both FDMs can be easily provided, this will be particularly useful for things like the fuel & balance dialog, which is currently specific to YASim only. (this is being separately discussed, see FDM Feature Standardization
  • 3D clouds do not work properly on ATI 9200 cards, we get a clear sky when enabling 3d clouds (even using -bpp=32 ?) (no longer applicable, there are now new shader based clouds in CVS/OSG)
  • In Progress - Convert all hardcoded PUI dialogs to dynamic XML dialogs that are based on FGDialog (and become stylable that way) was also finished some time ago
  • Fix the "reset" routine, so that it works reliably, even after a crash (or unusual attitude) (is this problem still occuring?)
  • Provide more finely grained control over simulator resets [3]
  • the default winds (~10-30kts) should practically never be able to move a standing aircraft, however several default aircraft (even larger ones) are still moved by the wind, even with engines off
  • subsystems that require to be run at a certain minimum update interval to run properly (like the FDM) should emit a warning if this minimum interval cannot be reached (i.e. due to slow hardware), otherwise the sim behaviour gets pretty soon undefined. Also, subsystems with configurable update intervals (like the FDMs) should probably warn if the configured update interval cannot be reached at runtime (i.e. if /sim/model-hz=500, and the actually reached interval is 'only' 200, there should be a warning about this circumstance)
  • Fix the "positioning" routine for the "location-on-ground.xml" dialog, so that it is no longer case sensitive and finds airports and runways regardless of whether capital letters were used or not. This problem doesn't occur in the CVS version from 2007-08-24.
  • Add support for optional use of multiple separate threads (i.e. FDM,sound, I/O, network) so that SMP machines can optionally use multiple threads
  • Add support for multiplayer messaging/chat so that players can communicate with each other this is available
  • Provide a file picker dialog for the GUI, so that users can browse to directories for loading/saving data (i.e. flights), instead of having to remember the exact path and filename of each saved flight
  • Fix framerate display code, so that the framerate is also shown in 2D cockpits and not only in 3D (cockpit) mode, possibly adjust the text color on demand, so that readability is improved automatically if required. - DONE
  • provide new startup parameter to allow for automatic offset usage for cases where lat/lon pairs lie on tile boundaries, something like --lat-lon-auto-offset would seem useful?
  • Provide new startup parameter to disable threads completely, to make debugging easier
  • Put model loading into separate thread, so that FlightGear is not slowed down too much upon joining multiplayer nodes (slow disk access is almost certainly the major problem here) (implemented)
  • Aircraft panels with autopilots installed should no longer require the autopilot to be used from within a GUI dialog but should also have corresponding bindings to the autopilot panel (this is an aircraft-specific issue)
  • Consider putting multiplayer routines optionally into separate thread, to avoid lag related performance issues
  • Consider shipping binaries with a separate binary including debugging symbols/information (i.e. fgfs-dbg), so that non-developers can provide more useful feedback in case of problems (this is release specific and should go somewhere else)
  • Modify multiplayer source code, so that the port number in router setups does not need to be provided, but is determined automatically
  • Fix those YASim aircraft that still use legacy definition files, these emit currently unnecessary warnings in the console
  • During startup: If specified runway could not be found for a certain airport, always fall back to the longest runway at that airport
  • Consider including atlas,fgsd and taxidraw with official 1.0 release by default-providing simgear as shared lib might be a good thing then? (again: release-specific)

Eye Candy / Look & Feel

  • Add and use a greater variety of textures for terrain texturing, the current scenery may sometimes look quite indifferent
  • Add support for landing lights in aircraft (initial patch already available)
  • "Look around" mode in 2D cockpit mode makes the cockpit panel unavailable, might be useful to add a key binding to re-center the view to the default, so that the original panel is visible again (already there - click the middle mouse button when in view mode)
  • improve startup time (requires often more than a minute, even on a recent system) according to discussions on the flightgear forums, FlightGear generally seems to start up in less than 30 seconds on multi core machines, while it may take up to 5 minutes (or even longer) on non-multi core machines
  • Possibly make the new "anthrax" style under $FG_ROOT/gui/styles the default style because it is likely to be much more appealing to the average user than the current default that's been done
  • Consider presenting ATC chat in the "anthrax" style dialog box rather than red on (usually) blue sky which is difficult to read. This could possibly be combined with an 'acknowledge' button until we have a more sophisticated ATC system.
  • The increase/decrease speedup (simulation time) does not work properly, will crash any aircraft in flight within seconds (that's mostly a matter of interactions between fdm and autopilot)
  • All aircraft included in the base package by default should provide their panel functionality preferably indpendent from the GUI (that's again a release specific thing)
  • The "Enhanced runway lighting" option looks sluggish on most non-nvidia hardware if enabled
  • Add support for illuminated instruments, so that instruments become more readable at nighttime (done some time ago)
  • The approach lights at KSFO are under water again
  • layer boundaries: 3D clouds look "cut off" for transistion layers no longer applicable: new 3D clouds implementation

General Todo

  • HUD Labels - At this time all HUD labels are hard coded values. It would be much more flexible if the code allows one to display the contents of a property instead. Then it is also possible to remove all the current hard-coded labels and redefine them in the HUD configuration file
  • Airport Issues
    • There are still a fair number of airports with runways that are on platforms relative to the local terrain with sharp drop edges on the sides of the runway, etc.
      • KASE
      • KSFO is another example where runway 28R doesn't quite match up with the surrounding terrain. Also the terminal building for SFO doesn't seem to be quite touching the ground as you can sometimes see the terrain that is behind the building.
    • A variety of airports were accidentally dropped from Robin Peel's last database, while others are duplicated.
    • When a runway at an airport has a localizer for both directions, and that localizer has the same frequency in each direction, it is often the case (e.g. KBOS 4R/22L, KMDW 13C/31C) that the nav radio grabs the localizer for the wrong direction. In other words, approaching KBOS 4R from the south, a nav radio on 110.3 should be receiving I-BOS, but instead gets I-LQN; approaching KBOS 22L from the north, a nav radio on 110.3 should be receiving I-LQN, but instead gets I-BOS. This makes the DME numbers disagree with those given on the relevant approach charts. More significantly, it also inverts the left-right sense on the localizer radial; a pilot turns right to move onto the localizer course, and ends up actually moving farther away.
    • Various airports have the new windsocks and beacons in the middle of the runways. (I know this is a known issue, but thought it'd be worthwhile to note it here, to make clear to anyone discovering it anew that it is known).
      • Edinburgh, has a Lighting Beacon right in the middle of the runway. While I have let Robin Peel know that the error is there, it will not be fixed untill the next scenery regeration. - Gorilla
      • UUEE - the same as above
    • It would be a good idea if a version number option was added to FlightGear (preferably --version). (available) By adding a version query function to SGSubsystem it is even possible to query the version numbers of all available subsystems (if required).
  • It might be useful to investigate the need for adding a paramater list to FlightGear: See: http://freshmeat.net/articles/view/1267/
  • The new scenery search path code allows one to distinguish between Model and Terrain paths. But at this time it is not possible to add a .stg file to the Model path unless it is also available in the Terrain directory. We have to make sure that adding models to the Model path doesn't require an airport (or other automatically defined scenery objects) in the Terrain directory have to be present. Update: This might be fixed by fixing an indexing problem. This has to be tested.
  • Thermal Modeling : it would be useful if there was more accurate and more complete support for modelling of thermals in FlightGear, preferably this would automatically add visual hints to the scenery (eg cmulus clouds or birds) to appropriate places.
  • In Progress It would be nice to have bad weather more completely modelled in flightgear, particularly rain drops and lighting
  • Model birds / bird strikes
  • It would be good if there was a convenient interface to the scenery downloads, that might allow users to specify airports, cities or countries for which they would like to download the tiles. That way a user could simply say, "I want all scenery for the KOAK airport, san fransico area", or "all scenery for belgium". This could probably be based on esri shapefiles to automatically get the corresponding coordinates for the tiles.
    • Such feature is available via using "TerraSync/SVN", 'terrasync' with the '-S' switch, which will download all the relevant Scenery for your current position.
Retrieved from "http://wiki.flightgear.org/index.php/FGFS_Todo"
Personal tools