diff --git a/Docs/README.kln89.html b/Docs/README.kln89.html
index f8f97016e..8ff95e805 100644
--- a/Docs/README.kln89.html
+++ b/Docs/README.kln89.html
@@ -1,55 +1,55 @@
-The KLN89 GPS unit in FlightGear
-
-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.
-
-
-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 here. Owners of the old Fly! 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 KLN89B may currently be found in FlightGear only on the 2D C172p panel:
-fgfs --aircraft=c172p-2dpanel
-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:
-fgfs --aircraft=c172p-2dpanel --geometry=1024x768
-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.
-
-
-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 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 KLN89 GPS unit in FlightGear
+
+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.
+
+
+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 here. Owners of the old Fly! 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 KLN89B may currently be found in FlightGear only on the 2D C172p panel:
+fgfs --aircraft=c172p-2dpanel
+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:
+fgfs --aircraft=c172p-2dpanel --geometry=1024x768
+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.
+
+
+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 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.
+
+
Getting Started with the Unit
Input
-
-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.
+
Basics
-
-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.
-
-
-Flight planning
-
-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...
-
-
-Navigation
-
-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.
-
-
-Approaches
-
-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 www.navfltsm.com 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.
-
-
-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.
-
+
+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.
+
+
+Flight planning
+
+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...
+
+
+Navigation
+
+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.
+
+
+Approaches
+
+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 www.navfltsm.com 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.
+
+
+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.
+
Approach example: KLSN to C83
-
+
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 here. Start FlightGear with:
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.
-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 Atlas 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 Atlas 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.
+
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.
@@ -71,7 +71,7 @@ Shortly after PATYY is passed approach mode will arm. The CDI scale smoothly ch
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.
-
-Miscellaneous
-
-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 :-)
+
+Miscellaneous
+
+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 :-)
diff --git a/Docs/README.xmlparticles b/Docs/README.xmlparticles
index c89aa5f84..88e2ef011 100644
--- a/Docs/README.xmlparticles
+++ b/Docs/README.xmlparticles
@@ -1,242 +1,242 @@
-Document started 27/01/2008 by Tiago Gusmão
-Updated 02/02/2008 to reflect syntax changes
-Updated 03/02/2008 to add trails (connected particles)
-
-This is a short specification/tutorial to define particle systems in FlightGear using XML
-
-Meaningless example (what i had accumulated due to tests):
-
-
- fuel
-
- false
- true
-
-
- 35
- -0.3
- 0
-
-
-
-
-
- world
-
-
- point
-
-
-
- 84
- 86
- -1.5
- 1.5
-
- 10
- 2.5
-
-
- 0
- 0
- 0
- 0
- 0
- 0
-
-
-
-
-
- 1
- 0
-
-
-
- billboard
-
-
-
-
-
- 0.9
-
-
- 0.09
-
-
- 0.09
-
-
- 1.0
-
-
-
- 0.25
-
-
-
-
-
-
- 1
-
-
- 0.1
-
-
- 0.1
-
-
- 0.0
-
-
-
- 4
-
-
-
-
- 10
-
-
- 0.25
- 0.1
-
-
-
- air
- true
- true
-
-
-
-Stick this inside any model XML like it was an animation and it should
-work (notice the condition requires wheel on the ground)
-
-Specification:
-
-Note:
- means you can either specify a property with factor and
-offset (result = (prop*factor)+offset ) in the usual way
-
-
-
- = the base tag
- string can be "normal" or "trail", normal is the usual quad particles, trail is a string of connected line shapes by default.
- = this places the source of the particles (the emitter) in relation to the perhaps already offset model (see model-howto.html for details)
- float
- float
- float
- float
- float
- float
-
- =a typical condition that if not true stops particles from being emitted (PPS=0)
- ....
-
- string = the name of the particle system (so it can be referenced by normal animations)
- string = 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)
- string = the texture path relative to the XML file location
- bool = self-explanatory
- bool = yet to be tested, but seems obvious
- string = can be "billboard" or "fixed"
- = where particles are born
- string = can be "sector" (inside a circle), "segments"(user-defined segments) and "point" (default)
- *float = only for sector, inner radius at which particles appear
- *float = only for sector, outer radius at which particles appear
- *float = only for sector, starting angle of the slide at which particles appear
- *float = only for sector, ending angle of the slide at which particles appear
- = only for segments, encloses sequential points that form segments
- = specifies one point, put as many as you want
- float
- float
- float
-
- ....
-
- ...
-
-
-
- = the shooter defines the initial velocity vector for your particles
- *float = horizontal angle limits of the particle cone
- *float
- *float = vertical angle limits of the particle cone
- *float for an illustration of theta/phi see http://www.cs.clemson.edu/~malloy/courses/3dgames-2007/tutor/web/particles/particles.html
- = the scalar velocity (meter per second)
- = see note
- * the "tolerance" in each direction so values are in the range [value-spread, value+spread]
-
- = the range of initial rotational speed of the particles
- *float
- *float
- *float
- *float
- *float
- *float
-
-
-
-
- = see note
- * the "tolerance" in each direction so values are in the range [value-spread, value+spread]
-
-
- = defines the particle properties
-
- = initial color (at time of emission)
- = color component in normalized value [0,1]
-
-
-
-
- = as above, but for size
-
-
-
-
- = final color (at the end of the particle life)
-
-
-
-
-
-
-
-
-
- * = the time the particles will be alive, in seconds
-
- *
- *float = each particles is physically treated as a sphere with this radius
- *float = mass in KG
-
- = defines external forces acting upon a particle
- string = can be "air" or "water"
- bool = can be "true" or "false". uses standard gravity
- bool = 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)
-
-
-
-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)
- 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
- 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)
- 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.
- 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.
-
+Document started 27/01/2008 by Tiago Gusmão
+Updated 02/02/2008 to reflect syntax changes
+Updated 03/02/2008 to add trails (connected particles)
+
+This is a short specification/tutorial to define particle systems in FlightGear using XML
+
+Meaningless example (what i had accumulated due to tests):
+
+
+ fuel
+
+ false
+ true
+
+
+ 35
+ -0.3
+ 0
+
+
+
+
+
+ world
+
+
+ point
+
+
+
+ 84
+ 86
+ -1.5
+ 1.5
+
+ 10
+ 2.5
+
+
+ 0
+ 0
+ 0
+ 0
+ 0
+ 0
+
+
+
+
+
+ 1
+ 0
+
+
+
+ billboard
+
+
+
+
+
+ 0.9
+
+
+ 0.09
+
+
+ 0.09
+
+
+ 1.0
+
+
+
+ 0.25
+
+
+
+
+
+
+ 1
+
+
+ 0.1
+
+
+ 0.1
+
+
+ 0.0
+
+
+
+ 4
+
+
+
+
+ 10
+
+
+ 0.25
+ 0.1
+
+
+
+ air
+ true
+ true
+
+
+
+Stick this inside any model XML like it was an animation and it should
+work (notice the condition requires wheel on the ground)
+
+Specification:
+
+Note:
+ means you can either specify a property with factor and
+offset (result = (prop*factor)+offset ) in the usual way
+
+
+
+ = the base tag
+ string can be "normal" or "trail", normal is the usual quad particles, trail is a string of connected line shapes by default.
+ = this places the source of the particles (the emitter) in relation to the perhaps already offset model (see model-howto.html for details)
+ float
+ float
+ float
+ float
+ float
+ float
+
+ =a typical condition that if not true stops particles from being emitted (PPS=0)
+ ....
+
+ string = the name of the particle system (so it can be referenced by normal animations)
+ string = 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)
+ string = the texture path relative to the XML file location
+ bool = self-explanatory
+ bool = yet to be tested, but seems obvious
+ string = can be "billboard" or "fixed"
+ = where particles are born
+ string = can be "sector" (inside a circle), "segments"(user-defined segments) and "point" (default)
+ *float = only for sector, inner radius at which particles appear
+ *float = only for sector, outer radius at which particles appear
+ *float = only for sector, starting angle of the slide at which particles appear
+ *float = only for sector, ending angle of the slide at which particles appear
+ = only for segments, encloses sequential points that form segments
+ = specifies one point, put as many as you want
+ float
+ float
+ float
+
+ ....
+
+ ...
+
+
+
+ = the shooter defines the initial velocity vector for your particles
+ *float = horizontal angle limits of the particle cone
+ *float
+ *float = vertical angle limits of the particle cone
+ *float for an illustration of theta/phi see http://www.cs.clemson.edu/~malloy/courses/3dgames-2007/tutor/web/particles/particles.html
+ = the scalar velocity (meter per second)
+ = see note
+ * the "tolerance" in each direction so values are in the range [value-spread, value+spread]
+
+ = the range of initial rotational speed of the particles
+ *float
+ *float
+ *float
+ *float
+ *float
+ *float
+
+
+
+
+ = see note
+ * the "tolerance" in each direction so values are in the range [value-spread, value+spread]
+
+
+ = defines the particle properties
+
+ = initial color (at time of emission)
+ = color component in normalized value [0,1]
+
+
+
+
+ = as above, but for size
+
+
+
+
+ = final color (at the end of the particle life)
+
+
+
+
+
+
+
+
+
+ * = the time the particles will be alive, in seconds
+
+ *
+ *float = each particles is physically treated as a sphere with this radius
+ *float = mass in KG
+
+ = defines external forces acting upon a particle
+ string = can be "air" or "water"
+ bool = can be "true" or "false". uses standard gravity
+ bool = 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)
+
+
+
+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)
+ 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
+ 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)
+ 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.
+ 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.
+
diff --git a/Docs/README.yasim b/Docs/README.yasim
index 7017a89e9..d3a93d0d5 100644
--- a/Docs/README.yasim
+++ b/Docs/README.yasim
@@ -1,838 +1,838 @@
-Coordinate system notes: All positions specified are in meters (which
-is weird, since all other units in the file are English). The X axis
-points forward, Y is left, and Z is up. Take your right hand, and
-hold it like a gun. Your first and second fingers are the X and Y
-axes, and your upwards-pointing thumb is the Z. This is slightly
-different from the coordinate system used by JSBSim. Sorry. The
-origin can be placed anywhere, so long as you are consistent. I use
-the nose of the aircraft.
-
-XML Elements
-------------
-
-airplane: The top-level element for the file. It contains only one
- attribute:
- mass: The empty (no fuel) weight, in pounds.
-
-approach: The approach parameters for the aircraft. The solver will
- generate an aircraft that matches these settings. The element
- can (and should) contain elements indicating pilot
- input settings, such as flaps and throttle, for the
- approach.
- speed: The approach airspeed, in knots TAS.
- aoa: The approach angle of attack, in degrees
- fuel: Fraction (0-1) of fuel in the tanks. Default is 0.2.
-
-cruise: The cruise speed and altitude for the solver to match. As
- above, this should contain elements indicating
- aircraft configuration. Especially, make sure the engines
- are generating enough thrust at cruise!
- speed: The cruise speed, in knots TAS.
- alt: The cruise altitude, in feet MSL.
- fuel: Fraction (0-1) of fuel in the tanks. Default is 0.2.
-
-cockpit: The location of the cockpit (pilot eyepoint).
- x,y,z: eyepoint location (see coordinates note)
-
-fuselage: This defines a tubelike structure. It will be given an even
- mass and aerodynamic force distribution by the solver. You
- can have as many as you like, in any orientation you please.
- ax,ay,az: One end of the tube (typically the front)
- bx,by,bz: The other ("back") end.
- width: The width of the tube, in meters.
- taper: The approximate radius at the "tips" of the fuselage
- expressed as a fraction (0-1) of the width value.
- midpoint: The location of the widest part of the fuselage,
- expressed as a fraction of the distance between A and B.
- idrag: Multiplier for the "induced drag" generated by this
- object. Default is one. With idrag=0 the fuselage
- generates only drag.
- cx,cy,cz: Factors for the generated drag in the fuselages "local
- coordinate system" with x pointing from end to front,
- z perpendicular to x with y=0 in the aircraft coordinate
- system. E.g. for a fuselage of a height of 2 times the
- width you can define cy=2 and (due to the doubled front
- surface) cx=2.
-
-wing: This defines the main wing of the aircraft. You can have
- only one (but see below about using vstab objects for extra
- lifting surfaces). The wing should have a subelement to
- indicate stall behavior, control surface subelements (flap0,
- flap1, spoiler, slat) to indicate what and where the control
- surfaces are, and subelements to map user input
- properties to the control surfaces.
- x,y,z: The "base" of the wing, specified as the location of
- the mid-chord (not leading edge, trailing edge, or
- aerodynamic center) point at the root of the LEFT
- (!) wing.
- length: The length from the base of the wing to the midchord
- point at the tip. Note that this is not the same
- thing as span.
- chord: The chord of the wing at its base, along the X axis
- (not normal to the leading edge, as it is
- sometimes defined).
- incidence: The incidence angle at the wing root, in degrees.
- Zero is level with the fuselage (as in an
- aerobatic plane), positive means that the leading
- edge is higher than the trailing edge (as in a
- trainer).
- twist: The difference between the incidence angle at the
- wing root and the incidence angle at the wing
- tip. Typically, this is a negative number so
- that the wing tips have a lower angle of attack
- and stall after the wing root (washout).
- taper: The taper fraction, expressed as the tip chord
- divided by the root chord. A taper of one is a
- hershey bar wing, and zero would be a wing ending
- at a point. Defaults to one.
- sweep: The sweep angle of the wing, in degrees. Zero is
- no sweep, positive angles are swept back.
- Defaults to zero.
- dihedral: The dihedral angle of the wing. Positive angles
- are upward dihedral. Defaults to zero.
- idrag: Multiplier for the "induced drag" generated by this
- surface. In general, low aspect wings will
- generate less induced drag per-AoA than high
- aspect (glider) wings. This value isn't
- constrained well by the solution process, and may
- require tuning to get throttle settings correct in
- high AoA (approach) situations.
- camber: The lift produced by the wing at zero angle of
- attack, expressed as a fraction of the maximum
- lift produced at the stall AoA.
-
-hstab: These defines the horizontal stabilizer of the aircraft.
- Internally, it is just a wing object and therefore works the
- same in XML. You are allowed only one hstab object; the
- solver needs to know which wing's incidence to play with to
- get the aircraft trimmed correctly.
-
-vstab: A "vertical" stabilizer. Like hstab, this is just another
- wing, with a few special properties. The surface is not
- "mirrored" as are wing and hstab objects. If you define a
- left wing only, you'll only get a left wing. The default
- dihedral, if unspecified, is 90 degrees instead of zero.
- But all parameters are equally settable, so there's no
- requirement that this object be "vertical" at all. You can
- use it for anything you like, such as extra wings for
- biplanes. Most importantly, these surfaces are not involved
- with the solver computation, so you can have none, or as
- many as you like.
-
-mstab: A mirrored horizontal stabilizer. Exactly the same as wing, but
- not involved with the solver computation, so you can have none,
- or as many as you like.
-
-stall: A subelement of a wing (or hstab/vstab/mstab) that specifies the
- stall behavior.
- aoa: The stall angle (maximum lift) in degrees. Note that
- this is relative to the wing, not the fuselage (since
- the wing may have a non-zero incidence angle).
- width: The "width" of the stall, in degrees. A high value
- indicates a gentle stall. Low values are viscious
- for a non-twisted wing, but are acceptable for a
- twisted one (since the whole wing will not stall at
- the same time).
- peak: The height of the lift peak, relative to the
- post-stall secondary lift peak at 45 degrees.
- Defaults to 1.5. This one is deep voodoo, and
- probably doesn't need to change much. Bug me for an
- explanation if you're curious.
-
-flap0, flap1, slat, spoiler:
- These are subelements of wing/hstab/vstab objects, and specify
- the location and effectiveness of the control surfaces.
- start: The position along the wing where the control
- surface begins. Zero is the root, one is the tip.
- end: The position where the surface ends, as above.
- lift: The lift multiplier for a flap or slat at full
- extension. One is a no-op, a typical aileron might
- be 1.2 or so, a giant jetliner flap 2.0, and a
- spoiler 0.0. For spoilers, the interpretation is a
- little different -- they spoil only "prestall" lift.
- Lift due purely to "flat plate" effects isn't
- affected. For typical wings that stall at low AoA's
- essentially all lift is pre-stall and you don't have
- to care. Jet fighters tend not to have wing
- spoilers, for exactly this reason. This value is
- not applicable to slats, which affect stall AoA
- only.
- drag: The drag multiplier, as above. Typically should be
- higher than the lift multiplier for flaps.
- aoa: Applicable only to slats. This indicates the
- angle by which the stall AoA is translated by the
- slat extension.
-
-thruster: A very simple "thrust only" engine object. Useful for
- things like thrust vectoring nozzles. All it does is map
- its THROTTLE input axis to its output thrust rating. Does
- not consume fuel, etc...
- thrust: Maximum thrust in pounds
- x,y,z: The point on the airframe where thrust will be
- applied.
- vx,vy,vy: The direction of the thrust in airframe
- coordinates. The vector will be normalized
- automatically, so any non-zero vector will work
- fine.
-
-jet: A turbojet/fan engine. It accepts a subelement to map a
- property to its throttle setting, and an subelement
- to place the action point of the thrust at a different
- position than the mass of the engine.
- x,y,z: The location of the engine, as a point mass.
- If no actionpt is specified, this will also
- be the point of application of thrust.
- mass: The mass of the engine, in pounds.
- thrust: The maximum sea-level thrust, in pounds.
- afterburner: Maximum total thrust with afterburner/reheat,
- in pounds [defaults to "no additional
- thrust"].
- rotate: Vector angle of the thrust in degrees about the
- Y axis [0].
- n1-idle: Idling rotor speed [55].
- n1-max: Maximum rotor speed [102].
- n2-idle: Idling compressor speed [73].
- n2-max: Maximum compressor speed [103].
- tsfc: Thrust-specific fuel consumption [0.8].
- This should be considerably lower for modern
- turbofans.
- egt: Exhaust gas temperature at takeoff [1050].
- epr: Engine pressure ratio at takeoff [3.0].
- exhaust-speed: The maximum exhaust speed in knots [~1555].
- spool-time: Time, in seconds, for the engine to respond to
- 90% of a commanded power setting.
-
-propeller: A propeller. This element requires an engine subtag.
- Currently and are
- supported.
- x,y,z: The position of the mass (!) of the
- engine/propeller combination. If the point
- of force application is different (and it
- will be) it should be set with an
- subelement.
- mass: The mass of the engine/propeller, in pounds.
- moment: The moment, in kg-meters^2. This has to be
- hand calculated and guessed at for now. A
- more automated system will be forthcoming.
- Use a negative moment value for
- counter-rotating ("European" -- CCW as seen
- from behind the prop) propellers.
- A good guess for this value is the radius of
- the prop (in meters) squared times the mass
- (kg) divided by three; that is the moment of
- a plain "stick" bolted to the prop shaft.
- radius: The radius, in meters, or the propeller.
- cruise-speed: The max efficiency cruise speed of the
- propeller. Generally not the same as the
- aircraft's cruise speed.
- cruise-rpm: The RPM of the propeller at max-eff. cruise.
- cruise-power: The power sunk by the prop at cruise, in horsepower.
- cruise-alt: The reference cruise altitude in feet.
- takeoff-power: The takeoff power required by the propeller...
- takeoff-rpm: ...at the given takeoff RPM.
- min-rpm: The minimum operational RPM for a constant speed
- propeller. This is the speed to which the
- prop governor will seek when the blue lever
- is at minimum. The coarse-stop attribute
- limits how far the governor can go into trying
- to reach this RPM.
- max-rpm: The maximum operational RPM for a constant speed
- propeller. See above. The fine-stop attribute
- limits how far the governor can go in trying
- to reach this RPM.
- fine-stop: The minimum pitch of the propeller (high RPM) as a
- ratio of ideal cruise pitch. This is set to 0.25
- by default -- a higher value will result in a
- lower RPM at low power settings (e.g. idle, taxi,
- and approach).
- coarse-stop: The maximum pitch of the propeller (low RPM) as
- a ratio of ideal cruise pitch. This is set to
- 4.0 by default -- a lower value may result in a
- higher RPM at high power settings.
- gear-ratio: The factor by which the engine RPM is multiplied
- to produce the propeller RPM. Optional (defaults
- to 1.0).
- contra: When set (contra="1"), this indicates that the
- propeller is a contra-rotating pair. It
- will not contribute to the aircraft's net
- gyroscopic moment, nor will it produce
- asymmetric torque on the aircraft body.
- Asymmetric slipstream effects, when
- implemented, will also be zero when this is
- set.
-
-piston-engine: A piston engine definition. This must be a subelement
- of an enclosing tag.
- eng-power: Maximum BHP of the engine at sea level.
- eng-rpm: The engine RPM at which eng-power is developed
- displacement: The engine displacement in cubic inches.
- compression: The engine compression ratio.
- turbo-mul: The turbo/super-charger pressure multiplier.
- Static pressure will be multiplied by this
- value to get the manifold pressure.
- wastegate-mp: The maximum manifold pressure. Beyond
- this, the gate will release to keep the
- MP below this number. (inHG). This value
- can be changed at runtime using the
- WASTEGATE control axis, which is a
- multiplier in the range [0:1].
- turbo-lag: Time lag, in seconds, for 90% of a power change
- to be reflected in the turbocharger boost
- pressure.
-
-turbine-engine: A turbine engine definition. This must be a subelement
- of an enclosing tag.
- eng-power: Maximum BHP of the engine at a suitable
- cruise altitude.
- eng-rpm: The engine RPM at which eng-power is
- developed. Note that this is "shaft" RPM
- as seen by the propeller. Don't use a
- gear-ratio on the enclosing propeller, or
- else you'll get confused. :)
- alt: The altitude at which eng-power is developed.
- This should be high enough to be lower (!)
- than the flat-rating power.
- flat-rating: The maximum allowed power developed by
- the engine. Most turboprops are flat
- rated below a certain altitude and
- temperature range to prevent engine
- damage.
- min-n2: N2 (percent) turbine speed at zero throttle.
- max-n2: N2 (percent) turbine speed at max throttle.
- bsfc: Specific fuel consumption, in lbs/hr per
- horsepower.
-
-
-actionpt: Defines an "action point" for an enclosing jet or propeller
- element. This is the location where the force from the thruster
- will be applied.
- x,y,z: The location of force application.
-
-gear: Defines a landing gear. Accepts subelements to map
- properties to steering and braking. Can also be used to simulate
- floats. Although the coefficients are still called ..fric, it
- is calculated in fluids as a drag (proportional to the square
- of the speed). In fluids gears are not considered to detect
- crashes (as on ground).
- x,y,z: The location of the fully-extended gear tip.
- compression: The distance in meters along the "up" axis that
- the gear will compress.
- initial-load: The initial load of the spring in multiples of
- compression. Defaults to 0. (With this parameter
- a lower spring-constants will be used for the
- gear-> can reduce numerical problems (jitter))
- Note: the spring-constant is varied from 0%
- compression to 20% compression to get continuous
- behavior around 0 compression. (could be physically
- explained by wheel deformation)
- upx/upy/upz: The direction of compression, defaults to
- vertical (0,0,1) if unspecified. These are
- used only for a direction -- the vector need
- not be normalized, as the length is specified
- by "compression".
- sfric: Static (non-skidding) coefficient of
- friction. Defaults to 0.8.
- dfric: Dynamic friction. Defaults to 0.7.
- spring: A dimensionless multiplier for the automatically
- generated spring constant. Increase to make
- the gear stiffer, decrease to make it
- squishier.
- damp: A dimensionless multiplier for the automatically
- generated damping coefficient. Decrease to
- make the gear "bouncier", increase to make it
- "slower". Beware of increasing this too far:
- very high damping forces can make the numerics
- unstable. If you can't make the gear stop
- bouncing with this number, try increasing the
- compression length instead.
- on-water: if this is set to "0" the gear will be ignored if
- on water. Defaults to "0"
- on-solid: if this set to "0" the gear will be ignored if
- not on water. Defaults to "1"
- speed-planing:
- spring-factor-not-planing:
- At zero speed the spring factor is multiplied by
- spring-factor-not-planing. Above speed-planing this
- factor is equal to 1. The idea is, to use this for
- floats simulating the transition from swimming to
- planing. speed-planing defaults to 0,
- spring-factor-not-planing defaults to 1.
- reduce-friction-by-extension: at full extension the friction is
- reduced by this relative value. 0.7 means 30% friction
- at full extension. If you specify a value greater
- than one, the friction will be zero before reaching
- full extension. Defaults to "0"
- ignored-by-solver: with the on-water/on-solid tags you can have more
- than one set of gears in one aircraft, If the solver
- (who automatically generates the spring constants)
- would take all gears into account, the result would be
- wrong. E. G. set this tag to "1" for all gears, which
- are not active on runways. Defaults to "0". You can
- not exclude all gears in the solving process.
-
-launchbar: Defines a catapult launchbar or strop. The default acceleration
- provided by the catapult is 25m/s^2. This can be
- modified by the use of the control axis LACCEL.
- x,y,z: The location of the mount point of the launch bar or
- strop on the aircraft.
- length: The length of the launch bar from mount point to tip
- down-angle: The max angle below the horizontal the
- launchbar can achieve.
- up-angle: The max angle above the horizontal the launchbar
- can achieve.
- holdback-{x,y,z}: The location of the holdback mount point
- on the aircraft.
- holdback-length: The length of the holdback from mount
- point to tip. Note: holdback up-angle and
- down-angle are the same as those defined
- for the launchbar and are not specified in
- the configuration.
-
-tank: A fuel tank. Tanks in the aircraft are identified
- numerically (starting from zero), in the order they are
- defined in the file. If the left tank is first, "tank[0]"
- will be the left tank.
- x,y,z: The location of the tank.
- capacity: The maximum contents of the tank, in pounds. Not
- gallons -- YASim supports fuels of varying
- densities.
- jet: A boolean. If present, this causes the fuel
- density to be treated as Jet-A. Otherwise,
- gasoline density is used. A more elaborate
- density setting (in pounds per gallon, for
- example) would be easy to implement. Bug me.
-
-ballast: This is a mechanism for modifying the mass distribution of
- the aircraft. A ballast setting specifies that a particular
- amount of the empty weight of the aircraft must be placed at
- a given location. The remaining non-ballast weight will be
- distributed "intelligently" across the fuselage and wing
- objects. Note again: this does NOT change the empty weight
- of the aircraft.
- x,y,z: The location of the ballast.
- mass: How much mass, in pounds, to put there. Note that
- this value can be negative. I find that I often need
- to "lighten" the tail of the aircraft.
-
-weight: This is an added weight, something not part of the empty
- weight of the aircraft, like passengers, cargo, or external
- stores. The actual value of the mass is not specified here,
- instead, a mapping to a property is used. This allows
- external code, such as the panel, to control the weight
- (loading a given cargo configuration from preference files,
- dropping bombs at runtime, etc...)
- x,y,z: The location of the weight.
- mass-prop: The name of the fgfs property containing the
- mass, in pounds, of this weight.
- size: The aerodynamic "size", in meters, of the
- object. This is important for external stores,
- which will cause drag. For reasonably
- aerodynamic stuff like bombs, the size should be
- roughly the width of the object. For other
- stuff, you're on your own. The default is zero,
- which results in no aerodynamic force (internal
- cargo).
-
-solve-weight:
- Subtag of approach and cruise parameters. Used to specify a
- non-zero setting for a tag during solution. The
- default is to assume all weights are zero at the given
- performance numbers.
- idx: Index of the weight in the file (starting with zero).
- weight: Weight setting in pounds.
-
-
-control-input:
- This element manages a mapping from fgfs properties (user
- input) to settable values on the aircraft's objects. Note
- that the value to be set MUST (!) be valid on the given
- object type. This is not checked for by the parser, and
- will cause a runtime crash if you try it. Wing's don't have
- throttle controls, etc... Note that multiple axes may be
- set on the same value. They are summed before setting.
-
- axis: The name of the double-valued fgfs property "axis" to
- use as input, such as "/controls/flight/aileron".
- control: Which control axis to set on the objects. It can have
- the following values:
- THROTTLE - The throttle on a jet or propeller.
- MIXTURE - The mixture on a propeller.
- REHEAT - The afterburner on a jet
- PROP - The propeller advance
- BRAKE - The brake on a gear.
- STEER - The steering angle on a gear.
- INCIDENCE - The incidence angle of a wing.
- FLAP0 - The flap0 deflection of a wing.
- FLAP1 - The flap1 deflection of a wing.
- FLAP[0/1]EFFECTIVENESS - a multiplier for flap lift, but not drag
- (useful for blown flaps)
- SLAT - The slat extension of a wing.
- SPOILER - The spoiler extension for a wing.
- CYCLICAIL - The "aileron" cyclic input of a rotor
- CYCLICELE - The "elevator" cyclic input of a rotor
- COLLECTIVE - The collective input of a rotor
- ROTORENGINEON - If not equal zero the rotor is rotating
- WINCHRELSPEED - The relative winch speed
- LACCEL - The acceleration provided by the catapult.
- {... and many more, see FGFDM.cpp ...}
- invert: Negate the value of the property before setting on
- the object.
- split: Applicable to wing control surfaces. Sets the
- normal value on the left wing, and a negated value
- on the right wing.
- square: Squares the value before setting. Useful for
- controls like steering that need a wide range, yet
- lots of sensitivity in the center. Obviously only
- applicable to values that have a range of [-1:1] or
- [0:1].
- src0/src1/dst0/dst1:
- If present, these defined a linear mapping from the
- source to the output value. Input values in the
- range src0-src1 are mapped linearly to dst0-dst1,
- with clamping for input values that lie outside the
- range.
-
-control-output:
- This can be used to pass the value of a YASim control axis
- (after all mapping and summing is applied) back to the
- property tree.
-
- control: Name of the control axis. See above.
- prop: Property node to receive the value.
- side: Optional, for split controls. Either "right" or "left"
- min/max: Clamping applied to output value.
-
-control-speed:
- Some controls (most notably flaps and hydraulics) have
- maximum slew rates and cannot respond instantly to pilot
- input. This can be implemented with a control-speed tag,
- which defines a "transition time" required to slew through
- the full input range. Note that this tag is
- semi-deprecated, complicated control input filtering can be
- done much more robustly from a Nasal script.
-
- control: Name of the control axis. See above.
- transition-time: Time in seconds to slew through input range.
-
-control-setting:
- This tag is used to define a particular setting for a
- control axis inside the or tags, where
- obviously property input is not available. It can be used,
- for example, to inform the solver that the approach
- performance values assume full flaps, etc...
-
- axis: Name of the control input (i.e. a property name)
- value: Value of the control axis.
-
-hitch: A hitch, can be used for winch-start (in gliders) or aerotow (in
- gliders and motor aircrafts) or for external cargo with helicopter.
- You can do aerotow over the net via multiplayer (see j3 and bocian
- as an example).
-
- name: the name of the hitch. must be aerotow if you want to do
- aerotow via multiplayer. You will find many properties
- at /sim/hitches/name. Most of them are directly tied to
- the internal variables, you can modify them as you like.
- You can add a listener to the property "broken", e. g. for
- playing a sound.
- x,y,z: The position of the hitch
- force-is-calculated-by-other: if you want to simulate aerotowing
- over the internet, set this value to "1" in the motor
- aircraft. Don't specify or set this to zero in gliders.
- In a LAN the time lag might be small enough to set it on
- both aircrafts to "0". It's intended, that this is done
- automatically in the future.
-
-tow: The tow used for aerotow or winch. This must be a subelement
- of an enclosing tag.
- length: upstretched length in m
- weight-per-meter: in kg/m
- elastic-constant: lower values give higher elasticity
- break-force: in N
- mp-auto-connect-period: the every x seconds a towed multiplayer
- aircraft is searched. If found, this tow is connected
- automatically, parameters are copied from the other
- aircraft. Should be set only in the motor aircraft, not
- in the glider
-
-winch: The tow used for aerotow or winch. This must be a subelement
- of an enclosing tag.
- max-tow-length:
- min-tow-length:
- initial-tow-length: all are in m. The initial tow length also
- defines the length/search radius used for the mp-autoconnect
- feature
- max-winch-speed: in m/s
- power: in kW
- max-force: in N
-
-
-rotor: A rotor. Used for simulating helicopters. You can have one, two
- or even more.
- There is a drawing of a rotor in the Doc-directory
- (README.yasim.rotor.png) Please find the measures from this drawing
- for several parameters in square brackets [].
- If you specify a rotor, you do not need to specify a wing or hstab,
- the settings for approach and cruise will be ignored then. You have
- to specify the solver results manually. See below.
- The rotor generates downwash acting on all stabs, surfaces and
- fuselages. For all fuselages in the rotor downwash you should
- specify idrag="0" to get realistic results.
-
- name: The name of the rotor.
- (some data is stored at /rotors/name/)
- The rpm, cone angle, yaw angle and roll angle are stored
- for the complete rotor. For every blade the position
- angle, the flap angle and the incidence angle are stored.
- All angles are in degree, positive values always mean "up".
- This is not completely tested, but seem to work at least
- for rotors rotating counterclockwise.
- A value stall gives the fraction of the rotor in stall
- (weighted by the fraction the have on lift and drag
- without stall). Use this for modifying the rotor-sound.
- x,y,z: The position of the rotor center
- nx,ny,nz: The normal of the rotor (pointing upwards, will be
- normalized by the computer)
- fx,fy,fz: A Vector pointing forward, if not perpendicular to the
- normal it will be corrected by the computer
- diameter: The diameter in meter [D]
- numblades: The number of blades
- weightperblade: The weight per blade in pounds
- relbladecenter: The relative center of gravity of the blade. Maybe
- not 100% correct interpreted; use 0.5 for the start and
- change in small steps [b/R]
- chord: The chord of the blade its base, along the X axis
- (not normal to the leading edge, as it is
- sometimes defined). [c]
- twist: The difference between the incidence angle at the
- blade root and the incidence angle at the wing
- tip. Typically, this is a negative number so
- that the rotor tips have a lower angle of attack.
- taper: The taper fraction, expressed as the tip chord
- divided by the root chord. A taper of one is a
- bar blade, and zero would be a blade ending
- at a point. Defaults to one. [d/c]
- rel-len-where-incidence-is-measured: If the blade is twisted,
- you need a point where to measure the incidence angle.
- Zero means at the base, 1 means at the tip. Typically
- it should be something near 0.7
- rel-len-blade-start: Typically the blade is not mounted in the
- center of the rotor [a/R]
- rpm: rounds per minute.
- phi0: initial position of this rotor
- ccw: determines if the rotor rotates clockwise (="0") or
- counterclockwise (="1"), (if you look on the top of the
- normal, so the bo105 has counterclockwise rotor).
- "true" and "false" are not any longer supported to
- increase my lifespan. ;-)
- maxcollective: The maximum of the collective incidence in degree
- mincollective: The minimum of the collective incidence in degree
- maxcyclicele: The maximum of the cyclic incidence in degree for
- the elevator like function
- mincyclicele: The minimum of the cyclic incidence in degree for
- the elevator like function
- maxcyclicail: The maximum of the cyclic incidence in degree for
- the aileron like function
- mincyclicail: The minimum of the cyclic incidence in degree for
- the aileron like function
- airfoil-incidence-no-lift: non symmetric airfoils produces lift
- with no incidence. This is is the incidence, where the
- airfoil is producing no lift. Zero for symmetrical airfoils
- (default)
- incidence-stall-zero-speed:
- incidence-stall-half-sonic-speed: the stall incidence is a function
- of the speed. I found some measured data, where this is
- linear over a wide range of speed. Of course the linear
- region ends at higher speeds than zero, but just
- extrapolate the linear behavior to zero.
- lift-factor-stall: In stall airfoils produce less lift. Without
- stall the c-lift of the profile is assumed to be
- sin(incidence-"airfoil-incidence-no-lift")*liftcoef;
- And in stall:
- sin(2*(incidence-"airfoil-incidence-no-lift"))*liftcoef*...
- ..."lift-factor-stall";
- Therefore this factor is not the quotient between lift
- with and without stall. Use 0.28 if you have no idea.
- drag-factor-stall: The drag of an airfoil in stall is larger than
- without stall.
- Without stall c-drag is assumed to be
- abs(sin(incidence-"airfoil-incidence-no-lift"))...
- ..*dragcoef1+dragcoef0);
- With stall this is multiplied by drag-factor
- stall-change-over: For incidence<"incidence-stall" there is no stall.
- For incidence>("incidence-stall"+"stall-change-over") there
- is stall. In the range between this incidences it is
- interpolated linear.
-
- pitch-a:
- pitch-b: collective incidence angles, If you start flightgear
- with --log-level=info, flightgear reports lift and needed
- power for theses incidence angles
- forceatpitch-a:
- poweratpitch-b:
- poweratpitch-0: old tokens, not supported any longer, the result are
- not exactly the expected lift and power values. Will be
- removed in one of the next updates.directly.Use "real"
- coefficients instead (see below) and adjust the lift with
- rotor-correction-factor.
-
- The airfoil of the rotor is described as follows:
- The way is to define the lift and drag coefficients directly.
- Without stall the c-lift of the profile is assumed to be
- sin(incidence-"airfoil-incidence-no-lift")*liftcoef;
- And in stall:
- sin(2*(incidence-"airfoil-incidence-no-lift"))*liftcoef*...
- ..."lift-factor-stall";
- Without stall c-drag is assumed to be
- abs(sin(incidence-"airfoil-incidence-no-lift"))...
- ..*dragcoef1+dragcoef0);
- See above, how the coefficients are defined with stall.
- The parameters:
- airfoil-lift-coefficient: liftcoef
- airfoil-drag-coefficient0: dragcoef0
- airfoil-drag-coefficient1: dragcoef1
- To find the right values: see README.yasim.rotor.ods
- (Open Office file) or README.yasim.rotor.xls (Excel
- file). With theses files you can generate graphs of the
- airfoil coefficients and adjust the parameters to match
- real airfoils. For many airfoils you find data published
- in the internet. Parameters for the airfoils NACA 23012
- (main rotor of bo105) and NACA 0012 (tail rotor of bo105?)
- are included.
-
- rotor-correction-factor:
- If you calculate the lift of a heli rotor or even of a
- propeller, you get a value larger than the real measured
- one. (Due to vortex effects.) This is considered in the
- simulation, but with a old theory by Prantl, which is known
- to give still too large. This is corrected by this token,
- default: 1
- flapmin: Minimum flapping angle. (Should normally never reached)
- flapmax: Maximum flapping angle. (Should normally never reached)
- flap0: Flapping angle at no rotation, i.e. -5
- dynamic: this changes the reactions speed of the rotor to an input.
- normally 1 (Maybe there are rotors with a little faster
- reaction, than use a value a little greater than one.
- A value greater than one will result in a more inert,
- system. Maybe it's useful for simulating the rotor of the
- Bell UH1
- rellenflaphinge: The relative length from the center of the rotor
- to the flapping hinge. Can be taken from pictures of the
- helicopter (i.e. 0 for Bell206, about 0.05 for most
- rotors) For rotors without flapping hinge (where the blade
- are twisted instead, i.e. Bo 105, Lynx) use a mean value,
- maybe 0.2. This value has a extreme result in the behavior
- of the rotor [F/r]
- sharedflaphinge: determines, if the rotor has one central flapping
- hinge (="1") for the blades (like the Bell206 or the tail
- rotor of the Bo 105), default is "0".
- delta3: Some rotors have a delta3 effect, which results in a
- decreasing of the incidence when the rotor is flapping.
- A value of 0 (as most helicopters have) means no change in
- incidence, a value of 1 result in a decreases of one degree
- per one degree flapping.
- So delta3 is the proportional factor between flapping and
- decrease of incidence. I.e. the tail rotor of a Bo105 has
- a delta3 of 1.
- In some publications delta3 is described by an angle. The
- value in YASim is the atan of this angle
- delta: A factor for the damping constant for the flapping. 1 means
- a analytical result, which is only a approximation. Has a
- very strong result in the reaction of the rotor system on
- control inputs.
- If you know the flapping angle for a given cyclic input you
- can adjust this by changing this value. Or if you now the
- maximum roll rate or ...
- translift-maxfactor: Helicopters have "translational lift", which
- is due to turbulence. In forward flying the rotor gets less
- turbulence air and produces more lift. The factor is the
- quotient between lift at high airspeeds to the lift at
- hover (with same pitch).
- translift-ve: the speed, where the translational lift reaches 1/e of
- the maximum value. In m/s.
- ground-effect-constant: Near to the ground the rotor produces more
- torque than in higher altitudes. The ground effect is
- calculated as
- factor = 1+diameter/altitude*"ground-effect-constant"
- number-of-parts:
- number-of-segments: The rotor is simulated in "number-of-parts"
- different directions.
- In every direction the rotor is simulated at
- number-of-segments points. If the value is to small, the
- rotor will react unrealistic. If it is to high, cpu-power
- will be wasted. I now use a value of 8 for
- "number-of-parts" and 8 for number-of-segments for the main
- rotor and 4 for "number-of-parts" and 5 for
- "number-of-segments" for the tail rotor.
- "number-of-parts" must be a multiple of 4 (if not, it
- is corrected)
- cyclic-factor: The response of a rotor to cyclic input is hard to
- calculate (its a damped oscillator in resonance, some
- parameters have very large impact to the cyclic response)
- With this parameter (default 1) you can adjust the
- simulator to the real helo.
- downwashfactor: A factor for the downwash of the rotor, default 1.
- balance: The balance of the rotor. 1.0: the rotor is 100% balanced,
- 0.0: half of the blades are missing. Use a value near one
- (0.98 ... 0.999) to add some vibration.
- tiltcenterx:
- tiltcentery:
- tiltcenterz: The center for the tilting of the complete rotorhead/
- mast. Can be used for simulating of the Osprey or small
- autogyros.
- mintiltyaw:
- mintiltpitch:
- mintiltroll:
- maxtiltyaw:
- maxtiltpitch:
- maxtiltroll: The limits (in degree) for tilting the rotor head
-
- All rotor can have subelements for the cyclic
- (CYCLICELE, CYCLICAIL) and collective (COLLECTIVE) input.
- and can have subelements for the tilting the whole rotor
- head around the y-axis (TILTPITCH), the x-axis (TILTROLL) and the
- z-axis (TILTYAW). ROTORBALANCE is a factor for the balance.
-
-rotorgear: If you are using one or more rotors you have to define a
- rotorgear. It connects all the rotors and adds a simple engine.
- In future it will be possible, to add a YASim-engine.
- max-power-engine: the maximum power of the engine, in kW.
- engine-prop-factor: the engine is working as a pd-regulator. This
- is the width of the regulation-band, or, in other words,
- the inverse of the proportional-factor of the regulator.
- If you set it to 0.02, than up to 98% of the rotor-rpm
- the engine will produce maximum torque. At 100% of
- the engine will produce no torque. It is planned to use
- YASim-engines instead of this simple engine.
- engine-accel-limit: The d-factor of the engine is defined as the
- maximum acceleration rate of the engine in %/s,
- default is 5%/s.
- max-power-rotor-brake: the maximum power of the rotor brake, in kW
- at normal rpm (most? real rotor brakes would be overheated
- if used at normal rpm, but this is not simulated now)
- rotorgear-friction: the power loss due to friction in kW at normal
- RPM
- yasimdragfactor:
- yasimliftfactor: the solver is not working with rotor-aircraft.
- Therefore you have to specify the results yourself.
- 10 for drag and 140 for lift seem to be good starting
- values. Although the solve is not invoked for aircraft
- with at least one rotor, you need to specify the cruise
- and the approach settings. The approach speed is needed to
- calculate the gear springs. Use a speed of approx. 50knots.
- They do not need to match any real value.
-
- The rotorgear needs a subelement for the engine
- (ROTORGEARENGINEON) and can have further subelements:
- ROTORBRAKE: rotor brake
- ROTORRELTARGET: the target rpm of the engine relative to
- the "normal" value for the governor. Default is
- 1.
- ROTORENGINEMAXRELTORQUE: the maximum torque of the engine
- relative to the torque defined by the engine-
- power. Default is 1. By setting the rel-target
- to a large number you get control over the
- engine by this control.
- Alternatively you can use these two values for
- individual start-up sequences (see the s58)
-
+Coordinate system notes: All positions specified are in meters (which
+is weird, since all other units in the file are English). The X axis
+points forward, Y is left, and Z is up. Take your right hand, and
+hold it like a gun. Your first and second fingers are the X and Y
+axes, and your upwards-pointing thumb is the Z. This is slightly
+different from the coordinate system used by JSBSim. Sorry. The
+origin can be placed anywhere, so long as you are consistent. I use
+the nose of the aircraft.
+
+XML Elements
+------------
+
+airplane: The top-level element for the file. It contains only one
+ attribute:
+ mass: The empty (no fuel) weight, in pounds.
+
+approach: The approach parameters for the aircraft. The solver will
+ generate an aircraft that matches these settings. The element
+ can (and should) contain elements indicating pilot
+ input settings, such as flaps and throttle, for the
+ approach.
+ speed: The approach airspeed, in knots TAS.
+ aoa: The approach angle of attack, in degrees
+ fuel: Fraction (0-1) of fuel in the tanks. Default is 0.2.
+
+cruise: The cruise speed and altitude for the solver to match. As
+ above, this should contain elements indicating
+ aircraft configuration. Especially, make sure the engines
+ are generating enough thrust at cruise!
+ speed: The cruise speed, in knots TAS.
+ alt: The cruise altitude, in feet MSL.
+ fuel: Fraction (0-1) of fuel in the tanks. Default is 0.2.
+
+cockpit: The location of the cockpit (pilot eyepoint).
+ x,y,z: eyepoint location (see coordinates note)
+
+fuselage: This defines a tubelike structure. It will be given an even
+ mass and aerodynamic force distribution by the solver. You
+ can have as many as you like, in any orientation you please.
+ ax,ay,az: One end of the tube (typically the front)
+ bx,by,bz: The other ("back") end.
+ width: The width of the tube, in meters.
+ taper: The approximate radius at the "tips" of the fuselage
+ expressed as a fraction (0-1) of the width value.
+ midpoint: The location of the widest part of the fuselage,
+ expressed as a fraction of the distance between A and B.
+ idrag: Multiplier for the "induced drag" generated by this
+ object. Default is one. With idrag=0 the fuselage
+ generates only drag.
+ cx,cy,cz: Factors for the generated drag in the fuselages "local
+ coordinate system" with x pointing from end to front,
+ z perpendicular to x with y=0 in the aircraft coordinate
+ system. E.g. for a fuselage of a height of 2 times the
+ width you can define cy=2 and (due to the doubled front
+ surface) cx=2.
+
+wing: This defines the main wing of the aircraft. You can have
+ only one (but see below about using vstab objects for extra
+ lifting surfaces). The wing should have a subelement to
+ indicate stall behavior, control surface subelements (flap0,
+ flap1, spoiler, slat) to indicate what and where the control
+ surfaces are, and subelements to map user input
+ properties to the control surfaces.
+ x,y,z: The "base" of the wing, specified as the location of
+ the mid-chord (not leading edge, trailing edge, or
+ aerodynamic center) point at the root of the LEFT
+ (!) wing.
+ length: The length from the base of the wing to the midchord
+ point at the tip. Note that this is not the same
+ thing as span.
+ chord: The chord of the wing at its base, along the X axis
+ (not normal to the leading edge, as it is
+ sometimes defined).
+ incidence: The incidence angle at the wing root, in degrees.
+ Zero is level with the fuselage (as in an
+ aerobatic plane), positive means that the leading
+ edge is higher than the trailing edge (as in a
+ trainer).
+ twist: The difference between the incidence angle at the
+ wing root and the incidence angle at the wing
+ tip. Typically, this is a negative number so
+ that the wing tips have a lower angle of attack
+ and stall after the wing root (washout).
+ taper: The taper fraction, expressed as the tip chord
+ divided by the root chord. A taper of one is a
+ hershey bar wing, and zero would be a wing ending
+ at a point. Defaults to one.
+ sweep: The sweep angle of the wing, in degrees. Zero is
+ no sweep, positive angles are swept back.
+ Defaults to zero.
+ dihedral: The dihedral angle of the wing. Positive angles
+ are upward dihedral. Defaults to zero.
+ idrag: Multiplier for the "induced drag" generated by this
+ surface. In general, low aspect wings will
+ generate less induced drag per-AoA than high
+ aspect (glider) wings. This value isn't
+ constrained well by the solution process, and may
+ require tuning to get throttle settings correct in
+ high AoA (approach) situations.
+ camber: The lift produced by the wing at zero angle of
+ attack, expressed as a fraction of the maximum
+ lift produced at the stall AoA.
+
+hstab: These defines the horizontal stabilizer of the aircraft.
+ Internally, it is just a wing object and therefore works the
+ same in XML. You are allowed only one hstab object; the
+ solver needs to know which wing's incidence to play with to
+ get the aircraft trimmed correctly.
+
+vstab: A "vertical" stabilizer. Like hstab, this is just another
+ wing, with a few special properties. The surface is not
+ "mirrored" as are wing and hstab objects. If you define a
+ left wing only, you'll only get a left wing. The default
+ dihedral, if unspecified, is 90 degrees instead of zero.
+ But all parameters are equally settable, so there's no
+ requirement that this object be "vertical" at all. You can
+ use it for anything you like, such as extra wings for
+ biplanes. Most importantly, these surfaces are not involved
+ with the solver computation, so you can have none, or as
+ many as you like.
+
+mstab: A mirrored horizontal stabilizer. Exactly the same as wing, but
+ not involved with the solver computation, so you can have none,
+ or as many as you like.
+
+stall: A subelement of a wing (or hstab/vstab/mstab) that specifies the
+ stall behavior.
+ aoa: The stall angle (maximum lift) in degrees. Note that
+ this is relative to the wing, not the fuselage (since
+ the wing may have a non-zero incidence angle).
+ width: The "width" of the stall, in degrees. A high value
+ indicates a gentle stall. Low values are viscious
+ for a non-twisted wing, but are acceptable for a
+ twisted one (since the whole wing will not stall at
+ the same time).
+ peak: The height of the lift peak, relative to the
+ post-stall secondary lift peak at 45 degrees.
+ Defaults to 1.5. This one is deep voodoo, and
+ probably doesn't need to change much. Bug me for an
+ explanation if you're curious.
+
+flap0, flap1, slat, spoiler:
+ These are subelements of wing/hstab/vstab objects, and specify
+ the location and effectiveness of the control surfaces.
+ start: The position along the wing where the control
+ surface begins. Zero is the root, one is the tip.
+ end: The position where the surface ends, as above.
+ lift: The lift multiplier for a flap or slat at full
+ extension. One is a no-op, a typical aileron might
+ be 1.2 or so, a giant jetliner flap 2.0, and a
+ spoiler 0.0. For spoilers, the interpretation is a
+ little different -- they spoil only "prestall" lift.
+ Lift due purely to "flat plate" effects isn't
+ affected. For typical wings that stall at low AoA's
+ essentially all lift is pre-stall and you don't have
+ to care. Jet fighters tend not to have wing
+ spoilers, for exactly this reason. This value is
+ not applicable to slats, which affect stall AoA
+ only.
+ drag: The drag multiplier, as above. Typically should be
+ higher than the lift multiplier for flaps.
+ aoa: Applicable only to slats. This indicates the
+ angle by which the stall AoA is translated by the
+ slat extension.
+
+thruster: A very simple "thrust only" engine object. Useful for
+ things like thrust vectoring nozzles. All it does is map
+ its THROTTLE input axis to its output thrust rating. Does
+ not consume fuel, etc...
+ thrust: Maximum thrust in pounds
+ x,y,z: The point on the airframe where thrust will be
+ applied.
+ vx,vy,vy: The direction of the thrust in airframe
+ coordinates. The vector will be normalized
+ automatically, so any non-zero vector will work
+ fine.
+
+jet: A turbojet/fan engine. It accepts a subelement to map a
+ property to its throttle setting, and an subelement
+ to place the action point of the thrust at a different
+ position than the mass of the engine.
+ x,y,z: The location of the engine, as a point mass.
+ If no actionpt is specified, this will also
+ be the point of application of thrust.
+ mass: The mass of the engine, in pounds.
+ thrust: The maximum sea-level thrust, in pounds.
+ afterburner: Maximum total thrust with afterburner/reheat,
+ in pounds [defaults to "no additional
+ thrust"].
+ rotate: Vector angle of the thrust in degrees about the
+ Y axis [0].
+ n1-idle: Idling rotor speed [55].
+ n1-max: Maximum rotor speed [102].
+ n2-idle: Idling compressor speed [73].
+ n2-max: Maximum compressor speed [103].
+ tsfc: Thrust-specific fuel consumption [0.8].
+ This should be considerably lower for modern
+ turbofans.
+ egt: Exhaust gas temperature at takeoff [1050].
+ epr: Engine pressure ratio at takeoff [3.0].
+ exhaust-speed: The maximum exhaust speed in knots [~1555].
+ spool-time: Time, in seconds, for the engine to respond to
+ 90% of a commanded power setting.
+
+propeller: A propeller. This element requires an engine subtag.
+ Currently and are
+ supported.
+ x,y,z: The position of the mass (!) of the
+ engine/propeller combination. If the point
+ of force application is different (and it
+ will be) it should be set with an
+ subelement.
+ mass: The mass of the engine/propeller, in pounds.
+ moment: The moment, in kg-meters^2. This has to be
+ hand calculated and guessed at for now. A
+ more automated system will be forthcoming.
+ Use a negative moment value for
+ counter-rotating ("European" -- CCW as seen
+ from behind the prop) propellers.
+ A good guess for this value is the radius of
+ the prop (in meters) squared times the mass
+ (kg) divided by three; that is the moment of
+ a plain "stick" bolted to the prop shaft.
+ radius: The radius, in meters, or the propeller.
+ cruise-speed: The max efficiency cruise speed of the
+ propeller. Generally not the same as the
+ aircraft's cruise speed.
+ cruise-rpm: The RPM of the propeller at max-eff. cruise.
+ cruise-power: The power sunk by the prop at cruise, in horsepower.
+ cruise-alt: The reference cruise altitude in feet.
+ takeoff-power: The takeoff power required by the propeller...
+ takeoff-rpm: ...at the given takeoff RPM.
+ min-rpm: The minimum operational RPM for a constant speed
+ propeller. This is the speed to which the
+ prop governor will seek when the blue lever
+ is at minimum. The coarse-stop attribute
+ limits how far the governor can go into trying
+ to reach this RPM.
+ max-rpm: The maximum operational RPM for a constant speed
+ propeller. See above. The fine-stop attribute
+ limits how far the governor can go in trying
+ to reach this RPM.
+ fine-stop: The minimum pitch of the propeller (high RPM) as a
+ ratio of ideal cruise pitch. This is set to 0.25
+ by default -- a higher value will result in a
+ lower RPM at low power settings (e.g. idle, taxi,
+ and approach).
+ coarse-stop: The maximum pitch of the propeller (low RPM) as
+ a ratio of ideal cruise pitch. This is set to
+ 4.0 by default -- a lower value may result in a
+ higher RPM at high power settings.
+ gear-ratio: The factor by which the engine RPM is multiplied
+ to produce the propeller RPM. Optional (defaults
+ to 1.0).
+ contra: When set (contra="1"), this indicates that the
+ propeller is a contra-rotating pair. It
+ will not contribute to the aircraft's net
+ gyroscopic moment, nor will it produce
+ asymmetric torque on the aircraft body.
+ Asymmetric slipstream effects, when
+ implemented, will also be zero when this is
+ set.
+
+piston-engine: A piston engine definition. This must be a subelement
+ of an enclosing tag.
+ eng-power: Maximum BHP of the engine at sea level.
+ eng-rpm: The engine RPM at which eng-power is developed
+ displacement: The engine displacement in cubic inches.
+ compression: The engine compression ratio.
+ turbo-mul: The turbo/super-charger pressure multiplier.
+ Static pressure will be multiplied by this
+ value to get the manifold pressure.
+ wastegate-mp: The maximum manifold pressure. Beyond
+ this, the gate will release to keep the
+ MP below this number. (inHG). This value
+ can be changed at runtime using the
+ WASTEGATE control axis, which is a
+ multiplier in the range [0:1].
+ turbo-lag: Time lag, in seconds, for 90% of a power change
+ to be reflected in the turbocharger boost
+ pressure.
+
+turbine-engine: A turbine engine definition. This must be a subelement
+ of an enclosing tag.
+ eng-power: Maximum BHP of the engine at a suitable
+ cruise altitude.
+ eng-rpm: The engine RPM at which eng-power is
+ developed. Note that this is "shaft" RPM
+ as seen by the propeller. Don't use a
+ gear-ratio on the enclosing propeller, or
+ else you'll get confused. :)
+ alt: The altitude at which eng-power is developed.
+ This should be high enough to be lower (!)
+ than the flat-rating power.
+ flat-rating: The maximum allowed power developed by
+ the engine. Most turboprops are flat
+ rated below a certain altitude and
+ temperature range to prevent engine
+ damage.
+ min-n2: N2 (percent) turbine speed at zero throttle.
+ max-n2: N2 (percent) turbine speed at max throttle.
+ bsfc: Specific fuel consumption, in lbs/hr per
+ horsepower.
+
+
+actionpt: Defines an "action point" for an enclosing jet or propeller
+ element. This is the location where the force from the thruster
+ will be applied.
+ x,y,z: The location of force application.
+
+gear: Defines a landing gear. Accepts subelements to map
+ properties to steering and braking. Can also be used to simulate
+ floats. Although the coefficients are still called ..fric, it
+ is calculated in fluids as a drag (proportional to the square
+ of the speed). In fluids gears are not considered to detect
+ crashes (as on ground).
+ x,y,z: The location of the fully-extended gear tip.
+ compression: The distance in meters along the "up" axis that
+ the gear will compress.
+ initial-load: The initial load of the spring in multiples of
+ compression. Defaults to 0. (With this parameter
+ a lower spring-constants will be used for the
+ gear-> can reduce numerical problems (jitter))
+ Note: the spring-constant is varied from 0%
+ compression to 20% compression to get continuous
+ behavior around 0 compression. (could be physically
+ explained by wheel deformation)
+ upx/upy/upz: The direction of compression, defaults to
+ vertical (0,0,1) if unspecified. These are
+ used only for a direction -- the vector need
+ not be normalized, as the length is specified
+ by "compression".
+ sfric: Static (non-skidding) coefficient of
+ friction. Defaults to 0.8.
+ dfric: Dynamic friction. Defaults to 0.7.
+ spring: A dimensionless multiplier for the automatically
+ generated spring constant. Increase to make
+ the gear stiffer, decrease to make it
+ squishier.
+ damp: A dimensionless multiplier for the automatically
+ generated damping coefficient. Decrease to
+ make the gear "bouncier", increase to make it
+ "slower". Beware of increasing this too far:
+ very high damping forces can make the numerics
+ unstable. If you can't make the gear stop
+ bouncing with this number, try increasing the
+ compression length instead.
+ on-water: if this is set to "0" the gear will be ignored if
+ on water. Defaults to "0"
+ on-solid: if this set to "0" the gear will be ignored if
+ not on water. Defaults to "1"
+ speed-planing:
+ spring-factor-not-planing:
+ At zero speed the spring factor is multiplied by
+ spring-factor-not-planing. Above speed-planing this
+ factor is equal to 1. The idea is, to use this for
+ floats simulating the transition from swimming to
+ planing. speed-planing defaults to 0,
+ spring-factor-not-planing defaults to 1.
+ reduce-friction-by-extension: at full extension the friction is
+ reduced by this relative value. 0.7 means 30% friction
+ at full extension. If you specify a value greater
+ than one, the friction will be zero before reaching
+ full extension. Defaults to "0"
+ ignored-by-solver: with the on-water/on-solid tags you can have more
+ than one set of gears in one aircraft, If the solver
+ (who automatically generates the spring constants)
+ would take all gears into account, the result would be
+ wrong. E. G. set this tag to "1" for all gears, which
+ are not active on runways. Defaults to "0". You can
+ not exclude all gears in the solving process.
+
+launchbar: Defines a catapult launchbar or strop. The default acceleration
+ provided by the catapult is 25m/s^2. This can be
+ modified by the use of the control axis LACCEL.
+ x,y,z: The location of the mount point of the launch bar or
+ strop on the aircraft.
+ length: The length of the launch bar from mount point to tip
+ down-angle: The max angle below the horizontal the
+ launchbar can achieve.
+ up-angle: The max angle above the horizontal the launchbar
+ can achieve.
+ holdback-{x,y,z}: The location of the holdback mount point
+ on the aircraft.
+ holdback-length: The length of the holdback from mount
+ point to tip. Note: holdback up-angle and
+ down-angle are the same as those defined
+ for the launchbar and are not specified in
+ the configuration.
+
+tank: A fuel tank. Tanks in the aircraft are identified
+ numerically (starting from zero), in the order they are
+ defined in the file. If the left tank is first, "tank[0]"
+ will be the left tank.
+ x,y,z: The location of the tank.
+ capacity: The maximum contents of the tank, in pounds. Not
+ gallons -- YASim supports fuels of varying
+ densities.
+ jet: A boolean. If present, this causes the fuel
+ density to be treated as Jet-A. Otherwise,
+ gasoline density is used. A more elaborate
+ density setting (in pounds per gallon, for
+ example) would be easy to implement. Bug me.
+
+ballast: This is a mechanism for modifying the mass distribution of
+ the aircraft. A ballast setting specifies that a particular
+ amount of the empty weight of the aircraft must be placed at
+ a given location. The remaining non-ballast weight will be
+ distributed "intelligently" across the fuselage and wing
+ objects. Note again: this does NOT change the empty weight
+ of the aircraft.
+ x,y,z: The location of the ballast.
+ mass: How much mass, in pounds, to put there. Note that
+ this value can be negative. I find that I often need
+ to "lighten" the tail of the aircraft.
+
+weight: This is an added weight, something not part of the empty
+ weight of the aircraft, like passengers, cargo, or external
+ stores. The actual value of the mass is not specified here,
+ instead, a mapping to a property is used. This allows
+ external code, such as the panel, to control the weight
+ (loading a given cargo configuration from preference files,
+ dropping bombs at runtime, etc...)
+ x,y,z: The location of the weight.
+ mass-prop: The name of the fgfs property containing the
+ mass, in pounds, of this weight.
+ size: The aerodynamic "size", in meters, of the
+ object. This is important for external stores,
+ which will cause drag. For reasonably
+ aerodynamic stuff like bombs, the size should be
+ roughly the width of the object. For other
+ stuff, you're on your own. The default is zero,
+ which results in no aerodynamic force (internal
+ cargo).
+
+solve-weight:
+ Subtag of approach and cruise parameters. Used to specify a
+ non-zero setting for a tag during solution. The
+ default is to assume all weights are zero at the given
+ performance numbers.
+ idx: Index of the weight in the file (starting with zero).
+ weight: Weight setting in pounds.
+
+
+control-input:
+ This element manages a mapping from fgfs properties (user
+ input) to settable values on the aircraft's objects. Note
+ that the value to be set MUST (!) be valid on the given
+ object type. This is not checked for by the parser, and
+ will cause a runtime crash if you try it. Wing's don't have
+ throttle controls, etc... Note that multiple axes may be
+ set on the same value. They are summed before setting.
+
+ axis: The name of the double-valued fgfs property "axis" to
+ use as input, such as "/controls/flight/aileron".
+ control: Which control axis to set on the objects. It can have
+ the following values:
+ THROTTLE - The throttle on a jet or propeller.
+ MIXTURE - The mixture on a propeller.
+ REHEAT - The afterburner on a jet
+ PROP - The propeller advance
+ BRAKE - The brake on a gear.
+ STEER - The steering angle on a gear.
+ INCIDENCE - The incidence angle of a wing.
+ FLAP0 - The flap0 deflection of a wing.
+ FLAP1 - The flap1 deflection of a wing.
+ FLAP[0/1]EFFECTIVENESS - a multiplier for flap lift, but not drag
+ (useful for blown flaps)
+ SLAT - The slat extension of a wing.
+ SPOILER - The spoiler extension for a wing.
+ CYCLICAIL - The "aileron" cyclic input of a rotor
+ CYCLICELE - The "elevator" cyclic input of a rotor
+ COLLECTIVE - The collective input of a rotor
+ ROTORENGINEON - If not equal zero the rotor is rotating
+ WINCHRELSPEED - The relative winch speed
+ LACCEL - The acceleration provided by the catapult.
+ {... and many more, see FGFDM.cpp ...}
+ invert: Negate the value of the property before setting on
+ the object.
+ split: Applicable to wing control surfaces. Sets the
+ normal value on the left wing, and a negated value
+ on the right wing.
+ square: Squares the value before setting. Useful for
+ controls like steering that need a wide range, yet
+ lots of sensitivity in the center. Obviously only
+ applicable to values that have a range of [-1:1] or
+ [0:1].
+ src0/src1/dst0/dst1:
+ If present, these defined a linear mapping from the
+ source to the output value. Input values in the
+ range src0-src1 are mapped linearly to dst0-dst1,
+ with clamping for input values that lie outside the
+ range.
+
+control-output:
+ This can be used to pass the value of a YASim control axis
+ (after all mapping and summing is applied) back to the
+ property tree.
+
+ control: Name of the control axis. See above.
+ prop: Property node to receive the value.
+ side: Optional, for split controls. Either "right" or "left"
+ min/max: Clamping applied to output value.
+
+control-speed:
+ Some controls (most notably flaps and hydraulics) have
+ maximum slew rates and cannot respond instantly to pilot
+ input. This can be implemented with a control-speed tag,
+ which defines a "transition time" required to slew through
+ the full input range. Note that this tag is
+ semi-deprecated, complicated control input filtering can be
+ done much more robustly from a Nasal script.
+
+ control: Name of the control axis. See above.
+ transition-time: Time in seconds to slew through input range.
+
+control-setting:
+ This tag is used to define a particular setting for a
+ control axis inside the or tags, where
+ obviously property input is not available. It can be used,
+ for example, to inform the solver that the approach
+ performance values assume full flaps, etc...
+
+ axis: Name of the control input (i.e. a property name)
+ value: Value of the control axis.
+
+hitch: A hitch, can be used for winch-start (in gliders) or aerotow (in
+ gliders and motor aircrafts) or for external cargo with helicopter.
+ You can do aerotow over the net via multiplayer (see j3 and bocian
+ as an example).
+
+ name: the name of the hitch. must be aerotow if you want to do
+ aerotow via multiplayer. You will find many properties
+ at /sim/hitches/name. Most of them are directly tied to
+ the internal variables, you can modify them as you like.
+ You can add a listener to the property "broken", e. g. for
+ playing a sound.
+ x,y,z: The position of the hitch
+ force-is-calculated-by-other: if you want to simulate aerotowing
+ over the internet, set this value to "1" in the motor
+ aircraft. Don't specify or set this to zero in gliders.
+ In a LAN the time lag might be small enough to set it on
+ both aircrafts to "0". It's intended, that this is done
+ automatically in the future.
+
+tow: The tow used for aerotow or winch. This must be a subelement
+ of an enclosing tag.
+ length: upstretched length in m
+ weight-per-meter: in kg/m
+ elastic-constant: lower values give higher elasticity
+ break-force: in N
+ mp-auto-connect-period: the every x seconds a towed multiplayer
+ aircraft is searched. If found, this tow is connected
+ automatically, parameters are copied from the other
+ aircraft. Should be set only in the motor aircraft, not
+ in the glider
+
+winch: The tow used for aerotow or winch. This must be a subelement
+ of an enclosing tag.
+ max-tow-length:
+ min-tow-length:
+ initial-tow-length: all are in m. The initial tow length also
+ defines the length/search radius used for the mp-autoconnect
+ feature
+ max-winch-speed: in m/s
+ power: in kW
+ max-force: in N
+
+
+rotor: A rotor. Used for simulating helicopters. You can have one, two
+ or even more.
+ There is a drawing of a rotor in the Doc-directory
+ (README.yasim.rotor.png) Please find the measures from this drawing
+ for several parameters in square brackets [].
+ If you specify a rotor, you do not need to specify a wing or hstab,
+ the settings for approach and cruise will be ignored then. You have
+ to specify the solver results manually. See below.
+ The rotor generates downwash acting on all stabs, surfaces and
+ fuselages. For all fuselages in the rotor downwash you should
+ specify idrag="0" to get realistic results.
+
+ name: The name of the rotor.
+ (some data is stored at /rotors/name/)
+ The rpm, cone angle, yaw angle and roll angle are stored
+ for the complete rotor. For every blade the position
+ angle, the flap angle and the incidence angle are stored.
+ All angles are in degree, positive values always mean "up".
+ This is not completely tested, but seem to work at least
+ for rotors rotating counterclockwise.
+ A value stall gives the fraction of the rotor in stall
+ (weighted by the fraction the have on lift and drag
+ without stall). Use this for modifying the rotor-sound.
+ x,y,z: The position of the rotor center
+ nx,ny,nz: The normal of the rotor (pointing upwards, will be
+ normalized by the computer)
+ fx,fy,fz: A Vector pointing forward, if not perpendicular to the
+ normal it will be corrected by the computer
+ diameter: The diameter in meter [D]
+ numblades: The number of blades
+ weightperblade: The weight per blade in pounds
+ relbladecenter: The relative center of gravity of the blade. Maybe
+ not 100% correct interpreted; use 0.5 for the start and
+ change in small steps [b/R]
+ chord: The chord of the blade its base, along the X axis
+ (not normal to the leading edge, as it is
+ sometimes defined). [c]
+ twist: The difference between the incidence angle at the
+ blade root and the incidence angle at the wing
+ tip. Typically, this is a negative number so
+ that the rotor tips have a lower angle of attack.
+ taper: The taper fraction, expressed as the tip chord
+ divided by the root chord. A taper of one is a
+ bar blade, and zero would be a blade ending
+ at a point. Defaults to one. [d/c]
+ rel-len-where-incidence-is-measured: If the blade is twisted,
+ you need a point where to measure the incidence angle.
+ Zero means at the base, 1 means at the tip. Typically
+ it should be something near 0.7
+ rel-len-blade-start: Typically the blade is not mounted in the
+ center of the rotor [a/R]
+ rpm: rounds per minute.
+ phi0: initial position of this rotor
+ ccw: determines if the rotor rotates clockwise (="0") or
+ counterclockwise (="1"), (if you look on the top of the
+ normal, so the bo105 has counterclockwise rotor).
+ "true" and "false" are not any longer supported to
+ increase my lifespan. ;-)
+ maxcollective: The maximum of the collective incidence in degree
+ mincollective: The minimum of the collective incidence in degree
+ maxcyclicele: The maximum of the cyclic incidence in degree for
+ the elevator like function
+ mincyclicele: The minimum of the cyclic incidence in degree for
+ the elevator like function
+ maxcyclicail: The maximum of the cyclic incidence in degree for
+ the aileron like function
+ mincyclicail: The minimum of the cyclic incidence in degree for
+ the aileron like function
+ airfoil-incidence-no-lift: non symmetric airfoils produces lift
+ with no incidence. This is is the incidence, where the
+ airfoil is producing no lift. Zero for symmetrical airfoils
+ (default)
+ incidence-stall-zero-speed:
+ incidence-stall-half-sonic-speed: the stall incidence is a function
+ of the speed. I found some measured data, where this is
+ linear over a wide range of speed. Of course the linear
+ region ends at higher speeds than zero, but just
+ extrapolate the linear behavior to zero.
+ lift-factor-stall: In stall airfoils produce less lift. Without
+ stall the c-lift of the profile is assumed to be
+ sin(incidence-"airfoil-incidence-no-lift")*liftcoef;
+ And in stall:
+ sin(2*(incidence-"airfoil-incidence-no-lift"))*liftcoef*...
+ ..."lift-factor-stall";
+ Therefore this factor is not the quotient between lift
+ with and without stall. Use 0.28 if you have no idea.
+ drag-factor-stall: The drag of an airfoil in stall is larger than
+ without stall.
+ Without stall c-drag is assumed to be
+ abs(sin(incidence-"airfoil-incidence-no-lift"))...
+ ..*dragcoef1+dragcoef0);
+ With stall this is multiplied by drag-factor
+ stall-change-over: For incidence<"incidence-stall" there is no stall.
+ For incidence>("incidence-stall"+"stall-change-over") there
+ is stall. In the range between this incidences it is
+ interpolated linear.
+
+ pitch-a:
+ pitch-b: collective incidence angles, If you start flightgear
+ with --log-level=info, flightgear reports lift and needed
+ power for theses incidence angles
+ forceatpitch-a:
+ poweratpitch-b:
+ poweratpitch-0: old tokens, not supported any longer, the result are
+ not exactly the expected lift and power values. Will be
+ removed in one of the next updates.directly.Use "real"
+ coefficients instead (see below) and adjust the lift with
+ rotor-correction-factor.
+
+ The airfoil of the rotor is described as follows:
+ The way is to define the lift and drag coefficients directly.
+ Without stall the c-lift of the profile is assumed to be
+ sin(incidence-"airfoil-incidence-no-lift")*liftcoef;
+ And in stall:
+ sin(2*(incidence-"airfoil-incidence-no-lift"))*liftcoef*...
+ ..."lift-factor-stall";
+ Without stall c-drag is assumed to be
+ abs(sin(incidence-"airfoil-incidence-no-lift"))...
+ ..*dragcoef1+dragcoef0);
+ See above, how the coefficients are defined with stall.
+ The parameters:
+ airfoil-lift-coefficient: liftcoef
+ airfoil-drag-coefficient0: dragcoef0
+ airfoil-drag-coefficient1: dragcoef1
+ To find the right values: see README.yasim.rotor.ods
+ (Open Office file) or README.yasim.rotor.xls (Excel
+ file). With theses files you can generate graphs of the
+ airfoil coefficients and adjust the parameters to match
+ real airfoils. For many airfoils you find data published
+ in the internet. Parameters for the airfoils NACA 23012
+ (main rotor of bo105) and NACA 0012 (tail rotor of bo105?)
+ are included.
+
+ rotor-correction-factor:
+ If you calculate the lift of a heli rotor or even of a
+ propeller, you get a value larger than the real measured
+ one. (Due to vortex effects.) This is considered in the
+ simulation, but with a old theory by Prantl, which is known
+ to give still too large. This is corrected by this token,
+ default: 1
+ flapmin: Minimum flapping angle. (Should normally never reached)
+ flapmax: Maximum flapping angle. (Should normally never reached)
+ flap0: Flapping angle at no rotation, i.e. -5
+ dynamic: this changes the reactions speed of the rotor to an input.
+ normally 1 (Maybe there are rotors with a little faster
+ reaction, than use a value a little greater than one.
+ A value greater than one will result in a more inert,
+ system. Maybe it's useful for simulating the rotor of the
+ Bell UH1
+ rellenflaphinge: The relative length from the center of the rotor
+ to the flapping hinge. Can be taken from pictures of the
+ helicopter (i.e. 0 for Bell206, about 0.05 for most
+ rotors) For rotors without flapping hinge (where the blade
+ are twisted instead, i.e. Bo 105, Lynx) use a mean value,
+ maybe 0.2. This value has a extreme result in the behavior
+ of the rotor [F/r]
+ sharedflaphinge: determines, if the rotor has one central flapping
+ hinge (="1") for the blades (like the Bell206 or the tail
+ rotor of the Bo 105), default is "0".
+ delta3: Some rotors have a delta3 effect, which results in a
+ decreasing of the incidence when the rotor is flapping.
+ A value of 0 (as most helicopters have) means no change in
+ incidence, a value of 1 result in a decreases of one degree
+ per one degree flapping.
+ So delta3 is the proportional factor between flapping and
+ decrease of incidence. I.e. the tail rotor of a Bo105 has
+ a delta3 of 1.
+ In some publications delta3 is described by an angle. The
+ value in YASim is the atan of this angle
+ delta: A factor for the damping constant for the flapping. 1 means
+ a analytical result, which is only a approximation. Has a
+ very strong result in the reaction of the rotor system on
+ control inputs.
+ If you know the flapping angle for a given cyclic input you
+ can adjust this by changing this value. Or if you now the
+ maximum roll rate or ...
+ translift-maxfactor: Helicopters have "translational lift", which
+ is due to turbulence. In forward flying the rotor gets less
+ turbulence air and produces more lift. The factor is the
+ quotient between lift at high airspeeds to the lift at
+ hover (with same pitch).
+ translift-ve: the speed, where the translational lift reaches 1/e of
+ the maximum value. In m/s.
+ ground-effect-constant: Near to the ground the rotor produces more
+ torque than in higher altitudes. The ground effect is
+ calculated as
+ factor = 1+diameter/altitude*"ground-effect-constant"
+ number-of-parts:
+ number-of-segments: The rotor is simulated in "number-of-parts"
+ different directions.
+ In every direction the rotor is simulated at
+ number-of-segments points. If the value is to small, the
+ rotor will react unrealistic. If it is to high, cpu-power
+ will be wasted. I now use a value of 8 for
+ "number-of-parts" and 8 for number-of-segments for the main
+ rotor and 4 for "number-of-parts" and 5 for
+ "number-of-segments" for the tail rotor.
+ "number-of-parts" must be a multiple of 4 (if not, it
+ is corrected)
+ cyclic-factor: The response of a rotor to cyclic input is hard to
+ calculate (its a damped oscillator in resonance, some
+ parameters have very large impact to the cyclic response)
+ With this parameter (default 1) you can adjust the
+ simulator to the real helo.
+ downwashfactor: A factor for the downwash of the rotor, default 1.
+ balance: The balance of the rotor. 1.0: the rotor is 100% balanced,
+ 0.0: half of the blades are missing. Use a value near one
+ (0.98 ... 0.999) to add some vibration.
+ tiltcenterx:
+ tiltcentery:
+ tiltcenterz: The center for the tilting of the complete rotorhead/
+ mast. Can be used for simulating of the Osprey or small
+ autogyros.
+ mintiltyaw:
+ mintiltpitch:
+ mintiltroll:
+ maxtiltyaw:
+ maxtiltpitch:
+ maxtiltroll: The limits (in degree) for tilting the rotor head
+
+ All rotor can have subelements for the cyclic
+ (CYCLICELE, CYCLICAIL) and collective (COLLECTIVE) input.
+ and can have subelements for the tilting the whole rotor
+ head around the y-axis (TILTPITCH), the x-axis (TILTROLL) and the
+ z-axis (TILTYAW). ROTORBALANCE is a factor for the balance.
+
+rotorgear: If you are using one or more rotors you have to define a
+ rotorgear. It connects all the rotors and adds a simple engine.
+ In future it will be possible, to add a YASim-engine.
+ max-power-engine: the maximum power of the engine, in kW.
+ engine-prop-factor: the engine is working as a pd-regulator. This
+ is the width of the regulation-band, or, in other words,
+ the inverse of the proportional-factor of the regulator.
+ If you set it to 0.02, than up to 98% of the rotor-rpm
+ the engine will produce maximum torque. At 100% of
+ the engine will produce no torque. It is planned to use
+ YASim-engines instead of this simple engine.
+ engine-accel-limit: The d-factor of the engine is defined as the
+ maximum acceleration rate of the engine in %/s,
+ default is 5%/s.
+ max-power-rotor-brake: the maximum power of the rotor brake, in kW
+ at normal rpm (most? real rotor brakes would be overheated
+ if used at normal rpm, but this is not simulated now)
+ rotorgear-friction: the power loss due to friction in kW at normal
+ RPM
+ yasimdragfactor:
+ yasimliftfactor: the solver is not working with rotor-aircraft.
+ Therefore you have to specify the results yourself.
+ 10 for drag and 140 for lift seem to be good starting
+ values. Although the solve is not invoked for aircraft
+ with at least one rotor, you need to specify the cruise
+ and the approach settings. The approach speed is needed to
+ calculate the gear springs. Use a speed of approx. 50knots.
+ They do not need to match any real value.
+
+ The rotorgear needs a subelement for the engine
+ (ROTORGEARENGINEON) and can have further subelements:
+ ROTORBRAKE: rotor brake
+ ROTORRELTARGET: the target rpm of the engine relative to
+ the "normal" value for the governor. Default is
+ 1.
+ ROTORENGINEMAXRELTORQUE: the maximum torque of the engine
+ relative to the torque defined by the engine-
+ power. Default is 1. By setting the rel-target
+ to a large number you get control over the
+ engine by this control.
+ Alternatively you can use these two values for
+ individual start-up sequences (see the s58)
+