https://wiki.flightgear.org/w/api.php?action=feedcontributions&feedformat=atom&user=MaerchenprinzFlightGear wiki - User contributions [en]2026-04-05T14:43:36ZUser contributionsMediaWiki 1.39.6https://wiki.flightgear.org/w/index.php?title=Troubleshooting_performance_issues&diff=132624Troubleshooting performance issues2021-07-31T11:59:35Z<p>Maerchenprinz: /* FlightGear configuration */changed preferences.xml to defaults.xml</p>
<hr />
<div><br />
{{Troubleshooting}}<br />
<br />
'''Troubleshooting performance issues''' will help you if:<br />
* you think that FlightGear could run smoother on your computer<br />
* [[Hardware Recommendations|your hardware]] is not exactly from the latest generation<br />
* you're already fiddling with the settings but can't get any FPS out of it<br />
* you're trying to track down who's responsible for [[Troubleshooting graphics artifacts|graphics artifacts]] you're seeing.<br />
By progressively following all the hints of this page, in fact, you'll slowly get to a [[Howto:Debugging FlightGear Crashes|minimum startup profile]] in which most properly configured machines should have no problems.<br />
<br />
<br />
== Performance in FlightGear ==<br />
=== What can I aim at? ===<br />
It depends on many things as you'll see. It's easier to tell you what you ''should'' aim at: at least 20 FPS (frames per second). Under this value, things get very choppy and especially flying [[VFR]] will be more difficult. A much more decent value is 30 FPS, also to face better possible stuttering.<br />
<br />
It makes no sense to exceed the refresh rate of your monitor. This is typically 60 FPS, but some monitors support speeds as high as 120 FPS. <br />
<br />
=== How do I see my framerate? ===<br />
During the simulation, open the ''View > View Options'' menu and toggle ''Show frame rate''. You'll see the number at the bottom right of the screen.<br />
<br />
=== How do I use this page? ===<br />
Below, you'll find a list of performance factors. Each of them affect performance, but it's not the same for everyone. So, to find out what you can give up for less stuttering, more regular FPS, or what's killing the framerate, or what could be causing certain artifacts, you'll have to check each of them. <br />
<br />
Most important, you'll have to '''check them singularly''', otherwise you'll never be sure if one of the factors is more determinant than others. Also, make your experiments in a fixed environment, like always starting with the same aircraft on the same runway.<br />
<br />
The list order is reasoned, so try to follow it, unless you know what you're doing (e.g. everything worked, until you have fiddled with some particular options and broke it.) We know it's boring, but this is the only way to try to fix these issues.<br />
<br />
=== Minimal startup profile as a faster alternative ===<br />
If you feel like fiddling with configuration files, command line options and such, you can ease the process and make it more thorough by using the [[Howto:Debugging FlightGear Crashes|minimal startup profile]] that is used for troubleshooting crashes. The idea is always the same: change options one at a time (you can do that also in-sim) and tune them to suit your needs.<br />
<br />
== Performance factors ==<br />
=== Hardware setup ===<br />
*'''Problematic video cards''': There is a list of [[Problematic Video Cards]]. Check that yours is not there.<br />
*'''Integrated video cards''': These are probably in the above list, but sometimes you can play with them, reducing "eye candy". Two of these cards are Intel HD graphics 3000 and 4000. With integrated video cards it's also often possible to specify the amount of system memory to be shared and used as video RAM (VRAM).<br />
*'''Video screen''': Actually, this does not affect performance. The problem though is that with a large screen you might want to use higher resolution, but that ''will'' affect performance (and so will color-depth).<br />
<br />
=== Operating system and driver setup ===<br />
*'''Background programs''': Check that your operating system is not cluttered by unnecessary programs running in the background. Have as little programs running as possible.<br />
* '''Maximize power performance settings''': If you're running a laptop, chances are your system defaults to a power-saving mode, even with the laptop plugged in. Adjust these settings to maximal power while running FlightGear.<br />
* '''Disable Optimus/Hybrid Graphics''': Most notebooks that run Windows 7 have the so called Optimus Technology (NVidia) or Hybrid Graphics technology (ATI) onboard. This is meant to increase battery life, by automatically switching of the powerful graphics card when it's not needed. However, FlightGear needs it all the time, even if Optimus says it doesn't! This miscommunication results in low framerates (because your computer will run Flightgear on the weak onboard processor) and often FlightGear will quit with the following error:<br />
Unknown exception in the main loop. Aborting... <br />
Possible cause: Not enough space<br />
: If you own an NVidia card, check that it is actually used:<br />
:# Go to the NVidia control panel. Probably located in the Windows Control Panel.<br />
:# Open the 3D Settings tab. Now there's two options you can take:<br />
:#* On the "General settings tab", set "Prefered graphics processor" to NVidia. The NVidia card will now be used for all software. This can decrease battery life significantly.<br />
:#* On the "Programm settings" tab, locate <tt>fgfs.exe</tt> (eg. <tt>C:/Program Files/FlightGear/bin/win32/fgfs.exe</tt>) and assign the NVidia card to it. From now on the NVidia card will be used for FlightGear.<br />
* '''Linux users''': Many newer Linux distributions come with 3D enhanced, composite desktop environments (KDE4, Compiz, Fusion...) They're known to consume CPU and GPU resources, even slowing FlightGear down by 10 FPS. Choosing another window manager from the login screen, like XFCE, results in higher FlightGear performance. Setting "Compositing" to "off" in KDE4 might also help.<br />
<br />
=== Graphics drivers setup ===<br />
*'''Graphics card drivers''': Ensure that the manufacturer's graphics card drivers are installed. You may be able to download and install drivers specific to your card from the manufacturer's site. See [[Graphics drivers configuration]].<br />
* '''Graphics drivers settings''': Disable Anti-Aliasing and Anisotropic Filtering or at least set them to their lowest settings. Decreasing the setting for Mip-Mapping to its lowest setting can also help.<br />
<br />
=== FlightGear configuration ===<br />
From FlightGear Launcher (some options appear also during the simulation, so better to check them there too):<br />
* '''Rembrandt''': If you enabled the [[Project Rembrandt|Rembrandt renderer]], well, you knew that's experimental. First of all, try to change shadows settings, and consider disabling them. If it's not enough, disable Rembrandt altogether. To check if it's enabled: last tab, ''Advanced > Rendering >'' uncheck ''Rembrandt''.<br />
* '''3D Clouds''': One of the worst offenders in terms of performance impact. Disable them. (in-sim too)<br />
* '''Screen resolution''': The amount of pixels that the graphics card must draw affects performance, so reducing resolution can often help.<br />
* '''Shading''': Set to "flat"<br />
* '''Fog''': set to "nicest" or "disabled"<br />
* '''Visibility''': Try reducing visibility, especially with high-detail scenery. (corresponds to ''bare'' settings in-sim, ''View > LOD settings'')<br />
* '''Log level''': Check that the log level is set to "alert" in ''Advanced > Debugging > Log level''. Logging can cost some FPS.<br />
* '''Everything else''': Both ''Advanced > features'' and ''Advanced > rendering'' have few settings that you can try out.<br />
* '''Texture compression''': If you're experiencing stuttering when turning left/right or when loading new tiles, it is possible that texture compression is not handled correctly. Disable it by adding the property <tt>/sim/rendering/texture-compression=off</tt> in FGrun: ''Advanced > Properties''. This can be tried for nVidia, ATI cards and for Intel integrated chips with MesaGL, that suffer from bugs with texture compression and FlightGear.<br />
*'''Multithreading''': '''''WARNING!''''' If you know what you're doing, in defaults.xml enable <tt><multithreading-mode></tt>. If your framerate is lower with this setting enabled, and both you and your computer survived, disable it again.<br />
<br />
During the simulation:<br />
* '''Shaders''': If you cranked all the way up these settings, it's very likely the cause of your FPS problem, and possibly of any [[Troubleshooting graphics artifacts|artifact]]. To check, during the simulation go in ''View > Rendering options'', check the [[Shader]]s slider position. If that seems the problem, you can select ''Custom'' and try to see which one, at which position is the cause of your problems. It can be a particular combination of them, too.<br />
* '''Random features''': Try disabling, one by one, random buildings, random objects, random trees. If any of them seem to be the cause of your problems, you could try to fine-tune their density, or just leave them disabled. They require to reload the scenery.<br />
* '''Everything else''': Try disabling one by one each of the other rendering features. Some will need a restart.<br />
* '''Framerate limiter''': be sure that it's unchecked, or that it's not forcing to a too low FPS.<br />
<br />
=== FlightGear simulation choices ===<br />
* '''Time of day''': Changing from nighttime to daytime flying is not only easier on the piloting, but also easier on the graphic requirement. Check the "Time of day" box and select a daytime setting. This is not true, however, if you have shadows enabled: these are pretty consuming, and present only during daytime.<br />
* '''Location''': KSFO is a wonderful airport but also known for a high-volume of traffic, which can slow performance. Try another airport if you encounter performance issues.<br />
* '''Rural flying''': While framerate may initially be as slow as 5 fps during takeoff, they may jump 5x or more after flying out to less-populated areas.<br />
* '''Weather''': Fly in clear skies. Clouds always incur a more or less pronounced performance hit.<br />
* '''Choice of aircraft''': Certain aircraft have lower resource requirements, especially the UFO. The 777 instead is known to be quite heavy.<br />
* '''2D panels''': Although 3D cockpits look very tempting, simple 2D panels are much easier on the framerate.<br />
* '''AI traffic''': [[AI Traffic]] is computer controlled traffic, which includes traffic over the [[Howto: Multiplayer|Multiplayer network]]. By turning off this function you're not able to see other aircraft. Most stuttering, or lag, is caused by the need to load the models for these aircraft while they appear. It can range from a minor annoyance to a crash. Turning off just the computer-generated aircraft (leaving the MP traffic visible), can be done by adding the property <tt>/sim/traffic-manager/enabled=0</tt> to [[FGRun]], through ''Advanced > Properties''.<br />
<br />
=== Nothing worked. Now what? ===<br />
It is unlikely, so this must be more than a simple performance issue. You'll need to ask for someone's support and provide them some diagnostic data. See [[Troubleshooting graphics artifacts#Requesting support|Troubleshooting graphics artifacts]] for information on how to do that.<br />
<br />
== For the geeks out there ==<br />
=== FPS and frame spacing ===<br />
Frames per second is an average by definition, and as such is not an optimal indicator of performance, because you could have half a second with 100 FPS and the other half with 0 FPS. You'd get a respectable 50 FPS but an unacceptable stutter of 0.5 seconds. A much better one is keeping track of the maximum frame spacing (i.e. the delay/time needed to create new frames), that gives a measure in milliseconds of the worst performance during a fixed interval.<br />
<br />
=== Tools for performance evaluation ===<br />
The performance impact can be evaluated by using:<br />
* The frame rate counter (frames created per second)<br />
* The frame spacing indicator (latencies between rendered frames)<br />
* The [[Howto:Use the system monitor|built-in system monitor]] (can be inspected via telnet/http using [[Telnet usage|--telnet=5900]]) <br />
* The OSG on-screen stats<br />
* The [[Built-in Profiler]]<br />
<br />
=== Some more details on the inner workings ===<br />
==== FPS throttling ====<br />
Older versions of FG (before 1.9) would get choppy if the frame rate got too high (well above the monitor refresh rate) but newer versions seem to have less problems with this. However, depending on your system setup you may need to throttle the frame rate to prevent choppiness at high frame rates, but it's not very likely with the current version of FlightGear. Most users anyway don't have enough GPU power to be concerned about frame rates getting too high with current FlightGear versions and those (lucky) users can, to some extent, throttle frame rates by increasing/maximizing eye candy settings.<br />
<br />
==== How FPS affects the simulation ====<br />
Keep in mind that things like nasal listeners, animations and other parts of the sim run at the video frame (main loop) rate and if your frame rate gets too low these things might not work as well as they should. As an example, if your aircraft is one armed with machine guns, you may see the guns change rate of fire if your frame rate is too low. This will definitely be the case with the JSBSim P-51D if your frame rates are below 30fps. As more things are decoupled from the main loop this should become less of an issue in future versions of FlightGear.<br />
<br />
Additionally, the more the framerate decreases, the more other features of the simulation will suffer. The current [[FlightGear]] software architecture is such that long rendering times (slow framerates) may prevent other parts of the flight simulator, such as the autopilot, from having sufficient CPU time to respond correctly in the context of the simulation.<br />
<br />
==== More on factors ====<br />
FlightGear's framerate is influenced by various factors, including:<br />
* [[scenery]] complexity (terrain, clouds, trees, particles, random 3D objects, multiplayer/AI traffic, animated jetways)<br />
* [[cockpit]] complexity (2D vs. 3D)<br />
* environmental options (eg. visibility, precipitation)<br />
* [[FDM]] update interval<br />
* AI scenarios<br />
* [[aircraft]] speed (scenery paging)<br />
* rendering options<br />
* debugging level<br />
<br />
=== A note from the developers ===<br />
==== Performance and the OpenGL Shading Language (GLSL) ====<br />
If working through this article doesn't solve the problem, you are probably facing a hardware/driver issue, which means that you may need to fix your drivers (version or settings).<br />
<br />
If however at some point the error stops from occurring, that would suggest that FG is using some "code paths" that are not supported by your current driver. We have an increasing number of GLSL shaders, while most of the existing FG code was really only written with a fixed rendering pipeline in mind - and in fact, much of it even predates the OSG port, such as for example the GUI (PLIB/PUI).<br />
<br />
In summary, our way of using OSG is not particularly optimized, and we're doing a lot of things that are known to be inefficient, such as having lots of GL state changes, and using legacy GL code in conjunction with more modern code. All of these also affecting compatibility, because GLSL, unlike DirectX shader code, is not bytecode, but compiled on-the-fly by your driver - in other words, each GPU vendor will typically have their own GLSL compiler implementation, and these are known to be fragile under certain circumstances. We do not have the resources to test each shader on all major hardware platforms, so we really rely on end-user quality feedback, e.g. by using tools like gDebugger or the corresponding ATI/AMD and nvidia equivalents.<br />
<br />
==== The move to OpenSceneGraph (OSG) ====<br />
Some people have been suggesting to our core/shaders developers to switch to AMD/ATI or even Intel hardware in order to get rid of certain problems. But it's not as simple as that to be honest: FlightGear is a fairly old code base, and it also isn't particularly modern - these days, many parts are basically unmaintained, and haven't been touched in years, despite containing lots of legacy code.<br />
<br />
OSG is much more powerful than you may think, but it cannot magically fix all the problems that FlightGear introduces, we have a ton of features that basically still date back to the pre-OSG days, i.e. when we were using purely PLIB and SDL. OSG itself is generally rock-solid and there are rarely any issues found with it. To see for yourself, just run fgviewer or any of the OSG examples (osgviewer).<br />
<br />
As recently pointed out elsewhere, those OSG examples even support Intel GMA cards, often even shaders to some degree - but we have never really formalized the way OpenGL/OSG code is written/developed for FlightGear, including effects and shaders.<br />
<br />
[[Category:Troubleshooting]]<br />
<br />
[[es:Resolviendo_problemas_de_rendimiento]]</div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=Aircraft_tester_list&diff=127074Aircraft tester list2020-08-27T14:56:38Z<p>Maerchenprinz: </p>
<hr />
<div>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.<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Aircraft !! Tester(s) !! Remarks<br />
|-<br />
| 737NGs || James Turner || <br />
|-<br />
| 757 || James Turner|| <br />
|-<br />
| A300 || Jonathan Redpath|| <br />
|-<br />
| A320-200 || Jonathan Redpath|| [NB - upstream github repo for issues]<br />
|-<br />
| A340-600 || Jonathan Redpath|| <br />
|-<br />
| A380 || Jonathan Redpath|| <br />
|-<br />
| A6M2 Zero || Stuart Buchanan || <br />
|-<br />
| Aerostar-700 || James Turner || <br />
|-<br />
| B1900D || James Turner || <br />
|-<br />
| CH-53E || Richard H. || <br />
|-<br />
| CRJ700 family || Henning, Daniel || <br />
|-<br />
| Cap 10C || Scott || <br />
|-<br />
| Cessna 208B Caravan || James Turner || <br />
|-<br />
| DR400 || Scott || <br />
|-<br />
| DaSH || Wayne Bragg|| <br />
|-<br />
| F-14 || Richard H. || Willing to reassign upon request to those with experience of this aircraft<br />
|-<br />
| F-15 || Richard H. || Willing to reassign upon request to those with experience of this aircraft<br />
|-<br />
| F-16 || Stuart ||<br />
|-<br />
| F6F - Hellcat || Keith || <br />
|-<br />
| F-86 || Jonathan Redpath || <br />
|-<br />
| Fokker 100 || Jonathan Redpath || <br />
|-<br />
| Grob || Scott || <br />
|-<br />
| Hansa Jet || Adrian S. || <br />
|-<br />
| Jaguar || Richard || <br />
|-<br />
| Junkers JU-52 || James Turner || <br />
|-<br />
| hunter || Stuart || <br />
|-<br />
| J3Cub || Wayne Bragg|| <br />
|-<br />
| Lionceau || Scott || <br />
|-<br />
| p51d || Stuart || <br />
|-<br />
| SUMPAC || Wayne Bragg|| <br />
|-<br />
| Skyvan || Keith || <br />
|-<br />
| Socata || Scott || <br />
|-<br />
| seahawk || Stuart || <br />
|-<br />
| wrightFlyer || Stuart || <br />
|-<br />
| tu154b || Gaétan Allaert || <br />
|-<br />
| Pilatus PC-9M || vanosten || <br />
|-<br />
|}<br />
<br />
[[Category:Aircraft enhancement]]</div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=Modules.nas&diff=122837Modules.nas2020-04-01T16:43:47Z<p>Maerchenprinz: Missing quotation marks added</p>
<hr />
<div>= Nasal runtime re-loadable modules =<br />
== Introduction and motivation ==<br />
Nasal (Flightgears integrated scripting language) comes with a limited number of [[Nasal library|core functions]]. <br />
The language was [[Howto:Extend Nasal|extended by C++ functions]], as well as libraries written in Nasal (e.g. [[Nasal library/props|props]], [[Nasal library/io|io]], [[Nasal library/math|math]], [[Nasal library/debug|debug]] ...). <br />
<br />
The latter are stored in the [[Fgdata]] repository under /Nasal and loaded automatically by FlightGear.<br />
Optional code, which is loaded only on demand, can be handled either by the legacy module system implemented in C++ or by modules.nas if run-time re-load support is required.<br />
<br />
For more information on how and when these files are loaded see [[Nasal Initialization]].<br />
<br />
== Differences between add-ons and modules ==<br />
While there are many similarities between add-ons and modules, some words on the differences: <br />
<br />
Modules are distributed with FlightGear as part of Fgdata.<br />
Add-ons have to be downloaded separately by a FlightGear user from wherever the author of the add-on publishes the add-on.<br />
<br />
Modules can be loaded e.g. by an aircraft if the aircraft developer wants to make use of the module.<br />
Add-ons are selected by the user before launching FlightGear, thus they may or may not be available at runtime.<br />
<br />
<br />
= HowTo / Examples =<br />
First some examples, the API documentation follows below.<br />
<br />
== Nasal modules in an aircraft (e.g. for development) ==<br />
Nasal code for an aircraft is usually loaded by a XML declaration in the <aircraft>-set.xml file like this:<br />
<syntaxhighlight lang="xml"><br />
<PropertyList><br />
<nasal><br />
<foo> <!-- Nasal namespace foo --><br />
<file>Nasal/foo.nas</file><br />
</foo><br />
<bar> <!-- Nasal namespace bar --><br />
<file>Aircraft/Generic/foo.nas</file><br />
</bar><br />
<myAircraft> <!-- Nasal namespace myAircraft--><br />
<file>Nasal/efis_module.nas</file><br />
</myAircraft><br />
</nasal><br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
This is fine unless you are developing a Nasal subsystem for the aircraft and have to restart FlightGear every time you edit a few lines. <br />
For this case you could consider to use the Module class (defined in FGDATA/Nasal/modules.nas) and make your code re-loadable at runtime, <br />
which means you do not have to restart whole FlightGear just for a few lines of edited Nasal code.<br />
<br />
'''Example Nasal/efis_module.nas:'''<br />
<syntaxhighlight lang="nasal"><br />
#-- load EFIS as reloadable module<br />
var my_efis = modules.Module.new("myAircraft_EFIS"); # Module name<br />
my_efis.setDebug(1); # 0=(mostly) silent; 1=print setlistener and maketimer calls to console; 2=print also each listener hit, be very careful with this! <br />
my_efis.setFilePath(getprop("/sim/aircraft-dir")~"/Nasal/EFIS");<br />
my_efis.setMainFile("myAircraft-efis.nas");<br />
my_efis.load();<br />
</syntaxhighlight><br />
<br />
Now add a menu item for easy reloading like this:<br />
{{note|<br />
The module name in the property path must match the name passed to modules.Module.new() <br />
|margin=10px |width=50%}}<br />
<syntaxhighlight lang="xml"><br />
<menubar><br />
<default><br />
<menu n="100"><br />
<!-- normal aircraft menu --><br />
</menu><br />
<menu n="101"><br />
<label>Aircraft Development</label><br />
<item><br />
<label>Reload EFIS</label><br />
<binding><br />
<command>property-assign</command><br />
<property>/nasal/modules/myAircraft_EFIS/reload</property><br />
<value>1</value><br />
</binding><br />
</item><br />
</menu><br />
</default><br />
</menubar><br />
</syntaxhighlight><br />
<br />
{{tip|<br />
You can also call {{code| myAircraft.my_efis.reload();}} to trigger the reload. myAircraft is the namespace given in the <aircraft>-set.xml file, my_efis is the module object (see above). <br />
|margin=10px |width=50%}}<br />
<br />
== Nasal frameworks ==<br />
Another usecase for Modules.nas is frameworks that need reload support. <br />
A framework usually provides more or less generic functionality that has to be adapted (configured) for a specific usecase (e.g. a specific aircraft).<br />
Reload support may become very convenient, if the customizing based on such framework involves many iterations of edit-reload-test.<br />
<br />
First living example is the canvas_efis framework which can be included into an aircraft with a single line of code: <br />
<br />
{{code|<br />
<nowiki>var efis_module = modules.load("canvas_efis");</nowiki><br />
}}<br />
<br />
(see also last chapter at the end of this article)<br />
<br />
= Structure of Nasal reloadable modules =<br />
A module must contain at least the file '''main.nas''' (default, other filename is possible) and should contain the functions {{code|main()}} and {{code|unload()}}.<br />
<br />
=== main() function ===<br />
The main.nas file shall contain a function {{code|main()}} that will be called on load with either the module object as parameter or the parameters passed to the {{code|module.load()}} function.<br />
<br />
=== unload() function ===<br />
If you want the module to be re-/un-loadable, you must make sure to track resources and remove them on onload.<br />
For this the main.nas shall contain a function {{code|unload()}} that removes any resources which were created by the module.<br />
<br />
'''Example:''' any canvas created by the module should have called its {{code|del()}} method here.<br />
<br />
{{note|Calls to {{code|setlistener()}} and {{code|maketimer()}} are automatically tracked by the Module class for you, timers will be stopped automatically, listeners will be removed automatically on {{code|unload()}}.}}<br />
<br />
=== Rules for Module names ===<br />
# Module names shall contain only letters (a-z, A-Z), numbers (0-9) and underscores ('_').<br />
# The name must contain at least one letter so it cannot be confused with a number<br />
# The name shall not match any existing .nas file or directory in FGDATA/Nasal to avoid namespace clashes<br />
<br />
{{note|<br />
Reloadable modules shipped with FlightGear are stored in subdirectories of FGDATA/Nasal/modules/ as these subdirectories will not be loaded automatically by Flightgear on start.<br />
However, modules.nas will scan this directory to create a list of available modules (list of subdirectories). <br />
Each module correspondes to one subdirectory and the direcory name is also the module name.<br />
}}<br />
<br />
= modules.nas =<br />
In ''modules.nas'' the class ''Module'' is defined. <br />
A module object holds information about the path and filename of the Nasal script and supports unloading and reloading the code at runtime<br />
(e.g. without restarting Flightgear as a whole) by tracking some critical resources like [[Listeners|listeners]] and [[Timers|timers]].<br />
<br />
{{note|Parts of this functionality were added to the [[Addons|addons]] manager earlier and have now been extracted to avoid code duplication.}}<br />
<br />
{{caution| Within a module {{code|setlistener()}} is overloaded and the default value for the 4th argument (runtime) is changed to 0, so the listener will run only if the property value has changed.<br />
}}<br />
<br />
== library functions ==<br />
=== modules.isAvailable() ===<br />
{{Nasal doc<br />
|syntax = modules.isAvailable(module_name);<br />
|text = This function returns true, if there is a module (subdirectory) in FGDATA/Nasal/modules/ with the given name.<br />
|param1 = module_name<br />
|param1text = The name of the module (=subdirectory in Nasal/modules) to load.<br />
|example1 = <br />
if (modules.isAvailable("foo_bar")) {<br />
modules.load("foo_bar");<br />
} <br />
}}<br />
<br />
=== modules.setDebug() ===<br />
{{Nasal doc<br />
|syntax = modules.setDebug(module_name, [debug=1]);<br />
|text = This function enables debugging for a module. It must be called '''before''' load()!<br />
|param1 = module_name<br />
|param1text = The name of the module (=subdirectory in Nasal/modules) to load.<br />
|param2 = debug<br />
|param2text = Defaults to 1 (true), use 0 to disable debug. If debug > 1, each listener hit will be printed, be careful not to listen to rapidly changing props, do not set runtime=1 in setlistener().<br />
|example1 = <br />
var debug = 1;<br />
modules.setDebug("foo_bar", debug); <br />
}}<br />
<br />
=== modules.load() ===<br />
{{Nasal doc<br />
|syntax = modules.load(module_name, [namespace_name]);<br />
|text = This function attempts to load a module from FGDATA/Nasal/modules/<br />
|param1 = module_name<br />
|param1text = The name of the module (=subdirectory in Nasal/modules) to load.<br />
|param2 = namespace_name<br />
|param2text = Optional, load module to a different namespace.<br />
|example1 = <br />
modules.load("foo_bar"); <br />
}}<br />
<br />
== Methods of class Module ==<br />
=== setFilePath() ===<br />
{{Nasal doc<br />
|syntax = mymod.setFilePath(path);<br />
|text = Configure where to look for the main file, e.g. aircraft (sub-)directory.<br />
|param1 = path<br />
|param1text = File path where the module is stored.<br />
}}<br />
<br />
=== setMainFile() ===<br />
{{Nasal doc<br />
|syntax = mymod.setMainFile(filename);<br />
|text = Configure the nasal file to load.<br />
|param1 = filename<br />
|param1text = File that will be loaded by load().<br />
|example1 =<br />
# if you develop a new nasal system for your aircraft, it might be handy to implement it as module<br />
# so you can reload the file quickly without restarting FlightGear<br />
var my_foo_sys = modules.Module.new("my_aircraft_foo");<br />
my_foo_sys.setDebug(1);<br />
my_foo_sys.setFilePath(getprop("/sim/aircraft-dir")~"/Nasal");<br />
my_foo_sys.setMainFile("foo.nas");<br />
my_foo_sys.load();<br />
}}<br />
<br />
=== setNamespace() ===<br />
{{Nasal doc<br />
|syntax = mymod.setNamespace(namespace);<br />
|text = Configure the Nasal namespace to use. Be really carefull when using existing namespaces! unload() or reload() will destroy them!<br />
|param1 = namespace<br />
|param1text = The Nasal namespace the module code will be loaded into.<br />
}}<br />
<br />
=== setDebug() ===<br />
{{Nasal doc<br />
|syntax = mymod.setDebug(debug=1);<br />
|text = Activate debugging for this module. '''Must be called before calling load()!'''<br />
|param1 = debug<br />
|param1text = <br />
0: no debugging; <br />
1 (default if no argument given): print calls to redirected {{code|setlister()}} and {{code|maketimer()}}; <br />
<br />
2: listeners print property path when hit (Use with caution! Do not call {{code|setlistener()}} with runtime=1.)<br />
}}<br />
<br />
=== load() ===<br />
{{Nasal doc<br />
|syntax = mymod.load([args]);<br />
|text = This function attempts to load the module into its namespace.<br />
|param1 = optional args<br />
|param1text = Arguments are passed to the main() function of the module. If empty, the module object will be passed to main().<br />
}}<br />
<br />
=== unload() ===<br />
{{Nasal doc<br />
|syntax = mymod.unload();<br />
|text = This function attempts to remove tracked resources and remove the module by killing its namespace.<br />
}}<br />
<br />
=== reload() ===<br />
{{Nasal doc<br />
|syntax = mymod.reload();<br />
|text = Shorthand, calls unload() and load().<br />
}}<br />
<br />
=== get() ===<br />
{{Nasal doc<br />
|syntax = mymod.get(var_name);<br />
|text = Returns a variable from modules namespace.<br />
|param1 = var_name<br />
|param1text = The variable to get.<br />
|example1 =<br />
var foo = modules.load("foo");<br />
var bar = foo.get("bar"); # get variable "bar" defined in FGDATA/Nasal/modules/foo/main.nas (or a file included by this file)<br />
}}<br />
<br />
= Property tree interface for modules.nas =<br />
In the property tree there is a subtree /nasal to control modules and get some statistics.<br />
The properties available depend on the type of module ("load-once" or "reloadable", see [[Nasal Initialization]] for more information on the differences).<br />
<br />
== Reloadable modules / frameworks ==<br />
Modules handled by modules.nas will have their properties in /nasal/modules/<moduleName> where <moduleName> is given by the developer when calling either <br />
{{code|Module.new("<moduleName>")}} or {{code|modules.load("<moduleName>")}}. <br />
In the latter case <moduleName> specifies the subdirectory FGDATA/Nasal/modules/<moduleName> in which some framework is stored.<br />
<br />
{| class="wikitable"<br />
|-<br />
! property !! type !! content<br />
|-<br />
| loaded || bool || true if module was loaded without errors<br />
|-<br />
| reload || bool || set this to true to trigger reload<br />
|-<br />
| listeners || int || Number of tracked listeners<br />
|-<br />
| listener-hits || int || If debugging is enabled, this prop shows the total number of hits to all tracked listeners.<br />
|-<br />
| timers || int || Number of tracked timers (maketimer).<br />
|}<br />
<br />
== Legacy load-once modules ==<br />
A legacy load-once module is a direct (1st level) subdirectory of FGDATA/Nasal/ and its corresponding property tree is /nasal/<moduleName>/ where <moduleName> equals the name of the subdirectory. <br />
It is handled by C++ code and must have a corresponding entry in FGDATA/defaults.xml which defines a property "enabled" and optionally a property "module".<br />
If enabled is set to false in defaults.xml, the C++ code will setup a listener and load the module as soon as enabled is set to true.<br />
The property name "module" is a bit misleading, it is used to define into which namespace the files shall be loaded.<br />
<br />
For each .nas file in the subdirectory a file[i] property is created holding the full path+filename.<br />
<br />
The bool "loaded" property shows the status of the module.<br />
<br />
= Existing modules with reload support =<br />
Stable Nasal frameworks which support reloading can be added to ''FGDATA/Nasal/modules/<module_name>''. <br />
This allows an aircraft developer to configure the framework for a specific aircraft and make use of the reload magic while developing the configuration.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Module name !! Desctiption !! time added <br />
|-<br />
| [[Canvas EFIS Framework|canvas_efis]] || framework to manage canvas based EFIS screens || 02/2020<br />
|}</div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=Antonov_An-24&diff=122173Antonov An-242020-03-14T12:00:53Z<p>Maerchenprinz: </p>
<hr />
<div>{{aero-stub}}<br />
{{:{{PAGENAME}}/info}}<br />
The '''Antonov An-24''' was basically built as regional airliner from 1959-1978 in the USSR. Having many variants, the An-24 also served, and serves, e.g. as transport, reconnaissance, fire fighter, or even as navigator training plane. It's derivatives, the An-26, An-30 and An-32 are used for military purposes.<br />
= The An-24B =<br />
In late 1957, Oleg Antonov and his design bureau were commissioned to develop, test and produce a 44-seat regional airliner. To not just fulfil these demands of the Council of Ministers, but also the requirements of soviet infrastructure of that time, the An-24's design features several special characteristics: Among these are high-mounted engines to avoid suction of dirt or dust from unprepared runways, the maingear being retracted into the engine nacelles for better aerodynamics and sophisticated navigational equipment for use in remote regions.<br />
In total, more than 1300 An-24 were built; In the 1970's no less than 30% of passenger transport in the USSR was in charge of the An-24 with the An-24B being one of the most used variants.<br />
<br />
= Development status/Issues =<br />
Under ongoing development; Most research done, mostly everything of importance exists as 3D-Model with animations, waiting to be filled with life<br />
<br />
= To-do =<br />
Model/Textures/Animations<br />
* Cockpit cabin: Correcting dimensions, making texture, adding details etc.<br />
* Airframe: Animations, lights, engine nacelles ("gear bulges"), cut-outs (doors, hatches), etc.<br />
<br />
Systems<br />
* Basic hydraulic system<br />
* Basic oil system<br />
* Water injection, PRT-24, fire warning and extinguishing, ice warning and de-icing, air conditioning etc.<br />
<br />
Instruments<br />
* Minor improvements on many instruments<br />
* Radio implementation (US-8 and R-836)<br />
<br />
Documentation<br />
* Expanding the manual<br />
* This Wiki-page<br />
<br />
== External links ==<br />
* [http://en.wikipedia.org/wiki/Antonov_An-24 Wikipedia]<br />
<br />
{{Antonov}}</div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=Antonov_An-24/info&diff=122172Antonov An-24/info2020-03-14T11:50:20Z<p>Maerchenprinz: </p>
<hr />
<div><includeonly>{{infobox aircraft<br />
| name = An-24B<br />
| hangar = fgaddon<br />
| aircraft = an24b<br />
| image = Antonov An-24B.png<br />
| type = Airliner<br />
| config = High wing aircraft<br />
| propulsion = Turboprop aircraft/Twin-engine aircraft<br />
| manufacturer = Antonov<br />
| authors = Michael Soitanen (FDM, Systems)/Adrian aka Maerchenprinz (3D, Systems)<br />
| fdm = JSBSim<br />
| fgname = an24b<br />
| status = Production<br />
| status-fdm = 5<br />
| status-systems = 4<br />
| status-cockpit = 4<br />
| status-model = 3<br />
|| navbar = 1<br />
}}</includeonly><noinclude><br />
This is the aircraft infobox subpage of the [[Antonov An-24]].<br />
[[Category:Aircraft infobox documentation]]<br />
</noinclude></div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=Antonov_An-24/info&diff=122169Antonov An-24/info2020-03-14T11:38:22Z<p>Maerchenprinz: removed link to abandoned personal repository</p>
<hr />
<div><includeonly>{{infobox aircraft<br />
| name = An-24B<br />
| hangar = fgaddon<br />
| aircraft = an24b<br />
| image = Antonov An-24B.png<br />
| type = Airliner<br />
| config = High wing aircraft<br />
| propulsion = Turboprop aircraft/Twin-engine aircraft<br />
| manufacturer = Antonov<br />
| authors = Michael Soitanen (FDM)/Adrian aka Maerchenprinz (Rest)<br />
| fdm = JSBSim<br />
| fgname = an24b<br />
| status = Production<br />
| status-fdm = 5<br />
| status-systems = 4<br />
| status-cockpit = 4<br />
| status-model = 3<br />
|| navbar = 1<br />
}}</includeonly><noinclude><br />
This is the aircraft infobox subpage of the [[Antonov An-24]].<br />
[[Category:Aircraft infobox documentation]]<br />
</noinclude></div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=Aircraft_checklists&diff=122136Aircraft checklists2020-03-13T21:47:46Z<p>Maerchenprinz: Note that <and> tags are needed</p>
<hr />
<div><br />
{{infobox subsystem<br />
|image =Aircraft Checklists dialog.jpg<br />
|name = Generic Aircraft Checklists<br />
|started= 03/2010 <br />
|description = Centralized checklist management<br />
|status = Under active development as of 05/2015<br />
|maintainers = {{usr|Stuart}}<br />
|developers = * {{usr|Stuart}}<br />
* {{usr|Sanhozay}}<br />
|changelog = * {{Git File History|project=flightgear|sub-project=fgdata|path=/Nasal/checklist.nas}}<br />
* {{Git File History|project=flightgear|sub-project=fgdata|path=/gui/dialogs/checklist.xml}}<br />
* {{Git File History|project=flightgear|sub-project=fgdata|path=/Aircraft/Generic/autochecklist.nas}}<br />
}}<br />
<br />
{{Startup}}<br />
{{Checklists}}<br />
<br />
<br />
As of version 2.9, [[FlightGear]] can display '''aircraft checklists''' in a standardized way, under Help > Aircraft Checklists. <br />
<br />
== Adding checklists ==<br />
To learn more about creating custom checklists, see {{readme file|checklists}} and the [[Cessna 172P]] as the reference implementation. Increasingly, the [[tutorials]] system is also extended such that it may make use of aircraft checklists.<br />
<br />
Checklists are situated under <tt>/sim/checklists</tt>. As the checklists may be quite long, it is recommended that they are put in a separate file using the following entry in the <tt>-set.xml</tt> file of the aircraft:<br />
<br />
<syntaxhighlight lang="xml"><br />
<checklists include="c172-checklists.xml"/><br />
</syntaxhighlight><br />
<br />
Each individual checklist is created under a <checklist> XML tag, with the following sub-properties:<br />
<br />
* <code><title></code> The name of the checklist<br />
* <code><page></code> One or more pages from the checklist, containing one or more of the following:<br />
** <code><item></code> A checklist item, containing<br />
*** <code><name></code> The item name, to appear on the left hand side of the checklist<br />
*** <code><value></code> One or more values, to appear on the right hand side of the checklist. Second and and subsequent <value> tags are displayed underneath each other. It is recommended that the <value> tags are kept short, to minimize the size of the displayed checklist.<br />
*** <code><condition></code> An optional [[Howto:Animate models#Conditions|condition node]] that evaluates when the checklist item is complete. Incomplete checklist items are shown in yellow, while completed items are shown in green (NOTE: When more than one condition has to be met, the use of <and></and> is mandatory to make this work).<br />
*** <code><marker></code> An optional marker node that is used to display a circle around a control when the user clicks a "?" button next to the item. This contains <x-m>, <y-m>, <z-m> and <scale> sub-elements and uses the [[Tutorials#Marker|tutorial marker]]. Note that this requires the marker model to be included in the aircraft model, as explained in the aforementioned article. <br />
*** <code><binding></code> Zero or more XML bindings that are used by the simulator to execute the checklist item if the user clicks on a ">" button next to the item.<br />
<br />
For simple checklists the <page> element can be omitted and <item> entries placed directly under the <checklist>.<br />
<br />
The following example shows a simple checklists XML file:<br />
<br />
<syntaxhighlight lang="xml"><br />
<PropertyList><br />
<checklist><br />
<title>After Landing</title> <br />
<item><br />
<name>Carburetor Heat</name><br />
<value>COLD</value><br />
<condition><br />
<equals><br />
<property>/controls/anti-ice/engine[0]/carb-heat</property><br />
<value>0</value><br />
</equals><br />
</condition><br />
<marker><br />
<x-m>-0.3225</x-m><br />
<y-m>-0.0850</y-m><br />
<z-m>-0.2117</z-m><br />
<scale>2.0500</scale><br />
</marker> <br />
<binding><br />
<command>property-assign</command><br />
<value>0</value><br />
</binding><br />
</item><br />
<item><br />
<name>Wing Flaps</name><br />
<value>UP</value><br />
</item><br />
</checklist><br />
<checklist><br />
<title>Getting hamburger</title><br />
<page><br />
<item><br />
...<br />
</item><br />
</page><br />
</checklist><br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
See the Cessna 172P for an example of how this all fits together.<br />
<br />
=== Bindings ===<br />
[[File:C172p-checklist-via-pui.png|thumb|FlightGear [[Aircraft Checklists]] [[PUI]] dialog]]<br />
One or more [[Bindings|binding elements]] can be added to a checklist item. Conceptually, these are the actions that the user should execute to complete the item. The checklist GUI displays items with such <binding> elements with an additional [>] button. Clicking on the button executes the bindings, allowing the user to watch as the computer/co-pilot/instructor executes the checklist item.<br />
<br />
The <binding> element is exactly as you would expect - so property-assign, nasal etc. works.<br />
<br />
The plan is to extend this function so that checklists with one or more items containing a <binding> element can have an (optional) button<br />
to execute the entire checklist.<br />
<br />
=== Grouping Checklists ===<br />
<br />
Checklists can optionally be grouped together under a <group> node in the property tree, with each group given a descriptive name. For example:<br />
<br />
<group><br />
<name>Emergency</name><br />
<checklist>...<br />
<checklist>...<br />
</group><br />
<group><br />
<name>Ground</name><br />
<checklist>...<br />
<checklist>...<br />
</group><br />
<br />
This is supported within the Checklist dialog, and also by the FG1000.<br />
<br />
== Reloading checklists ==<br />
Cut and paste this little code snippet in the [[Nasal Console]] and excecute it:<br />
<br />
<syntaxhighlight lang="nasal"><br />
var reload_checklist = func(filename) {<br />
var checklist_path=sprintf("%s/%s",getprop("/sim/aircraft-dir"),filename);<br />
var data = io.read_properties(checklist_path,"/sim/checklists");<br />
}<br />
<br />
reload_checklist(filename: "777-200-checklists.xml");<br />
</syntaxhighlight><br />
<br />
Change the filename to the name of the file you are editing. Make sure to monitor the startup window and/or the [[Nasal Console]] loglist widget for any XML related warnings (e.g. parsing errors).<br />
<br />
== Automated checklist execution ==<br />
<br />
As of version 3.5, [[FlightGear]] can automate the execution of various sequences of aircraft checklists using the <tt>autochecklist.nas</tt> script in <tt>$FGDATA/Aircraft/Generic</tt>. The advantage of this approach is that the checklist files become the source of checklists, tutorials and autostart; if the checklists change, so does the autostart (see {{Wikipedia|Don't repeat yourself}}). <br />
<br />
The <tt>autochecklist.nas</tt> script can be used to create an autostart menu but is not restricted to autostart; any checklist sequence can be run from any piece of Nasal code.<br />
<br />
Automated checklists may not work for more complex aircraft startup sequences, but they are so easy to set up that it's worth trying alongside the development of the aircraft startup process. If it works, great! If it doesn't, you haven't wasted your time because you have at least made a start on your checklists.<br />
<br />
=== Background ===<br />
<br />
The <tt>autochecklist.nas</tt> script relies on the aircraft having a set of checklists that have complete sets of [[Bindings|bindings]] to take the aircraft from one state to another. For autostart, for example, you need to be able to start the aircraft solely by pressing the binding buttons on the right side of the checklist.<br />
<br />
Using the script is a simple three step process involving a few lines of XML and as little as one line of [[Nasal]] code:<br />
<br />
# Add the script to your aircraft<br />
# Define one or more named checklist sequences<br />
# Call the script to execute a checklist sequence <br />
<br />
For example, you could define a sequence called "startup" that runs the sequence of checklists: "Before Starting Engines" and "Start Engines". Calling the <tt>autochecklist.nas</tt> script from a menu item binding with "startup" as the argument creates an autostart menu.<br />
<br />
When you invoke the <tt>autochecklist</tt> script, it executes the checklists defined in the named sequence in the order that they are listed. Starting with the first item in the first checklist, it checks the {{readme file|conditions}} associated with the checklist item. If false, it runs the binding. It then moves onto the next item and checks if the condition from the previous item has been satisfied. If it is still false, it waits for a number of seconds -- maybe the binding was interpolated or the condition is waiting for something to start, e.g. APU spooling up. Once the condition from the previous item is satisfied, it looks at the condition on the current item and runs the binding if the condition is false. Execution continues like this until all checklist items have their bindings satisfied.<br />
<br />
In some cases, e.g. checks on maximum takeoff weight, bindings will never cause the condition to be satisfied. To cover these cases, the script will consider the checklist to have failed if the condition associated with a checklist item does not become true within a timeout period. In these cases, the pilot needs to review the checklist manually and work out why the aircraft will not start. Once the condition has been corrected, e.g. they removed some fuel or payload to get below MTOW, the checklists can be executed again and should be successful. Because the script checks the condition of each item before running the binding, the automated execution is re-entrant; it just picks up where it left off and does only what needs to be done.<br />
<br />
=== Add the script ===<br />
<br />
Add <tt>autochecklist.nas</tt> to the aircraft's <tt>-set.xml</tt> file (or equivalent):<br />
<br />
<syntaxhighlight lang="xml"><br />
<nasal><br />
...<br />
<autochecklist><br />
<file>Aircraft/Generic/autochecklist.nas</file><br />
</autochecklist><br />
</nasal><br />
</syntaxhighlight><br />
<br />
=== Define checklist sequences ===<br />
<br />
In the aircraft's <tt>-set.xml</tt> file, create one or more named checklist sequences that specify ordered lists of checklists to execute. The names can be anything you like as long as they are valid XML tags. The names are never displayed within the simulator.<br />
<br />
For example, to run checklists with indexes 0 and 1 for startup and checklist 9 for shutdown:<br />
<br />
<syntaxhighlight lang="xml"><br />
<sim><br />
<checklists><br />
<checklist include="Checklists/before-starting-engines.xml"/><br />
<checklist include="Checklists/start-engines.xml"/><br />
<!-- Other checklists here with indexes 2 to 8 ... --><br />
<checklist include="Checklists/parking.xml"/><br />
<startup><br />
<index n="0">0</index> <!-- Before starting engines --><br />
<index n="1">1</index> <!-- Start engines --><br />
</startup><br />
<shutdown><br />
<index n="0">9</index> <!-- Parking --><br />
</shutdown><br />
</checklists><br />
</sim><br />
</syntaxhighlight><br />
<br />
=== Execute the checklist sequence ===<br />
<br />
For the typical usage of autostart, add a Nasal binding as a menu item and execute the named checklist sequence:<br />
<br />
<syntaxhighlight lang="xml"><br />
<item><br />
<label>Autostart</label><br />
<binding><br />
<command>nasal</command><br />
<script>autochecklist.complete_checklists("startup");</script><br />
</binding><br />
</item><br />
</syntaxhighlight><br />
<br />
Obviously, additional logic can be included in the binding if you want the autostart menu to toggle between autostart and shutdown.<br />
<br />
==== Fine tuning checklist bindings ====<br />
<br />
Sometimes, a checklist binding will do something like display a dialog, e.g. fuel and payload dialog. It would be irritating to the pilot if these things happened during automated execution. These bindings can make use of the <code>sim/checklists/auto/active</code> property, which will be <tt>true</tt> when the checklist binding is being run by the autochecklist script and <tt>false</tt> otherwise.<br />
<br />
<syntaxhighlight lang="xml"><br />
<binding><br />
<command>nasal</command><br />
<script><br />
var auto = getprop("sim/checklists/auto/active");<br />
if (!auto) gui.showWeightDialog();<br />
</script><br />
</binding><br />
</syntaxhighlight><br />
<br />
==== Expedited checklists ====<br />
<br />
For in-air start sequences in some aircraft, you can pass zero as the second argument of the <tt>complete_checklists</tt> function to expedite the sequence. All items in the checklist sequence will be executed without waiting for previous items to complete. Note that this means the checklist sequence is never considered to have failed.<br />
<br />
<syntaxhighlight lang="nasal"><br />
if (!getprop("gear/gear/wow")) {<br />
autochecklist.complete_checklists(sequence: "in-air-start", wait: 0);<br />
} else {<br />
autochecklist.complete_checklists("ground-start");<br />
}<br />
</syntaxhighlight><br />
<br />
Clearly the checklist sequence used for in-air start should be different from a ground start and should put the aircraft into a flying state, e.g. gear up, flaps up. Bindings can use the property <code>sim/checklists/auto/expedited</code> to check if the execution is expedited, i.e. there is no wait between items. Note that the expedited flag does not in itself indicate whether a binding is being run as part of an automated checklist. You may need to test both the <code>sim/checklists/auto/active</code> and <code>sim/checklists/auto/expedited</code> properties, e.g.<br />
<br />
<syntaxhighlight lang="nasal"><br />
var auto = getprop("sim/checklists/auto/active");<br />
var expedited = getprop("sim/checklists/auto/expedited");<br />
<br />
if (auto and expedited) {<br />
...<br />
}<br />
</syntaxhighlight><br />
<br />
=== Customizing execution (optional) ===<br />
<br />
The behavior of the <tt>autochecklist.nas</tt> script can be customized by setting properties, either in the aircraft's <tt>-set.xml</tt> file or at runtime. Configuration is under the <tt>sim/checklists/auto</tt> node.<br />
<br />
<syntaxhighlight lang="xml"><br />
<sim><br />
<checklists><br />
...<br />
<auto><br />
<startup-message>Running checklists, please wait ...</startup-message><br />
<completed-message>Checklists complete.</completed-message><br />
<timeout-message>Some checks failed.</timeout-message><br />
<timeout-sec>10</timeout-sec><br />
<wait-sec>3</wait-sec><br />
<auto><br />
</checklists><br />
</sim><br />
</syntaxhighlight><br />
<br />
* <code>startup-message</code> message displayed prior to automated checklist execution<br />
* <code>completed-message</code> message displayed on successful completion of the checklist<br />
* <code>timeout-message</code> message displayed if checklist execution times out waiting for a checklist condition to be satisfied<br />
* <code>timeout-sec</code> if the previous condition is not satisfied within this timeout, the automated execution fails<br />
* <code>wait-sec</code> time to wait before re-checking the status of the previous item if its condition is false after running the binding (effectively a polling interval).<br />
<br />
Messages are displayed as copilot announcements (by setting <tt>sim/messages/copilot</tt>). They can be set empty if messages are not required. Note that messages are never displayed for expedited starts.<br />
<br />
Care should be taken with the timeout value. This is the timeout for a single item waiting for the previous condition to be satisfied, not the overall timeout for the checklist sequence. If the timeout is set to a large value and conditions cannot be satisfied, the pilot will have to wait a long time for the failure message to appear.<br />
<br />
=== Other features and ideas ===<br />
<br />
Automated checklist execution is not restricted to autostart and shutdown. If you have an "After Landing" checklist that switches landing lights off, raises flaps and turns taxi lights on, for example, you could assign that to a keyboard shortcut. Rollout and taxi is a busy time on some aircraft and it's often not easy to find the switches and controls necessary to complete this kind of checklist.<br />
<br />
To use the <tt>autochecklist.nas</tt> script, pilots need <tt>FGDATA</tt> v3.5 or greater, otherwise the script will not be available. The availability of automated checklists can be tested by checking whether the <tt>sim/checklists/auto</tt> node is nil and a suitable indication given to the pilot if it is nil.<br />
<br />
For an example of using automated checklists, refer to the [[Lockheed Constellation]], for which the script was originally written.<br />
<br />
== Development ==<br />
the docs for this particular feature are to be found in {{readme file|checklists}}.<br />
This is also where you can read that the c172p is considered the reference implementation.<br />
The system itself is located in {{fgdata source|path=gui/dialogs/checklist.xml|line=18|pre=$FG_ROOT|post=(embedded Nasal)}}, but -at least for now- that should not matter to you - unless you want to extend the system to add support for new features (in which case, you'll also want to check out $FG_ROOT/Nasal/checklist.nas).<br />
Whatever is added to the Nasal code should never be aircraft-specific - aircraft specific stuff needs to be expressed via your own XML files - if something is missing, just extend the Nasal file, or ask for help so that we can post some pointers/snippets.<br />
<ref> {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=218209#p218209<br />
| title = <nowiki>Re: </nowiki><br />
| author = <nowiki>Hooray</nowiki><br />
| date = Sep 11th, 2014<br />
| added = Sep 11th, 2014<br />
| script_version = 0.25<br />
}}<br />
</ref><br />
<br />
it would be a good idea to localie any custom Nasal blocks, and instead introduce custom fgcommands using the addcommand() API - basically the reason being that there could be an aircraft-specific API using fgcommands for starting engines, instead of having aircraft-specific "Nasal blobs" in each checklist file. A while ago, this was actually discussed on the devel list, too. In other words, an "fgcommand" (implemented in Nasal) would help better isolate checklists from aircraft specifics.<br />
<ref> {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=241259#p241259<br />
| title = <nowiki>Re: Automated Checklist Execution</nowiki><br />
| author = <nowiki>Hooray</nowiki><br />
| date = May 1st, 2015<br />
| added = May 1st, 2015<br />
| script_version = 0.25<br />
}}<br />
</ref><br />
<br />
== Checklist Generation Language ==<br />
<br />
Forum user sanhozay has created a custom language called [https://github.com/sanhozay/CLGen CLGen] for generating checklists.<br />
<br />
The main benefits to be gained from using CLGen are:<br />
<br />
* More compact Nasal-like syntax that is easier to work with than XML<br />
* Re-use of item definitions means source code is around 20-25% of the equivalent hand-written XML<br />
* PDF and Graphviz DOT views of the checklists to aid prototyping<br />
* Type checking and code generation means less debugging of checklists in Flightgear<br />
<br />
Creating checklists with CLGen can be as simple as:<br />
<br />
<pre><br />
checklist("Startup") {<br />
check("Parking Brake", "ON");<br />
check("Navigation Lights", "ON");<br />
check("Beacon", "OFF");<br />
}</pre><br />
<br />
CLGen supports conditions expressed in Nasal-like syntax, bindings, fgcommands, markers and automated inclusion of copyright headers. It is also possible, with some restrictions, to reverse-engineer existing checklists into CLGen source format and to generate PDF and Graphviz DOT representations of existing checklists.<br />
<br />
[[File:CLGen DOT File.png|500px|Example of an image created from CLGen's DOT file output.]]<br />
[[File:CLGen PDF Output.png|300px|Example of a PDF file created from CLGen.]]<br />
<br />
CLGen is written in Java and runs on Mac OS, Linux and Windows platforms with a Java 8 runtime.<br />
<br />
For more information, including a step-by-step Wiki tutorial, visit the [https://github.com/sanhozay/CLGen CLGen project on Github]<br />
<br />
== External link ==<br />
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38325.html Aircraft Checklists] (mailing list)<br />
* [https://sourceforge.net/p/flightgear/mailman/message/33904555/ Automated Checklist Execution] (mailing list)<br />
* [https://forum.flightgear.org/viewtopic.php?f=4&t=32180&p=310216#p310216 CLGen Release Announcement] (forum)<br />
<br />
[[Category:Aircraft enhancement]]</div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=Antonov_An-24&diff=117355Antonov An-242019-02-14T13:37:35Z<p>Maerchenprinz: </p>
<hr />
<div>{{aero-stub}}<br />
{{:{{PAGENAME}}/info}}<br />
The '''Antonov An-24''' was basically built as regional airliner from 1959-1978 in the USSR. Having many variants, the An-24 also served, and serves, e.g. as transport, reconnaissance, fire fighter, or even as navigator training plane. It's derivatives, the An-26, An-30 and An-32 are used for military purposes.<br />
= The An-24B =<br />
In late 1957, Oleg Antonov and his design bureau were commissioned to develop, test and produce a 44-seat regional airliner. To not just fulfil these demands of the Council of Ministers, but also the requirements of soviet infrastructure of that time, the An-24's design features several special characteristics: Among these are high-mounted engines to avoid suction of dirt or dust from unprepared runways, the maingear being retracted into the engine nacelles for better aerodynamics and sophisticated navigational equipment for use in remote regions.<br />
In total, more than 1300 An-24 were built; In the 1970's no less than 30% of passenger transport in the USSR was in charge of the An-24 with the An-24B being one of the most used variants.<br />
<br />
= Development status/Issues =<br />
Under ongoing development; Most research done, mostly everything of importance exists as 3D-Model with animations, waiting to be filled with life<br />
<br />
= To-do =<br />
Model/Textures/Animations<br />
* Cockpit cabin: correcting dimensions, making texture, adding details etc.<br />
* Airframe: correcting dimensions of forward section, engine nacelles ("gear bulges"), cut-outs (doors, hatches), etc.<br />
<br />
Systems<br />
* Advanced electrical system<br />
* Basic hydraulic system<br />
* Basic oil system<br />
* Water injection, PRT-24, fire warning and extinguishing, ice warning and de-icing, feathering system, etc.<br />
<br />
Instruments<br />
* Minor improvements on many instruments<br />
* Radio implementation (US-8 and R-836)<br />
<br />
Documentation<br />
* Expanding the manual<br />
* This Wiki-page<br />
<br />
== External links ==<br />
* [http://en.wikipedia.org/wiki/Antonov_An-24 Wikipedia]<br />
* [http://www.flightgear.ru/forum/viewtopic.php?f=9&t=515 Russian development topic]<br />
<br />
{{Antonov}}</div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=Antonov_An-24/info&diff=117354Antonov An-24/info2019-02-14T13:35:48Z<p>Maerchenprinz: From early to production</p>
<hr />
<div><includeonly>{{infobox aircraft<br />
| name = An-24B<br />
| hangar = fgaddon<br />
| aircraft = an24b<br />
| image = Antonov An-24B.png<br />
| type = Airliner<br />
| config = High wing aircraft<br />
| propulsion = Turboprop aircraft/Twin-engine aircraft<br />
| manufacturer = Antonov<br />
| authors = Michael Soitanen (FDM)/Adrian aka Maerchenprinz (Rest)<br />
| fdm = JSBSim<br />
| fgname = an24b<br />
| status = Production<br />
| status-fdm = 5<br />
| status-systems = 4<br />
| status-cockpit = 4<br />
| status-model = 3<br />
| devel-repo = {{github url|user=maerchenprinz|repo=an24b}}<br />
| navbar = 1<br />
}}</includeonly><noinclude><br />
This is the aircraft infobox subpage of the [[Antonov An-24]].<br />
[[Category:Aircraft infobox documentation]]<br />
</noinclude></div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=Antonov_An-24/info&diff=115835Antonov An-24/info2018-08-10T15:08:09Z<p>Maerchenprinz: Rating included</p>
<hr />
<div><includeonly>{{infobox aircraft<br />
| name = An-24B<br />
| hangar = fgaddon<br />
| aircraft = an24b<br />
| image = Antonov An-24B.png<br />
| type = Airliner<br />
| config = High wing aircraft<br />
| propulsion = Turboprop aircraft/Twin-engine aircraft<br />
| manufacturer = Antonov<br />
| authors = Michael Soitanen (FDM)/Adrian (3D)<br />
| fdm = JSBSim<br />
| fgname = an24b<br />
| status = Early production<br />
| status-fdm = 5<br />
| status-systems = 3<br />
| status-cockpit = 4<br />
| status-model = 3<br />
| devel-repo = {{github url|user=maerchenprinz|repo=an24b}}<br />
| navbar = 1<br />
}}</includeonly><noinclude><br />
This is the aircraft infobox subpage of the [[Antonov An-24]].<br />
[[Category:Aircraft infobox documentation]]<br />
</noinclude></div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=Antonov_An-24&diff=115419Antonov An-242018-06-08T10:01:43Z<p>Maerchenprinz: First add of content (History/Summary and Todo)</p>
<hr />
<div>{{aero-stub}}<br />
{{:{{PAGENAME}}/info}}<br />
The '''Antonov An-24''' was basically built as regional airliner from 1959-1978 in the USSR. Having many variants, the An-24 also served, and serves, e.g. as transport, reconnaissance, fire fighter, or even as navigator training plane. It's derivatives, the An-26, An-30 and An-32 are used for military purposes.<br />
= The An-24B =<br />
In late 1957, Oleg Antonov and his design bureau were commissioned to develop, test and produce a 44-seat regional airliner. To not just fulfil these demands of the Council of Ministers, but also the requirements of soviet infrastructure of that time, the An-24's design features several special characteristics: Among these are high-mounted engines to avoid suction of dirt or dust from unprepared runways, the maingear being retracted into the engine nacelles for better aerodynamics and sophisticated navigational equipment for use in remote regions.<br />
In total, more than 1300 An-24 were built; In the 1970's no less than 30% of passenger transport in the USSR was in charge of the An-24 with the An-24B being one of the most used variants.<br />
<br />
= Development status/Issues =<br />
Under ongoing development; Most research done, mostly everything of importance exists as 3D-Model with animations, waiting to be filled with life<br />
<br />
= To-do =<br />
Model/Textures/Animations<br />
* Cockpit cabin: correcting dimensions, making texture, adding details etc.<br />
* Airframe: correcting dimensions of forward section, engine nacelles ("gear bulges"), cut-outs (doors, hatches), etc.<br />
<br />
Systems<br />
* Basic electrical system<br />
* Basic hydraulic system<br />
* Basic oil system<br />
* Water injection, PRT-24, fire warning and extinguishing, ice warning and de-icing, feathering system, etc.<br />
<br />
Instruments<br />
* Minor improvements on many instruments<br />
* Radio implementation (US-8 and R-836)<br />
<br />
Documentation<br />
* Expanding the manual<br />
* This Wiki-page<br />
<br />
== External links ==<br />
* [http://en.wikipedia.org/wiki/Antonov_An-24 Wikipedia]<br />
* [http://www.flightgear.ru/forum/viewtopic.php?f=9&t=515 Russian development topic]<br />
<br />
{{Antonov}}</div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=De/Avionics_and_Instruments&diff=20583De/Avionics and Instruments2010-03-30T12:14:22Z<p>Maerchenprinz: </p>
<hr />
<div>= Kompasse =<br />
<br />
In der Fliegerei werden zwei unterschiedliche Kompassarten verwendet:<br />
* der '''Magnetkompass'''<br />
* der '''Kurskreisel'''<br />
<br />
== Magnetkompass ==<br />
Der '''Magnetkompass''' richtet sich nach dem magnetischem Feld aus, das die Erde umgibt.<br />
<br />
Zu beachten ist dabei, dass sich der magnetische und der geografische Nordpol NICHT an der gleichen Stelle befinden. Die Differenz zwischen magnetischer Feldausrichtung (Kompassnadel) und Ausrichtung auf den geografischen Nordpol (''wahres Nord'' oder engl. ''true north'') heisst ''magnetische Variation'', abgekürzt mit ''VAR'' oder ''MV''. Je nach Ort, an dem man sich befindet, ist die magnetische Variation unterschiedlich; ebenso ändert sie sich mit der Zeit, da die magnetischen Pole wandern.<br />
<br />
Wenn man einen Flugplan macht, sollte man die ''magnetische Variation'' entlang der Flugroute kennen. In der Luftnavigation bedient man sich der magnetischen Ausrichtung: Auf Flugkarten ist alles als magnetische Ausrichtung verzeichnet, VOR-Stationen zeigen nach magnetisch Nord, auch Landebahnen bekommen ihren Namen nach ihrer magnetischen Richtung. So hat zum Beispiel die Landebahn 10L am Flughafen San Francisco, KSFO, die magnetische Richtung 100, wahre Ausrichtung ist aber ca. 115 Grad. Sogar GPS-Geräte für Luftnavigation zeigen magnetische Richtungswerte an, obwohl sie die wahren Richtungswerte kennen.<br />
<br />
Angegeben wird die magnetische Variation in ''Grad Ost'' oder ''Grad West'' (engl. ''degrees east'' bzw. ''degrees west''), auf Luftkarten oft geschrieben als z.B. "MV 15′E" oder "MV +15′", dabei ist + Ost, - West.<br />
<br />
Nur die Windrichtung vom METAR wird als wahrer Richtungswert gemeldet, was bei der Berechnung des Winddreiecks wichtig ist:<br />
Fliegt man zum Beispiel die Landebahn 10 vom Flughafen KSFO mit Kompassweisung 100 Grad an und bekommt die Windmeldung "aus 100 Grad mit 12 Knoten", so hat man nicht einen schönen Gegenwind, sondern einen ordentlichen Seitenwind von vorne links (etwa -15 Grad zur Landebahn).<br />
Auch bei der Flugroute muss die magnetische Variation mit einberechnet werden: Eine Linie auf der Landkarte von San Francisco nach Seattle zeigt exakt nach Norden; Folgte man aber ab dem Start vom KSFO einfach der Kompassanzeige ''360′ Nord'', fände die Landung zum Missfallen der Passagiere etwa 200 Meilen östlich in Spokane anstatt in Seattle statt.<br />
<br />
In der Praxis gibt es unterschiedliche Herangehensweisen, um mit dieser Missweisung des Magnetkompasses umzugehen: Zum einen kann man die Kompassrose oder andere richtungsweisende Instrumente so einstellen, dass sie "wahres Norden" anzeigen, zum anderen kann man die magnetische Variation in seinen angezeigten Kurs mit einbeziehen.<br />
Welche dieser beiden Herangehensweisen am praktischten ist, hängt von der Flugroute, der Instrumentierung des Flugzeuges und von den Präferenzen des Piloten ab, und kann auf den verschiedenen Abschnitten eines Fluges wechseln; Wichtig ist nur, sich immer bewusst zu sein, was die Instrumente gerade anzeigen und ob der Flugplan magnetischen oder wahren Kurs beschreibt. Ebenso sollte man wissen, welche Referenz die verschiedene Systeme des Flugzeugs, wie z.B. der Autopilot, verwenden.<br />
<br />
Findet man keine Karte, auf der die magnetische Variation des Abflug- oder Zielflughafens verzeichnet ist, hat man bei FlightGear zwei Möglichichkeiten, sie herauszufinden. Erstens kann man sie unter File-> Browse Internal Properties-> /environment/magnetic-variation-deg überprüfen, zweitens kann man folgendes Shell-Script verwenden:<br />
<br />
#!/bin/bash<br />
if [ $# -ne 2 ]; then<br />
echo "Usage: $(basename $0) lat long";<br />
echo "East and north are positive.";<br />
else<br />
testmagvar $1 $2 0 $(date +"%m %d %g")|tail -1|tr -s [:space:] \\t|cut -f6;<br />
fi<br />
<br />
Ein guter Pilot weiss aber immmer schon vorher, welche MV ihn erwartet! Und wir sind doch natürlich alle gute Piloten, oder nicht?<br />
<br />
== Kurskreisel ==<br />
[[Image:Directional-gyro.png|Gyro of default Cesna|right]]<br />
<br />
Der '''Kurskreisel''' (engl. ''directional gyro'' oder ''heading indicator'') dient, ebenso wie der ''Magnetkompass'', zur Richtungsanzeige. Er weiss allerdings nichts über einen magnetischen oder geografischen Nordpol, sondern arbeitet, vereinfacht gesagt, rein nach dem Trägheitsprinzip.<br />
<br />
Aus dem Schulunterricht ist den meisten das Experiment bekannt, bei dem jemand das abmontierte Rad eines Fahrrads an der Achse in den Händen hält; dreht sich das Rad nicht, ist es sehr leicht, es herumzuschwenken, dreht man es doch, ist es sehr schwer, seine Richtung zu ändern.<br />
Im Kurskreisel befindet sich also (mindestens) eine im Vakuum frei aufgehängte, möglichst schwere Scheibe, die von einem Elektromotor möglichst schnell gedreht wird. Diese Scheibe "wehrt" sich gegen jede Richtungsänderung des Flugzeugs und bleibt in der Richtung, in der sie initiiert wurde.<br />
<br />
Will man den Kurskreisel benutzen, muss man ihn zuerst mit dem Magnetkompass abgleichen; in den meisten Flugzeugen ist der Kurskreisel aber schon mit dem Magnetkompass verbunden, so dass er bei der Initiierung mit ihm abgeglichen wird, oder während des gesamten Fluges dem Magnetkompass folgt.<br />
Der Grund, warum der Kurskreisel ein wichtiges Instrument ist, auch wenn er dem Magnetkompass folgt, ist der, dass der Kurskreisel in bestimmten Situationen zur Richtungsmessung besser geeignet ist:<br />
Bei längeren Kurven, wie z.B. der oft gefragten halben ''Standardkurve'' (engl. ''standard turn'') von 180′ hängt die Anzeige des Magnetkompasses hinterher oder geht vor, und die Neigung des Flugzeugs, und mit ihm die des Magnetkompasses, bringt ihn zu fehlerhaften Messungen. Ebenso ist im Gegensatz zum Magnetkompass der Kurskreisel nicht anfällig für plötzliche Änderungen des Magnetfeldes, wie sie etwa bei der Annäherung an Gebiete mit starken Funksendern oder magnetischen Mineralien auftreten.<br />
Deswegen nehmen Navigationssysteme oder Autopiloten normalerweise den Kurskreisel und nicht den Magnetkompass als primäre Referenz.<br />
<br />
Mit zunehmender Flugzeit wird aber auch der Kurskreisel ungenau, weshalb er auch nachjustiert werden muss. Weiterer Nachteil des Kurskreisels ist seine Abhängigkeit von einer Strom- und Vakuumquelle; Fällt eine von beiden aus, verliert ein Kurskreisel sehr langsam seine Richtung, was es dem Piloten sehr schwer macht, den Fehler zu entdecken. Bei starken Turbulenzen oder heftigen Flugmanövern zeigt der Kurskreisel oft sprunghafte Werte an. <br />
<br />
In einigen grösseren Flugzeugen kann man wählen, welches Kompasssystem sich nach dem anderen richtet; Das bestimmende wird als "Master-", das folgende als "Slave-" bezeichnet. <br />
<br />
Anmerkung: Die Begriffe ''Gyrokompass'' und ''Gyroskop'' werden fälschlicherweise oft synonym für 'Kurskreisel' verwendet, werden aber innerhalb der Fliegergemeinschaft als Begriff für 'Kurskreisel' normalerweise nicht missverstanden. <br />
<br />
= Höhenmesser =<br />
[[Image:Altimeter.png|right|Altmeter of default Cesna]]<br />
<br />
Per Definition ist ein '''Höhenmesser''' , (meistens "'''Altimeter'''" genannt) , ein Instrument, das die Höhe über einer festgelegten Ebene misst.<br />
<br />
Diese, sehr technisch gesprochene "festgelegte Ebene" ist in der Luftfahrt in der Regel der mittlere Meeresspiegel (''MSL'', von engl. ''mean sea level'') oder die Bodenhöhe unter dem Flugzeug (''GL'', von engl. ''ground level'').<br />
<br />
== Messung per Luftdruck ==<br />
Als Flieger wird man am häufigsten mit der Höhe "feet ASL", (engl. ''feet above sea level'') also ''Fuss über Meeresspiegel'' konfrontiert. Diese Höhe wird immer mit Hilfe des umgebenden Luftdrucks gemessen, ausser bei GPS. GPS-Höhenangaben sollten aber höchstens nur als Kontrolle verwendet werden, weil: '''Das Bezugssystem für die Höhe in der Luftfahrt ist der Luftdruck.'''<br />
<br />
Internationale Einheit für die Flughöhe ist, bis auf wenige Ausnahmen, ''Fuss'' bzw. ''feet'', abgekürzt ''ft''.<br />
Ein ''feet'' entspricht 30.48cm, über den krummen Daumen gepeilt kann man also rechnen: "Feet durch 3 und etwas weniger = Meter "<br />
<br />
Da der Luftdruck variiert, muss der Höhenmesser justiert werden. Dazu stellt man den Luftdruckwähler des Altimeters auf den Wert ein, den man vom ATIS oder vom Tower durchgesagt bekommen hat. An einem müssigen Sommerabend, oder wenn der Flugplatz keinen Tower oder ATIS besitzt, kann man vor dem Start aber auch den Luftdruckwähler soweit drehen, bis der Höhenmesser die Höhe des Plugplatzes (die man natürlich kennt!) anzeigt.<br />
<br />
Ab einer gewissen Höhe, der ''Übergangshöhe'' (engl. ''transition level''), wird am Höhenmesser der sogenannte "Normaldruck" von 29.92 inHG eingestellt. Damit erreicht man, dass alle Flugzeuge den gleichen Bezugswert haben; Soll zum Beispiel ein Flugzeug in einem Hochdruckgebiet die Höhe 12000ft, ein anderes 13000ft halten, fliegt das eine vielleicht auf 12500ft, das andere auf 13500ft. Da beide Piloten aber auf ihrem Höhenmesser mit eingestelltem 29.92inHG Luftdruck die ihnen jeweils zugewiesene Flughöhe lesen, können beide mit 1000ft Höhenunterschied ihren Weg kreuzen, ohne zu kollidieren. Würde jeder Pilot den Luftdruck seines Startflugplatzes beibehalten, gäbe es am Himmel ein buntes Allerlei an Interpretationen der richtigen Flughöhe.<br />
Die Standard-Übergangshöhe ist je nach Land unterschiedlich, findet sich aber oft auf Flugkarten bzw. wird vom Tower festgelegt und durchgegeben.<br />
<br />
== Messung per Radar ==<br />
Der '''Radarhöhenmesser''' (engl. ''''radio altimeter'''') misst die Flughöhe uber Grund, also AGL (engl. ''above ground level''), in dem er das Echo seiner abgestrahlten Radarwellen interpretiert. Verwendet wird er im militärischen Bereich (Stichwort Tiefflug) und bei präzisen Instrumentenlandungen.<br />
<br />
<br />
= Künstlicher Horizont =<br />
<br />
[[Image:Artificial-horizon.png|right|Künstlicher Horizont einer Cessna]]<br />
<br />
<br />
Der '''künstliche Horizont''' (engl. '''artificial horizon''' oder gebräuchlicher '''attitude indicator''', abgekürzt '''ai'''), zeigt die Lage des Flugzeugs, wie der Name schon sagt, anhand eines künstlichen Horizontes an. Die Anzeige ist unterteilt in "Himmel" (normalerweise blau) und "Boden" (normalerweise braun), dazu gesellt sich mittig eine stilisierte Darstellung des Flugzeug von hinten.<br />
<br />
Anhand des künstlichen Horizontes kann man als Pilot die Fluglage seines Fugzeugs ablesen, ohne den natürlichen Horizont zu sehen.<br />
<br />
Prinzipiell kann man sich vorstellen, die Horizontanzeige sei eine Kugel, hätte ein Gewicht unter sich angebracht, und bleibe deswegen immer der Schwerkraft treu, indem das Gewicht die Kugel immer zum Erdmittelpunkt zieht; aus verschiedenen technischen Gründen wird der künstliche Horizont aber, ähnlich wie der Kurskreisel, mit Hilfe von sich drehenden Scheiben auf Richtung gehalten. Dieser technische Hintergrund ist aber eher für Instrumentenbauer als für Piloten relevant.<br />
<br />
Als Flugschüler lernt man schnell, den Blick vom natürlichen Horizont zum künstlichen zu wenden, noch bevor man in eine Wolke oder eine Nebelwand fliegt. Aber auch bei guten Sichtverhältnissen sollte der künstliche Horizont immer mit einbezogen werden, da der natürliche das Auge trügen kann: Fliegt man z.B. in den Bergen in einem flachen Tal und hat eine von links nach rechts ansteigende Bergkette vor sich, rechnet das Gehirn unweigerlich diese Bergkette als waagerechten Horizont, wie die Meeresoberfläche, mit ein, und man neigt nach links, auch wenn man als Bezugspunkt das waagerechte und flache Tal unter sich anschaut. Ein weiterer psychologischer Faktor ist die Präferenz eines Menschen, eine leichte Neigung des Flugzeugs nach links als gerade anzusehen; Man kann diesen Effekt mit einem Experiment sehr schön nachstellen, indem man bei FlightGear einfach von der Startbahn gerade abhebt (bei Windstille), und dann, ohne die Instrumente anzuschauen, zwei Minuten weiterfliegt. Etwa 98% der Flieger befinden sich dann weit links von der gedachten Fortführung der Startbahn. Es gibt weitere solcher psychologischen Effekte, die den künstlichen Horizont unerlässlich machen.<br />
<br />
(''Anmerkung des Autors: Der Linkspräferenzeffekt ohne Bezugspunkt wird von einigen Psychologen auf das normalerweise stärkere rechte Bein des Menschen zurückgeführt; ich selbst bin allerdings Linksfuss (aber auch Rechtshänder). Trotzdem befinde ich mich ebenso immer bis zu 10′ links neben der Startbahnlinie bei dem o.g. Experiment! Diese Linkspräferenz ist ein Fakt, der Grund dafür noch ungeklärt.'')</div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=De/Avionics_and_Instruments&diff=20542De/Avionics and Instruments2010-03-28T12:55:20Z<p>Maerchenprinz: </p>
<hr />
<div>= Kompasse =<br />
<br />
In der Fliegerei werden zwei unterschiedliche Kompassarten verwendet:<br />
* der '''Magnetkompass'''<br />
* der '''Kurskreisel'''<br />
<br />
== Magnetkompass ==<br />
Der '''Magnetkompass''' richtet sich nach dem magnetischem Feld aus, das die Erde umgibt.<br />
<br />
Zu beachten ist dabei, dass sich der magnetische und der geografische Nordpol NICHT an der gleichen Stelle befinden. Die Differenz zwischen magnetischer Feldausrichtung (Kompassnadel) und Ausrichtung auf den geografischen Nordpol (''wahres Nord'' oder engl. ''true north'') heisst ''magnetische Variation'', abgekürzt mit ''VAR'' oder ''MV''. Je nach Ort, an dem man sich befindet, ist die magnetische Variation unterschiedlich; ebenso ändert sie sich mit der Zeit, da die magnetischen Pole wandern.<br />
<br />
Wenn man einen Flugplan macht, sollte man die ''magnetische Variation'' entlang der Flugroute kennen. In der Luftnavigation bedient man sich der magnetischen Ausrichtung: Auf Flugkarten ist alles als magnetische Ausrichtung verzeichnet, VOR-Stationen zeigen nach magnetisch Nord, auch Landebahnen bekommen ihren Namen nach ihrer magnetischen Richtung. So hat zum Beispiel die Landebahn 10L am Flughafen San Francisco, KSFO, die magnetische Richtung 100, wahre Ausrichtung ist aber ca. 115 Grad. Sogar GPS-Geräte für Luftnavigation zeigen magnetische Richtungswerte an, obwohl sie die wahren Richtungswerte kennen.<br />
<br />
Angegeben wird die magnetische Variation in ''Grad Ost'' oder ''Grad West'' (engl. ''degrees east'' bzw. ''degrees west''), auf Luftkarten oft geschrieben als z.B. "MV 15′E" oder "MV +15′", dabei ist + Ost, - West.<br />
<br />
Nur die Windrichtung vom METAR wird als wahrer Richtungswert gemeldet, was bei der Berechnung des Winddreiecks wichtig ist:<br />
Fliegt man zum Beispiel die Landebahn 10 vom Flughafen KSFO mit Kompassweisung 100 Grad an und bekommt die Windmeldung "aus 100 Grad mit 12 Knoten", so hat man nicht einen schönen Gegenwind, sondern einen ordentlichen Seitenwind von vorne links (etwa -15 Grad zur Landebahn).<br />
Auch bei der Flugroute muss die magnetische Variation mit einberechnet werden: Eine Linie auf der Landkarte von San Francisco nach Seattle zeigt exakt nach Norden; Folgte man aber ab dem Start vom KSFO einfach der Kompassanzeige ''360′ Nord'', fände die Landung zum Missfallen der Passagiere etwa 200 Meilen östlich in Spokane anstatt in Seattle statt.<br />
<br />
In der Praxis gibt es unterschiedliche Herangehensweisen, um mit dieser Missweisung des Magnetkompasses umzugehen: Zum einen kann man die Kompassrose oder andere richtungsweisende Instrumente so einstellen, dass sie "wahres Norden" anzeigen, zum anderen kann man die magnetische Variation in seinen angezeigten Kurs mit einbeziehen.<br />
Welche dieser beiden Herangehensweisen am praktischten ist, hängt von der Flugroute, der Instrumentierung des Flugzeuges und von den Präferenzen des Piloten ab, und kann auf den verschiedenen Abschnitten eines Fluges wechseln; Wichtig ist nur, sich immer bewusst zu sein, was die Instrumente gerade anzeigen und ob der Flugplan magnetischen oder wahren Kurs beschreibt. Ebenso sollte man wissen, welche Referenz die verschiedene Systeme des Flugzeugs, wie z.B. der Autopilot, verwenden.<br />
<br />
Findet man keine Karte, auf der die magnetische Variation des Abflug- oder Zielflughafens verzeichnet ist, hat man bei FlightGear zwei Möglichichkeiten, sie herauszufinden. Erstens kann man sie unter File-> Browse Internal Properties-> /environment/magnetic-variation-deg überprüfen, zweitens kann man folgendes Shell-Script verwenden:<br />
<br />
#!/bin/bash<br />
if [ $# -ne 2 ]; then<br />
echo "Usage: $(basename $0) lat long";<br />
echo "East and north are positive.";<br />
else<br />
testmagvar $1 $2 0 $(date +"%m %d %g")|tail -1|tr -s [:space:] \\t|cut -f6;<br />
fi<br />
<br />
Ein guter Pilot weiss aber immmer schon vorher, welche MV ihn erwartet! Und wir sind doch natürlich alle gute Piloten, oder nicht?<br />
<br />
== Kurskreisel ==<br />
Der '''Kurskreisel''' (engl. ''directional gyro'' oder ''heading indicator'') dient, ebenso wie der ''Magnetkompass'', zur Richtungsanzeige. Er weiss allerdings nichts über einen magnetischen oder geografischen Nordpol, sondern arbeitet, vereinfacht gesagt, rein nach dem Trägheitsprinzip.<br />
<br />
Aus dem Schulunterricht ist den meisten das Experiment bekannt, bei dem jemand das abmontierte Rad eines Fahrrads an der Achse in den Händen hält; dreht sich das Rad nicht, ist es sehr leicht, es herumzuschwenken, dreht man es doch, ist es sehr schwer, seine Richtung zu ändern.<br />
Im Kurskreisel befindet sich also (mindestens) eine frei aufgehängte, möglichst schwere Scheibe, die von einem Elektromotor möglichst schnell gedreht wird. Diese Scheibe "wehrt" sich gegen jede Richtungsänderung des Flugzeugs und bleibt in der Richtung, in der sie initiiert wurde.<br />
<br />
Will man den Kurskreisel benutzen, muss man ihn zuerst mit dem Magnetkompass abgleichen; in den meisten Flugzeugen ist der Kurskreisel aber schon mit dem Magnetkompass verbunden, so dass er bei der Initiierung mit ihm abgeglichen wird, oder während des gesamten Fluges dem Magnetkompass folgt.<br />
Der Grund, warum der Kurskreisel ein wichtiges Instrument ist, auch wenn er dem Magnetkompass folgt, ist der, dass der Kurskreisel in bestimmten Situationen zur Richtungsmessung besser geeignet ist:<br />
Bei längeren Kurven, wie z.B. der oft gefragten halben ''Standardkurve'' (engl. ''standard turn'') von 180′ hängt die Anzeige des Magnetkompasses hinterher, und die Neigung des Flugzeugs, und mit ihm die des Magnetkompasses, bringt ihn zu fehlerhaften Messungen. Ebenso ist der Kurskreisel nicht anfällig für plötzliche Änderungen des Magnetfeldes, die etwa bei der Annäherung an Gebiete mit starken Funksendern oder magnetischen Mineralien auftreten.<br />
Deswegen nehmen Navigationssysteme oder Autopiloten normalerweise den Kurskreisel und nicht den Magnetkompass als primäre Referenz.<br />
Mit zunehmender Flugzeit wird aber auch der Kurskreisel ungenau, weshalb er auch nachjustiert werden muss.<br />
<br />
In einigen grösseren Flugzeugen kann man wählen, welches Kompasssystem sich nach dem anderen richtet; Das bestimmende wird als "Master-", das folgende als "Slave-" bezeichnet. <br />
<br />
Anmerkung: Die Begriffe ''Gyrokompass'' und ''Gyroskop'' werden fälschlicherweise oft synonym für 'Kurskreisel' verwendet, werden aber innerhalb der Fliegergemeinschaft als Begriff für 'Kurskreisel' normalerweise nicht missverstanden. <br />
<br />
= Höhenmesser =<br />
[[Image:Altimeter.png|right|Altmeter of default Cesna]]<br />
<br />
Per Definition ist ein '''Höhenmesser''' , (meistens "'''Altimeter'''" genannt) , ein Instrument, das die Höhe über einer festgelegten Ebene misst.<br />
<br />
Diese, sehr technisch gesprochene "festgelegte Ebene" ist in der Luftfahrt in der Regel der mittlere Meeresspiegel (''MSL'', von engl. ''mean sea level'') oder die Bodenhöhe unter dem Flugzeug (''GL'', von engl. ''ground level'').<br />
<br />
== Luftdruck ==<br />
Als Flieger wird man am häufigsten mit der Höhe "feet ASL", (engl. ''feet above sea level'') also ''Fuss über Meeresspiegel'' konfrontiert. Diese Höhe wird immer mit Hilfe des umgebenden Luftdrucks gemessen, ausser bei GPS. GPS-Höhenangaben sollten aber höchstens nur als Kontrolle verwendet werden, da das Bezugssystem für die Höhe in der Luftfahrt der Luftdruck ist.<br />
<br />
Internationale Einheit für die Flughöhe ist, bis auf wenige Ausnahmen, ''Fuss'' bzw. ''feet'', abgekürzt ''ft''.<br />
Ein ''feet'' entspricht 30.48cm, über den krummen Daumen gepeilt kann man also rechnen: "Feet durch 3 und etwas weniger = Meter "<br />
<br />
Da der Luftdruck variiert, muss der Höhenmesser justiert werden. Dazu stellt man den Luftdruckwähler des Altimeters auf den Wert ein, den man vom ATIS oder vom Tower durchgesagt bekommen hat. An einem müssigen Sommerabend, oder wenn der Flugplatz keinen Tower oder ATIS besitzt, kann man vor dem Start aber auch den Luftdruckwähler soweit drehen, bis der Höhenmesser die Höhe des Plugplatzes (die man natürlich kennt!) anzeigt.<br />
<br />
Ab einer gewissen Höhe, der ''Übergangshöhe'' (engl. ''transition level''), wird am Höhenmesser der sogenannte "Normaldruck" von 29.92 inHG eingestellt. Damit erreicht man, dass alle Flugzeuge den gleichen Bezugswert haben; Soll zum Beispiel ein Flugzeug in einem Hochdruckgebiet die Höhe 12000ft, ein anderes 13000ft halten, fliegt das eine vielleicht auf 12500ft, das andere auf 13500ft. Da beide Piloten aber auf ihrem Höhenmesser mit eingestelltem 29.92inHG Luftdruck die ihnen jeweils zugewiesene Flughöhe lesen, können beide mit 1000ft Höhenunterschied ihren Weg kreuzen, ohne zu kollidieren. Würde jeder Pilot den Luftdruck seines Startflugplatzes beibehalten, gäbe es am Himmel ein buntes Allerlei an Interpretationen der richtigen Flughöhe.<br />
Die Standard-Übergangshöhe ist je nach Land unterschiedlich, findet sich aber oft auf Flugkarten bzw. wird vom Tower festgelegt und durchgegeben.<br />
<br />
== Radar ==<br />
Der '''Radarhöhenmesser''' (engl. ''''radio altimeter'''') misst die Flughöhe uber Grund, also AGL (engl. ''above ground level''), in dem er das Echo seiner abgestrahlten Radarwellen interpretiert. Verwendet wird er im militärischen Bereich (Stichwort Tiefflug) und bei präzisen Instrumentenlandungen.<br />
<br />
<br />
= Künstlicher Horizont =<br />
<br />
Der '''künstliche Horizont''' (engl. '''artificial horizon''' oder gebräuchlicher '''attitude indicator''', abgekürzt '''ai'''), zeigt die Lage des Flugzeugs, wie der Name schon sagt, anhand eines künstlichen Horizontes an. Die Anzeige ist unterteilt in "Himmel" (normalerweise blau) und "Boden" (normalerweise braun), dazu gesellt sich mittig eine stilisierte Darstellung des Flugzeug von hinten.<br />
<br />
Anhand des künstlichen Horizontes kann man als Pilot die Fluglage seines Fugzeugs ablesen, ohne den natürlichen Horizont zu sehen.<br />
<br />
Prinzipiell kann man sich vorstellen, die Horizontanzeige sei eine Kugel, hätte ein Gewicht unter sich angebracht, und bleibe deswegen immer der Schwerkraft treu, indem das Gewicht die Kugel immer zum Erdmittelpunkt zieht; aus verschiedenen technischen Gründen wird der künstliche Horizont aber, ähnlich wie der Kurskreisel, mit Hilfe von sich drehenden Scheiben auf Richtung gehalten. Dieser technische Hintergrund ist aber eher für Instrumentenbauer als für Piloten relevant.<br />
<br />
Als Flugschüler lernt man schnell, den Blick vom natürlichen Horizont zum künstlichen zu wenden, noch bevor man in eine Wolke oder eine Nebelwand fliegt. Aber auch bei guten Sichtverhältnissen sollte der künstliche Horizont immer mit einbezogen werden, da der natürliche das Auge trügen kann: Fliegt man z.B. in den Bergen in einem flachen Tal und hat eine von links nach rechts ansteigende Bergkette vor sich, rechnet das Gehirn unweigerlich diese Bergkette als waagerechten Horizont, wie die Meeresoberfläche, mit ein, und man neigt nach links, auch wenn man als Bezugspunkt das waagerechte und flache Tal unter sich anschaut. Ein weiterer psychologischer Faktor ist die Präferenz eines Menschen, eine leichte Neigung des Flugzeugs nach links als gerade anzusehen; Man kann diesen Effekt mit einem Experiment sehr schön nachstellen, indem man bei FlightGear einfach von der Startbahn gerade abhebt (bei Windstille), und dann, ohne die Instrumente anzuschauen, zwei Minuten weiterfliegt. Etwa 98% der Flieger befinden sich dann weit links von der gedachten Fortführung der Startbahn. Es gibt weitere solcher psychologischen Effekte, die den künstlichen Horizont unerlässlich machen.<br />
<br />
(''Anmerkung des Autors: Der Linkspräferenzeffekt ohne Bezugspunkt wird von einigen Psychologen auf das normalerweise stärkere rechte Bein des Menschen zurückgeführt; ich selbst bin allerdings Linksfuss (aber auch Rechtshänder). Trotzdem befinde ich mich ebenso immer bis zu 10′ links neben der Startbahnlinie bei dem o.g. Experiment! Diese Linkspräferenz ist ein Fakt, der Grund dafür noch ungeklärt.'')</div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=De/Avionics_and_Instruments&diff=20541De/Avionics and Instruments2010-03-28T12:46:23Z<p>Maerchenprinz: </p>
<hr />
<div>= Kompasse =<br />
<br />
In der Fliegerei werden zwei unterschiedliche Kompassarten verwendet:<br />
* der '''Magnetkompass'''<br />
* der '''Kurskreisel'''<br />
<br />
== Magnetkompass ==<br />
Der '''Magnetkompass''' richtet sich nach dem magnetischem Feld aus, das die Erde umgibt.<br />
<br />
Zu beachten ist dabei, dass sich der magnetische und der geografische Nordpol NICHT an der gleichen Stelle befinden. Die Differenz zwischen magnetischer Feldausrichtung (Kompassnadel) und Ausrichtung auf den geografischen Nordpol (''wahres Nord'' oder engl. ''true north'') heisst ''magnetische Variation'', abgekürzt mit ''VAR'' oder ''MV''. Je nach Ort, an dem man sich befindet, ist die magnetische Variation unterschiedlich; ebenso ändert sie sich mit der Zeit, da die magnetischen Pole wandern.<br />
<br />
Wenn man einen Flugplan macht, sollte man die ''magnetische Variation'' entlang der Flugroute kennen. In der Luftnavigation bedient man sich der magnetischen Ausrichtung: Auf Flugkarten ist alles als magnetische Ausrichtung verzeichnet, VOR-Stationen zeigen nach magnetisch Nord, auch Landebahnen bekommen ihren Namen nach ihrer magnetischen Richtung. So hat zum Beispiel die Landebahn 10L am Flughafen San Francisco, KSFO, die magnetische Richtung 100, wahre Ausrichtung ist aber ca. 115 Grad. Sogar GPS-Geräte für Luftnavigation zeigen magnetische Richtungswerte an, obwohl sie die wahren Richtungswerte kennen.<br />
<br />
Angegeben wird die magnetische Variation in ''Grad Ost'' oder ''Grad West'' (engl. ''degrees east'' bzw. ''degrees west''), auf Luftkarten oft geschrieben als z.B. "MV 15′E" oder "MV +15′", dabei ist + Ost, - West.<br />
<br />
Nur die Windrichtung vom METAR wird als wahrer Richtungswert gemeldet, was bei der Berechnung des Winddreiecks wichtig ist:<br />
Fliegt man zum Beispiel die Landebahn 10 vom Flughafen KSFO mit Kompassweisung 100 Grad an und bekommt die Windmeldung "aus 100 Grad mit 12 Knoten", so hat man nicht einen schönen Gegenwind, sondern einen ordentlichen Seitenwind von vorne links (etwa -15 Grad zur Landebahn).<br />
Auch bei der Flugroute muss die magnetische Variation mit einberechnet werden: Eine Linie auf der Landkarte von San Francisco nach Seattle zeigt exakt nach Norden; Folgte man aber ab dem Start vom KSFO einfach der Kompassanzeige ''360′ Nord'', fände die Landung zum Missfallen der Passagiere etwa 200 Meilen östlich in Spokane anstatt in Seattle statt.<br />
<br />
In der Praxis gibt es unterschiedliche Herangehensweisen, um mit dieser Missweisung des Magnetkompasses umzugehen: Zum einen kann man die Kompassrose oder andere richtungsweisende Instrumente so einstellen, dass sie "wahres Norden" anzeigen, zum anderen kann man die magnetische Variation in seinen angezeigten Kurs mit einbeziehen.<br />
Welche dieser beiden Herangehensweisen am praktischten ist, hängt von der Flugroute, der Instrumentierung des Flugzeuges und von den Präferenzen des Piloten ab, und kann auf den verschiedenen Abschnitten eines Fluges wechseln; Wichtig ist nur, sich immer bewusst zu sein, was die Instrumente gerade anzeigen und ob der Flugplan magnetischen oder wahren Kurs beschreibt. Ebenso sollte man wissen, welche Referenz die verschiedene Systeme des Flugzeugs, wie z.B. der Autopilot, verwenden.<br />
<br />
Findet man keine Karte, auf der die magnetische Variation des Abflug- oder Zielflughafens verzeichnet ist, hat man bei FlightGear zwei Möglichichkeiten, sie herauszufinden. Erstens kann man sie unter File-> Browse Internal Properties-> /environment/magnetic-variation-deg überprüfen, zweitens kann man folgendes Shell-Script verwenden:<br />
<br />
#!/bin/bash<br />
if [ $# -ne 2 ]; then<br />
echo "Usage: $(basename $0) lat long";<br />
echo "East and north are positive.";<br />
else<br />
testmagvar $1 $2 0 $(date +"%m %d %g")|tail -1|tr -s [:space:] \\t|cut -f6;<br />
fi<br />
<br />
Ein guter Pilot weiss aber immmer schon vorher, welche MV ihn erwartet! Und wir sind doch natürlich alle gute Piloten, oder nicht?<br />
<br />
== Kurskreisel ==<br />
Der '''Kurskreisel''' (engl. ''directional gyro'' oder ''heading indicator'') dient, ebenso wie der ''Magnetkompass'', zur Richtungsanzeige. Er weiss allerdings nichts über einen magnetischen oder geografischen Nordpol, sondern arbeitet, vereinfacht gesagt, rein nach dem Trägheitsprinzip.<br />
<br />
Aus dem Schulunterricht ist den meisten das Experiment bekannt, bei dem jemand das abmontierte Rad eines Fahrrads an der Achse in den Händen hält; dreht sich das Rad nicht, ist es sehr leicht, es herumzuschwenken, dreht man es doch, ist es sehr schwer, seine Richtung zu ändern.<br />
Im Kurskreisel befindet sich also (mindestens) eine frei aufgehängte, möglichst schwere Scheibe, die von einem Elektromotor möglichst schnell gedreht wird. Diese Scheibe "wehrt" sich gegen jede Richtungsänderung des Flugzeugs und bleibt in der Richtung, in der sie initiiert wurde.<br />
<br />
Will man den Kurskreisel benutzen, muss man ihn zuerst mit dem Magnetkompass abgleichen; in den meisten Flugzeugen ist der Kurskreisel aber schon mit dem Magnetkompass verbunden, so dass er bei der Initiierung mit ihm abgeglichen wird, oder während des gesamten Fluges dem Magnetkompass folgt.<br />
Der Grund, warum der Kurskreisel ein wichtiges Instrument ist, auch wenn er dem Magnetkompass folgt, ist der, dass der Kurskreisel in bestimmten Situationen zur Richtungsmessung besser geeignet ist:<br />
Bei längeren Kurven, wie z.B. der oft gefragten halben ''Standardkurve'' (engl. ''standard turn'') von 180′ hängt die Anzeige des Magnetkompasses hinterher, und die Neigung des Flugzeugs, und mit ihm die des Magnetkompasses, bringt ihn zu fehlerhaften Messungen. Ebenso ist der Kurskreisel nicht anfällig für plötzliche Änderungen des Magnetfeldes, die etwa bei der Annäherung an Gebiete mit starken Funksendern oder magnetischen Mineralien auftreten.<br />
Deswegen nehmen Navigationssysteme oder Autopiloten normalerweise den Kurskreisel und nicht den Magnetkompass als primäre Referenz.<br />
Mit zunehmender Flugzeit wird aber auch der Kurskreisel ungenau, weshalb er auch nachjustiert werden muss.<br />
<br />
In einigen grösseren Flugzeugen kann man wählen, welches Kompasssystem sich nach dem anderen richtet; Das bestimmende wird als "Master-", das folgende als "Slave-" bezeichnet. <br />
<br />
Anmerkung: Die Begriffe ''Gyrokompass'' und ''Gyroskop'' werden fälschlicherweise oft synonym für 'Kurskreisel' verwendet, werden aber innerhalb der Fliegergemeinschaft als Begriff für 'Kurskreisel' normalerweise nicht missverstanden. <br />
<br />
= Höhenmesser =<br />
[[Image:Altimeter.png|right|Altmeter of default Cesna]]<br />
<br />
Per Definition ist ein '''Höhenmesser''' , (meistens "'''Altimeter'''" genannt) , ein Instrument, das die Höhe über einer festgelegten Ebene misst.<br />
<br />
Diese, sehr technisch gesprochene "festgelegte Ebene" ist in der Luftfahrt in der Regel der mittlere Meeresspiegel (''MSL'', von engl. ''mean sea level'') oder die Bodenhöhe unter dem Flugzeug (''GL'', von engl. ''ground level'').<br />
<br />
== Luftdruck ==<br />
Als Flieger wird man am häufigsten mit der Höhe "feet ASL", (engl. ''feet above sea level'') also ''Fuss über Meeresspiegel'' konfrontiert. Diese Höhe wird immer mit Hilfe des umgebenden Luftdrucks gemessen, ausser bei GPS. GPS-Höhenangaben sollten aber höchstens nur als Kontrolle verwendet werden, da das Bezugssystem für die Höhe in der Luftfahrt der Luftdruck ist.<br />
<br />
Internationale Einheit für die Flughöhe ist, bis auf wenige Ausnahmen, ''Fuss'' bzw. ''feet'', abgekürzt ''ft''.<br />
Ein ''feet'' entspricht 30.48cm, über den krummen Daumen gepeilt kann man also rechnen: "Feet durch 3 und etwas weniger = Meter "<br />
<br />
Da der Luftdruck variiert, muss der Höhenmesser justiert werden. Dazu stellt man den Luftdruckwähler des Altimeters auf den Wert ein, den man vom ATIS oder vom Tower durchgesagt bekommen hat. An einem müssigen Sommerabend, oder wenn der Flugplatz keinen Tower oder ATIS besitzt, kann man vor dem Start aber auch den Luftdruckwähler soweit drehen, bis der Höhenmesser die Höhe des Plugplatzes (die man natürlich kennt!) anzeigt.<br />
<br />
Ab einer gewissen Höhe, der ''Übergangshöhe'' (engl. ''transition level''), wird am Höhenmesser der sogenannte "Normaldruck" von 29.92 inHG eingestellt. Damit erreicht man, dass alle Flugzeuge den gleichen Bezugswert haben; Soll zum Beispiel ein Flugzeug in einem Hochdruckgebiet die Höhe 12000ft, ein anderes 13000ft halten, fliegt das eine vielleicht auf 12500ft, das andere auf 13500ft. Da beide Piloten aber auf ihrem Höhenmesser mit eingestelltem 29.92inHG Luftdruck die ihnen jeweils zugewiesene Flughöhe lesen, können beide mit 1000ft Höhenunterschied ihren Weg kreuzen, ohne zu kollidieren. Würde jeder Pilot den Luftdruck seines Startflugplatzes beibehalten, gäbe es am Himmel ein buntes Allerlei an Interpretationen der richtigen Flughöhe.<br />
Die Standard-Übergangshöhe ist je nach Land unterschiedlich, findet sich aber oft auf Flugkarten bzw. wird vom Tower festgelegt und durchgegeben.<br />
<br />
== Radar ==<br />
Der '''Radarhöhenmesser''' (engl. ''''radio altimeter'''') misst die Flughöhe uber Grund, also AGL (engl. ''above ground level''), in dem er das Echo seiner abgestrahlten Radarwellen interpretiert. Verwendet wird er im militärischen Bereich (Stichwort Tiefflug) und bei präzisen Instrumentenlandungen.<br />
<br />
<br />
= Künstlicher Horizont =<br />
<br />
Der '''künstliche Horizont''' (engl. '''artificial horizon''' oder gebräuchlicher '''attitude indicator''', abgekürzt '''ai'''), zeigt die Lage des Flugzeugs, wie der Name schon sagt, anhand eines künstlichen Horizontes an. Die Anzeige ist unterteilt in "Himmel" (normalerweise blau) und "Boden" (normalerweise braun), dazu gesellt sich mittig eine stilisierte Darstellung des Flugzeug von hinten.<br />
<br />
Anhand des künstlichen Horizontes kann man als Pilot die Fluglage seines Fugzeugs ablesen, ohne den natürlichen Horizont zu sehen.<br />
<br />
Prinzipiell kann man sich vorstellen, die Horizontanzeige sei eine Kugel, hätte ein Gewicht unter sich angebracht, und bleibe deswegen immer der Schwerkraft treu, indem das Gewicht die Kugel immer zum Erdmittelpunkt zieht; aus verschiedenen technischen Gründen wird der künstliche Horizont aber, ähnlich wie der Kurskreisel, mit Hilfe von sich drehenden Scheiben auf Richtung gehalten. Dieser technische Hintergrund ist aber eher für Instrumentenbauer als für Piloten relevant.<br />
<br />
Als Flugschüler lernt man schnell, den Blick vom natürlichen Horizont zum künstlichen zu wenden, noch bevor man in eine Wolke oder eine Nebelwand fliegt. Aber auch bei guten Sichtverhältnissen sollte der künstliche Horizont immer mit einbezogen werden, da der natürliche das Auge trügen kann: Fliegt man z.B. in den Bergen in einem flachen Tal und hat eine von links nach rechts ansteigende Bergkette vor sich, rechnet das Gehirn unweigerlich diese Bergkette als waagerechten Horizont, wie die Meeresoberfläche, mit ein, und man neigt nach links, auch wenn man als Bezugspunkt das waagerechte und flache Tal unter sich anschaut. Ein weiterer psychologischer Faktor ist die Präferenz eines Menschen, eine leichte Neigung des Flugzeugs nach links als gerade anzusehen; Man kann diesen Effekt mit einem Experiment sehr schön nachstellen, indem man bei FlightGear einfach von der Startbahn gerade abhebt (bei Windstille), und dann, ohne die Instrumente anzuschauen, zwei Minuten weiterfliegt. Etwa 98% der Flieger befinden sich dann weit links von der gedachten Fortführung der Startbahn. Es gibt weitere solcher psychologischen Effekte, die den künstlichen Horizont unerlässlich machen.<br />
<br />
(''Anmerkung des Autors: Der Linkspräferenzeffekt mit Bezugspunkt wird von einigen Psychologen auf das normalerweise stärkere rechte Bein des Menschen zurückgeführt; ich selbst bin allerdings Linksfuss (aber auch Rechtshänder). Trotzdem befinde ich mich ebenso immer bis zu 10′ links neben der Startbahnlinie bei dem o.g. Experiment! Diese Linkspräferenz ist ein Fakt, der Grund dafür noch ungeklärt.'')</div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=De/Avionics_and_Instruments&diff=20540De/Avionics and Instruments2010-03-28T12:17:35Z<p>Maerchenprinz: </p>
<hr />
<div>= Kompasse =<br />
<br />
In der Fliegerei werden zwei unterschiedliche Kompassarten verwendet:<br />
* der '''Magnetkompass'''<br />
* der '''Kurskreisel'''<br />
<br />
== Magnetkompass ==<br />
Der '''Magnetkompass''' richtet sich nach dem magnetischem Feld aus, das die Erde umgibt.<br />
<br />
Zu beachten ist dabei, dass sich der magnetische und der geografische Nordpol NICHT an der gleichen Stelle befinden. Die Differenz zwischen magnetischer Feldausrichtung (Kompassnadel) und Ausrichtung auf den geografischen Nordpol (''wahres Nord'' oder engl. ''true north'') heisst ''magnetische Variation'', abgekürzt mit ''VAR'' oder ''MV''. Je nach Ort, an dem man sich befindet, ist die magnetische Variation unterschiedlich; ebenso ändert sie sich mit der Zeit, da die magnetischen Pole wandern.<br />
<br />
Wenn man einen Flugplan macht, sollte man die ''magnetische Variation'' entlang der Flugroute kennen. In der Luftnavigation bedient man sich der magnetischen Ausrichtung: Auf Flugkarten ist alles als magnetische Ausrichtung verzeichnet, VOR-Stationen zeigen nach magnetisch Nord, auch Landebahnen bekommen ihren Namen nach ihrer magnetischen Richtung. So hat zum Beispiel die Landebahn 10L am Flughafen San Francisco, KSFO, die magnetische Richtung 100, wahre Ausrichtung ist aber ca. 115 Grad. Sogar GPS-Geräte für Luftnavigation zeigen magnetische Richtungswerte an, obwohl sie die wahren Richtungswerte kennen.<br />
<br />
Angegeben wird die magnetische Variation in ''Grad Ost'' oder ''Grad West'' (engl. ''degrees east'' bzw. ''degrees west''), auf Luftkarten oft geschrieben als z.B. "MV 15′E" oder "MV +15′", dabei ist + Ost, - West.<br />
<br />
Nur die Windrichtung vom METAR wird als wahrer Richtungswert gemeldet, was bei der Berechnung des Winddreiecks wichtig ist:<br />
Fliegt man zum Beispiel die Landebahn 10 vom Flughafen KSFO mit Kompassweisung 100 Grad an und bekommt die Windmeldung "aus 100 Grad mit 12 Knoten", so hat man nicht einen schönen Gegenwind, sondern einen ordentlichen Seitenwind von vorne links (etwa -15 Grad zur Landebahn).<br />
Auch bei der Flugroute muss die magnetische Variation mit einberechnet werden: Eine Linie auf der Landkarte von San Francisco nach Seattle zeigt exakt nach Norden; Folgte man aber ab dem Start vom KSFO einfach der Kompassanzeige ''360′ Nord'', fände die Landung zum Missfallen der Passagiere etwa 200 Meilen östlich in Spokane anstatt in Seattle statt.<br />
<br />
In der Praxis gibt es unterschiedliche Herangehensweisen, um mit dieser Missweisung des Magnetkompasses umzugehen: Zum einen kann man die Kompassrose oder andere richtungsweisende Instrumente so einstellen, dass sie "wahres Norden" anzeigen, zum anderen kann man die magnetische Variation in seinen angezeigten Kurs mit einbeziehen.<br />
Welche dieser beiden Herangehensweisen am praktischten ist, hängt von der Flugroute, der Instrumentierung des Flugzeuges und von den Präferenzen des Piloten ab, und kann auf den verschiedenen Abschnitten eines Fluges wechseln; Wichtig ist nur, sich immer bewusst zu sein, was die Instrumente gerade anzeigen und ob der Flugplan magnetischen oder wahren Kurs beschreibt. Ebenso sollte man wissen, welche Referenz die verschiedene Systeme des Flugzeugs, wie z.B. der Autopilot, verwenden.<br />
<br />
Findet man keine Karte, auf der die magnetische Variation des Abflug- oder Zielflughafens verzeichnet ist, hat man bei FlightGear zwei Möglichichkeiten, sie herauszufinden. Erstens kann man sie unter File-> Browse Internal Properties-> /environment/magnetic-variation-deg überprüfen, zweitens kann man folgendes Shell-Script verwenden:<br />
<br />
#!/bin/bash<br />
if [ $# -ne 2 ]; then<br />
echo "Usage: $(basename $0) lat long";<br />
echo "East and north are positive.";<br />
else<br />
testmagvar $1 $2 0 $(date +"%m %d %g")|tail -1|tr -s [:space:] \\t|cut -f6;<br />
fi<br />
<br />
Ein guter Pilot weiss aber immmer schon vorher, welche MV ihn erwartet! Und wir sind doch natürlich alle gute Piloten, oder nicht?<br />
<br />
== Kurskreisel ==<br />
Der '''Kurskreisel''' (engl. ''directional gyro'' oder ''heading indicator'') dient, ebenso wie der ''Magnetkompass'', zur Richtungsanzeige. Er weiss allerdings nichts über einen magnetischen oder geografischen Nordpol, sondern arbeitet, vereinfacht gesagt, rein nach dem Trägheitsprinzip.<br />
<br />
Aus dem Schulunterricht ist den meisten das Experiment bekannt, bei dem jemand das abmontierte Rad eines Fahrrads an der Achse in den Händen hält; dreht sich das Rad nicht, ist es sehr leicht, es herumzuschwenken, dreht man es doch, ist es sehr schwer, seine Richtung zu ändern.<br />
Im Kurskreisel befindet sich also (mindestens) eine frei aufgehängte, möglichst schwere Scheibe, die von einem Elektromotor möglichst schnell gedreht wird. Diese Scheibe "wehrt" sich gegen jede Richtungsänderung des Flugzeugs und bleibt in der Richtung, in der sie initiiert wurde.<br />
<br />
Will man den Kurskreisel benutzen, muss man ihn zuerst mit dem Magnetkompass abgleichen; in den meisten Flugzeugen ist der Kurskreisel aber schon mit dem Magnetkompass verbunden, so dass er bei der Initiierung mit ihm abgeglichen wird, oder während des gesamten Fluges dem Magnetkompass folgt.<br />
Der Grund, warum der Kurskreisel ein wichtiges Instrument ist, auch wenn er dem Magnetkompass folgt, ist der, dass der Kurskreisel in bestimmten Situationen zur Richtungsmessung besser geeignet ist:<br />
Bei längeren Kurven, wie z.B. der oft gefragten halben ''Standardkurve'' (engl. ''standard turn'') von 180′ hängt die Anzeige des Magnetkompasses hinterher, und die Neigung des Flugzeugs, und mit ihm die des Magnetkompasses, bringt ihn zu fehlerhaften Messungen. Ebenso ist der Kurskreisel nicht anfällig für plötzliche Änderungen des Magnetfeldes, die etwa bei der Annäherung an Gebiete mit starken Funksendern oder magnetischen Mineralien auftreten.<br />
Deswegen nehmen Navigationssysteme oder Autopiloten normalerweise den Kurskreisel und nicht den Magnetkompass als primäre Referenz.<br />
Mit zunehmender Flugzeit wird aber auch der Kurskreisel ungenau, weshalb er auch nachjustiert werden muss.<br />
<br />
In einigen grösseren Flugzeugen kann man wählen, welches Kompasssystem sich nach dem anderen richtet; Das bestimmende wird als "Master-", das folgende als "Slave-" bezeichnet. <br />
<br />
Anmerkung: Die Begriffe ''Gyrokompass'' und ''Gyroskop'' werden fälschlicherweise oft synonym für 'Kurskreisel' verwendet, werden aber innerhalb der Fliegergemeinschaft als Begriff für 'Kurskreisel' normalerweise nicht missverstanden. <br />
<br />
= Höhenmesser =<br />
[[Image:Altimeter.png|right|Altmeter of default Cesna]]<br />
<br />
Per Definition ist ein '''Höhenmesser''' , (meistens "'''Altimeter'''" genannt) , ein Instrument, das die Höhe über einer festgelegten Ebene misst.<br />
<br />
Diese, sehr technisch gesprochene "festgelegte Ebene" ist in der Luftfahrt in der Regel der mittlere Meeresspiegel (''MSL'', von engl. ''mean sea level'') oder die Bodenhöhe unter dem Flugzeug (''GL'', von engl. ''ground level'').<br />
<br />
== Luftdruck ==<br />
Als Flieger wird man am häufigsten mit der Höhe "feet ASL", (engl. ''feet above sea level'') also ''Fuss über Meeresspiegel'' konfrontiert. Diese Höhe wird immer mit Hilfe des umgebenden Luftdrucks gemessen, ausser bei GPS. GPS-Höhenangaben sollten aber höchstens nur als Kontrolle verwendet werden, da das Bezugssystem für die Höhe in der Luftfahrt der Luftdruck ist.<br />
<br />
Internationale Einheit für die Flughöhe ist, bis auf wenige Ausnahmen, ''Fuss'' bzw. ''feet'', abgekürzt ''ft''.<br />
Ein ''feet'' entspricht 30.48cm, über den krummen Daumen gepeilt kann man also rechnen: "Feet durch 3 und etwas weniger = Meter "<br />
<br />
Da der Luftdruck variiert, muss der Höhenmesser justiert werden. Dazu stellt man den Luftdruckwähler des Altimeters auf den Wert ein, den man vom ATIS oder vom Tower durchgesagt bekommen hat. An einem müssigen Sommerabend, oder wenn der Flugplatz keinen Tower oder ATIS besitzt, kann man vor dem Start aber auch den Luftdruckwähler soweit drehen, bis der Höhenmesser die Höhe des Plugplatzes (die man natürlich kennt!) anzeigt.<br />
<br />
Ab einer gewissen Höhe, der ''Übergangshöhe'' (engl. ''transition level''), wird am Höhenmesser der sogenannte "Normaldruck" von 29.92 inHG eingestellt. Damit erreicht man, dass alle Flugzeuge den gleichen Bezugswert haben; Soll zum Beispiel ein Flugzeug in einem Hochdruckgebiet die Höhe 12000ft, ein anderes 13000ft halten, fliegt das eine vielleicht auf 12500ft, das andere auf 13500ft. Da beide Piloten aber auf ihrem Höhenmesser mit eingestelltem 29.92inHG Luftdruck die ihnen jeweils zugewiesene Flughöhe lesen, können beide mit 1000ft Höhenunterschied ihren Weg kreuzen, ohne zu kollidieren. Würde jeder Pilot den Luftdruck seines Startflugplatzes beibehalten, gäbe es am Himmel ein buntes Allerlei an Interpretationen der richtigen Flughöhe.<br />
Die Standard-Übergangshöhe ist je nach Land unterschiedlich, findet sich aber oft auf Flugkarten bzw. wird vom Tower festgelegt und durchgegeben.<br />
<br />
== Radar ==<br />
Der '''Radarhöhenmesser''' (engl. ''''radio altimeter'''') misst die Flughöhe uber Grund, also AGL (engl. ''above ground level''), in dem er das Echo seiner abgestrahlten Radarwellen interpretiert. Verwendet wird er im militärischen Bereich (Stichwort Tiefflug) und bei präzisen Instrumentenlandungen.<br />
<br />
<br />
= Künstlicher Horizont =<br />
<br />
Der '''künstliche Horizont''' (engl. '''artificial horizon''' oder gebräuchlicher '''attitude indicator''', abgekürzt '''ai'''), zeigt die Lage des Flugzeugs, wie der Name schon sagt, anhand eines künstlichen Horizontes an. Die Anzeige ist unterteilt in "Himmel" (normalerweise blau) und "Boden" (normalerweise braun), dazu gesellt sich mittig eine stilisierte Darstellung des Flugzeug von hinten.<br />
<br />
Anhand des künstlichen Horizontes kann man als Pilot die Fluglage seines Fugzeugs ablesen, ohne den natürlichen Horizont zu sehen.<br />
<br />
Prinzipiell kann man sich vorstellen, die Horizontanzeige sei eine Kugel, hätte ein Gewicht unter sich angebracht, und bleibe deswegen immer der Schwerkraft treu, indem das Gewicht die Kugel immer zum Erdmittelpunkt zieht; aus verschiedenen technischen Gründen wird der künstliche Horizont aber, ähnlich wie der Kurskreisel, mit Hilfe von sich drehenden Scheiben auf Richtung gehalten. Dieser technische Hintergrund ist aber eher für Instrumentenbauer als für Piloten relevant.<br />
<br />
Als Flugschüler lernt man schnell, den Blick vom natürlichen Horizont zum künstlichen zu wenden, noch bevor man in eine Wolke oder eine Nebelwand fliegt. Aber auch bei guten Sichtverhältnissen sollte der künstliche Horizont immer mit einbezogen werden, da der natürliche das Auge trügen kann: Fliegt man z.B. in den Bergen in einem flachen Tal und hat eine von links nach rechts ansteigende Bergkette vor sich, rechnet das Gehirn unweigerlich diese Bergkette als waagerechten Horizont, wie die Meeresoberfläche, mit ein, und man neigt nach links, auch wenn man als Bezugspunkt das waagerechte und flache Tal unter sich anschaut. Ein weiterer psychologischer Faktor ist die Präferenz, eine leichte Neigung des Flugzeugs nach links als gerade anzusehen; Man kann diesen Effekt mit einem Experiment sehr schön nachstellen, wenn man bei FlightGear einfach von der Startbahn gerade abhebt (bei Windstille), und dann, ohne die Instrumente anzuschauen, zwei Minuten weiterfliegt. Etwa 98% der Flieger befinden sich dann weit links von der gedachten Fortführung der Startbahn. Es gibt weitere solcher psychologischen Effekte, die den künstlichen Horizont unerlässlich machen.<br />
(Anmerkung des Autors: Der Linkspräferenzeffekt mit präzisem Bezugspunkt wird von einigen Psychologen auf das normalerweise stärkere rechte Bein des Menschen zurückgeführt; ich selbst bin allerdings Linksfuss und Rechtshänder. Trotzdem befinde ich mich bis zu 10′ ausserhalb der Startbahnlinie bei dem o.g. Experiment!)</div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=De/Avionics_and_Instruments&diff=20539De/Avionics and Instruments2010-03-28T10:21:30Z<p>Maerchenprinz: </p>
<hr />
<div>= Kompasse =<br />
<br />
In der Fliegerei werden zwei unterschiedliche Kompassarten verwendet:<br />
* der '''Magnetkompass'''<br />
* der '''Kurskreisel'''<br />
<br />
== Magnetkompass ==<br />
Der '''Magnetkompass''' richtet sich nach dem magnetischem Feld aus, das die Erde umgibt.<br />
<br />
Zu beachten ist dabei, dass sich der magnetische und der geografische Nordpol NICHT an der gleichen Stelle befinden. Die Differenz zwischen magnetischer Feldausrichtung (Kompassnadel) und Ausrichtung auf den geografischen Nordpol (''wahres Nord'' oder engl. ''true north'') heisst ''magnetische Variation'', abgekürzt mit ''VAR'' oder ''MV''. Je nach Ort, an dem man sich befindet, ist die magnetische Variation unterschiedlich; ebenso ändert sie sich mit der Zeit, da die magnetischen Pole wandern.<br />
<br />
Wenn man einen Flugplan macht, sollte man die ''magnetische Variation'' entlang der Flugroute kennen. In der Luftnavigation bedient man sich der magnetischen Ausrichtung: Auf Flugkarten ist alles als magnetische Ausrichtung verzeichnet, VOR-Stationen zeigen nach magnetisch Nord, auch Landebahnen bekommen ihren Namen nach ihrer magnetischen Richtung. So hat zum Beispiel die Landebahn 10L am Flughafen San Francisco, KSFO, die magnetische Richtung 100, wahre Ausrichtung ist aber ca. 115 Grad. Sogar GPS-Geräte für Luftnavigation zeigen magnetische Richtungswerte an, obwohl sie die wahren Richtungswerte kennen.<br />
<br />
Angegeben wird die magnetische Variation in ''Grad Ost'' oder ''Grad West'' (engl. ''degrees east'' bzw. ''degrees west''), auf Luftkarten oft geschrieben als z.B. "MV 15′E" oder "MV +15′", dabei ist + Ost, - West.<br />
<br />
Nur die Windrichtung vom METAR wird als wahrer Richtungswert gemeldet, was bei der Berechnung des Winddreiecks wichtig ist:<br />
Fliegt man zum Beispiel die Landebahn 10 vom Flughafen KSFO mit Kompassweisung 100 Grad an und bekommt die Windmeldung "aus 100 Grad mit 12 Knoten", so hat man nicht einen schönen Gegenwind, sondern einen ordentlichen Seitenwind von vorne links (etwa -15 Grad zur Landebahn).<br />
Auch bei der Flugroute muss die magnetische Variation mit einberechnet werden: Eine Linie auf der Landkarte von San Francisco nach Seattle zeigt exakt nach Norden; Folgte man aber ab dem Start vom KSFO einfach der Kompassanzeige ''360′ Nord'', fände die Landung zum Missfallen der Passagiere etwa 200 Meilen östlich in Spokane anstatt in Seattle statt.<br />
<br />
In der Praxis gibt es unterschiedliche Herangehensweisen, um mit dieser Missweisung des Magnetkompasses umzugehen: Zum einen kann man die Kompassrose oder andere richtungsweisende Instrumente so einstellen, dass sie "wahres Norden" anzeigen, zum anderen kann man die magnetische Variation in seinen angezeigten Kurs mit einbeziehen.<br />
Welche dieser beiden Herangehensweisen am praktischten ist, hängt von der Flugroute, der Instrumentierung des Flugzeuges und von den Präferenzen des Piloten ab, und kann auf den verschiedenen Abschnitten eines Fluges wechseln; Wichtig ist nur, sich immer bewusst zu sein, was die Instrumente gerade anzeigen und ob der Flugplan magnetischen oder wahren Kurs beschreibt. Ebenso sollte man wissen, welche Referenz die verschiedene Systeme des Flugzeugs, wie z.B. der Autopilot, verwenden.<br />
<br />
Findet man keine Karte, auf der die magnetische Variation des Abflug- oder Zielflughafens verzeichnet ist, hat man bei FlightGear zwei Möglichichkeiten, sie herauszufinden. Erstens kann man sie unter File-> Browse Internal Properties-> /environment/magnetic-variation-deg überprüfen, zweitens kann man folgendes Shell-Script verwenden:<br />
<br />
#!/bin/bash<br />
if [ $# -ne 2 ]; then<br />
echo "Usage: $(basename $0) lat long";<br />
echo "East and north are positive.";<br />
else<br />
testmagvar $1 $2 0 $(date +"%m %d %g")|tail -1|tr -s [:space:] \\t|cut -f6;<br />
fi<br />
<br />
Ein guter Pilot weiss aber immmer schon vorher, welche MV ihn erwartet! Und wir sind doch natürlich alle gute Piloten, oder nicht?<br />
<br />
== Kurskreisel ==<br />
Der '''Kurskreisel''' (engl. ''directional gyro'' oder ''heading indicator'') dient, ebenso wie der ''Magnetkompass'', zur Richtungsanzeige. Er weiss allerdings nichts über einen magnetischen oder geografischen Nordpol, sondern arbeitet, vereinfacht gesagt, rein nach dem Trägheitsprinzip.<br />
<br />
Aus dem Schulunterricht ist den meisten das Experiment bekannt, bei dem jemand das abmontierte Rad eines Fahrrads an der Achse in den Händen hält; dreht sich das Rad nicht, ist es sehr leicht, es herumzuschwenken, dreht man es doch, ist es sehr schwer, seine Richtung zu ändern.<br />
Im Kurskreisel befindet sich also (mindestens) eine frei aufgehängte, möglichst schwere Scheibe, die von einem Elektromotor möglichst schnell gedreht wird. Diese Scheibe "wehrt" sich gegen jede Richtungsänderung des Flugzeugs und bleibt in der Richtung, in der sie initiiert wurde.<br />
<br />
Will man den Kurskreisel benutzen, muss man ihn zuerst mit dem Magnetkompass abgleichen; in den meisten Flugzeugen ist der Kurskreisel aber schon mit dem Magnetkompass verbunden, so dass er bei der Initiierung mit ihm abgeglichen wird, oder während des gesamten Fluges dem Magnetkompass folgt.<br />
Der Grund, warum der Kurskreisel ein wichtiges Instrument ist, auch wenn er dem Magnetkompass folgt, ist der, dass der Kurskreisel in bestimmten Situationen zur Richtungsmessung besser geeignet ist:<br />
Bei längeren Kurven, wie z.B. der oft gefragten halben ''Standardkurve'' (engl. ''standard turn'') von 180′ hängt die Anzeige des Magnetkompasses hinterher, und die Neigung des Flugzeugs, und mit ihm die des Magnetkompasses, bringt ihn zu fehlerhaften Messungen. Ebenso ist der Kurskreisel nicht anfällig für plötzliche Änderungen des Magnetfeldes, die etwa bei der Annäherung an Gebiete mit starken Funksendern oder magnetischen Mineralien auftreten.<br />
Deswegen nehmen Navigationssysteme oder Autopiloten normalerweise den Kurskreisel und nicht den Magnetkompass als primäre Referenz.<br />
Mit zunehmender Flugzeit wird aber auch der Kurskreisel ungenau, weshalb er auch nachjustiert werden muss.<br />
<br />
In einigen grösseren Flugzeugen kann man wählen, welches Kompasssystem sich nach dem anderen richtet; Das bestimmende wird als "Master-", das folgende als "Slave-" bezeichnet. <br />
<br />
Anmerkung: Die Begriffe ''Gyrokompass'' und ''Gyroskop'' werden fälschlicherweise oft synonym für 'Kurskreisel' verwendet, werden aber innerhalb der Fliegergemeinschaft als Begriff für 'Kurskreisel' normalerweise nicht missverstanden. <br />
<br />
= Höhenmesser =<br />
[[Image:Altimeter.png|right|Altmeter of default Cesna]]<br />
<br />
Per Definition ist ein '''Höhenmesser''' , (meistens "'''Altimeter'''" genannt) , ein Instrument, das die Höhe über einer festgelegten Ebene misst.<br />
<br />
Diese, sehr technisch gesprochene "festgelegte Ebene" ist in der Luftfahrt in der Regel der mittlere Meeresspiegel (''MSL'', von engl. ''mean sea level'') oder die Bodenhöhe unter dem Flugzeug (''GL'', von engl. ''ground level'').<br />
<br />
== Luftdruck ==<br />
Als Flieger wird man am häufigsten mit der Höhe "feet ASL", (engl. ''feet above sea level'') also ''Fuss über Meeresspiegel'' konfrontiert. Diese Höhe wird immer mit Hilfe des umgebenden Luftdrucks gemessen, ausser bei GPS. GPS-Höhenangaben sollten aber höchstens nur als Kontrolle verwendet werden, da das Bezugssystem für die Höhe in der Luftfahrt der Luftdruck ist.<br />
<br />
Internationale Einheit für die Flughöhe ist, bis auf wenige Ausnahmen, ''Fuss'' bzw. ''feet'', abgekürzt ''ft''.<br />
Ein ''feet'' entspricht 30.48cm, über den krummen Daumen gepeilt kann man also rechnen: "Feet durch 3 und etwas weniger = Meter "<br />
<br />
Da der Luftdruck variiert, muss der Höhenmesser justiert werden. Dazu stellt man den Luftdruckwähler des Altimeters auf den Wert ein, den man vom ATIS oder vom Tower durchgesagt bekommen hat. An einem müssigen Sommerabend, oder wenn der Flugplatz keinen Tower oder ATIS besitzt, kann man vor dem Start aber auch den Luftdruckwähler soweit drehen, bis der Höhenmesser die Höhe des Plugplatzes (die man natürlich kennt!) anzeigt.<br />
<br />
Ab einer gewissen Höhe, der ''Übergangshöhe'' (engl. ''transition level''), wird am Höhenmesser der sogenannte "Normaldruck" von 29.92 inHG eingestellt. Damit erreicht man, dass alle Flugzeuge den gleichen Bezugswert haben; Soll zum Beispiel ein Flugzeug in einem Hochdruckgebiet die Höhe 12000ft, ein anderes 13000ft halten, fliegt das eine vielleicht auf 12500ft, das andere auf 13500ft. Da beide Piloten aber auf ihrem Höhenmesser mit eingestelltem 29.92inHG Luftdruck die ihnen jeweils zugewiesene Flughöhe lesen, können beide mit 1000ft Höhenunterschied ihren Weg kreuzen, ohne zu kollidieren. Würde jeder Pilot den Luftdruck seines Startflugplatzes beibehalten, gäbe es am Himmel ein buntes Allerlei an Interpretationen der richtigen Flughöhe.<br />
Die Standard-Übergangshöhe ist je nach Land unterschiedlich, findet sich aber oft auf Flugkarten bzw. wird vom Tower festgelegt und durchgegeben.<br />
<br />
== Radar ==<br />
Der '''Radarhöhenmesser''' (engl. ''''radio altimeter'''') misst die Flughöhe uber Grund, also AGL (engl. ''above ground level''), in dem er das Echo seiner abgestrahlten Radarwellen interpretiert. Verwendet wird er im militärischen Bereich (Stichwort Tiefflug) und bei präzisen Instrumentenlandungen.</div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=De/Avionics_and_Instruments&diff=20538De/Avionics and Instruments2010-03-28T10:12:35Z<p>Maerchenprinz: Created page with '= Kompasse = In der Fliegerei werden zwei unterschiedliche Kompassarten verwendet: * der '''Magnetkompass''' * der '''Kurskreisel''' == Magnetkompass == Der '''Magnetkompass'''…'</p>
<hr />
<div>= Kompasse =<br />
<br />
In der Fliegerei werden zwei unterschiedliche Kompassarten verwendet:<br />
* der '''Magnetkompass'''<br />
* der '''Kurskreisel'''<br />
<br />
== Magnetkompass ==<br />
Der '''Magnetkompass''' richtet sich nach dem magnetischem Feld aus, das die Erde umgibt.<br />
<br />
Zu beachten ist dabei, dass sich der magnetische und der geografische Nordpol NICHT an der gleichen Stelle befinden. Die Differenz zwischen magnetischer Feldausrichtung (Kompassnadel) und Ausrichtung auf den geografischen Nordpol (''wahres Nord'' oder engl. ''true north'') heisst ''magnetische Variation'', abgekürzt mit ''VAR'' oder ''MV''. Je nach Ort, an dem man sich befindet, ist die magnetische Variation unterschiedlich; ebenso ändert sie sich mit der Zeit, da die magnetischen Pole wandern.<br />
<br />
Wenn man einen Flugplan macht, sollte man die ''magnetische Variation'' entlang der Flugroute kennen. In der Luftnavigation bedient man sich der magnetischen Ausrichtung: Auf Flugkarten ist alles als magnetische Ausrichtung verzeichnet, VOR-Stationen zeigen nach magnetisch Nord, auch Landebahnen bekommen ihren Namen nach ihrer magnetischen Richtung. So hat zum Beispiel die Landebahn 10L am Flughafen San Francisco, KSFO, die magnetische Richtung 100, wahre Ausrichtung ist aber ca. 115 Grad. Sogar GPS-Geräte für Luftnavigation zeigen magnetische Richtungswerte an, obwohl sie die wahren Richtungswerte kennen.<br />
<br />
Angegeben wird die magnetische Variation in ''Grad Ost'' oder ''Grad West'' (engl. ''degrees east'' bzw. ''degrees west''), auf Luftkarten oft geschrieben als z.B. "MV 15′E" oder "MV +15′", dabei ist + Ost, - West.<br />
<br />
Nur die Windrichtung vom METAR wird als wahrer Richtungswert gemeldet, was bei der Berechnung des Winddreiecks wichtig ist:<br />
Fliegt man zum Beispiel die Landebahn 10 vom Flughafen KSFO mit Kompassweisung 100 Grad an und bekommt die Windmeldung "aus 100 Grad mit 12 Knoten", so hat man nicht einen schönen Gegenwind, sondern einen ordentlichen Seitenwind von vorne links (etwa -15 Grad zur Landebahn).<br />
Auch bei der Flugroute muss die magnetische Variation mit einberechnet werden: Eine Linie auf der Landkarte von San Francisco nach Seattle zeigt exakt nach Norden; Folgte man aber ab dem Start vom KSFO einfach der Kompassanzeige ''360′ Nord'', fände die Landung zum Missfallen der Passagiere etwa 200 Meilen östlich in Spokane anstatt in Seattle statt.<br />
<br />
In der Praxis gibt es unterschiedliche Herangehensweisen, um mit dieser Missweisung des Magnetkompasses umzugehen: Zum einen kann man die Kompassrose oder andere richtungsweisende Instrumente so einstellen, dass sie "wahres Norden" anzeigen, zum anderen kann man die magnetische Variation in seinen angezeigten Kurs mit einbeziehen.<br />
Welche dieser beiden Herangehensweisen am praktischten ist, hängt von der Flugroute, der Instrumentierung des Flugzeuges und von den Präferenzen des Piloten ab, und kann auf den verschiedenen Abschnitten eines Fluges wechseln; Wichtig ist nur, sich immer bewusst zu sein, was die Instrumente gerade anzeigen und ob der Flugplan magnetischen oder wahren Kurs beschreibt. Ebenso sollte man wissen, welche Referenz die verschiedene Systeme des Flugzeugs, wie z.B. der Autopilot, verwenden.<br />
<br />
Findet man keine Karte, auf der die magnetische Variation des Abflug- oder Zielflughafens verzeichnet ist, hat man bei FlightGear zwei Möglichichkeiten, sie herauszufinden. Erstens kann man sie unter File-> Browse Internal Properties-> /environment/magnetic-variation-deg überprüfen, zweitens kann man folgendes Shell-Script verwenden:<br />
<br />
#!/bin/bash<br />
if [ $# -ne 2 ]; then<br />
echo "Usage: $(basename $0) lat long";<br />
echo "East and north are positive.";<br />
else<br />
testmagvar $1 $2 0 $(date +"%m %d %g")|tail -1|tr -s [:space:] \\t|cut -f6;<br />
fi<br />
<br />
Ein guter Pilot weiss aber immmer schon vorher, welche MV ihn erwartet! Und wir sind doch natürlich alle gute Piloten, oder nicht?<br />
<br />
== Kurskreisel ==<br />
Der '''Kurskreisel''' (engl. ''directional gyro'' oder ''heading indicator'') dient, ebenso wie der ''Magnetkompass'', zur Richtungsanzeige. Er weiss allerdings nichts über einen magnetischen oder geografischen Nordpol, sondern arbeitet, vereinfacht gesagt, rein nach dem Trägheitsprinzip.<br />
<br />
Aus dem Schulunterricht ist den meisten das Experiment bekannt, bei dem jemand das abmontierte Rad eines Fahrrads an der Achse in den Händen hält; dreht sich das Rad nicht, ist es sehr leicht, es herumzuschwenken, dreht man es doch, ist es sehr schwer, seine Richtung zu ändern.<br />
Im Kurskreisel befindet sich also (mindestens) eine frei aufgehängte, möglichst schwere Scheibe, die von einem Elektromotor möglichst schnell gedreht wird. Diese Scheibe "wehrt" sich gegen jede Richtungsänderung des Flugzeugs und bleibt in der Richtung, in der sie initiiert wurde.<br />
<br />
Will man den Kurskreisel benutzen, muss man ihn zuerst mit dem Magnetkompass abgleichen; in den meisten Flugzeugen ist der Kurskreisel aber schon mit dem Magnetkompass verbunden, so dass er bei der Initiierung mit ihm abgeglichen wird, oder während des gesamten Fluges dem Magnetkompass folgt.<br />
Der Grund, warum der Kurskreisel ein wichtiges Instrument ist, auch wenn er dem Magnetkompass folgt, ist der, dass der Kurskreisel in bestimmten Situationen zur Richtungsmessung besser geeignet ist:<br />
Bei längeren Kurven, wie z.B. der oft gefragten halben ''Standardkurve'' (engl. ''standard turn'') von 180′ hängt die Anzeige des Magnetkompasses hinterher, und die Neigung des Flugzeugs, und mit ihm die des Magnetkompasses, bringt ihn zu fehlerhaften Messungen. Ebenso ist der Kurskreisel nicht anfällig für plötzliche Änderungen des Magnetfeldes, die etwa bei der Annäherung an Gebiete mit starken Funksendern oder magnetischen Mineralien auftreten.<br />
Deswegen nehmen Navigationssysteme oder Autopiloten normalerweise den Kurskreisel und nicht den Magnetkompass als primäre Referenz.<br />
Mit zunehmender Flugzeit wird aber auch der Kurskreisel ungenau, weshalb er auch nachjustiert werden muss.<br />
<br />
In einigen grösseren Flugzeugen kann man wählen, welches Kompasssystem sich nach dem anderen richtet; Das bestimmende wird als "Master-", das folgende als "Slave-" bezeichnet. <br />
<br />
Anmerkung: Die Begriffe ''Gyrokompass'' und ''Gyroskop'' werden fälschlicherweise oft synonym für 'Kurskreisel' verwendet, werden aber innerhalb der Fliegergemeinschaft als Begriff für 'Kurskreisel' normalerweise nicht missverstanden. <br />
<br />
= Höhenmesser =<br />
[[Image:Altimeter.png|right|Altmeter of default Cesna]]<br />
<br />
Per Definition ist ein '''Höhenmesser''' , (meistens "'''Altimeter'''" genannt) , ein Instrument, das die Höhe über einer festgelegten Ebene misst.<br />
<br />
Diese, sehr technisch gesprochene "festgelegte Ebene" ist in der Luftfahrt in der Regel der mittlere Meeresspiegel (''MSL'', von engl. ''mean sea level'') oder die Bodenhöhe unter dem Flugzeug (''GL'', von engl. ''ground level'').<br />
<br />
== Luftdruck ==<br />
Als Flieger wird man am häufigsten mit der Höhe "feet ASL", (engl. ''feet above sea level'') also ''Fuss über Meeresspiegel'' konfrontiert. Diese Höhe wird immer mit Hilfe des umgebenden Luftdrucks gemessen, ausser bei GPS. GPS-Höhenangaben sollten aber höchstens nur als Kontrolle verwendet werden, da das Bezugssystem für die Höhe in der Luftfahrt der Luftdruck ist.<br />
<br />
Internationale Einheit für die Flughöhe ist, bis auf wenige Ausnahmen, ''Fuss'' bzw. ''feet'', abgekürzt ''ft''.<br />
Ein ''feet'' entspricht 30.48cm, über den krummen Daumen gepeilt kann man also rechnen: "Feet durch 3 und etwas weniger = Meter "<br />
<br />
Da der Luftdruck variiert, muss der Höhenmesser justiert werden. Dazu stellt man den Luftdruckwähler des Altimeters auf den Wert ein, den man vom ATIS oder vom Tower durchgesagt bekommen hat. An einem müssigen Sommerabend, oder wenn der Flugplatz keinen Tower oder ATIS besitzt, kann man vor dem Start aber auch den Luftdruckwähler soweit drehen, bis der Höhenmesser die Höhe des Plugplatzes (die man natürlich kennt!) anzeigt.<br />
<br />
Ab einer gewissen Höhe, der ''Übergangshöhe'' (engl. ''transition level''), wird am Höhenmesser der sogenannte "Normaldruck" von 29.92 inHG eingestellt. Damit erreicht man, dass alle Flugzeuge den gleichen Bezugswert haben; Soll zum Beispiel ein Flugzeug in einem Hochdruckgebiet die Höhe 12000ft, ein anderes 13000ft halten, fliegt das eine vielleicht auf 12500ft, das andere auf 13500ft. Da beide Piloten aber auf ihrem Höhenmesser mit eingestelltem 29.92inHG Luftdruck die ihnen jeweils zugewiesene Flughöhe lesen, können beide mit 1000ft Höhenunterschied ihren Weg kreuzen, ohne zu kollidieren. Würde jeder Pilot den Luftdruck seines Startflugplatzes beibehalten, gäbe es am Himmel ein buntes Allerlei an Interpretationen der richtigen Flughöhe.<br />
Die Standard-Übergangshöhe ist je nach Land unterschiedlich, findet sich aber oft auf Flugkarten bzw. wird vom Tower festgelegt und durchgegeben.<br />
<br />
== Radar ==<br />
Der '''Radarhöhenmesser''' (engl. ''''radio altimeter'''') misst die Flughöhe uber Boden, also AGL (engl. ''''above ground level''''), in dem er das Echo seiner abgestrahlten Radarwellen interpretiert. Verwendet wird er im militärischen Bereich (Stichwort Tiefflug) und bei präzisen Instrumentenlandungen.</div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=De/FlightGear&diff=20333De/FlightGear2010-03-25T05:39:06Z<p>Maerchenprinz: </p>
<hr />
<div>{{Infobox Software<br />
| title = FlightGear<br />
| logo = fglogosm.jpg<br />
| image = FlightGear - 1903 Wright Flyer.jpg<br />
| alt = [[Wright Flyer (UIUC)|Wright Flyer]] in 0.9.9<br />
| developedby = FlightGear Entwickler & Mitwirkende<br />
| initialrelease = 17. Juli, 1997<br />
| latestrelease = 2.0.0<br />
| writtenin = C++<br />
| os = 32-bit Windows, Linux, Mac OS X, FreeBSD, Solaris oder IRIX<br />
| platform = Plattformübergreifend<br />
| developmentstatus = Aktiv (1996-)<br />
| type = Flugsimulator<br />
| license = [[GNU General Public License]]<br />
| website = http://www.flightgear.org/<br />
}}<br />
<br />
[[Image:OV10A-NASA-in-action.jpg|thumb|right|270px|NASA [[OV-10]] in FlightGear 1.0]]<br />
<br />
Der '''FlightGear Flight Simulator''' (oft mit '''FlightGear''' oder '''FGFS''' abgekürzt) ist ein ausgereifter, anspruchsvoller, quelloffener Flugsimulator und ist ausschliesslich von Freiwilligen erschaffen. FlightGear wird unter den Bestimmungen der [[GNU General Public License]] veröffentlicht. Er ist hauptsächlich in der Programmiersprache C++ geschrieben.<br />
<br />
Seit dem Projektstart im Jahre 1996 werden jedes Jahr noch detailliertere und realistischere Versionen veröffentlicht.<br />
<br />
Die neueste Veröffentlichung kann kostenlos unter [http://www.flightgear.org/Downloads/ http://www.flightgear.org/Downloads/] heruntergeladen werden, dazu gehören vorgefertigte Versionen für eine Reihe von Betriebssystemen, darunter Microsoft Windows (Win 32), Mac OS X, Linux, IRIX und Solaris.<br />
<br />
==Geschichte==<br />
<br />
Siehe auch: Hauptartikel Geschichte von FlightGear (engl.)<br />
{{main article|FlightGear History}}<br />
<br />
Die Entwicklung von FlightGear begann im Jahre 1996 mit einem Vorhaben, einen Flugsimulator durch die Mitarbeit einer Internet-Gemeinschaft von Grund auf neu zu erschaffen. Angeführt von Curtis Olsen begann dann 1997 die Ausarbeitung einer OpenGL-basierten Version. Von Anbeginn an steuerten viele Leute dem Projekt bei.<br />
<br />
FlightGear schloss andere Open-Source-Ressourcen wie das Flugdynamikmodell LaRCsim der NASA und öffentlich erhältliche Höhendaten mit ein. Die ersten funktionierenden ausführbaren Dateien, die OpenGL als Grafikcode benutzten, kamen 1997 heraus. Durch enthusiastische Arbeit entstanden in den folgenden Jahren stabilere und fortgeschrittene Versionen. Seit 2001 veröffentlichte das Team regelmässig neue Betaversionen, seit 2005 sorgt die Reife des Programms für ein immer grösseres und breiteres Publikum. 2007 fand mit der Version 1.0.0 der formale Austritt aus dem Betastadium statt, zehn Jahre nach der ersten Veröffentlichung von FlightGear.<br />
<br />
[[Image:FG-A-10.jpg|thumb|270px|3D-Cockpit einer [[A-10]], Version 1.0.0, 2008]]<br />
<br />
Version 1.9.0, herausgekommen im Jahr 2008, beinhaltete eine grosse Veränderung: Duch den Wechsel von [[PLIB]] zu [[OSG]] gingen zeitweilig einige <br />
Features wie 3D-Wolken und Schatten verloren, während andere, z.B. Partikel, die Simulation noch realistischer machten.<br />
<br />
==Software==<br />
<br />
Die Simulationsengine von FlightGear, also die Funktionseinheit, die die komplexen Berechnungen der Simulation durchführt, heisst [[SimGear]]. Sie wird sowohl als Endbenutzerapplikation als auch im akademischen Umfeld und zur Forschung verwendet, um Ideen im Bereich Flugsimulation realisieren zu können.<br />
An der grossen Breite unterschiedlichster Fluggeräte, die von [[:Category:Gliders|Segelflieger]]n über [[Helicopter|Helikopter]] bis hin zu [[:Category:Airliners|Verkehrflugzeugen]] und [[Military aircraft|Kampfjets]] reicht, lässt sich die Anpassungsfähigkeit von FlightGear ermessen. Diese Modelle wurden und werden von vielen unterschiedlichen Freiwilligen beigesteuert.<br />
<br />
Die Fluggeräte benutzen eine der drei primären Datenmodelle: JSBSim, YASim oder, ab Version 0.9.10, UIUC. Als Geländeengine wird zur Zeit TerraGear verwendet. Zu den Wettereffekten gehören 3D-Wolken, Beleuchtungseffekte und Tageszeit.<br />
<br />
===Flugdynamikmodell===<br />
<br />
Das [[Flight Dynamics Models|Flugdynamikmodell]] (FDM) bestimmt, wie die Flugeigenschaften eines Flugzeuges vom Programm simuliert werden. FlightGear benutzt eine Vielfalt von internen und importierten Flugmodellprojekten. Jedwedes Fluggerät muss für eines dieser Modelle programmiert werden. Zur Zeit ist FlightGear der einzige grafische Flugsimulator, der alle FDMs benutzt, wobei UIUC und YASim speziell für FlightGear entwickelt wurden.<br />
<br />
Frühere Versionen benutzten ein FDM, das auf dem NASA-Modell [[LaRCsim]] basierte; dieses wurde aber später durch flexiblere ersetzt.<br />
<br />
*[[JSBSim]] - Die voreingestellte FDM-Software seit dem Jahr 2000.<br />
*[[YASim]] - ein weiteres FDM, das andere Berechnungsmethoden verwendet. Eingeführt 2002 mit Version 0.7.9.<br />
*[[UIUC]] - entwickelt von der UIUC Applied Aerodynamics Group an der Universität von Illinois in Urbana-Champaign; benutzt auch LaRCsim.<br />
*FlightGear kann auch so eingestellt werden, dass es den Input externer Datenquellen wie z.B. Matlab verwenden kann.<br />
*Ebenso wurden FDMs für sehr spezielle Flieger wie etwa Gasballons oder Zeppeline geschrieben. <br />
<br />
===Abhängigkeiten von FlightGear===<br />
<br />
Anders als kommerzielle Softwaretitel ist das Hauptergebnis des FGFS-Projektes eine Ansammlung von Softwarecode. Um sie in ein nutzbares Programm zu verwandeln, muss sie für eine bestimmte Plattform kompiliert werden. Dazu werden Softwarebibliotheken, sogenannte Libraries gebraucht. Mit der Zeit hat FlightGear unterschiedliche Libraries verwendet. Die wichtigste hierbei ist [[SimGear]], das die zugrundeliegende Simulationseinheit darstellt. [[TerraGear]] gehört nicht zu den Abhängigkeiten, sondern ist einfach der Name des hauptsächlich benutztem Geländedatenprogramms. OpenAL wird als Audio-/Sound-Software verwendet, seit Version 0.9.5 auch mit Unterstützung für SDL. Vorher sorgte PLIB als Audio-/Sound-Software, dient aber nun nur noch als Unterstützung für Hardwareroutinen. [[OpenGL]] wird wegen seiner integrierten 3D-Grafikroutinen verwendet; andere Hardwarebeschleunigung (namentlich DirectX) wird nicht unterstützt. [[OpenSceneGraph]] ist ebenso in FlightGear integriert. Zuguterletzt wird der sogenannte Simple DirectMedia Layer als Softwarebibliothek beim Kompilieren benutzt. Einige der Abhängigkeiten variieren je nach Plattform, auf der kompiliert wird. Benutzer von FlightGear können den Code entweder selbst kompilieren, oder eines der für viele Plattformen bereits erhältlichen vorkompilierten ausführbaren Programme nutzen.<br />
<br />
==Hardware==<br />
<br />
Die Hardware, die für FlightGear benötigt wird, braucht auf jeden Fall Unterstützung für [[OpenGL]] und 3D-Hardwarebeschleunigung, wobei sich NVIDIA als bessere Lösung herausgestellt hat. Frühere Versionen unterstützten auch 3dfx-Grafikkarten, mit immer höheren Hardwareanforderungen wurde die Unterstützung allerdings eingestellt.<br />
<br />
[[Image:Fgrun-page2.jpg|thumb|left|270px|The [[FlightGear Launch Control|FlightGear Launcher]]]]<br />
<br />
==Erweiterungen und persönliche Anpassung==<br />
<br />
Es gibt Programme, die entweder ''IN'' FlightGear integriert arbeiten (Abhängigkeiten), oder solche, die ''MIT'' FlightGear arbeiten. Einige der Programme sind schon in den Veröffentlichungen des Projektes für spezifische Plattformen enthalten, andere werden unabhängig zur Verfügung gestellt, aber vom FGFS-Projekt beherbergt.<br />
Zu den bedeutenden Zusatzprogrammen gehören solche, die es dem Benutzer erlauben, FlightGear mit Hilfe einer grafischen Oberfläche (Frontend), und nicht mit Hilfe einer [[command line|Kommandozeile]] zu starten. Die ''FlightGear Launch Control'' mit der ''[[FG launcher]]''-Oberfläche wurde 2003 mit Version 0.9.3 eingeführt. ''[[KFreeFlight]]'' ist ebensolch ein Frontend für die UNIX-Arbeitsumgebung KDE, ''FGTools'' eine Alternative unter Windows und der ''FGKicker'' ein auf GTK+ basierendes Startprogramm.<br />
<br />
Zu den anderen signifikanten Programmen gehören Editoren und Projekte für Geländedaten. ''[[Atlas]]'' z.B. ist eine sich bewegende Landkarte, der ''[[Kelpie Flight Planner]]'' ein Java-basierter Flugroutenplaner für FlightGear. ''[[FlightGear Scenery Designer]]'' arbeitet mit Geländedaten und kann zum editieren der FlightGear-Szenerie benutzt werden. Das ''[[World Custom Scenery Project]]'' ist ein Projekt, das die Arbeit an der Verfeinerung der Szenerie koordiniert; Mit ''[[TaxiDraw]]'' kann man Startbahnen und Rollfelder von Flughäfen bearbeiten.<br />
<br />
===Flugzeuge etc.===<br />
<br />
Siehe auch Hauptartikel: Liste der Modelle (engl.)<br />
{{Main article|Table of models}}<br />
<br />
<br />
FlightGear begann mit einem Flugzeug namens Navion mit dem NASA-Flugdynamikmodell LaRCSim; Die Navion wurde im Jahr 2000 von der Cessna 172 abgelöst. Die Weiterentwicklung sowohl von UIUC wie auch von JSBSim brachte mehrere Flugzeuge mit sich, genauso wie die Entwicklung von YASim, das mittlerweile das Haupt-FDM von FlightGear darstellt. Von den über 230 Fluggeräten, die für Version 1.9.0 erhältlich sind, ist nur eine Auswahl im Basispaket enthalten.<br />
<br />
[[Image:EHAM.jpg|thumb|270px|[[Boeing 737-300|Boeing 733]] docked in the [[EHAM]] scenery]]<br />
===Szenerie===<br />
<br />
Siehe auch Hauptartikel: Szenerie (engl.)<br />
{{Main article|Scenery}}<br />
<br />
Das ''[[world scenery|FlightGear World Scenery Project]]'' beinhaltet Höhen- und Landschaftsdaten der gesamten Erde. Objekte wie Flughafenterminals, Windmühlen oder Brücken sind in der [[FlightGear Scenery Database|Scenerie-Datenbank]] zusammengefasst.<br />
<br />
===Netzwerk und Multidisplay===<br />
<br />
Etliche Netzwerkoptionen erlauben es den verschiedenen Instanzen von FlightGear untereinander zu kommunizieren. Ein [[Multiplayer Howto|Mehrspieler]]-Protokoll steht zur Verfügung, um FlightGear in einem lokalen Netzwerk mit mehrern Flugzeugen zu betreiben, was man zum Formationsflug oder zur Simulation eines [[ATC|Kontrollturms]]s nutzen kann. Schnell entwickelte sich die Mehrspieler-Option dazu, FlightGear auch über das Internet spielen zu können. Ein weiteres Feature ist die Möglichkeit, auf einer Google-Maps basierten Karte zu beobachten, wo sich die anderen FG-Flieger gerade befinden.<br />
Mehrere Instanzen von FlightGear können so synchronisiert werden, dass mehrere Bildschirme gleichzeitig benutz werden können. Laufen alle Instanzen beständig mit der gleichen Frequenz, ist eine gute und akkurate Synchronization der Bildschirme möglich.<br />
<br />
==FlightGear-Code oder Binärdatei?==<br />
<br />
Der Grossteil kommerzieller Software ist als ausführbare Dateien, also als sogenannte Binaries oder Executables, erhältlich. Das FlightGear-Projekt veröffentlicht im Gegensatz dazu an den jeweiligen Erscheinungsdaten nur den zugrundeliegenden Code. Um ein lauffähiges Programm daraus zu schaffen, muss dieser Code kompiliert werden; Dazu werden mehrere spezielle Softwarebibliotheken benötigt, davon sind einige generell, andere spezifisch nötig, je nach Plattform und Betriebssystem. Da für die breite Masse diese Prozedur zu schwierig ist, werden von den FGFS-Mitwirkenden verschiedene plattform- und betriebssystem-spezifisch vorkompilierte Binaries zur Verfügnug gestellt. Diese können sich hinsichtlich ihrer Stabilität, Leistung, Abhängigkeiten und Aktualität unterscheiden. Zum Beispiel laufen einige ältere Binaries auf Mac OS 9, für Mac OS X werden allerdings neuere Versionen benötigt.<br />
<br />
Als Ende 2007 der zu der Zeit neueste Code unter der Bezeichnung 0.9.11-pre1 (Vorveröffentlichung) und 0.9.10 (endgültige Veröffentlichung) herauskam, variierten die dazugehörigen Binaries stark untereinander. Hier einige Beispiele:<br />
<br />
*Win-32 - als Paket mit 138 Mb (v0.9.10) (für Windows 98, 2000, ME, 32-bit XP)<br />
*Linux- pre-built-Paket für spezifische Linux-Distributionen<br />
**Slackware-Paket (v0.9.10), Fedora Core 2,3,4 Pakete (v0.9.10), Pardus (v0.9.10), Debian (v0.9.9) <br />
*Solaris-Pakete entweder für SPARC- oder x86-Prozessoren.<br />
**SPARC (v0.9.8), x86 (v0.9.9) <br />
*Silicon Graphics IRIX<br />
**SGI Binaries für (v0.9.9) <br />
*Mac OS X<br />
**Mac OS 10.4 (v0.9.10)<br />
**Mac OS 10.3 (v0.9.9) <br />
*FreeBSD-Paket für (v0.9.10)<br />
<br />
==FlightGear-Rezensionen==<br />
<br />
Siehe auch Hauptartikel FlightGear-Rezensionen (engl.)<br />
{{Main article|FlightGear Reviews}}<br />
<br />
==Externe Links==<br />
{{Main article|Links}}<br />
*[http://www.flightgear.org Offizielle Website]<br />
*[http://fgfs.i-net.hu/ Community Website] <br />
*[http://www.caballerosaguila.shialeweb.com/ Club Website] (Spanish)<br />
*[http://gallery.flightgear.org.uk/ Screenshots der Entwicklerversion]<br />
<br />
==Quellen==<br />
* [http://www.flightgear.org/proposal-3.0.1 Original Flight Gear Proposal] by David L. Murr (Revision 3.0.1)<br />
* [http://en.wikipedia.org/wiki/FlightGear Wikipedia]<br />
<br />
[[en:FlightGear]]<br />
[[es:FlightGear]]<br />
[[nl:FlightGear]]</div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=De/FlightGear&diff=20332De/FlightGear2010-03-25T05:29:35Z<p>Maerchenprinz: </p>
<hr />
<div>{{Infobox Software<br />
| title = FlightGear<br />
| logo = fglogosm.jpg<br />
| image = FlightGear - 1903 Wright Flyer.jpg<br />
| alt = [[Wright Flyer (UIUC)|Wright Flyer]] in 0.9.9<br />
| developedby = FlightGear Entwickler & Mitwirkende<br />
| initialrelease = 17. Juli, 1997<br />
| latestrelease = 2.0.0<br />
| writtenin = C++<br />
| os = 32-bit Windows, Linux, Mac OS X, FreeBSD, Solaris oder IRIX<br />
| platform = Plattformübergreifend<br />
| developmentstatus = Aktiv (1996-)<br />
| type = Flugsimulator<br />
| license = [[GNU General Public License]]<br />
| website = http://www.flightgear.org/<br />
}}<br />
<br />
[[Image:OV10A-NASA-in-action.jpg|thumb|right|270px|NASA [[OV-10]] in FlightGear 1.0]]<br />
<br />
Der '''FlightGear Flight Simulator''' (oft mit '''FlightGear''' oder '''FGFS''' abgekürzt) ist ein ausgereifter, anspruchsvoller, quelloffener Flugsimulator und ist ausschliesslich von Freiwilligen erschaffen. FlightGear wird unter den Bestimmungen der [[GNU General Public License]] veröffentlicht. Es ist hauptsächlich in der Programmiersprache C++ geschrieben.<br />
<br />
Seit dem Projektstart im Jahre 1996 werden jedes Jahr noch detailliertere und realistischere Versionen veröffentlicht.<br />
<br />
Die neueste Veröffentlichung kann kostenlos unter [http://www.flightgear.org/Downloads/ http://www.flightgear.org/Downloads/] heruntergeladen werden, dazu gehören vorgefertigte Versionen für eine Reihe von Betriebssystemen, darunter Microsoft Windows (Win 32), Mac OS X, Linux, IRIX und Solaris.<br />
<br />
==Geschichte==<br />
<br />
Siehe auch: Hauptartikel Geschichte von FlightGear (engl.)<br />
{{main article|FlightGear History}}<br />
<br />
Die Entwicklung von FlightGear begann im Jahre 1996 mit einem Vorhaben, einen Flugsimulator durch die Mitarbeit einer Internet-Gemeinschaft von Grund auf neu zu erschaffen. Angeführt von Curtis Olsen begann dann 1997 die Ausarbeitung einer OpenGL-basierten Version. Von Anbeginn an steuerten viele Leute dem Projekt bei.<br />
<br />
FlightGear schloss andere Open-Source-Ressourcen wie das Flugdynamikmodell LaRCsim der NASA und öffentlich erhältliche Höhendaten mit ein. Die ersten funktionierenden ausführbaren Dateien, die OpenGL als Grafikcode benutzten, kamen 1997 heraus. Durch enthusiastische Arbeit entstanden in den folgenden Jahren stabilere und fortgeschrittene Versionen. Seit 2001 veröffentlichte das Team regelmässig neue Betaversionen, seit 2005 sorgt die Reife des Programms für ein immer grösseres und breiteres Publikum. 2007 fand mit der Version 1.0.0 der formale Austritt aus dem Betastadium statt, zehn Jahre nach der ersten Veröffentlichung von FlightGear.<br />
<br />
[[Image:FG-A-10.jpg|thumb|270px|3D-Cockpit einer [[A-10]], Version 1.0.0, 2008]]<br />
<br />
<br />
Version 1.9.0, herausgekommen im Jahr 2008, beinhaltete eine grosse Veränderung: Duch den Wechsel von [[PLIB]] zu [[OSG]] gingen zeitweilig einige <br />
Features wie 3D-Wolken und Schatten verloren, während andere, z.B. Partikel, die Simulation noch realistischer machten.<br />
<br />
==Software==<br />
<br />
Die Simulationsengine von FlightGear, also die Funktionseinheit, die die komplexen Berechnungen der Simulation durchführt, heisst [[SimGear]]. Sie wird sowohl als Endbenutzerapplikation als auch im akademischen Umfeld und zur Forschung verwendet, um Ideen im Bereich Flugsimulation realisieren zu können.<br />
An der grossen Breite unterschiedlichster Fluggeräte, die von [[:Category:Gliders|Segelflieger]]n über [[Helicopter|Helikopter]] bis hin zu [[:Category:Airliners|Verkehrflugzeugen]] und [[Military aircraft|Kampfjets]] reicht, lässt sich die Anpassungsfähigkeit von FlightGear ermessen. Diese Modelle wurden und werden von vielen unterschiedlichen Freiwilligen beigesteuert.<br />
<br />
Die Fluggeräte benutzen eine der drei primären Datenmodelle: JSBSim, YASim oder, ab Version 0.9.10, UIUC. Zur Zeit wird. Als Geländeengine wird zur Zeit TerraGear verwendet. Zu den Wettereffekten gehören 3D-Wolken, Beleuchtungseffekte und Tageszeit.<br />
<br />
===Flugdynamikmodell===<br />
<br />
Das [[Flight Dynamics Models|Flugdynamikmodell]] (FDM) bestimmt, wie die Flugeigenschaften eines Flugzeuges vom Programm simuliert werden. FlightGear benutzt eine Vielfalt von internen und importierten Flugmodellprojekten. Jedwedes Fluggerät muss für eines dieser Modelle programmiert werden. Zur Zeit ist FlightGear der einzige grafische Flugsimulator, der alle FDMs benutzt, wobei UIUC und YASim speziell für FlightGear entwickelt wurden.<br />
<br />
Frühere Versionen benutzten ein FDM, das auf dem NASA-Modell [[LaRCsim]] basierte; dieses wurde aber später durch flexiblere ersetzt.<br />
<br />
*[[JSBSim]] - Die voreingestellte FDM-Software seit dem Jahr 2000.<br />
*[[YASim]] - ein weiteres FDM, das andere Berechnungsmethoden verwendet. Eingeführt 2002 mit Version 0.7.9.<br />
*[[UIUC]] - entwickelt von der UIUC Applied Aerodynamics Group an der Universität von Illinois in Urbana-Champaign; benutzt auch LaRCsim.<br />
*FlightGear kann auch so eingestellt werden, dass es den Input externer Datenquellen wie z.B. Matlab verwenden kann.<br />
*Ebenso wurden FDMs für sehr spezielle Flieger wie etwa Gasballons oder Zeppeline geschrieben. <br />
<br />
===Abhängigkeiten von FlightGear===<br />
<br />
Anders als kommerzielle Softwaretitel ist das Hauptergebnis des FGFS-Projektes eine Ansammlung von Softwarecode. Um sie in ein nutzbares Programm zu verwandeln, muss sie für eine bestimmte Plattform kompiliert werden. Dazu werden Softwarebibliotheken, sogenannte Libraries gebraucht. Mit der Zeit hat FlightGear unterschiedliche Libraries verwendet. Die wichtigste hierbei ist [[SimGear]], das die zugrundeliegende Simulationseinheit darstellt. [[TerraGear]] gehört nicht zu den Abhängigkeiten, sondern ist einfach der Name des hauptsächlich benutztem Geländedatenprogramms. OpenAL wird als Audio-/Sound-Software verwendet, seit Version 0.9.5 auch mit Unterstützung für SDL. Vorher sorgte PLIB als Audio-/Sound-Software, dient aber nun nur noch als Unterstützung für Hardwareroutinen. [[OpenGL]] wird wegen seiner integrierten 3D-Grafikroutinen verwendet; andere Hardwarebeschleunigung (namentlich DirectX) wird nicht unterstützt. [[OpenSceneGraph]] ist ebenso in FlightGear integriert. Zuguterletzt wird der sogenannte Simple DirectMedia Layer als Softwarebibliothek beim Kompilieren benutzt. Einige der Abhängigkeiten variieren je nach Plattform, auf der kompiliert wird. Benutzer von FlightGear können den Code entweder selbst kompilieren, oder eines der für viele Plattformen bereits erhältlichen vorkompilierten ausführbaren Programme nutzen.<br />
<br />
==Hardware==<br />
<br />
Die Hardware, die für FlightGear benötigt wird, braucht auf jeden Fall Unterstützung für [[OpenGL]] und 3D-Hardwarebeschleunigung, wobei sich NVIDIA als bessere Lösung herausgestellt hat. Frühere Versionen unterstützten auch 3dfx-Grafikkarten, mit immer höheren Hardwareanforderungen wurde die Unterstützung allerdings eingestellt.<br />
<br />
[[Image:Fgrun-page2.jpg|thumb|left|270px|The [[FlightGear Launch Control|FlightGear Launcher]]]]<br />
<br />
==Erweiterungen und persönliche Anpassung==<br />
<br />
Es gibt Programme, die entweder ''IN'' FlightGear integriert arbeiten (Abhängigkeiten), oder solche, die ''MIT'' FlightGear arbeiten. Einige der Programme sind schon in den Veröffentlichungen des Projektes für spezifische Plattformen enthalten, andere werden unabhängig zur Verfügung gestellt, aber vom FGFS-Projekt beherbergt.<br />
Zu den bedeutenden Zusatzprogrammen gehören solche, die es dem Benutzer erlauben, FlightGear mit Hilfe einer grafischen Oberfläche (Frontend), und nicht mit Hilfe einer [[command line|Kommandozeile]] zu starten. Die ''FlightGear Launch Control'' mit der ''[[FG launcher]]''-Oberfläche wurde 2003 mit Version 0.9.3 eingeführt. ''[[KFreeFlight]]'' ist ebensolch ein Frontend für die UNIX-Arbeitsumgebung KDE, ''FGTools'' eine Alternative unter Windows und der ''FGKicker'' ein auf GTK+ basierendes Startprogramm.<br />
<br />
Zu den anderen signifikanten Programmen gehören Editoren und Projekte für Geländedaten. ''[[Atlas]]'' z.B. ist eine sich bewegende Landkarte, der ''[[Kelpie Flight Planner]]'' ein Java-basierter Flugroutenplaner für FlightGear. ''[[FlightGear Scenery Designer]]'' arbeitet mit Geländedaten und kann zum editieren der FlightGear-Szenerie benutzt werden. Das ''[[World Custom Scenery Project]]'' ist ein Projekt, das die Arbeit an der Verfeinerung der Szenerie koordiniert; Mit ''[[TaxiDraw]]'' kann man Startbahnen und Rollfelder von Flughäfen bearbeiten.<br />
<br />
===Flugzeuge etc.===<br />
<br />
Siehe auch Hauptartikel: Liste der Modelle (engl.)<br />
{{Main article|Table of models}}<br />
<br />
<br />
FlightGear begann mit einem Flugzeug namens Navion mit dem NASA-Flugdynamikmodell LaRCSim; Die Navion wurde im Jahr 2000 von der Cessna 172 abgelöst. Die Weiterentwicklung sowohl von UIUC wie auch von JSBSim brachte mehrere Flugzeuge mit sich, genauso wie die Entwicklung von YASim, das mittlerweile das Haupt-FDM von FlightGear darstellt. Von den über 230 Fluggeräten, die für Version 1.9.0 erhältlich sind, ist nur eine Auswahl im Basispaket enthalten.<br />
<br />
[[Image:EHAM.jpg|thumb|270px|[[Boeing 737-300|Boeing 733]] docked in the [[EHAM]] scenery]]<br />
===Szenerie===<br />
<br />
Siehe auch Hauptartikel: Szenerie (engl.)<br />
{{Main article|Scenery}}<br />
<br />
Das ''[[world scenery|FlightGear World Scenery Project]]'' beinhaltet Höhen- und Landschaftsdaten der gesamten Erde. Objekte wie Flughafenterminals, Windmühlen oder Brücken sind in der [[FlightGear Scenery Database|Scenerie-Datenbank]] zusammengefasst.<br />
<br />
===Netzwerk und Multidisplay===<br />
<br />
Etliche Netzwerkoptionen erlauben es den verschiedenen Instanzen von FlightGear untereinander zu kommunizieren. Ein [[Multiplayer Howto|Mehrspieler]]-Protokoll steht zur Verfügung, um FlightGear in einem lokalen Netzwerk mit mehrern Flugzeugen zu betreiben, was man zum Formationsflug oder zur Simulation eines [[ATC|Kontrollturms]]s nutzen kann. Schnell entwickelte sich die Mehrspieler-Option dazu, FlightGear auch über das Internet spielen zu können. Ein weiteres Feature ist die Möglichkeit, auf einer Google-Maps basierten Karte zu beobachten, wo sich die anderen FG-Flieger gerade befinden.<br />
Mehrere Instanzen von FlightGear können so synchronisiert werden, dass mehrere Bildschirme gleichzeitig benutz werden können. Laufen alle Instanzen beständig mit der gleichen Frequenz, ist eine gute und akkurate Synchronization der Bildschirme möglich.<br />
<br />
==FlightGear-Code oder Binärdatei?==<br />
<br />
Der Grossteil kommerzieller Software ist als ausführbare Dateien, also als sogenannte Binaries oder Executables, erhältlich. Das FlightGear-Projekt veröffentlicht im Gegensatz dazu an den jeweiligen Erscheinungsdaten nur den zugrundeliegenden Code. Um ein lauffähiges Programm daraus zu schaffen, muss dieser Code kompiliert werden; Dazu werden mehrere spezielle Softwarebibliotheken benötigt, davon sind einige generell, andere spezifisch nötig, je nach Plattform und Betriebssystem. Da für die breite Masse diese Prozedur zu schwierig ist, werden von den FGFS-Mitwirkenden verschiedene plattform- und betriebssystem-spezifisch vorkompilierte Binaries zur Verfügnug gestellt. Diese können sich hinsichtlich ihrer Stabilität, Leistung, Abhängigkeiten und Aktualität unterscheiden. Zum Beispiel laufen einige ältere Binaries auf Mac OS 9, für Mac OS X werden allerdings neuere Versionen benötigt.<br />
<br />
Als Ende 2007 der zu der Zeit neueste Code unter der Bezeichnung 0.9.11-pre1 (Vorveröffentlichung) und 0.9.10 (endgültige Veröffentlichung) herauskam, variierten die dazugehörigen Binaries stark untereinander. Hier einige Beispiele:<br />
<br />
*Win-32 - als Paket mit 138 Mb (v0.9.10) (für Windows 98, 2000, ME, 32-bit XP)<br />
*Linux- pre-built-Paket für spezifische Linux-Distributionen<br />
**Slackware-Paket (v0.9.10), Fedora Core 2,3,4 Pakete (v0.9.10), Pardus (v0.9.10), Debian (v0.9.9) <br />
*Solaris-Pakete entweder für SPARC- oder x86-Prozessoren.<br />
**SPARC (v0.9.8), x86 (v0.9.9) <br />
*Silicon Graphics IRIX<br />
**SGI Binaries für (v0.9.9) <br />
*Mac OS X<br />
**Mac OS 10.4 (v0.9.10)<br />
**Mac OS 10.3 (v0.9.9) <br />
*FreeBSD-Paket für (v0.9.10)<br />
<br />
==FlightGear-Rezensionen==<br />
<br />
Siehe auch Hauptartikel FlightGear-Rezensionen (engl.)<br />
{{Main article|FlightGear Reviews}}<br />
<br />
==Externe Links==<br />
{{Main article|Links}}<br />
*[http://www.flightgear.org Offizielle Website]<br />
*[http://fgfs.i-net.hu/ Community Website] <br />
*[http://www.caballerosaguila.shialeweb.com/ Club Website] (Spanish)<br />
*[http://gallery.flightgear.org.uk/ Screenshots der Entwicklerversion]<br />
<br />
==Quellen==<br />
* [http://www.flightgear.org/proposal-3.0.1 Original Flight Gear Proposal] by David L. Murr (Revision 3.0.1)<br />
* [http://en.wikipedia.org/wiki/FlightGear Wikipedia]<br />
<br />
[[en:FlightGear]]<br />
[[es:FlightGear]]<br />
[[nl:FlightGear]]</div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=De/FlightGear&diff=20331De/FlightGear2010-03-25T05:24:53Z<p>Maerchenprinz: </p>
<hr />
<div>{{Infobox Software<br />
| title = FlightGear<br />
| logo = fglogosm.jpg<br />
| image = FlightGear - 1903 Wright Flyer.jpg<br />
| alt = [[Wright Flyer (UIUC)|Wright Flyer]] in 0.9.9<br />
| developedby = FlightGear Entwickler & Mitwirkende<br />
| initialrelease = 17. Juli, 1997<br />
| latestrelease = 2.0.0<br />
| writtenin = C++<br />
| os = 32-bit Windows, Linux, Mac OS X, FreeBSD, Solaris oder IRIX<br />
| platform = Plattformübergreifend<br />
| developmentstatus = Aktiv (1996-)<br />
| type = Flugsimulator<br />
| license = [[GNU General Public License]]<br />
| website = http://www.flightgear.org/<br />
}}<br />
<br />
[[Image:OV10A-NASA-in-action.jpg|thumb|right|270px|NASA [[OV-10]] in FlightGear 1.0]]<br />
<br />
Der '''FlightGear Flight Simulator''' (oft mit '''FlightGear''' oder '''FGFS''' abgekürzt) ist ein ausgereifter, anspruchsvoller, quelloffener Flugsimulator und ist ausschliesslich von Freiwilligen erschaffen. FlightGear wird unter den Bestimmungen der [[GNU General Public License]] veröffentlicht. Es ist hauptsächlich in der Programmiersprache C++ geschrieben.<br />
<br />
Seit dem Projektstart im Jahre 1996 werden jedes Jahr noch detailliertere und realistischere Versionen veröffentlicht.<br />
<br />
Die neueste Veröffentlichung kann kostenlos unter [http://www.flightgear.org/Downloads/ http://www.flightgear.org/Downloads/] heruntergeladen werden, dazu gehören vorgefertigte Versionen für eine Reihe von Betriebssystemen, darunter Microsoft Windows (Win 32), Mac OS X, Linux, IRIX und Solaris.<br />
<br />
==Geschichte==<br />
<br />
Siehe auch: Hauptartikel Geschichte von FlightGear (engl.)<br />
{{main article|FlightGear History}}<br />
<br />
Die Entwicklung von FlightGear begann im Jahre 1996 mit einem Vorhaben, das online gemacht wurde, und angepassten 3D-Grafikcode benutzen sollte. Angeführt von Curtis Olsen begann dann 1997 die Ausarbeitung einer OpenGL-basierten Version. Von Anbeginn an steuerten viele Leute dem Projekt bei.<br />
<br />
FlightGear schloss andere Open-Source-Ressourcen wie das Flugdynamikmodell LaRCsim der NASA und öffentlich erhältliche Höhendaten mit ein. Die ersten funktionierenden ausführbaren Dateien, die OpenGL als Grafikcode benutzten, kamen 1997 heraus. Durch enthusiastische Arbeit entstanden in den folgenden Jahren stabilere und fortgeschrittene Versionen. Seit 2001 veröffentlichte das Team regelmässig neue Betaversionen, seit 2005 sorgt die Reife des Programms für ein immer grösseres und breiteres Publikum. 2007 fand mit der Version 1.0.0 der formale Austritt aus dem Betastadium statt, zehn Jahre nach der ersten Veröffentlichung von FlightGear.<br />
<br />
[[Image:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]<br />
<br />
<br />
Version 1.9.0, herausgekommen im Jahr 2008, beinhaltete eine grosse Veränderung: Duch den Wechsel von [[PLIB]] zu [[OSG]] gingen zeitweilig einige <br />
Features wie 3D-Wolken und Schatten verloren, während andere, z.B. Partikel, die Simulation noch realistischer machten.<br />
<br />
==Software==<br />
<br />
Die Simulationsengine von FlightGear, also die Funktionseinheit, die die komplexen Berechnungen der Simulation durchführt, heisst [[SimGear]]. Sie wird sowohl als Endbenutzerapplikation als auch im akademischen Umfeld und zur Forschung verwendet, um Ideen im Bereich Flugsimulation realisieren zu können.<br />
An der grossen Breite unterschiedlichster Fluggeräte, die von [[:Category:Gliders|Segelflieger]]n über [[Helicopter|Helikopter]] bis hin zu [[:Category:Airliners|Verkehrflugzeugen]] und [[Military aircraft|Kampfjets]] reicht, lässt sich die Anpassungsfähigkeit von FlightGear ermessen. Diese Modelle wurden und werden von vielen unterschiedlichen Freiwilligen beigesteuert.<br />
<br />
Die Fluggeräte benutzen eine der drei primären Datenmodelle: JSBSim, YASim oder, ab Version 0.9.10, UIUC. Zur Zeit wird. Als Geländeengine wird zur Zeit TerraGear verwendet. Zu den Wettereffekten gehören 3D-Wolken, Beleuchtungseffekte und Tageszeit.<br />
<br />
===Flugdynamikmodell===<br />
<br />
Das [[Flight Dynamics Models|Flugdynamikmodell]] (FDM) bestimmt, wie die Flugeigenschaften eines Flugzeuges vom Programm simuliert werden. FlightGear benutzt eine Vielfalt von internen und importierten Flugmodellprojekten. Jedwedes Fluggerät muss für eines dieser Modelle programmiert werden. Zur Zeit ist FlightGear der einzige grafische Flugsimulator, der alle FDMs benutzt, wobei UIUC und YASim speziell für FlightGear entwickelt wurden.<br />
<br />
Frühere Versionen benutzten ein FDM, das auf dem NASA-Modell [[LaRCsim]] basierte; dieses wurde aber später durch flexiblere ersetzt.<br />
<br />
*[[JSBSim]] - Die voreingestellte FDM-Software seit dem Jahr 2000.<br />
*[[YASim]] - ein weiteres FDM, das andere Berechnungsmethoden verwendet. Eingeführt 2002 mit Version 0.7.9.<br />
*[[UIUC]] - entwickelt von der UIUC Applied Aerodynamics Group an der Universität von Illinois in Urbana-Champaign; benutzt auch LaRCsim.<br />
*FlightGear kann auch so eingestellt werden, dass es den Input externer Datenquellen wie z.B. Matlab verwenden kann.<br />
*Ebenso wurden FDMs für sehr spezielle Flieger wie etwa Gasballons oder Zeppeline geschrieben. <br />
<br />
===Abhängigkeiten von FlightGear===<br />
<br />
Anders als kommerzielle Softwaretitel ist das Hauptergebnis des FGFS-Projektes eine Ansammlung von Softwarecode. Um sie in ein nutzbares Programm zu verwandeln, muss sie für eine bestimmte Plattform kompiliert werden. Dazu werden Softwarebibliotheken, sogenannte Libraries gebraucht. Mit der Zeit hat FlightGear unterschiedliche Libraries verwendet. Die wichtigste hierbei ist [[SimGear]], das die zugrundeliegende Simulationseinheit darstellt. [[TerraGear]] gehört nicht zu den Abhängigkeiten, sondern ist einfach der Name des hauptsächlich benutztem Geländedatenprogramms. OpenAL wird als Audio-/Sound-Software verwendet, seit Version 0.9.5 auch mit Unterstützung für SDL. Vorher sorgte PLIB als Audio-/Sound-Software, dient aber nun nur noch als Unterstützung für Hardwareroutinen. [[OpenGL]] wird wegen seiner integrierten 3D-Grafikroutinen verwendet; andere Hardwarebeschleunigung (namentlich DirectX) wird nicht unterstützt. [[OpenSceneGraph]] ist ebenso in FlightGear integriert. Zuguterletzt wird der sogenannte Simple DirectMedia Layer als Softwarebibliothek beim Kompilieren benutzt. Einige der Abhängigkeiten variieren je nach Plattform, auf der kompiliert wird. Benutzer von FlightGear können den Code entweder selbst kompilieren, oder eines der für viele Plattformen bereits erhältlichen vorkompilierten ausführbaren Programme nutzen.<br />
<br />
==Hardware==<br />
<br />
Die Hardware, die für FlightGear benötigt wird, braucht auf jeden Fall Unterstützung für [[OpenGL]] und 3D-Hardwarebeschleunigung, wobei sich NVIDIA als bessere Lösung herausgestellt hat. Frühere Versionen unterstützten auch 3dfx-Grafikkarten, mit immer höheren Hardwareanforderungen wurde die Unterstützung allerdings eingestellt.<br />
<br />
[[Image:Fgrun-page2.jpg|thumb|left|270px|The [[FlightGear Launch Control|FlightGear Launcher]]]]<br />
<br />
==Erweiterungen und persönliche Anpassung==<br />
<br />
Es gibt Programme, die entweder ''IN'' FlightGear integriert arbeiten (Abhängigkeiten), oder solche, die ''MIT'' FlightGear arbeiten. Einige der Programme sind schon in den Veröffentlichungen des Projektes für spezifische Plattformen enthalten, andere werden unabhängig zur Verfügung gestellt, aber vom FGFS-Projekt beherbergt.<br />
Zu den bedeutenden Zusatzprogrammen gehören solche, die es dem Benutzer erlauben, FlightGear mit Hilfe einer grafischen Oberfläche (Frontend), und nicht mit Hilfe einer [[command line|Kommandozeile]] zu starten. Die ''FlightGear Launch Control'' mit der ''[[FG launcher]]''-Oberfläche wurde 2003 mit Version 0.9.3 eingeführt. ''[[KFreeFlight]]'' ist ebensolch ein Frontend für die UNIX-Arbeitsumgebung KDE, ''FGTools'' eine Alternative unter Windows und der ''FGKicker'' ein auf GTK+ basierendes Startprogramm.<br />
<br />
Zu den anderen signifikanten Programmen gehören Editoren und Projekte für Geländedaten. ''[[Atlas]]'' z.B. ist eine sich bewegende Landkarte, der ''[[Kelpie Flight Planner]]'' ein Java-basierter Flugroutenplaner für FlightGear. ''[[FlightGear Scenery Designer]]'' arbeitet mit Geländedaten und kann zum editieren der FlightGear-Szenerie benutzt werden. Das ''[[World Custom Scenery Project]]'' ist ein Projekt, das die Arbeit an der Verfeinerung der Szenerie koordiniert; Mit ''[[TaxiDraw]]'' kann man Startbahnen und Rollfelder von Flughäfen bearbeiten.<br />
<br />
===Flugzeuge etc.===<br />
<br />
Siehe auch Hauptartikel: Liste der Modelle (engl.)<br />
{{Main article|Table of models}}<br />
<br />
<br />
FlightGear begann mit einem Flugzeug namens Navion mit dem NASA-Flugdynamikmodell LaRCSim; Die Navion wurde im Jahr 2000 von der Cessna 172 abgelöst. Die Weiterentwicklung sowohl von UIUC wie auch von JSBSim brachte mehrere Flugzeuge mit sich, genauso wie die Entwicklung von YASim, das mittlerweile das Haupt-FDM von FlightGear darstellt. Von den über 230 Fluggeräten, die für Version 1.9.0 erhältlich sind, ist nur eine Auswahl im Basispaket enthalten.<br />
<br />
[[Image:EHAM.jpg|thumb|270px|[[Boeing 737-300|Boeing 733]] docked in the [[EHAM]] scenery]]<br />
===Szenerie===<br />
<br />
Siehe auch Hauptartikel: Szenerie (engl.)<br />
{{Main article|Scenery}}<br />
<br />
Das ''[[world scenery|FlightGear World Scenery Project]]'' beinhaltet Höhen- und Landschaftsdaten der gesamten Erde. Objekte wie Flughafenterminals, Windmühlen oder Brücken sind in der [[FlightGear Scenery Database|Scenerie-Datenbank]] zusammengefasst.<br />
<br />
===Netzwerk und Multidisplay===<br />
<br />
Etliche Netzwerkoptionen erlauben es den verschiedenen Instanzen von FlightGear untereinander zu kommunizieren. Ein [[Multiplayer Howto|Mehrspieler]]-Protokoll steht zur Verfügung, um FlightGear in einem lokalen Netzwerk mit mehrern Flugzeugen zu betreiben, was man zum Formationsflug oder zur Simulation eines [[ATC|Kontrollturms]]s nutzen kann. Schnell entwickelte sich die Mehrspieler-Option dazu, FlightGear auch über das Internet spielen zu können. Ein weiteres Feature ist die Möglichkeit, auf einer Google-Maps basierten Karte zu beobachten, wo sich die anderen FG-Flieger gerade befinden.<br />
Mehrere Instanzen von FlightGear können so synchronisiert werden, dass mehrere Bildschirme gleichzeitig benutz werden können. Laufen alle Instanzen beständig mit der gleichen Frequenz, ist eine gute und akkurate Synchronization der Bildschirme möglich.<br />
<br />
==FlightGear-Code oder Binärdatei?==<br />
<br />
Der Grossteil kommerzieller Software ist als ausführbare Dateien, also als sogenannte Binaries oder Executables, erhältlich. Das FlightGear-Projekt veröffentlicht im Gegensatz dazu an den jeweiligen Erscheinungsdaten nur den zugrundeliegenden Code. Um ein lauffähiges Programm daraus zu schaffen, muss dieser Code kompiliert werden; Dazu werden mehrere spezielle Softwarebibliotheken benötigt, davon sind einige generell, andere spezifisch nötig, je nach Plattform und Betriebssystem. Da für die breite Masse diese Prozedur zu schwierig ist, werden von den FGFS-Mitwirkenden verschiedene plattform- und betriebssystem-spezifisch vorkompilierte Binaries zur Verfügnug gestellt. Diese können sich hinsichtlich ihrer Stabilität, Leistung, Abhängigkeiten und Aktualität unterscheiden. Zum Beispiel laufen einige ältere Binaries auf Mac OS 9, für Mac OS X werden allerdings neuere Versionen benötigt.<br />
<br />
Als Ende 2007 der zu der Zeit neueste Code unter der Bezeichnung 0.9.11-pre1 (Vorveröffentlichung) und 0.9.10 (endgültige Veröffentlichung) herauskam, variierten die dazugehörigen Binaries stark untereinander. Hier einige Beispiele:<br />
<br />
*Win-32 - als Paket mit 138 Mb (v0.9.10) (für Windows 98, 2000, ME, 32-bit XP)<br />
*Linux- pre-built-Paket für spezifische Linux-Distributionen<br />
**Slackware-Paket (v0.9.10), Fedora Core 2,3,4 Pakete (v0.9.10), Pardus (v0.9.10), Debian (v0.9.9) <br />
*Solaris-Pakete entweder für SPARC- oder x86-Prozessoren.<br />
**SPARC (v0.9.8), x86 (v0.9.9) <br />
*Silicon Graphics IRIX<br />
**SGI Binaries für (v0.9.9) <br />
*Mac OS X<br />
**Mac OS 10.4 (v0.9.10)<br />
**Mac OS 10.3 (v0.9.9) <br />
*FreeBSD-Paket für (v0.9.10)<br />
<br />
==FlightGear-Rezensionen==<br />
<br />
Siehe auch Hauptartikel FlightGear-Rezensionen (engl.)<br />
{{Main article|FlightGear Reviews}}<br />
<br />
==Externe Links==<br />
{{Main article|Links}}<br />
*[http://www.flightgear.org Offizielle Website]<br />
*[http://fgfs.i-net.hu/ Community Website] <br />
*[http://www.caballerosaguila.shialeweb.com/ Club Website] (Spanish)<br />
*[http://gallery.flightgear.org.uk/ Screenshots der Entwicklerversion]<br />
<br />
==Quellen==<br />
* [http://www.flightgear.org/proposal-3.0.1 Original Flight Gear Proposal] by David L. Murr (Revision 3.0.1)<br />
* [http://en.wikipedia.org/wiki/FlightGear Wikipedia]<br />
<br />
[[en:FlightGear]]<br />
[[es:FlightGear]]<br />
[[nl:FlightGear]]</div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=Nl/FlightGear&diff=20296Nl/FlightGear2010-03-24T16:18:01Z<p>Maerchenprinz: added language de</p>
<hr />
<div>{{Infobox Software<br />
| title = FlightGear<br />
| logo = fglogosm.jpg<br />
| image = FlightGear - 1903 Wright Flyer.jpg<br />
| alt = [[Wright Flyer (UIUC)|Wright Flyer]] in 0.9.9<br />
| developedby = FlightGear Ontwikkelaars & Bijdragers<br />
| initialrelease = 17 juli 1997<br />
| lastrelease = 1.9.1<br />
| writtenin = C++<br />
| os = 32-bit Windows, Linux, Mac OS X, FreeBSD, Solaris of IRIX<br />
| platform = Cross-platform<br />
| developmentstatus = Actief (1996-)<br />
| type = Flight simulator<br />
| license = [[GNU General Public License]]<br />
| website = http://www.flightgear.org/<br />
}}<br />
<br />
[[Image:OV10A-NASA-in-action.jpg|thumb|right|270px|NASA [[OV-10]] in FlightGear 1.0]]<br />
<br />
'''FlightGear Flight Simulator''' (vaak afgekort tot '''FlightGear''' of '''FGFS''') is een geavenceerde, geheel vrije-bron vlucht simulator, gemaakt door vrijwilligers.<br />
<br />
Het project is in 1996 gestart, met een eerste uitgave in 1997. De laatste publieke uitgave is 1.9.1, uitgebracht in December 2008.<br />
<br />
FlightGear wordt uitgebracht onder de voorwaarden van de [[GNU General Public License]]. FlightGear is grotendeels geschreven in de programmeertaal C++, en deels in C.<br />
<br />
==Geschiedenis==<br />
===Het begin (1996-1997)===<br />
Eind 1990 begon de ontwikkeling officieel met een online voorstel en het schrijven van de code in 1996.<br />
<br />
In plaats van helemaal vanuit het niks te beginnen maakten de FlightGear ontwikkelaars gebruik van het LaRCsim model van NASA, met OpenGL voor 3D graphics en gratis hoogte data. De eerste werkende versie werd in 1997 uitgebracht.<br />
<br />
===Versies 0.7–0.9 (2001–2003)===<br />
Ten tijde van 2001 bracht het team regelmatig nieuwe beta versie uit (0.7.x, 0.8.0, gedurende 2001-2003 en 0.9.xx gedurende 2003-2006). Later in het decenium nam de snelheid van nieuwe uitgaves af, maar het aantal verbeteringen nam sterk toe (0.9.10, 1.0.0 enz.). De status van het programma in 2005 leidde tot meerdere reviews en een toegenomen populariteit. <br />
<br />
===Versies 0.9.0-0.9.11 (2002-2007)===<br />
Op 3 juni 2006 won FlightGear met versie 0.9.10 de Softpedia's ''Pick'' prijs (vijf van de vijf sterren), samen met de ''100% CLEAN'' prijs.<br />
<br />
Achter de schermen was er een 0.9.11-pre1 uitgave in 2007, welke uiteindelijk leidde to FlightGear 1.0.<br />
<br />
[[Image:FG-A-10.jpg|thumb|270px|3D-cockpit van een [[A-10]] in versie 1.0.0 in 2008]]<br />
===Versie 1.0 (2008)===<br />
Het versie number markeerde een formele overstap uit de beta ontwikkelingen sinds de eerste uitgave van het programma in 1997, 10 jaar eerder.<br />
<br />
===Versie 1.9.0 (2008)===<br />
Bij het uitbrengen van 1.9.0 stapte FlightGear over van [[PLIB]] naar [[OSG]], wat een tijdelijk verlies van sommige functies, zoals 3D wolken en schaduwen betekend. Daar tegenover stond dat nieuwe functies, zoals rook, de simulatie extra realistisch maakten. De meeste vliegtuigen ontwikkeld voor OSG werken niet met oudere versies. De gebruiker kan uit ongeveer 230 vliegtuigen kiezen, er zijn er echter maar een paar inbegrepen bij de standaard download. <br />
<br />
===Versies tijdlijn===<br />
Final build code release dates by year. <br />
<br />
{| class="vatop"<br />
|width="500" |<br />
{| class="wikitable"<br />
|-<br />
! Datum<br />
! Versie<br />
|-<br />
|17 Juli, 1997 || Eerste grote release van de code<br />
|-<br />
|23 September, 1997 || 0.12<br />
|-<br />
|9 December, 1997 || 0.15<br />
|-<br />
|17 December, 1997 || 0.18<br />
|-<br />
|30 December, 1997 || 0.19<br />
|-<br />
|6 Januari, 1998 || 0.22<br />
|-<br />
|11 Maart, 1998 || 0.37<br />
|-<br />
|8 April, 1998 || 0.41<br />
|-<br />
|14 April, 1998 || 0.42<br />
|-<br />
|23 April, 1998 || 0.43<br />
|-<br />
|28 April, 1998 || 0.44<br />
|-<br />
|7 Mei, 1998 || 0.45<br />
|-<br />
|11 Mei, 1998 || 0.46<br />
|-<br />
|18 Mei, 1998 || 0.47<br />
|-<br />
|9 Juni, 1998 || 0.48<br />
|-<br />
|27 Juni, 1998 || 0.49<br />
|-<br />
|13 Juli, 1998 || 0.50<br />
|-<br />
|21 Juli, 1998 || 0.51<br />
|-<br />
|15 Augustus, 1998 || 0.52<br />
|-<br />
|2 September, 1998 || 0.53<br />
|-<br />
|25 September, 1998 || 0.54<br />
|-<br />
|23 Oktober, 1998 || 0.55<br />
|-<br />
|23 November, 1998 || 0.56<br />
|-<br />
|21 Januari, 1999 || 0.57<br />
|-<br />
|10 Februari, 1999 || 0.58<br />
|-<br />
|31 Maart, 1999 || 0.59<br />
|-<br />
|26 Mei, 1999 || 0.6.0<br />
|}<br />
|width="500" |<br />
{| class="wikitable"<br />
! Datum<br />
! Versie<br />
|-<br />
|21 Juni, 1999 || 0.6.1<br />
|-<br />
|rowspan=2 | 11 September, 1999 ||0.6.2<br />
|-<br />
| 0.7.0<br />
|-<br />
|22 Oktober, 1999 || 0.7.1<br />
|-<br />
|17 Februari, 2000 || 0.7.2<br />
|-<br />
|18 Mei, 2000 || 0.7.3<br />
|-<br />
|20 Juli, 2000 || 0.7.4<br />
|-<br />
|18 September, 2000 || 0.7.5<br />
|-<br />
|19 December, 2000 || 0.7.6 <br />
|-<br />
|20 Juni, 2001 || 0.7.7<br />
|-<br />
|13 Juli, 2001 || 0.7.8 <br />
|-<br />
|16 Februari, 2002 || 0.7.9<br />
|-<br />
|20 April, 2002 || 0.7.10<br />
|-<br />
|7 September, 2002 || 0.8.0<br />
|-<br />
|4 December, 2002 || 0.9.0<br />
|-<br />
|5 December, 2002 || 0.9.1 <br />
|-<br />
|4 Juni, 2003 || 0.9.2<br />
|-<br />
|24 Oktober, 2003 || 0.9.3<br />
|-<br />
|26 Maart, 2004 || 0.9.4<br />
|-<br />
|29 Juli, 2004 || 0.9.5<br />
|-<br />
|12 Oktober, 2004 || 0.9.6<br />
|-<br />
|18 Januari, 2005 || 0.9.8<br />
|-<br />
|17 November, 2005 || 0.9.9<br />
|-<br />
|5 April, 2006 || 0.9.10<br />
|-<br />
|Mei 2007 || 0.9.11<br />
|-<br />
|17 December, 2007 || 1.0.0 <br />
|-<br />
|21 December, 2008 || 1.9.0 <br />
|-<br />
|25 Januari, 2009 || 1.9.1 (meest recente versie)<br />
|}<br />
|}<br />
<br />
==Software==<br />
De simulatie motor in FlightGear heet [[SimGear]].<br />
<br />
Het gebruikersgemak van FlightGear wordt weergeven door het grote aantal vliegtuigen dat beschikbaar is voor FlightGear: van [[Helicopters|helikopter]]s tot [[:Category:Gliders|zweefvliegtuig]]en en van [[:Category:Airliners|passagiersvliegtuig]]en tot militaire vliegtuigen. Deze vliegtuigen zijn aangedragen door vele mensen, van over de gehele wereld.<br />
<br />
===Vliegtuigen===<br />
{{Main article|Aircraft}}<br />
<br />
FlightGear begon met een vliegtuig uit NASA's LaRCsim, een Navion, welke vervangeng werdt door een [[Cessna 172]] in 2000. Ten tijde van versie 1.9.0 waren meer dan 230 vliegtuigen beschikbaar.<br />
<br />
[[Image:EHAM.jpg|thumb|270px|[[Boeing 737-300|Boeing 733]] aan de gate in [[EHAM]] scenery.]]<br />
<br />
==FlightGear reviews==<br />
{{Main article|FlightGear Reviews}}<br />
<br />
==Externe links==<br />
*[http://www.flightgear.org Officiële website]<br />
*[http://fgfs.i-net.hu/ Gemeenschap website] <br />
*[http://gallery.flightgear.org.uk/ Ontwikkelings screenshots]<br />
<br />
==Bronnen==<br />
* [http://nl.wikipedia.org/wiki/FlightGear Wikipedia]<br />
<br />
[[de:FlightGear]]<br />
[[en:FlightGear]]<br />
[[es:FlightGear]]</div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=Es/FlightGear&diff=20293Es/FlightGear2010-03-24T15:52:06Z<p>Maerchenprinz: </p>
<hr />
<div>{{Infobox Software<br />
| title = FlightGear<br />
| logo = fglogosm.jpg<br />
| image = FlightGear - 1903 Wright Flyer.jpg<br />
| alt = [[Wright Flyer (UIUC)|Wright Flyer]] in 0.9.9<br />
| developedby = FlightGear Developers & Contributors<br />
| initialrelease = July 17, 1997<br />
| lastrelease = 1.9.1<br />
| writtenin = C++<br />
| os = 32-bit Windows, Linux, Mac OS X, FreeBSD, Solaris or IRIX<br />
| platform = Cross-platform<br />
| developmentstatus = Active (1996-)<br />
| type = Flight simulator<br />
| license = [[GNU General Public License]]<br />
| website = http://www.flightgear.org/<br />
}}<br />
<br />
[[Image:OV10A-NASA-in-action.jpg|thumb|right|270px|NASA [[OV-10]] in FlightGear 1.0]]<br />
<br />
'''FlightGear Simulador de vuelo''' (a menudo acortado como '''FlightGear''' , '''FGFS''' o '''FG''') creado por voluntarios es un marco de trabajo de simulación de vuelo, libre, sofisticado, de código completamente abierto. <br />
<br />
El proyecto empezó tiempo atrás en 1996, con su primera publicación en 1997. La más reciente versión pública 1.9.1 es de Diciembre del 2008, con específicas arquitecturas para una variedad de sistemas operativos incluido Microsoft Windows (Win 32), Mac OS X, GNU/Linux, IRIX, and Solaris.<br />
<br />
FlightGear es publicado bajo los términos de [[GNU General Public License]]. FlightGear está principalmente escrito en C++ con algunos lenguajes de programación en C.<br />
<br />
==Historia==<br />
===Comienzos (1996-1997)===<br />
El desarrollo formal comienza a finales de 1990 con una propuesta en línea y código escrito en 1996, pero usando código de gráficos 3D personalizado. El desarrollo de una versión basada en [[OpenGL]] fué encabezada por Curtis Olsen comenzando en 1997, trás la salida inicial en el 1996. Una extensa respuesta de la comunidad ha guiado muchas contribuciones para el proyecto desde su comienzo en los pasados '90s hasta el presente.<br />
<br />
Lejos de empezar enteramente de la nada. Los desarrolladores de FlightGear hicieron uso del modelo de vuelo LaRCsim de la NASA, con OpenGL para el código de graficos 3D, y datos de elevación libremente disponibles. Los primeros trabajos binarios salieron en 1997, progresivamente más estable y con programas más avanzados, resultado de una intensa actualización de nuevas versiones durante años.<br />
<br />
===Versiones 0.7–0.9 (2001–2003)===<br />
En 2001, el equipo publicó regularmente nuevas versiones beta (0.7.x, 0.8.0, en los años 2001-2003) y con 0.9.xx (2003-2006). A finales de la década, el ritmo de las publicaciones finales públicas se ralentizó, pero con gran cantidad de contenido (0.9.10, 1.0.0 etc.). La madurez del software en 2005 comenzó a extender las críticas y a incrementarse la polularidad. <br />
<br />
===Version 0.9.0-0.9.11 (2002-2007)===<br />
El uso de los numeros de versión se ralentizó drásticamente a finales del 2002 después de la publicación de la versión 0.9.0. Versiones 0.9.9 (2005) y 0.9.10 (2006) contaron con ocho [[aircraft/es| aeronaves]] totalmente nuevas o rehechas sumandose a un total de 70-90 aeronaves. FlightGear 0.9.10 ganó el premio Softpedia "Pick" award (5 estrellas de 5 posibles) el 3 de Junio de 2006 tambien se llevó el premio de Softpedia "100% Limpio".<br />
<br />
Entre escenas estaba la publicación 0.9.11-pre1 que terminó siendo remplazada por FlightGear 1.0. La pre-versión tenia unos 33 aeronaves nuevas o rehechas.<br />
<br />
[[Image:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]<br />
<br />
===Versión 1.0 (2008)===<br />
El numero de versión marcó una transcición formal fuera del estado de desarrollo beta desde la primera publicación del software en 1997, 10 años antes.<br />
<br />
===Versión 1.9.0 (2008)===<br />
En el momento en que la versión 1.9.0 fue publicada FlightGear cambió de [[PLIB]] a [[OSG]], que causó la perdida temporal de algunas de las características como las sombras y las nubes en 3D. La buena noticia es que nuevas caracteristicas como la de particulas aporta un nuevo grado de realismo a la simulación. La mayoria de las aeronaves desarrolladas por OSG no funcionan con versiones anteriores. Los usuarios pueden elegir 230 aeronaves provistas con 1.9.0, sin embargo solo unos cuantos son incluido en el paquete básico.<br />
<br />
===Linea de tiempo de la publicación===<br />
Años y Fechas de publicación de código final construido. <br />
<br />
{| class="vatop"<br />
|width="500" |<br />
{| class="wikitable"<br />
|-<br />
! Date<br />
! Version<br />
|-<br />
|17 de Julio , 1997 || Primera publicación de código principal<br />
|-<br />
|23 de Septiembre, 1997 || 0.12<br />
|-<br />
|9 de Diciembre 1997 || 0.15<br />
|-<br />
|17 de Diciembre 1997 || 0.18<br />
|-<br />
|30 de Diciembre, 1997 || 0.19 (first binaries)<br />
|-<br />
|6 de Enero, 1998 || 0.22<br />
|-<br />
|11 de Marzo, 1998 || 0.37<br />
|-<br />
|8 de Abril, 1998 || 0.41<br />
|-<br />
|14 de Abril, 1998 || 0.42<br />
|-<br />
|23 de Abril, 1998 || 0.43<br />
|-<br />
|28 de Abril, 1998 || 0.44<br />
|-<br />
|7 de Mayo, 1998 || 0.45<br />
|-<br />
|11 de Mayo, 1998 || 0.46<br />
|-<br />
|18 de Mayo, 1998 || 0.47<br />
|-<br />
|9 de Junio, 1998 || 0.48<br />
|-<br />
|27 de Junio, 1998 || 0.49<br />
|-<br />
|13 de Julio, 1998 || 0.50<br />
|-<br />
|21 de Julio, 1998 || 0.51<br />
|-<br />
|15 de Agosto, 1998 || 0.52<br />
|-<br />
|2 de Septiembre, 1998 || 0.53<br />
|-<br />
|25 de Septiembre, 1998 || 0.54<br />
|-<br />
|23 de Octubre, 1998 || 0.55<br />
|-<br />
|23 de Noviembre, 1998 || 0.56<br />
|-<br />
|21 de Enero, 1999 || 0.57<br />
|-<br />
|10 de Febrero, 1999 || 0.58<br />
|-<br />
|31 de Marzo, 1999 || 0.59<br />
|-<br />
|26 de Mayo, 1999 || 0.6.0<br />
|}<br />
|width="500" |<br />
{| class="wikitable"<br />
! Date<br />
! Version<br />
|-<br />
|21 de Junio, 1999 || 0.6.1 (Stable)<br />
|-<br />
|rowspan=2 | 11 de Septiembre, 1999 || 0.7.0 (Development)<br />
|-<br />
|0.6.2 (Stable)<br />
|-<br />
|22 de Octubre, 1999 || 0.7.1 (Development)<br />
|-<br />
|17 de Febrero, 2000 || 0.7.2 (Development)<br />
|-<br />
|18 de Mayo, 2000 || 0.7.3 (Development)<br />
|-<br />
|20 de July, 2000 || 0.7.4<br />
|-<br />
|18 de Septiembre, 2000 || 0.7.5<br />
|-<br />
|19 de Diciembre, 2000 || 0.7.6 <br />
|-<br />
|20 de Junio, 2001 || 0.7.7<br />
|-<br />
|13 de Julio, 2001 || 0.7.8 <br />
|-<br />
|16 de Febrero, 2002 || 0.7.9<br />
|-<br />
|20 de Abril, 2002 || 0.7.10<br />
|-<br />
|7 de Septiembre, 2002 || 0.8.0<br />
|-<br />
|3 de Diciembre, 2002 || 0.9.0<br />
|-<br />
|5 de Diciembre, 2002 || 0.9.1 <br />
|-<br />
|4 de June, 2003 || 0.9.2<br />
|-<br />
|24 de Octubre, 2003 || 0.9.3<br />
|-<br />
|26 de Marzo, 2004 || 0.9.4<br />
|-<br />
|29 de Julio 29, 2004 || 0.9.5<br />
|-<br />
|12 de Octubre, 2004 || 0.9.6<br />
|-<br />
|18 de Enero, 2005 || 0.9.8<br />
|-<br />
|17 de Noviembre, 2005 || 0.9.9<br />
|-<br />
|5 Abril, 2006 || 0.9.10<br />
|-<br />
|Mayo, 2007 || 0.9.11-pre1<br />
|-<br />
|17 de Diciembre, 2007 || 1.0.0<br />
|-<br />
|22 de Diciembre, 2008 || 1.9.0 (latest final build)<br />
|}<br />
|}<br />
<br />
==Software==<br />
El motor de simulación en FlightGear es llamado [[SimGear]]. Este es usado tanto como por usuarios finales, en entornos académicos y de investigación para el desarollo y prosecución de ideas de simulación de vuelo.<br />
<br />
Esta personalización de FlightGear está ilustrada por un amplio rango de modelos de aeronaves que estan disponibles en FlightGear, desde [[:Category:Gliders|Planeadores]]hasta [[Helicopter|Helicoptero]]s, y desde [[:Category:Airliners|aviones de aerolínea]] hasta [[Military aircraft| jets de combate]]. Estos modelos de aeronave han sido contribución de mucha gente diferente.<br />
<br />
La aeronaves de FlightGear usan unos de los tres modelos principales de datos JSBSim, YAsim, o UIUC desde la version 0.9.10. En la actualidad solo un modelo de motor de terreno es usado, TerraGear. Los efectos de metereologia incluyen nubes 3D , efectos de relampagos, y hora del dia.<br />
<br />
===Modelos Dinámicos de Vuelo===<br />
[[Flight Dynamics Models]] (FDM) Es como el programa simula el vuelo de una aeronave. FlightGear usa una variedad de proyectos de modelos de vuelo internamente escritos. Toda aeronave ha de ser programada para usar estos modelos. En la actualidad FlightGear es el único simulador de vuelo gráfico que es usado por todos los Modelos Dinamicos de vuelo, y UIUC y YASim fueron desarrollados especificamente para FlightGear. <br />
<br />
La versión temprana usaba un FDM de la NASA basado en [[LaRCsim]], el cual fue reemplazado por un FDM más flexible. <br />
<br />
*[[JSBSim]] - desde el 2000 el software de Modelos Dinámicos de Vuelo por defecto.<br />
*[[YASim]] - otro FDM que usa un metodo de calculo diferente. Se introdujo en 2002 comenzando en 0.7.9.<br />
*[[UIUC]] - otro FDM incluido, desarrollado por el UIUC Applied Aerodynamics Group at University of Illinois at Urbana-Champaign, tambien hace uso de LaRCsim.<br />
*Flight Gear tambien puede ser configurado para rendir usando entradas de fuentes FDM externas, como asi desde Matlab.<br />
*Han sido escritos otros FDM personalizados para aeronaves específicas, como aquellas aeronaves que sean más ligéras que el aire.<br />
<br />
===FlightGear dependencies===<br />
Unlike commercial software titles, the main output of the project is simply the release of a collection of code. To turn it into a usable program it must be compiled for a given platform. The software libraries used to create FlightGear have varied over time. The main one is [[SimGear]], which is the underlying sim engine for FlightGear. [[TerraGear]] is not a dependency, but simply a name for the default terrain data program in FlightGear. OpenAL is used for sound/audio software, including support for SDL (since 0.9.5). PLIB is used for hardware support routines, formerly used for sound support also which was taken over by OpenAL. [[OpenGL]] is used for its integrated 3D graphics routines, and other hardware acceleration (namely DirectX) is not supported. [[OpenSceneGraph]] is also integrated into FlightGear. Finally, Simple DirectMedia Layer is a software library which is used for compiling. Some of the dependencies vary depending on which platform the code is being compiled for. FlightGear users must either compile the code themselves, or find a third party to release a binary, if it is not among the ones available from the project.<br />
<br />
==Hardware==<br />
Hardware needed for FlightGear is narrow to machines that support [[OpenGL]] and 3D hardware acceleration, with NVIDIA hardware having better support. Early versions had support for 3dfx cards, though this dropped as hardware requirements increased.<br />
<br />
[[Image:Fgrun-page2.jpg|thumb|left|270px|The [[FlightGear Launch Control|FlightGear Launcher]]]]<br />
==Add-ons and customization==<br />
There are programs that are either integrated into FlightGear (dependencies) or perform a function with it. Some of these are included in the release of FlightGear for a specific platform but made by the project, while others are independently distributed but are hosted by the FlightGear project. <br />
<br />
One major additional software is the actual interface for launching an executable of FlightGear. For most of its early life FlightGear was only run through [[command line]] interfaces. However, the FlightGear Launch Control has been included with the ''[[FG launcher]]'' front-end since 0.9.3 in 2003. ''[[KFreeFlight]]'' is a launcher/front-end for KDE. ''FGTools'' is an alternative windows launcher front-end. ''FGKicker'' is a GTK+ based front-end.<br />
<br />
Other significant programs include editors and projects for Terrain Data. ''[[Atlas]]'' is a chart/map support for FlightGear; ''[[Kelpie Flight Planner]]'' is a Java based flight planner for FlightGear. ''[[FlightGear Scenery Designer]]'' is a FlightGear scenery editor for working with terrain data. The ''[[World Custom Scenery Project]]'' is a project coordinating custom scenery efforts. Finally, ''[[TaxiDraw]]'' is an editor for airport runways and taxiways.<br />
<br />
===Aircraft===<br />
{{Main article|Table of models}}<br />
<br />
FlightGear started out with an aircraft included in NASA's LaRCsim, a Navion, which was replaced by a Cessna 172 by 2000. UIUC as well as JSBsim development brought several more aircraft with them, as did the development of YASim which have since become the main FDM used in FG. As of version 1.9.0 an amount of more than 230 aircraft is provided.<br />
<br />
[[Image:EHAM.jpg|thumb|270px|[[Boeing 737-300|Boeing 733]] docked in the [[EHAM]] scenery]]<br />
===Scenery===<br />
{{Main article|Scenery}}<br />
FlightGears [[world scenery]] project contains elevation and landclass data of the enitre world. Objects -like terminals, windmills and bridges- are collected in the [[FlightGear Scenery Database|Scenery Database]].<br />
<br />
===Networking and multi-display===<br />
Several networking options allow FlightGear to communicate with other instances of FlightGear. A [[Multiplayer Howto|multiplayer]] protocol is available for using FlightGear on a local network in a multi aircraft environment. This could be used for formation flight or [[ATC|control tower]] simulation. Multiplayer was soon expanded to allow playing over the internet. Other features include a Google maps based moving up that allows users to observe where other players are.<br />
<br />
Several instances of FlightGear can be synchronized to allow for a multi-monitor environment. If all instances are running at the same frame rate consistently, it is possible to get good and tight synchronization between displays.<br />
<br />
==FlightGear code vs. binaries==<br />
Unlike most commercial software, the project release dates only apply to a release of code, not an executable program. To create a runnable program the code must be compiled, which requires several specific libraries, including some general ones and, in some cases some platform specific ones. However, since this too difficult for most mainstream users, other contributors will work to make binaries available for a specific platform and operating system. These packages vary in their stability, performance, dependencies, and how up to date they are with the code base. For example, some older binaries work on Mac OS 9 but newer releases require specific Mac OS X versions.<br />
<br />
For example, by late 2007 the latest code release was 0.9.11-pre1 (pre-release) and 0.9.10 (final). However, the actual binaries available vary significantly. Examples of actual binaries available a year after the release of the 0.9.10 code release:<br />
<br />
*Win-32 has ~138 Mb package (v0.9.10) (For Windows 98, 2000, ME, 32-bit XP) <br />
*Linux- pre-built packages for specific Linux distributions<br />
**Slackware package (v0.9.10), Fedora Core 2,3,4 packages (v0.9.10), Pardus (v0.9.10), Debian (v0.9.9) <br />
*Solaris packages either for it running on either SPARC or x86 processors.<br />
** SPARC (v0.9.8), x86 (v0.9.9) <br />
*Silicon Graphics IRIX<br />
**SGI binaries for (v0.9.9) <br />
*Mac OS X<br />
**Mac OS 10.4 (v0.9.10) <br />
**Mac OS 10.3 (v0.9.9) <br />
*FreeBSD has a package for(v0.9.10)<br />
<br />
==FlightGear reviews==<br />
{{Main article|FlightGear Reviews}}<br />
<br />
==External links==<br />
*[http://www.flightgear.org Official website]<br />
*[http://fgfs.i-net.hu/ Community website] <br />
*[http://gallery.flightgear.org.uk/ Development screenshots]<br />
<br />
==Sources==<br />
* [http://en.wikipedia.org/wiki/FlightGear Wikipedia]<br />
<br />
[[de:FlightGear]]<br />
[[en:FlightGear]]<br />
[[nl:FlightGear]]</div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=De/FlightGear&diff=20292De/FlightGear2010-03-24T15:51:01Z<p>Maerchenprinz: Created page with '{{Infobox Software | title = FlightGear | logo = fglogosm.jpg | image = FlightGear - 1903 Wright Flyer.jpg | alt …'</p>
<hr />
<div>{{Infobox Software<br />
| title = FlightGear<br />
| logo = fglogosm.jpg<br />
| image = FlightGear - 1903 Wright Flyer.jpg<br />
| alt = [[Wright Flyer (UIUC)|Wright Flyer]] in 0.9.9<br />
| developedby = FlightGear Entwickler & Mitwirkende<br />
| initialrelease = 17. Juli, 1997<br />
| latestrelease = 2.0.0<br />
| writtenin = C++<br />
| os = 32-bit Windows, Linux, Mac OS X, FreeBSD, Solaris oder IRIX<br />
| platform = Plattformübergreifend<br />
| developmentstatus = Aktiv (1996-)<br />
| type = Flugsimulator<br />
| license = [[GNU General Public License]]<br />
| website = http://www.flightgear.org/<br />
}}<br />
<br />
[[Image:OV10A-NASA-in-action.jpg|thumb|right|270px|NASA [[OV-10]] in FlightGear 1.0]]<br />
<br />
Der FlightGear Flight Simulator (oft mit FlightGear oder FGFS abgekürzt) ist ein ausgereifter, anspruchsvoller, quelloffener Flugsimulator und ist ausschliesslich von Freiwilligen erschaffen. FlightGear wird unter den Bestimmungen der [[GNU General Public License]] veröffentlicht. Es ist hauptsächlich in der Programmiersprache C++ geschrieben.<br />
<br />
Seit dem Projektstart im Jahre 1996 werden jedes Jahr noch detailliertere und realistischere Versionen veröffentlicht.<br />
<br />
Die neueste Veröffentlichung kann kostenlos unter [http://www.flightgear.org/Downloads/ http://www.flightgear.org/Downloads/] heruntergeladen werden, dazu gehören vorgefertigte Versionen für eine Reihe von Betriebssystemen, darunter Microsoft Windows (Win 32), Mac OS X, Linux, IRIX und Solaris.<br />
<br />
==Geschichte==<br />
<br />
Siehe auch: Hauptartikel Geschichte von FlightGear (engl.)<br />
{{main article|FlightGear History}}<br />
<br />
Die Entwicklung von FlightGear begann im Jahre 1996 mit einem Vorhaben, das online gemacht wurde, und angepassten 3D-Grafikcode benutzen sollte. Angeführt von Curtis Olsen begann dann 1997 die Ausarbeitung einer OpenGL-basierten Version. Von Anbeginn an steuerten viele Leute dem Projekt bei.<br />
<br />
FlightGear schloss andere open-source-Ressourcen wie das Flugdynamikmodell LaRCsim der NASA und öffentlich erhältliche Höhendaten mit ein. Die ersten funktionierenden ausführbaren Dateien, die OpenGL als Grafikcode benutzten, kamen 1997 heraus. Durch enthusiastische Arbeit entstanden in den folgenden Jahren stabilere und fortgeschrittene Versionen. Seit 2001 veröffentlichte das Team regelmässig neue Betaversionen, seit 2005 sorgt die Reife des Programms für ein immer grösseres und breiteres Publikum. 2007 fand mit der Version 1.0.0 der formale Austritt aus dem Betastadium statt, zehn Jahre nach der ersten Veröffentlichung von FlightGear.<br />
<br />
[[Image:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]<br />
<br />
<br />
Version 1.9.0, herausgekommen im Jahr 2008, beinhaltete eine grosse Veränderung: Duch den Wechsel von [[PLIB]] zu [[OSG]] gingen zeitweilig einige <br />
Features wie 3D-Wolken und Schatten verloren, während andere, z.B. Partikel, die Simulation noch realistischer machten.<br />
<br />
==Software==<br />
<br />
Die Simulationsengine von FlightGear, also die Funktionseinheit, die die komplexen Berechnungen der Simulation durchführt, heisst [[SimGear]]. Sie wird sowohl als Endbenutzerapplikation als auch im akademischen Umfeld und zur Forschung verwendet, um Ideen im Bereich Flugsimulation realisieren zu können.<br />
An der grossen Breite unterschiedlichster Fluggeräte, die von [[:Category:Gliders|Segelflieger]]n über [[Helicopter|Helikopter]] bis hin zu [[:Category:Airliners|Verkehrflugzeugen]] und [[Military aircraft|Kampfjets]] reicht, lässt sich die Anpassungsfähigkeit von FlightGear ermessen. Diese Modelle wurden und werden von vielen unterschiedlichen Freiwilligen beigesteuert.<br />
<br />
Die Fluggeräte benutzen eine der drei primären Datenmodelle: JSBSim, YASim oder, ab Version 0.9.10, UIUC. Zur Zeit wird. Als Geländeengine wird zur Zeit TerraGear verwendet. Zu den Wettereffekten gehören 3D-Wolken, Beleuchtungseffekte und Tageszeit.<br />
<br />
===Flugdynamikmodell===<br />
<br />
Das [[Flight Dynamics Models|Flugdynamikmodell]] (FDM) bestimmt, wie die Flugeigenschaften eines Flugzeuges vom Programm simuliert werden. FlightGear benutzt eine Vielfalt von internen und importierten Flugmodellprojekten. Jedwedes Fluggerät muss für eines dieser Modelle programmiert werden. Zur Zeit ist FlightGear der einzige grafische Flugsimulator, der alle FDMs benutzt, wobei UIUC und YASim speziell für FlightGear entwickelt wurden.<br />
<br />
Frühere Versionen benutzten ein FDM, das auf dem NASA-Modell [[LaRCsim]] basierte; dieses wurde aber später durch flexiblere ersetzt.<br />
<br />
*[[JSBSim]] - Die voreingestellte FDM-Software seit dem Jahr 2000.<br />
*[[YASim]] - ein weiteres FDM, das andere Berechnungsmethoden verwendet. Eingeführt 2002 mit Version 0.7.9.<br />
*[[UIUC]] - entwickelt von der UIUC Applied Aerodynamics Group an der Universität von Illinois in Urbana-Champaign; benutzt auch LaRCsim.<br />
*FlightGear kann auch so eingestellt werden, dass es den Input externer Datenquellen wie z.B. Matlab verwenden kann.<br />
*Ebenso wurden FDMs für sehr spezielle Flieger wie etwa Gasballons oder Zeppeline geschrieben. <br />
<br />
===Abhängigkeiten von FlightGear===<br />
<br />
Anders als kommerzielle Softwaretitel ist das Hauptergebnis des FGFS-Projektes eine Ansammlung von Softwarecode. Um sie in ein nutzbares Programm zu verwandeln, muss sie für eine bestimmte Plattform kompiliert werden. Dazu werden Softwarebibliotheken, sogenannte Libraries gebraucht. Mit der Zeit hat FlightGear unterschiedliche Libraries verwendet. Die wichtigste hierbei ist [[SimGear]], das die zugrundeliegende Simulationseinheit darstellt. [[TerraGear]] gehört nicht zu den Abhängigkeiten, sondern ist einfach der Name des hauptsächlich benutztem Geländedatenprogramms. OpenAL wird als Audio-/Sound-Software verwendet, seit Version 0.9.5 auch mit Unterstützung für SDL. Vorher sorgte PLIB als Audio-/Sound-Software, dient aber nun nur noch als Unterstützung für Hardwareroutinen. [[OpenGL]] wird wegen seiner integrierten 3D-Grafikroutinen verwendet; andere Hardwarebeschleunigung (namentlich DirectX) wird nicht unterstützt. [[OpenSceneGraph]] ist ebenso in FlightGear integriert. Zuguterletzt wird der sogenannte Simple DirectMedia Layer als Softwarebibliothek beim Kompilieren benutzt. Einige der Abhängigkeiten variieren je nach Plattform, auf der kompiliert wird. Benutzer von FlightGear können den Code entweder selbst kompilieren, oder eines der für viele Plattformen bereits erhältlichen vorkompilierten ausführbaren Programme nutzen.<br />
<br />
==Hardware==<br />
<br />
Die Hardware, die für FlightGear benötigt wird, braucht auf jeden Fall Unterstützung für [[OpenGL]] und 3D-Hardwarebeschleunigung, wobei sich NVIDIA als bessere Lösung herausgestellt hat. Frühere Versionen unterstützten auch 3dfx-Grafikkarten, mit immer höheren Hardwareanforderungen wurde die Unterstützung allerdings eingestellt.<br />
<br />
[[Image:Fgrun-page2.jpg|thumb|left|270px|The [[FlightGear Launch Control|FlightGear Launcher]]]]<br />
<br />
==Erweiterungen und persönliche Anpassung==<br />
<br />
Es gibt Programme, die entweder ''IN'' FlightGear integriert arbeiten (Abhängigkeiten), oder solche, die ''MIT'' FlightGear arbeiten. Einige der Programme sind schon in den Veröffentlichungen des Projektes für spezifische Plattformen enthalten, andere werden unabhängig zur Verfügung gestellt, aber vom FGFS-Projekt beherbergt.<br />
Zu den bedeutenden Zusatzprogrammen gehören solche, die es dem Benutzer erlauben, FlightGear mit Hilfe einer grafischen Oberfläche (Frontend), und nicht mit Hilfe einer [[command line|Kommandozeile]] zu starten. Die ''FlightGear Launch Control'' mit der ''[[FG launcher]]''-Oberfläche wurde 2003 mit Version 0.9.3 eingeführt. ''[[KFreeFlight]]'' ist ebensolch ein Frontend für die UNIX-Arbeitsumgebung KDE, ''FGTools'' eine Alternative unter Windows und der ''FGKicker'' ein auf GTK+ basierendes Startprogramm.<br />
<br />
Zu den anderen signifikanten Programmen gehören Editoren und Projekte für Geländedaten. ''[[Atlas]]'' z.B. ist eine sich bewegende Landkarte, der ''[[Kelpie Flight Planner]]'' ein Java-basierter Flugroutenplaner für FlightGear. ''[[FlightGear Scenery Designer]]'' arbeitet mit Geländedaten und kann zum editieren der FlightGear-Szenerie benutzt werden. Das ''[[World Custom Scenery Project]]'' ist ein Projekt, das die Arbeit an der Verfeinerung der Szenerie koordiniert; Mit ''[[TaxiDraw]]'' kann man Startbahnen und Rollfelder von Flughäfen bearbeiten.<br />
<br />
===Flugzeuge etc.===<br />
<br />
Siehe auch Hauptartikel: Liste der Modelle (engl.)<br />
{{Main article|Table of models}}<br />
<br />
<br />
FlightGear begann mit einem Flugzeug namens Navion mit dem NASA-Flugdynamikmodell LaRCSim; Die Navion wurde im Jahr 2000 von der Cessna 172 abgelöst. Die Weiterentwicklung sowohl von UIUC wie auch von JSBSim brachte mehrere Flugzeuge mit sich, genauso wie die Entwicklung von YASim, das mittlerweile das Haupt-FDM von FlightGear darstellt. Von den über 230 Fluggeräten, die für Version 1.9.0 erhältlich sind, ist nur eine Auswahl im Basispaket enthalten.<br />
<br />
[[Image:EHAM.jpg|thumb|270px|[[Boeing 737-300|Boeing 733]] docked in the [[EHAM]] scenery]]<br />
===Szenerie===<br />
<br />
Siehe auch Hauptartikel: Szenerie (engl.)<br />
{{Main article|Scenery}}<br />
<br />
Das ''[[world scenery|FlightGear World Scenery Project]]'' beinhaltet Höhen- und Landschaftsdaten der gesamten Erde. Objekte wie Flughafenterminals, Windmühlen oder Brücken sind in der [[FlightGear Scenery Database|Scenerie-Datenbank]] zusammengefasst.<br />
<br />
===Netzwerk und Multidisplay===<br />
<br />
Etliche Netzwerkoptionen erlauben es den verschiedenen Instanzen von FlightGear untereinander zu kommunizieren. Ein [[Multiplayer Howto|Mehrspieler]]-Protokoll steht zur Verfügung, um FlightGear in einem lokalen Netzwerk mit mehrern Flugzeugen zu betreiben, was man zum Formationsflug oder zur Simulation eines [[ATC|Kontrollturms]]s nutzen kann. Schnell entwickelte sich die Mehrspieler-Option dazu, FlightGear auch über das Internet spielen zu können. Ein weiteres Feature ist die Möglichkeit, auf einer Google-Maps basierten Karte zu beobachten, wo sich die anderen FG-Flieger gerade befinden.<br />
Mehrere Instanzen von FlightGear können so synchronisiert werden, dass mehrere Bildschirme gleichzeitig benutz werden können. Laufen alle Instanzen beständig mit der gleichen Frequenz, ist eine gute und akkurate Synchronization der Bildschirme möglich.<br />
<br />
==FlightGear-Code oder Binärdatei?==<br />
<br />
Der Grossteil kommerzieller Software ist als ausführbare Dateien, also als sogenannte Binaries oder Executables, erhältlich. Das FlightGear-Projekt veröffentlicht im Gegensatz dazu an den jeweiligen Erscheinungsdaten nur den zugrundeliegenden Code. Um ein lauffähiges Programm daraus zu schaffen, muss dieser Code kompiliert werden; Dazu werden mehrere spezielle Softwarebibliotheken benötigt, davon sind einige generell, andere spezifisch nötig, je nach Plattform und Betriebssystem. Da für die breite Masse diese Prozedur zu schwierig ist, werden von den FGFS-Mitwirkenden verschiedene plattform- und betriebssystem-spezifisch vorkompilierte Binaries zur Verfügnug gestellt. Diese können sich hinsichtlich ihrer Stabilität, Leistung, Abhängigkeiten und Aktualität unterscheiden. Zum Beispiel laufen einige ältere Binaries auf Mac OS 9, für Mac OS X werden allerdings neuere Versionen benötigt.<br />
<br />
Als Ende 2007 der zu der Zeit neueste Code unter der Bezeichnung 0.9.11-pre1 (Vorveröffentlichung) und 0.9.10 (endgültige Veröffentlichung) herauskam, variierten die dazugehörigen Binaries stark untereinander. Hier einige Beispiele:<br />
<br />
*Win-32 - als Paket mit 138 Mb (v0.9.10) (für Windows 98, 2000, ME, 32-bit XP)<br />
*Linux- pre-built-Paket für spezifische Linux-Distributionen<br />
**Slackware-Paket (v0.9.10), Fedora Core 2,3,4 Pakete (v0.9.10), Pardus (v0.9.10), Debian (v0.9.9) <br />
*Solaris-Pakete entweder für SPARC- oder x86-Prozessoren.<br />
**SPARC (v0.9.8), x86 (v0.9.9) <br />
*Silicon Graphics IRIX<br />
**SGI Binaries für (v0.9.9) <br />
*Mac OS X<br />
**Mac OS 10.4 (v0.9.10)<br />
**Mac OS 10.3 (v0.9.9) <br />
*FreeBSD-Paket für (v0.9.10)<br />
<br />
==FlightGear-Rezensionen==<br />
<br />
Siehe auch Hauptartikel FlightGear-Rezensionen (engl.)<br />
{{Main article|FlightGear Reviews}}<br />
<br />
==Externe Links==<br />
{{Main article|Links}}<br />
*[http://www.flightgear.org Offizielle Website]<br />
*[http://fgfs.i-net.hu/ Community Website] <br />
*[http://www.caballerosaguila.shialeweb.com/ Club Website] (Spanish)<br />
*[http://gallery.flightgear.org.uk/ Screenshots der Entwicklerversion]<br />
<br />
==Quellen==<br />
* [http://www.flightgear.org/proposal-3.0.1 Original Flight Gear Proposal] by David L. Murr (Revision 3.0.1)<br />
* [http://en.wikipedia.org/wiki/FlightGear Wikipedia]<br />
<br />
[[en:FlightGear]]<br />
[[es:FlightGear]]<br />
[[nl:FlightGear]]</div>Maerchenprinzhttps://wiki.flightgear.org/w/index.php?title=FlightGear&diff=20291FlightGear2010-03-24T15:49:57Z<p>Maerchenprinz: </p>
<hr />
<div>{{Infobox Software<br />
| title = FlightGear<br />
| logo = fglogosm.jpg<br />
| image = FlightGear - 1903 Wright Flyer.jpg<br />
| alt = [[Wright Flyer (UIUC)|Wright Flyer]] in 0.9.9<br />
| developedby = FlightGear Developers & Contributors<br />
| initialrelease = July 17, 1997<br />
| latestrelease = 2.0.0<br />
| writtenin = C++<br />
| os = 32-bit Windows, Linux, Mac OS X, FreeBSD, Solaris or IRIX<br />
| platform = Cross-platform<br />
| developmentstatus = Active (1996-)<br />
| type = Flight simulator<br />
| license = [[GNU General Public License]]<br />
| website = http://www.flightgear.org/<br />
}}<br />
<br />
[[Image:OV10A-NASA-in-action.jpg|thumb|right|270px|NASA [[OV-10]] in FlightGear 1.0]]<br />
<br />
'''FlightGear Flight Simulator''' (often shortened to '''FlightGear''' or '''FGFS''') is a sophisticated free, completely open-source flight simulator framework, created by volunteers. FlightGear is released under the terms of the [[GNU General Public License]]. FlightGear is mostly written in the C++ programming language.<br />
<br />
Increasingly detailed and realistic versions of FlightGear have been released every year since the project was started in 1996.<br />
<br />
The latest public release is available as a free download at [http://www.flightgear.org/Downloads/ http://www.flightgear.org/Downloads/], with specific builds for a variety of operating systems including Microsoft Windows (Win 32), Mac OS X, Linux, IRIX, and Solaris.<br />
<br />
==History==<br />
{{main article|FlightGear History}}<br />
<br />
FlightGear development started with an online proposal in 1996, using custom 3D graphics code. Development of an [[OpenGL]] based version was spearheaded by Curtis Olson starting in 1997. Many people have contributed to the project in the years since its inception.<br />
<br />
FlightGear incorporated other open-source resources, including the LaRCsim flight model from NASA, and freely available elevation data. The first working binaries, using OpenGL for 3D graphic code, came out in 1997. Enthusiastic development of newer versions for several years resulted in progressively more stable and advanced versions. By 2001, the team was releasing new beta versions regularly, and by 2005, the maturity of software lead to more widespread reviews, and increased popularity. 2007 marked a formal transition out of beta development with the release of version 1.0.0, ten years after FlightGear's first release in 1997.<br />
<br />
[[Image:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]<br />
<br />
In 2008, version 1.9.0 of FlightGear included a major change from [[PLIB]] to [[OSG]], which caused the temporarily loss of some features like 3D clouds and shadows, while newly added features, such as particles, imparted another degree of realism to the simulation. <br />
<br />
==Software==<br />
<br />
The simulation engine in FlightGear is called [[SimGear]]. It is used both as an end-user application and in academic and research environments, for the development and pursuit of flight simulation ideas.<br />
<br />
This customizability of FlightGear is illustrated by the wide range of aircraft models that are available in FlightGear, from [[:Category:Gliders|glider]]s to [[Helicopter]]s, and from [[:Category:Airliners|airliners]] to [[Military aircraft|fighter jets]]. These aircraft models have been contributed by many different people.<br />
<br />
The FlightGear aircraft use one of three main data models JSBSim, YAsim, or UIUC as of version 0.9.10. Currently only one terrain engine is used, TerraGear. Weather effects include 3D clouds, lighting effects, and time of day.<br />
<br />
===Flight Dynamics Models===<br />
[[Flight Dynamics Models]] (FDM) are how the flight for an aircraft is simulated in the program. FlightGear uses a variety of internally written and imported flight model projects. Any aircraft must be programmed to use one of these models. Currently FlightGear is the only flight graphical flight simulator all the FDM are used for, and UIUC and YASim were developed specifically for FlightGear. <br />
<br />
Early version used a FDM based on [[LaRCsim]] by NASA, which was replaced with more flexible FDM. <br />
<br />
*[[JSBSim]] - the default flight dynamics model software since 2000.<br />
*[[YASim]] - another FDM using different calculation method. Introduced starting in 0.7.9 in 2002.<br />
*[[UIUC]] - another included FDM, developed by the UIUC Applied Aerodynamics Group at University of Illinois at Urbana-Champaign, also made use of LaRCsim.<br />
*Flight Gear can also be setup to render using inputs from an external FDM source, such as from Matlab.<br />
*Other custom FDM for a specific aircraft type have been written, such as for lighter than air aircraft.<br />
<br />
===FlightGear dependencies===<br />
Unlike commercial software titles, the main output of the project is simply the release of a collection of code. To turn it into a usable program it must be compiled for a given platform. The software libraries used to create FlightGear have varied over time. The main one is [[SimGear]], which is the underlying sim engine for FlightGear. [[TerraGear]] is not a dependency, but simply a name for the default terrain data program in FlightGear. OpenAL is used for sound/audio software, including support for SDL (since 0.9.5). PLIB is used for hardware support routines, formerly used for sound support also which was taken over by OpenAL. [[OpenGL]] is used for its integrated 3D graphics routines, and other hardware acceleration (namely DirectX) is not supported. [[OpenSceneGraph]] is also integrated into FlightGear. Finally, Simple DirectMedia Layer is a software library which is used for compiling. Some of the dependencies vary depending on which platform the code is being compiled for. FlightGear users must either compile the code themselves, or find a third party to release a binary, if it is not among the ones available from the project.<br />
<br />
==Hardware==<br />
Hardware needed for FlightGear is narrow to machines that support [[OpenGL]] and 3D hardware acceleration, with NVIDIA hardware having better support. Early versions had support for 3dfx cards, though this dropped as hardware requirements increased.<br />
<br />
[[Image:Fgrun-page2.jpg|thumb|left|270px|The [[FlightGear Launch Control|FlightGear Launcher]]]]<br />
==Add-ons and customization==<br />
There are programs that are either integrated into FlightGear (dependencies) or perform a function with it. Some of these are included in the release of FlightGear for a specific platform but made by the project, while others are independently distributed but are hosted by the FlightGear project. <br />
<br />
One major additional software is the actual interface for launching an executable of FlightGear. For most of its early life FlightGear was only run through [[command line]] interfaces. However, the FlightGear Launch Control has been included with the ''[[FG launcher]]'' front-end since 0.9.3 in 2003. ''[[KFreeFlight]]'' is a launcher/front-end for KDE. ''FGTools'' is an alternative windows launcher front-end. ''FGKicker'' is a GTK+ based front-end.<br />
<br />
Other significant programs include editors and projects for Terrain Data. ''[[Atlas]]'' is a chart/map support for FlightGear; ''[[Kelpie Flight Planner]]'' is a Java based flight planner for FlightGear. ''[[FlightGear Scenery Designer]]'' is a FlightGear scenery editor for working with terrain data. The ''[[World Custom Scenery Project]]'' is a project coordinating custom scenery efforts. Finally, ''[[TaxiDraw]]'' is an editor for airport runways and taxiways.<br />
<br />
===Aircraft===<br />
{{Main article|Table of models}}<br />
<br />
FlightGear started out with an aircraft included in NASA's LaRCsim, a Navion, which was replaced by a Cessna 172 by 2000. UIUC as well as JSBsim development brought several more aircraft with them, as did the development of YASim which have since become the main FDM used in FG. Over 230 aircraft are available for version 1.9.0, although only a few are included in the base package.<br />
<br />
[[Image:EHAM.jpg|thumb|270px|[[Boeing 737-300|Boeing 733]] docked in the [[EHAM]] scenery]]<br />
===Scenery===<br />
{{Main article|Scenery}}<br />
FlightGears [[world scenery]] project contains elevation and landclass data of the enitre world. Objects -like terminals, windmills and bridges- are collected in the [[FlightGear Scenery Database|Scenery Database]].<br />
<br />
===Networking and multi-display===<br />
Several networking options allow FlightGear to communicate with other instances of FlightGear. A [[Multiplayer Howto|multiplayer]] protocol is available for using FlightGear on a local network in a multi aircraft environment. This could be used for formation flight or [[ATC|control tower]] simulation. Multiplayer was soon expanded to allow playing over the internet. Other features include a Google maps based moving up that allows users to observe where other players are.<br />
<br />
Several instances of FlightGear can be synchronized to allow for a multi-monitor environment. If all instances are running at the same frame rate consistently, it is possible to get good and tight synchronization between displays.<br />
<br />
==FlightGear code vs. binaries==<br />
Unlike most commercial software, the project release dates only apply to a release of code, not an executable program. To create a runnable program the code must be compiled, which requires several specific libraries, including some general ones and, in some cases some platform specific ones. However, since this too difficult for most mainstream users, other contributors will work to make binaries available for a specific platform and operating system. These packages vary in their stability, performance, dependencies, and how up to date they are with the code base. For example, some older binaries work on Mac OS 9 but newer releases require specific Mac OS X versions.<br />
<br />
For example, by late 2007 the latest code release was 0.9.11-pre1 (pre-release) and 0.9.10 (final). However, the actual binaries available vary significantly. Examples of actual binaries available a year after the release of the 0.9.10 code release:<br />
<br />
*Win-32 has ~138 Mb package (v0.9.10) (For Windows 98, 2000, ME, 32-bit XP) <br />
*Linux- pre-built packages for specific Linux distributions<br />
**Slackware package (v0.9.10), Fedora Core 2,3,4 packages (v0.9.10), Pardus (v0.9.10), Debian (v0.9.9) <br />
*Solaris packages either for it running on either SPARC or x86 processors.<br />
** SPARC (v0.9.8), x86 (v0.9.9) <br />
*Silicon Graphics IRIX<br />
**SGI binaries for (v0.9.9) <br />
*Mac OS X<br />
**Mac OS 10.4 (v0.9.10) <br />
**Mac OS 10.3 (v0.9.9) <br />
*FreeBSD has a package for(v0.9.10)<br />
<br />
==FlightGear reviews==<br />
{{Main article|FlightGear Reviews}}<br />
<br />
==External links==<br />
{{Main article|Links}}<br />
*[http://www.flightgear.org Official website]<br />
*[http://fgfs.i-net.hu/ Community website] <br />
*[http://www.caballerosaguila.shialeweb.com/ Club website] (Spanish)<br />
*[http://gallery.flightgear.org.uk/ Development screenshots]<br />
<br />
==Sources==<br />
* [http://www.flightgear.org/proposal-3.0.1 Original Flight Gear Proposal] by David L. Murr (Revision 3.0.1)<br />
* [http://en.wikipedia.org/wiki/FlightGear Wikipedia]<br />
<br />
[[de:FlightGear]]<br />
[[es:FlightGear]]<br />
[[nl:FlightGear]]<br />
{{Languages|PageName}}</div>Maerchenprinz