OpenSuSE: Fix inconsistent line-feeds in READMEs
Also drop a stray ".bak" file. Thanks to OpenSuSE build service.
This commit is contained in:
ThorstenB
parent
0481fc5010
commit
e2cb030351
3 changed files with 1132 additions and 1132 deletions
|
|
@ -1,55 +1,55 @@
|
||||||
<h1>The KLN89 GPS unit in FlightGear</h1>
|
<h1>The KLN89 GPS unit in FlightGear</h1>
|
||||||
|
|
||||||
FlightGear includes a simulation of the KLN89B GPS unit. This is an IFR en-route, terminal and non-precision approach capable GPS (FAA TSO-C129 level A1) introduced around 1994. The majority of the display is text based, but there is a fairly rudimentary moving map display.
|
FlightGear includes a simulation of the KLN89B GPS unit. This is an IFR en-route, terminal and non-precision approach capable GPS (FAA TSO-C129 level A1) introduced around 1994. The majority of the display is text based, but there is a fairly rudimentary moving map display.
|
||||||
<br>
|
<br>
|
||||||
<br>
|
<br>
|
||||||
The user-interface and capabilities of this unit are extremely complex, and as far as possible the simulation is a faithful reproduction of the behaviour of the original. The best documentation is therefore the original manual, which is readily available on the web. A working link at the time of writing can be found <a href="http://www.buffaloairways.com/manuals/manuals.htm">here</a>. Owners of the old <i>Fly!</i> flight simulator will also find a useful section on the KLN89 in the accompanying manual. Various other relevant iterature on the web may be found by searching.
|
The user-interface and capabilities of this unit are extremely complex, and as far as possible the simulation is a faithful reproduction of the behaviour of the original. The best documentation is therefore the original manual, which is readily available on the web. A working link at the time of writing can be found <a href="http://www.buffaloairways.com/manuals/manuals.htm">here</a>. Owners of the old <i>Fly!</i> flight simulator will also find a useful section on the KLN89 in the accompanying manual. Various other relevant iterature on the web may be found by searching.
|
||||||
<br>
|
<br>
|
||||||
<br>
|
<br>
|
||||||
The KLN89B may currently be found in FlightGear only on the 2D C172p panel:
|
The KLN89B may currently be found in FlightGear only on the 2D C172p panel:
|
||||||
<pre>fgfs --aircraft=c172p-2dpanel</pre>
|
<pre>fgfs --aircraft=c172p-2dpanel</pre>
|
||||||
The display is clearest at a FG area size of 1024x768, since at that geometry there is a 1:1 mapping between screen and KLN89 display pixels:
|
The display is clearest at a FG area size of 1024x768, since at that geometry there is a 1:1 mapping between screen and KLN89 display pixels:
|
||||||
<pre>fgfs --aircraft=c172p-2dpanel --geometry=1024x768</pre>
|
<pre>fgfs --aircraft=c172p-2dpanel --geometry=1024x768</pre>
|
||||||
At higher resolutions the display is readable but slightly blurred, at lower resolutions the display may be largely unreadable. Advanced note: One possible way around this is to make up a custom mini-panel containing only the KLN89B at the correct resolution. Check out the KLN90 mini-panel on the b1900d for a template to get started.
|
At higher resolutions the display is readable but slightly blurred, at lower resolutions the display may be largely unreadable. Advanced note: One possible way around this is to make up a custom mini-panel containing only the KLN89B at the correct resolution. Check out the KLN90 mini-panel on the b1900d for a template to get started.
|
||||||
<br>
|
<br>
|
||||||
<br>
|
<br>
|
||||||
The unit is currently functional for en-route navigation and non-precision approaches, but is not yet fully complete, and is missing a number of features. The duplicate waypoint page is not available, so some waypoints (particularly NDBs) which have duplicated IDs worldwide may be unselectable. There is no provision for altitude input. The moving map page only displays the active flightplan, not airports or navaids not on the flightplan. Only a couple of non-precision approaches are available in the database, at KHWD and C83. It is not possible to enter user-defined waypoints. Most of the OTH (auxiliary) and CAL (calculator) pages are unimplemented (info such as satellite position and status, fuel calculator etc). The nearest search functions don't work yet. Waypoint scan with the inner-knob out only works on the NAV4 (moving map) page. There is no turn anticipation. Only some user settings are changable in the SET pages, and these are not persistent between FG sessions. That list sounds long, but the unit is still under active development, and hopefully it gives some indication of how much *has* been implemented so far!
|
The unit is currently functional for en-route navigation and non-precision approaches, but is not yet fully complete, and is missing a number of features. The duplicate waypoint page is not available, so some waypoints (particularly NDBs) which have duplicated IDs worldwide may be unselectable. There is no provision for altitude input. The moving map page only displays the active flightplan, not airports or navaids not on the flightplan. Only a couple of non-precision approaches are available in the database, at KHWD and C83. It is not possible to enter user-defined waypoints. Most of the OTH (auxiliary) and CAL (calculator) pages are unimplemented (info such as satellite position and status, fuel calculator etc). The nearest search functions don't work yet. Waypoint scan with the inner-knob out only works on the NAV4 (moving map) page. There is no turn anticipation. Only some user settings are changable in the SET pages, and these are not persistent between FG sessions. That list sounds long, but the unit is still under active development, and hopefully it gives some indication of how much *has* been implemented so far!
|
||||||
<br>
|
<br>
|
||||||
<br>
|
<br>
|
||||||
The rest of this documentation is a short introduction to using the unit, and a description of the specific peculiarities of using the unit within FlightGear.
|
The rest of this documentation is a short introduction to using the unit, and a description of the specific peculiarities of using the unit within FlightGear.
|
||||||
<br>
|
<br>
|
||||||
<br>
|
<br>
|
||||||
<h2>Getting Started with the Unit</h2>
|
<h2>Getting Started with the Unit</h2>
|
||||||
<b><i>Input</b></i>
|
<b><i>Input</b></i>
|
||||||
<br>
|
<br>
|
||||||
Input to a complex instrument is unfortunately somewhat more awkward in a simulator than on the real-life unit. Input to the unit in FlightGear is via the mouse, although key-bindings could be configured by the user. At the right-hand side of the unit is a double knob, composed of an inner and outer knob. Both knobs may be turned in either direction by clicking with the mouse (left mouse button): press Ctrl-C to see where the hot-spots are, and practice clicking the correct knob on the ground before commencing an approach. The inner knob may be pulled out - the middle mouse button is used to pull out and push in the middle knob. The left mouse button is used to turn the inner knob when pulled out in the same manner as before.
|
Input to a complex instrument is unfortunately somewhat more awkward in a simulator than on the real-life unit. Input to the unit in FlightGear is via the mouse, although key-bindings could be configured by the user. At the right-hand side of the unit is a double knob, composed of an inner and outer knob. Both knobs may be turned in either direction by clicking with the mouse (left mouse button): press Ctrl-C to see where the hot-spots are, and practice clicking the correct knob on the ground before commencing an approach. The inner knob may be pulled out - the middle mouse button is used to pull out and push in the middle knob. The left mouse button is used to turn the inner knob when pulled out in the same manner as before.
|
||||||
<br>
|
<br>
|
||||||
<br>
|
<br>
|
||||||
<b><i>Basics</b></i>
|
<b><i>Basics</b></i>
|
||||||
<br>
|
<br>
|
||||||
The unit is organised in pages, eg. APT (airport data), NAV (navigation display). Most pages are composed of several subpages, eg. NAV1 (CDI and basic nav info), NAV4 (moving map page). Moving between pages is done using the outer knob, moving between subpages is done using the inner knob. Most pages have several editable or changable data fields. Press the CRSR button to enter or exit edit mode. In edit mode, the outer knob moves between editable items, and the inner knob changes items, except for cyclic fields (indicated by '>'), which require the CLR button to cycle through the choices. Sometimes a specific choice may require confirmation to set it; in this case the unit will flash 'ENT', and the ENT button must be pressed to confirm (or generally either the CLR or CRSR button to reject). The DTO button allows navigation direct to a selectable waypoint. The OBS button allows navigation relative to a radial to or from a given waypoint, in a similar manner to VOR navigation.
|
The unit is organised in pages, eg. APT (airport data), NAV (navigation display). Most pages are composed of several subpages, eg. NAV1 (CDI and basic nav info), NAV4 (moving map page). Moving between pages is done using the outer knob, moving between subpages is done using the inner knob. Most pages have several editable or changable data fields. Press the CRSR button to enter or exit edit mode. In edit mode, the outer knob moves between editable items, and the inner knob changes items, except for cyclic fields (indicated by '>'), which require the CLR button to cycle through the choices. Sometimes a specific choice may require confirmation to set it; in this case the unit will flash 'ENT', and the ENT button must be pressed to confirm (or generally either the CLR or CRSR button to reject). The DTO button allows navigation direct to a selectable waypoint. The OBS button allows navigation relative to a radial to or from a given waypoint, in a similar manner to VOR navigation.
|
||||||
<br>
|
<br>
|
||||||
<br>
|
<br>
|
||||||
<b><i>Flight planning</b></i>
|
<b><i>Flight planning</b></i>
|
||||||
<br>
|
<br>
|
||||||
Central to operation of the unit is the concept of the active flightplan, which is a path connecting a set of waypoints that the user intends to follow. By default the unit operates in LEG mode, whereby navigation is provided along each leg (great-circle path between waypoints) of the flightplan. Several flightplans are programmed into the FPL pages at startup for convienience. Other flightplans may be entered into any of the FPL pages (except FPL0, the active flightplan) as per the manual instructions (or trial-and-error for the adventurous!). Any flightplan can be made active, at which point it is copied to the FPL0 page. Currently flightplans can not be entered on the command line, loaded from file, nor are entered flightplans in the unit saved between sessions. This will come eventually...
|
Central to operation of the unit is the concept of the active flightplan, which is a path connecting a set of waypoints that the user intends to follow. By default the unit operates in LEG mode, whereby navigation is provided along each leg (great-circle path between waypoints) of the flightplan. Several flightplans are programmed into the FPL pages at startup for convienience. Other flightplans may be entered into any of the FPL pages (except FPL0, the active flightplan) as per the manual instructions (or trial-and-error for the adventurous!). Any flightplan can be made active, at which point it is copied to the FPL0 page. Currently flightplans can not be entered on the command line, loaded from file, nor are entered flightplans in the unit saved between sessions. This will come eventually...
|
||||||
<br>
|
<br>
|
||||||
<br>
|
<br>
|
||||||
<b><i>Navigation</b></i>
|
<b><i>Navigation</b></i>
|
||||||
<br>
|
<br>
|
||||||
The NAV1 page contains a CDI-type display. The scale may be changed. NAV4 contains the moving map display, which currently shows only the active flightplan. Press the CRSR button to access the map scale change, or the CRSR button, then left-outer-knob, then ENT button (!) to access the map menu. Note that if you select heading-up display then the map will blank out at speeds less than about 2 knots unless the unit is interfaced to a heading source (not currently done in FG) - this is consistent with the real-life unit. The waypoints of the active flightplan may be 'scanned' on this page by pulling the inner knob out (middle mouse button) and turning it (left mouse button). This allows the default direct-to waypoint to be changed (to the one displayed in the bottom-right of the screen), which can be very useful when under ATC control on an IFR flight-plan.
|
The NAV1 page contains a CDI-type display. The scale may be changed. NAV4 contains the moving map display, which currently shows only the active flightplan. Press the CRSR button to access the map scale change, or the CRSR button, then left-outer-knob, then ENT button (!) to access the map menu. Note that if you select heading-up display then the map will blank out at speeds less than about 2 knots unless the unit is interfaced to a heading source (not currently done in FG) - this is consistent with the real-life unit. The waypoints of the active flightplan may be 'scanned' on this page by pulling the inner knob out (middle mouse button) and turning it (left mouse button). This allows the default direct-to waypoint to be changed (to the one displayed in the bottom-right of the screen), which can be very useful when under ATC control on an IFR flight-plan.
|
||||||
<br>
|
<br>
|
||||||
<br>
|
<br>
|
||||||
<b><i>Approaches</b></i>
|
<b><i>Approaches</b></i>
|
||||||
<br>
|
<br>
|
||||||
The KLN89B is classed as TSO-C129 level A1 by the FAA, which among other things means it is suitable for non-precision IFR approaches if mounted in a suitable installation. The FG installation currently doesn't quite comply, since there is no altitude input, but this is a sim so we won't worry too much for now! How to fly non-precision approaches is beyond the scope of this document - see Charles Wood's excellent pages at <a href="http://www.navfltsm.addr.com/">www.navfltsm.com</a> for a thorough grounding. The FAA GPS regulations state that the waypoints for a given approach must be stored in a database in the correct order, and must not be editable by the user! Approaches for a given airport may be selected from the APT8 page, but only if that airport is in the active flightplan. If there is a choice of IAF (initial approach fix), then this is chosen on the APT8 page as well. The approach will be added to the active flightplan, but will be removed if the unit is power-cycled (another FAA reg. I believe). Hence there are is no approach in the active flight-plan at FG startup. Currently only 3 approaches are available, two at KHWD (Hayward Executive) and one at C83 (Byron), both of which are in the FG base package. These are hardwired into the code at present, but it is hoped to move them to a file that the user can enter their favourite approaches into.
|
The KLN89B is classed as TSO-C129 level A1 by the FAA, which among other things means it is suitable for non-precision IFR approaches if mounted in a suitable installation. The FG installation currently doesn't quite comply, since there is no altitude input, but this is a sim so we won't worry too much for now! How to fly non-precision approaches is beyond the scope of this document - see Charles Wood's excellent pages at <a href="http://www.navfltsm.addr.com/">www.navfltsm.com</a> for a thorough grounding. The FAA GPS regulations state that the waypoints for a given approach must be stored in a database in the correct order, and must not be editable by the user! Approaches for a given airport may be selected from the APT8 page, but only if that airport is in the active flightplan. If there is a choice of IAF (initial approach fix), then this is chosen on the APT8 page as well. The approach will be added to the active flightplan, but will be removed if the unit is power-cycled (another FAA reg. I believe). Hence there are is no approach in the active flight-plan at FG startup. Currently only 3 approaches are available, two at KHWD (Hayward Executive) and one at C83 (Byron), both of which are in the FG base package. These are hardwired into the code at present, but it is hoped to move them to a file that the user can enter their favourite approaches into.
|
||||||
<br>
|
<br>
|
||||||
<br>
|
<br>
|
||||||
To fly an approach, make sure that the NAV1 CDI is slaved to the GPS by using the GPS/NAV switch on the annunciator unit near the top of the panel. If everything is setup OK, the approach should arm about 30 miles or so from the destination, indicated on the annunciator, and the FSD of the CDI will change smoothly from 5 miles to 1 mile. When 2nm from the final approach fix (FAF), if everything is OK then the unit will change to approach active mode, indicated by ACTV on the annunciator. FSD will change from 1 to 0.3 miles. If the status fails to change to ACTV by the time the FAF has been passed then a missed approach must be flown.
|
To fly an approach, make sure that the NAV1 CDI is slaved to the GPS by using the GPS/NAV switch on the annunciator unit near the top of the panel. If everything is setup OK, the approach should arm about 30 miles or so from the destination, indicated on the annunciator, and the FSD of the CDI will change smoothly from 5 miles to 1 mile. When 2nm from the final approach fix (FAF), if everything is OK then the unit will change to approach active mode, indicated by ACTV on the annunciator. FSD will change from 1 to 0.3 miles. If the status fails to change to ACTV by the time the FAF has been passed then a missed approach must be flown.
|
||||||
<br>
|
<br>
|
||||||
<br>
|
<br>
|
||||||
<b><i>Approach example: KLSN to C83</b></i>
|
<b><i>Approach example: KLSN to C83</b></i>
|
||||||
<br>
|
<br>
|
||||||
An example flight with a non-precision approach flown entirely within the base-package scenery area is KLSN (Los Banos Muni) to C83 (Byron) in IFR conditions. The approach chart for C83 GPS rwy 30 can be found online <a href="http://204.108.4.16/d-tpp/0602/09141G30.PDF">here</a>. Start FlightGear with:
|
An example flight with a non-precision approach flown entirely within the base-package scenery area is KLSN (Los Banos Muni) to C83 (Byron) in IFR conditions. The approach chart for C83 GPS rwy 30 can be found online <a href="http://204.108.4.16/d-tpp/0602/09141G30.PDF">here</a>. Start FlightGear with:
|
||||||
<pre>
|
<pre>
|
||||||
fgfs --airport=KLSN --aircraft=c172p-2dpanel --geometry=1024x768 --ceiling=1000 --visibility=3000 --wind=300@5
|
fgfs --airport=KLSN --aircraft=c172p-2dpanel --geometry=1024x768 --ceiling=1000 --visibility=3000 --wind=300@5
|
||||||
|
|
@ -60,8 +60,8 @@ For the adventurous, increase the difficulty by adding turbulence, putting the w
|
||||||
Before taking off from KLSN, set up the instruments for the flight. Use the outer knob on the KLN89 to move to the FPL page. Use the inner knob to move to FPL5, which contains KLSN -> C83. Press the CRSR button, and the 'Use?' legend is underlined and starts to flash, along with the 'ENT' legend in the left-hand frame. Press ENT to use the flightplan, and the flightplan is then copied to the FPL0 page, and becomes the active flightplan.
|
Before taking off from KLSN, set up the instruments for the flight. Use the outer knob on the KLN89 to move to the FPL page. Use the inner knob to move to FPL5, which contains KLSN -> C83. Press the CRSR button, and the 'Use?' legend is underlined and starts to flash, along with the 'ENT' legend in the left-hand frame. Press ENT to use the flightplan, and the flightplan is then copied to the FPL0 page, and becomes the active flightplan.
|
||||||
<br>
|
<br>
|
||||||
<br>
|
<br>
|
||||||
Now we must add the approach. Approaches are selected from the APT8 page. This would require C83 to be selected on the APT pages. However, because C83 is the active waypoint, we can select the approach from the ACT pages, which are a straight copy of the appropriate data pages (APT, NDB, VOR etc) for the active waypoint. Click left on the outer knob a couple of times to reach the ACT page. Click left on the inner knob once (or right seven times!) to reach the ACT8 page. Press the CRSR button and use the outer knob to select an approach (there is only one for this airport). Press ENT to select the approach. Use the outer knob to select an IAF (we want PATYY for this flight since that introduces a slight dog-leg into the flightplan that keeps us clear of high ground. Use <a href="http://atlas.sourceforge.net">Atlas</a> to visulise this). Press ENT to select the IAF. Finally, press ENT once more to add the approach to the flightplan. Press the NAV/GPS button on the annunciator to slave the NAV1 CDI to the GPS (the nav/gps flag on NAV1 won't change at the current state of development - you'll need to trust the annunciator indication instead), and tune NAV2 to Modesto VOR if desired (114.6) for a handy positional sanity check.
|
Now we must add the approach. Approaches are selected from the APT8 page. This would require C83 to be selected on the APT pages. However, because C83 is the active waypoint, we can select the approach from the ACT pages, which are a straight copy of the appropriate data pages (APT, NDB, VOR etc) for the active waypoint. Click left on the outer knob a couple of times to reach the ACT page. Click left on the inner knob once (or right seven times!) to reach the ACT8 page. Press the CRSR button and use the outer knob to select an approach (there is only one for this airport). Press ENT to select the approach. Use the outer knob to select an IAF (we want PATYY for this flight since that introduces a slight dog-leg into the flightplan that keeps us clear of high ground. Use <a href="http://atlas.sourceforge.net">Atlas</a> to visulise this). Press ENT to select the IAF. Finally, press ENT once more to add the approach to the flightplan. Press the NAV/GPS button on the annunciator to slave the NAV1 CDI to the GPS (the nav/gps flag on NAV1 won't change at the current state of development - you'll need to trust the annunciator indication instead), and tune NAV2 to Modesto VOR if desired (114.6) for a handy positional sanity check.
|
||||||
<br>
|
<br>
|
||||||
<br>
|
<br>
|
||||||
Take off and fly to PATYY. It's quite a long flight (over 50nm total, about 25 to PATYY), so gain a bit of height. Five to six thousand feet is probably appropriate, and gets us above the clouds. Note that the published chart mandates arming the approach mode before reaching PATYY (PATYY is more than 30 miles from the airport, so it won't arm automatically by then), but currently this is not supported in the code, so we'll need to wait until it automatically arms between PATYY and TRACY. Close to PATYY the waypoint alert will flash, and after waypoint sequencing occurs, the KLN89 will flash the message annunciation, indicating a message to view. Press MSG to view the message, which will contain the new course to follow to the new active waypoint (TRACY), and MSG again to clear the message screen.
|
Take off and fly to PATYY. It's quite a long flight (over 50nm total, about 25 to PATYY), so gain a bit of height. Five to six thousand feet is probably appropriate, and gets us above the clouds. Note that the published chart mandates arming the approach mode before reaching PATYY (PATYY is more than 30 miles from the airport, so it won't arm automatically by then), but currently this is not supported in the code, so we'll need to wait until it automatically arms between PATYY and TRACY. Close to PATYY the waypoint alert will flash, and after waypoint sequencing occurs, the KLN89 will flash the message annunciation, indicating a message to view. Press MSG to view the message, which will contain the new course to follow to the new active waypoint (TRACY), and MSG again to clear the message screen.
|
||||||
<br>
|
<br>
|
||||||
|
|
@ -71,7 +71,7 @@ Shortly after PATYY is passed approach mode will arm. The CDI scale smoothly ch
|
||||||
<br>
|
<br>
|
||||||
Once we reach TRACY things start to get exciting. The next waypoint is the final approach fix (FAF), BABPI in this case. BABPI is only 6.1nm from TRACY, with only a further 3.5nm to the missed approach point (MAP), AMOSY, located at the runway threshold. You can descend no lower than 1300ft before passing BABPI, and should try to get down close to that height to avoid an alarming descent rate over the final leg. Approaching the FAF (BABPI) the approach should activate, indicated by the ACTV annunciation on the MD41 unit (the annunciator panel above NAV1), and the CDI smoothly changing scale from 1nm to 0.3nm per dot. If the approach fails to activate prior to passing the FAF then the missed approach procedure must be flown. Assuming we have an ACTV approach passing BABPI, turn onto the final approach course to AMOSY, check gear, flaps and mixture setting (sure, it's a fixed gear plane, but it doesn't hurt to get into good habits!), and descend to minimum altitude, which is 740ft for the RWY30 straight-in approach that we are flying, or 880ft for this aircraft for a circling approach to another runway. You need a positive visual fix on the runway prior to reaching the MAP in order to transition to visuals and land, otherwise the missed approach procedure must be flown. No waypoint sequencing past the MAP occurs (another FAA reg) - it is necessary to fly the missed approach procedure and then use DTO or OBS mode to navigate to the missed approach holding point (MAHP) as appropriate.
|
Once we reach TRACY things start to get exciting. The next waypoint is the final approach fix (FAF), BABPI in this case. BABPI is only 6.1nm from TRACY, with only a further 3.5nm to the missed approach point (MAP), AMOSY, located at the runway threshold. You can descend no lower than 1300ft before passing BABPI, and should try to get down close to that height to avoid an alarming descent rate over the final leg. Approaching the FAF (BABPI) the approach should activate, indicated by the ACTV annunciation on the MD41 unit (the annunciator panel above NAV1), and the CDI smoothly changing scale from 1nm to 0.3nm per dot. If the approach fails to activate prior to passing the FAF then the missed approach procedure must be flown. Assuming we have an ACTV approach passing BABPI, turn onto the final approach course to AMOSY, check gear, flaps and mixture setting (sure, it's a fixed gear plane, but it doesn't hurt to get into good habits!), and descend to minimum altitude, which is 740ft for the RWY30 straight-in approach that we are flying, or 880ft for this aircraft for a circling approach to another runway. You need a positive visual fix on the runway prior to reaching the MAP in order to transition to visuals and land, otherwise the missed approach procedure must be flown. No waypoint sequencing past the MAP occurs (another FAA reg) - it is necessary to fly the missed approach procedure and then use DTO or OBS mode to navigate to the missed approach holding point (MAHP) as appropriate.
|
||||||
<br>
|
<br>
|
||||||
<br>
|
<br>
|
||||||
<b><i>Miscellaneous</b></i>
|
<b><i>Miscellaneous</b></i>
|
||||||
<br>
|
<br>
|
||||||
Currently the GPS position is always correct, although in future a small random drift may be added. No simulation of range ahead integrity monitoring (RAIM) is done. At the time the units were introduced the GPS satellite constellation was less complete giving the possibility of unacceptable (but predicatable) navigation degradation due to poor satellite geometry. I doubt that RAIM failure due to poor satellite geometry is an issue now, but would welcome an opinion one way or another from an IFR GPS-using pilot. Report bugs to the FlightGear lists or to daveluff AT ntlworld DOT com. Have fun :-)
|
Currently the GPS position is always correct, although in future a small random drift may be added. No simulation of range ahead integrity monitoring (RAIM) is done. At the time the units were introduced the GPS satellite constellation was less complete giving the possibility of unacceptable (but predicatable) navigation degradation due to poor satellite geometry. I doubt that RAIM failure due to poor satellite geometry is an issue now, but would welcome an opinion one way or another from an IFR GPS-using pilot. Report bugs to the FlightGear lists or to daveluff AT ntlworld DOT com. Have fun :-)
|
||||||
|
|
|
||||||
|
|
@ -1,242 +1,242 @@
|
||||||
Document started 27/01/2008 by Tiago Gusmão
|
Document started 27/01/2008 by Tiago Gusmão
|
||||||
Updated 02/02/2008 to reflect syntax changes
|
Updated 02/02/2008 to reflect syntax changes
|
||||||
Updated 03/02/2008 to add trails (connected particles)
|
Updated 03/02/2008 to add trails (connected particles)
|
||||||
|
|
||||||
This is a short specification/tutorial to define particle systems in FlightGear using XML
|
This is a short specification/tutorial to define particle systems in FlightGear using XML
|
||||||
|
|
||||||
Meaningless example (what i had accumulated due to tests):
|
Meaningless example (what i had accumulated due to tests):
|
||||||
|
|
||||||
<particlesystem>
|
<particlesystem>
|
||||||
<name>fuel</name>
|
<name>fuel</name>
|
||||||
<!-- <texture>particle.rgb</texture> -->
|
<!-- <texture>particle.rgb</texture> -->
|
||||||
<emissive>false</emissive>
|
<emissive>false</emissive>
|
||||||
<lighting>true</lighting>
|
<lighting>true</lighting>
|
||||||
|
|
||||||
<offsets>
|
<offsets>
|
||||||
<x-m>35</x-m>
|
<x-m>35</x-m>
|
||||||
<y-m>-0.3</y-m>
|
<y-m>-0.3</y-m>
|
||||||
<z-m>0</z-m>
|
<z-m>0</z-m>
|
||||||
<!--<pitch-deg>90</pitch-deg>-->
|
<!--<pitch-deg>90</pitch-deg>-->
|
||||||
</offsets>
|
</offsets>
|
||||||
|
|
||||||
<!--<condition>
|
<!--<condition>
|
||||||
<and>
|
<and>
|
||||||
<equals>
|
<equals>
|
||||||
<property>engines/engine/smoking</property>
|
<property>engines/engine/smoking</property>
|
||||||
<value>true</value>
|
<value>true</value>
|
||||||
</equals>
|
</equals>
|
||||||
<less-than>
|
<less-than>
|
||||||
<property>position/altitude-agl-ft</property>
|
<property>position/altitude-agl-ft</property>
|
||||||
<value>12000</value>
|
<value>12000</value>
|
||||||
</less-than>
|
</less-than>
|
||||||
</and>
|
</and>
|
||||||
</condition>-->
|
</condition>-->
|
||||||
|
|
||||||
<attach>world</attach>
|
<attach>world</attach>
|
||||||
|
|
||||||
<placer>
|
<placer>
|
||||||
<type>point</type>
|
<type>point</type>
|
||||||
</placer>
|
</placer>
|
||||||
|
|
||||||
<shooter>
|
<shooter>
|
||||||
<theta-min-deg>84</theta-min-deg>
|
<theta-min-deg>84</theta-min-deg>
|
||||||
<theta-max-deg>86</theta-max-deg>
|
<theta-max-deg>86</theta-max-deg>
|
||||||
<phi-min-deg>-1.5</phi-min-deg>
|
<phi-min-deg>-1.5</phi-min-deg>
|
||||||
<phi-max-deg>1.5</phi-max-deg>
|
<phi-max-deg>1.5</phi-max-deg>
|
||||||
<speed>
|
<speed>
|
||||||
<value>10</value>
|
<value>10</value>
|
||||||
<spread>2.5</spread>
|
<spread>2.5</spread>
|
||||||
</speed>
|
</speed>
|
||||||
<rotation-speed>
|
<rotation-speed>
|
||||||
<x-min-deg-sec>0</x-min-deg-sec>
|
<x-min-deg-sec>0</x-min-deg-sec>
|
||||||
<y-min-deg-sec>0</y-min-deg-sec>
|
<y-min-deg-sec>0</y-min-deg-sec>
|
||||||
<z-min-deg-sec>0</z-min-deg-sec>
|
<z-min-deg-sec>0</z-min-deg-sec>
|
||||||
<x-max-deg-sec>0</x-max-deg-sec>
|
<x-max-deg-sec>0</x-max-deg-sec>
|
||||||
<y-max-deg-sec>0</y-max-deg-sec>
|
<y-max-deg-sec>0</y-max-deg-sec>
|
||||||
<z-max-deg-sec>0</z-max-deg-sec>
|
<z-max-deg-sec>0</z-max-deg-sec>
|
||||||
</rotation-speed>
|
</rotation-speed>
|
||||||
</shooter>
|
</shooter>
|
||||||
|
|
||||||
<counter>
|
<counter>
|
||||||
<particles-per-sec>
|
<particles-per-sec>
|
||||||
<value>1</value>
|
<value>1</value>
|
||||||
<spread>0</spread>
|
<spread>0</spread>
|
||||||
</particles-per-sec>
|
</particles-per-sec>
|
||||||
</counter>
|
</counter>
|
||||||
|
|
||||||
<align>billboard</align>
|
<align>billboard</align>
|
||||||
|
|
||||||
<particle>
|
<particle>
|
||||||
<start>
|
<start>
|
||||||
<color>
|
<color>
|
||||||
<red>
|
<red>
|
||||||
<value>0.9</value>
|
<value>0.9</value>
|
||||||
</red>
|
</red>
|
||||||
<green>
|
<green>
|
||||||
<value>0.09</value>
|
<value>0.09</value>
|
||||||
</green>
|
</green>
|
||||||
<blue>
|
<blue>
|
||||||
<value>0.09</value>
|
<value>0.09</value>
|
||||||
</blue>
|
</blue>
|
||||||
<alpha>
|
<alpha>
|
||||||
<value>1.0</value>
|
<value>1.0</value>
|
||||||
</alpha>
|
</alpha>
|
||||||
</color>
|
</color>
|
||||||
<size>
|
<size>
|
||||||
<value>0.25</value>
|
<value>0.25</value>
|
||||||
</size>
|
</size>
|
||||||
</start>
|
</start>
|
||||||
|
|
||||||
<end>
|
<end>
|
||||||
<color>
|
<color>
|
||||||
<red>
|
<red>
|
||||||
<value>1</value>
|
<value>1</value>
|
||||||
</red>
|
</red>
|
||||||
<green>
|
<green>
|
||||||
<value>0.1</value>
|
<value>0.1</value>
|
||||||
</green>
|
</green>
|
||||||
<blue>
|
<blue>
|
||||||
<value>0.1</value>
|
<value>0.1</value>
|
||||||
</blue>
|
</blue>
|
||||||
<alpha>
|
<alpha>
|
||||||
<value>0.0</value>
|
<value>0.0</value>
|
||||||
</alpha>
|
</alpha>
|
||||||
</color>
|
</color>
|
||||||
<size>
|
<size>
|
||||||
<value>4</value>
|
<value>4</value>
|
||||||
</size>
|
</size>
|
||||||
</end>
|
</end>
|
||||||
|
|
||||||
<life-sec>
|
<life-sec>
|
||||||
<value>10</value>
|
<value>10</value>
|
||||||
</life-sec>
|
</life-sec>
|
||||||
|
|
||||||
<mass-kg>0.25</mass-kg>
|
<mass-kg>0.25</mass-kg>
|
||||||
<radius-m>0.1</radius-m>
|
<radius-m>0.1</radius-m>
|
||||||
</particle>
|
</particle>
|
||||||
|
|
||||||
<program>
|
<program>
|
||||||
<fluid>air</fluid>
|
<fluid>air</fluid>
|
||||||
<gravity type="bool">true</gravity>
|
<gravity type="bool">true</gravity>
|
||||||
<wind type="bool">true</wind>
|
<wind type="bool">true</wind>
|
||||||
</program>
|
</program>
|
||||||
</particlesystem>
|
</particlesystem>
|
||||||
|
|
||||||
Stick this inside any model XML like it was an animation and it should
|
Stick this inside any model XML like it was an animation and it should
|
||||||
work (notice the condition requires wheel on the ground)
|
work (notice the condition requires wheel on the ground)
|
||||||
|
|
||||||
Specification:
|
Specification:
|
||||||
|
|
||||||
Note:
|
Note:
|
||||||
<VALUEORPROP/> means you can either specify a property with factor and
|
<VALUEORPROP/> means you can either specify a property with factor and
|
||||||
offset (result = (prop*factor)+offset ) in the usual way
|
offset (result = (prop*factor)+offset ) in the usual way
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
<particlesystem> = the base tag
|
<particlesystem> = the base tag
|
||||||
<type>string</type> can be "normal" or "trail", normal is the usual quad particles, trail is a string of connected line shapes by default.
|
<type>string</type> can be "normal" or "trail", normal is the usual quad particles, trail is a string of connected line shapes by default.
|
||||||
<offsets> = this places the source of the particles (the emitter) in relation to the perhaps already offset model (see model-howto.html for details)
|
<offsets> = this places the source of the particles (the emitter) in relation to the perhaps already offset model (see model-howto.html for details)
|
||||||
<x-m>float</x-m>
|
<x-m>float</x-m>
|
||||||
<y-m>float</y-m>
|
<y-m>float</y-m>
|
||||||
<z-m>float</z-m>
|
<z-m>float</z-m>
|
||||||
<pitch-deg>float</pitch-deg>
|
<pitch-deg>float</pitch-deg>
|
||||||
<roll-deg>float</roll-deg>
|
<roll-deg>float</roll-deg>
|
||||||
<heading-deg>float</heading-deg>
|
<heading-deg>float</heading-deg>
|
||||||
</offsets>
|
</offsets>
|
||||||
<condition> =a typical condition that if not true stops particles from being emitted (PPS=0)
|
<condition> =a typical condition that if not true stops particles from being emitted (PPS=0)
|
||||||
....
|
....
|
||||||
</condition>
|
</condition>
|
||||||
<name>string</name> = the name of the particle system (so it can be referenced by normal animations)
|
<name>string</name> = the name of the particle system (so it can be referenced by normal animations)
|
||||||
<attach>string</attach> = can be "world" or "local". "world means the particles aren't "physically linked" to the model (necessary for use outside moving models), "local" means the opposite (can be used for static objects or inside moving objects)
|
<attach>string</attach> = can be "world" or "local". "world means the particles aren't "physically linked" to the model (necessary for use outside moving models), "local" means the opposite (can be used for static objects or inside moving objects)
|
||||||
<texture>string</texture> = the texture path relative to the XML file location
|
<texture>string</texture> = the texture path relative to the XML file location
|
||||||
<emissive>bool</emissive> = self-explanatory
|
<emissive>bool</emissive> = self-explanatory
|
||||||
<lighting>bool</lighting> = yet to be tested, but seems obvious
|
<lighting>bool</lighting> = yet to be tested, but seems obvious
|
||||||
<align>string</align> = can be "billboard" or "fixed"
|
<align>string</align> = can be "billboard" or "fixed"
|
||||||
<placer> = where particles are born
|
<placer> = where particles are born
|
||||||
<type>string</type> = can be "sector" (inside a circle), "segments"(user-defined segments) and "point" (default)
|
<type>string</type> = can be "sector" (inside a circle), "segments"(user-defined segments) and "point" (default)
|
||||||
*<radius-min-m>float</radius-min-m> = only for sector, inner radius at which particles appear
|
*<radius-min-m>float</radius-min-m> = only for sector, inner radius at which particles appear
|
||||||
*<radius-max-m>float</radius-max-m> = only for sector, outer radius at which particles appear
|
*<radius-max-m>float</radius-max-m> = only for sector, outer radius at which particles appear
|
||||||
*<phi-min-deg>float</phi-min-deg> = only for sector, starting angle of the slide at which particles appear
|
*<phi-min-deg>float</phi-min-deg> = only for sector, starting angle of the slide at which particles appear
|
||||||
*<phi-max-deg>float</phi-max-deg> = only for sector, ending angle of the slide at which particles appear
|
*<phi-max-deg>float</phi-max-deg> = only for sector, ending angle of the slide at which particles appear
|
||||||
<segments> = only for segments, encloses sequential points that form segments
|
<segments> = only for segments, encloses sequential points that form segments
|
||||||
<vertex> = specifies one point, put as many as you want
|
<vertex> = specifies one point, put as many as you want
|
||||||
<x-m>float</x-m>
|
<x-m>float</x-m>
|
||||||
<y-m>float</y-m>
|
<y-m>float</y-m>
|
||||||
<z-m>float</z-m>
|
<z-m>float</z-m>
|
||||||
</vertex>
|
</vertex>
|
||||||
....
|
....
|
||||||
<vertex>
|
<vertex>
|
||||||
...
|
...
|
||||||
</vertex>
|
</vertex>
|
||||||
</segments>
|
</segments>
|
||||||
</placer>
|
</placer>
|
||||||
<shooter> = the shooter defines the initial velocity vector for your particles
|
<shooter> = the shooter defines the initial velocity vector for your particles
|
||||||
*<theta-min-deg>float</theta-min-deg> = horizontal angle limits of the particle cone
|
*<theta-min-deg>float</theta-min-deg> = horizontal angle limits of the particle cone
|
||||||
*<theta-max-deg>float</theta-max-deg>
|
*<theta-max-deg>float</theta-max-deg>
|
||||||
*<phi-min-deg>float</phi-min-deg> = vertical angle limits of the particle cone
|
*<phi-min-deg>float</phi-min-deg> = vertical angle limits of the particle cone
|
||||||
*<phi-max-deg>float</phi-max-deg> for an illustration of theta/phi see http://www.cs.clemson.edu/~malloy/courses/3dgames-2007/tutor/web/particles/particles.html
|
*<phi-max-deg>float</phi-max-deg> for an illustration of theta/phi see http://www.cs.clemson.edu/~malloy/courses/3dgames-2007/tutor/web/particles/particles.html
|
||||||
<speed-mps> = the scalar velocity (meter per second)
|
<speed-mps> = the scalar velocity (meter per second)
|
||||||
<VALUEORPROP/> = see note
|
<VALUEORPROP/> = see note
|
||||||
*<spread> the "tolerance" in each direction so values are in the range [value-spread, value+spread]
|
*<spread> the "tolerance" in each direction so values are in the range [value-spread, value+spread]
|
||||||
</speed-mps>
|
</speed-mps>
|
||||||
<rotation-speed> = the range of initial rotational speed of the particles
|
<rotation-speed> = the range of initial rotational speed of the particles
|
||||||
*<x-min-deg-sec>float</x-min-deg-sec>
|
*<x-min-deg-sec>float</x-min-deg-sec>
|
||||||
*<y-min-deg-sec>float</y-min-deg-sec>
|
*<y-min-deg-sec>float</y-min-deg-sec>
|
||||||
*<z-min-deg-sec>float</z-min-deg-sec>
|
*<z-min-deg-sec>float</z-min-deg-sec>
|
||||||
*<x-max-deg-sec>float</x-max-deg-sec>
|
*<x-max-deg-sec>float</x-max-deg-sec>
|
||||||
*<y-max-deg-sec>float</y-max-deg-sec>
|
*<y-max-deg-sec>float</y-max-deg-sec>
|
||||||
*<z-max-deg-sec>float</z-max-deg-sec>
|
*<z-max-deg-sec>float</z-max-deg-sec>
|
||||||
</rotation-speed>
|
</rotation-speed>
|
||||||
</shooter>
|
</shooter>
|
||||||
<counter>
|
<counter>
|
||||||
<particles-per-sec>
|
<particles-per-sec>
|
||||||
<VALUEORPROP/> = see note
|
<VALUEORPROP/> = see note
|
||||||
*<spread> the "tolerance" in each direction so values are in the range [value-spread, value+spread]
|
*<spread> the "tolerance" in each direction so values are in the range [value-spread, value+spread]
|
||||||
</particles-per-sec>
|
</particles-per-sec>
|
||||||
</counter>
|
</counter>
|
||||||
<particle> = defines the particle properties
|
<particle> = defines the particle properties
|
||||||
<start>
|
<start>
|
||||||
<color> = initial color (at time of emission)
|
<color> = initial color (at time of emission)
|
||||||
<red><VALUEORPROP/></red> = color component in normalized value [0,1]
|
<red><VALUEORPROP/></red> = color component in normalized value [0,1]
|
||||||
<green><VALUEORPROP/></green>
|
<green><VALUEORPROP/></green>
|
||||||
<blue><VALUEORPROP/></blue>
|
<blue><VALUEORPROP/></blue>
|
||||||
<alpha><VALUEORPROP/></alpha>
|
<alpha><VALUEORPROP/></alpha>
|
||||||
</color>
|
</color>
|
||||||
<size> = as above, but for size
|
<size> = as above, but for size
|
||||||
<VALUEORPROP/>
|
<VALUEORPROP/>
|
||||||
</size>
|
</size>
|
||||||
</start>
|
</start>
|
||||||
<end>
|
<end>
|
||||||
<color> = final color (at the end of the particle life)
|
<color> = final color (at the end of the particle life)
|
||||||
<red><VALUEORPROP/></red>
|
<red><VALUEORPROP/></red>
|
||||||
<green><VALUEORPROP/></green>
|
<green><VALUEORPROP/></green>
|
||||||
<blue><VALUEORPROP/></blue>
|
<blue><VALUEORPROP/></blue>
|
||||||
<alpha><VALUEORPROP/></alpha>
|
<alpha><VALUEORPROP/></alpha>
|
||||||
</color>
|
</color>
|
||||||
<size>
|
<size>
|
||||||
<VALUEORPROP/>
|
<VALUEORPROP/>
|
||||||
</size>
|
</size>
|
||||||
</end>
|
</end>
|
||||||
*<life-sec> = the time the particles will be alive, in seconds
|
*<life-sec> = the time the particles will be alive, in seconds
|
||||||
<VALUEORPROP/>
|
<VALUEORPROP/>
|
||||||
*</life-sec>
|
*</life-sec>
|
||||||
*<radius-m>float</radius-m> = each particles is physically treated as a sphere with this radius
|
*<radius-m>float</radius-m> = each particles is physically treated as a sphere with this radius
|
||||||
*<mass-kg>float</mass-kg> = mass in KG
|
*<mass-kg>float</mass-kg> = mass in KG
|
||||||
</particle>
|
</particle>
|
||||||
<program> = defines external forces acting upon a particle
|
<program> = defines external forces acting upon a particle
|
||||||
<fluid>string<fluid> = can be "air" or "water"
|
<fluid>string<fluid> = can be "air" or "water"
|
||||||
<gravity>bool</gravity> = can be "true" or "false". uses standard gravity
|
<gravity>bool</gravity> = can be "true" or "false". uses standard gravity
|
||||||
<wind>bool</wind> = can be "true" or "false". uses user position wind (not the model position, but shouldn't be noticeable, you want to disabled it when using local attach)
|
<wind>bool</wind> = can be "true" or "false". uses user position wind (not the model position, but shouldn't be noticeable, you want to disabled it when using local attach)
|
||||||
</program>
|
</program>
|
||||||
</particles>
|
</particles>
|
||||||
|
|
||||||
Remarks:
|
Remarks:
|
||||||
Don't forget you can use existing animations with particles, so if you want to direct or translate the emitter, just use translate, rotate, spin and so on (other animations might have interesting effects too I guess)
|
Don't forget you can use existing animations with particles, so if you want to direct or translate the emitter, just use translate, rotate, spin and so on (other animations might have interesting effects too I guess)
|
||||||
Particle XML should be compatible with plib, as the tags will be ignored (you might get some warning if you attach them to animations though)
|
Particle XML should be compatible with plib, as the tags will be ignored (you might get some warning if you attach them to animations though)
|
||||||
Try not to use a lot of particles in a way that fills the screen, that will demand lots of fill rate and hurt FPS
|
Try not to use a lot of particles in a way that fills the screen, that will demand lots of fill rate and hurt FPS
|
||||||
If you don't use any properties nor conditions, your particle system doesn't need to use a callback a so it's slightly better on the CPU (mostly useful for static models)
|
If you don't use any properties nor conditions, your particle system doesn't need to use a callback a so it's slightly better on the CPU (mostly useful for static models)
|
||||||
If your particle lifetime is too big you might run out of particles temporarily (still being investigated)
|
If your particle lifetime is too big you might run out of particles temporarily (still being investigated)
|
||||||
Use mass and size(radius) to adjust the reaction to gravity and wind (mass/size = density)
|
Use mass and size(radius) to adjust the reaction to gravity and wind (mass/size = density)
|
||||||
Although at the moment severe graphical bugs can be seen in the trails, they are usable.
|
Although at the moment severe graphical bugs can be seen in the trails, they are usable.
|
||||||
Consider your options correctly! You should consider giving them no initial velocity and most important, no spread, otherwise particles will race and the trail will fold. Start simple (no velocities and forces) and work your way up.
|
Consider your options correctly! You should consider giving them no initial velocity and most important, no spread, otherwise particles will race and the trail will fold. Start simple (no velocities and forces) and work your way up.
|
||||||
|
|
||||||
|
|
|
||||||
1676
Docs/README.yasim
1676
Docs/README.yasim
File diff suppressed because it is too large
Load diff
Loading…
Reference in a new issue