etc.
Improved the weather system to interpolate between different
elevations and deal with boundary-layer conditions. The configuration
properties are now different (see $FG_ROOT/preferences.xml).
Normally for smoothest frame rates you would configure to sync
to your monitor's vertical refresh signal. This is card/platform
dependent ... for instance with Linux/Nvidia there is
an environment variable you can set to enable this feature.
However, if your monitor is refreshing at 60hz and you can't quite sustain
that with flightgear, you can get smoother frame rates by artificially
throttling yourself to 30hz. Note that once you are about about 24fps, it
is *change* or inconsistancy in frame rate that leads to percieved jerkiness.
You want to do whole divisors of your monitor refresh rate, so if your
display is syncing at 75 hz, you might want to try throttling to 25 hz.
Melchior FRANZ:
The reason: these models are to be added to the scenery, but the
scenery isn't yet set up at this point. The correct order is:
- set up model_lib (needed by the scenery)
- set up scenery (needed by the model manager)
- set up model manager
What is actually happening is the camera is pointing to the right place (try zooming in), but the camera is also travelling up and down with the nose and it should be staying more steady (in sync with the CG altitude).
Attached is a fix for this. There is still something a little funky going on with the camera, but this solves the biggest problem. You will note that I deleted an unecessary reference to scenery.hxx in the patch.
I split the FGModelPlacement code out into it's own set of source files.
I created two versions of the fgLoad3DModel() routine. One that is
unecumbered by a panelnode dependency and one that is. acmodel.cxx is
the only place that needs to load an aircraft with instrument panels.
model.[ch]xx are now pretty much free to move over into simgear.
loader.[ch]xx should be able to follow closely behind.
This will be a big step towards being able to move the material management
code over into simgear.
the ascii scenery file format has actually worked in quite some time, and the
ADA runway light code has been supersceded by a slightly different mechanism.
requested parameters to determine if this should be an on-ground vs. in-air
start. The problem was that we never defaulted the value to anything so
if we didn't match an in-air condition, we simply inherited whatever value
was there from before.
scene management code and organizing it within simgear. My strategy is
to identify the code I want to move, and break it's direct flightgear
dependencies. Then it will be free to move over into the simgear package.
- Moved some property specific code into simgear/props/
- Split out the condition code from fgfs/src/Main/fg_props and put it
in it's own source file in simgear/props/
- Created a scene subdirectory for scenery, model, and material property
related code.
- Moved location.[ch]xx into simgear/scene/model/
- The location and condition code had dependencies on flightgear's global
state (all the globals-> stuff, the flightgear property tree, etc.) SimGear
code can't depend on it so that data has to be passed as parameters to the
functions/methods/constructors.
- This need to pass data as function parameters had a dramatic cascading
effect throughout the FlightGear code.
Set a random value for a numeric property
Params:
<property> - the name of the property to randomize
<min> - the minimum allowed value
<max> - the maximum allowed value
The one to fg_init.cxx initialises the AI subsystem regardless of whether it's enabled or not so that later enabling by the user doesn't crash it, and the one to main.cxx avoids running the ATC manager and ATC display system unless enabled.
This is just a port of an old 3D HUD patch to the new view code.
This pans the HUD with the view, by pasting it onto a quad fixed in front of the viewer. It also fixes the awful, arbitrary scaling problems the HUD code has. The old HUD only looks right when viewed at 1024x768 and 55 degree FOV. This works the scale out magically so that it looks right in all views. It also redefines the "<compression-factor>" tag in the ladder to (1) mean compression instead of expansion and (2) have non-psychopathic units (now "1" means 1 degree per degree). Fix this in your existing HUD ladder files before reporting bugs. It's definitely a cosmetic win -- the velocity vector points at the right thing and the horizon lines up properly.
Norman wrote:
I have created a modified version of Andy's patch that implements the 3D HUD as the 'normal' and the 2D HUD as the 'minimal' HUD. < i > and < shift I > keys
I've fixed a bug in FGRunways::search(aptid, tgt_hdg) which wasn't working properly for airports with multiple parallel runways. I've also firmed up and pulled out into it's own function the GetReverseRunwayNo code, and done some input checking.
As a result of fixing the above in runways.cxx, I've pulled out the
parallel implementation in the functions that set position by airport and
heading/runway number in fg_init.cxx and called the runways functions
instead.
earlier, before fgInitSubsystems().
Modify fgInitPos() so that the plane is not automatically aligned with
a runway when an airport is the reference point unless (a) a runway
was explicitly requested, or (b) the plane is on the ground with no
offset distance specified. To set up the plane lined up on an
approach to a runway, use something like
fgfs --airport=CYOW --runway=32 --altitude=300 --offset-distance=0.5
This way, it's possible to specify a starting position relative to an
airport without getting snapped onto a runway approach (unless you
want to be).
04Feb. Actually been running since the beginning of January with these
patches. All changes work without crashing with the current base package cvs,
but there are some visual problems with the views (other than pilot view)
without changes to the base package.
As soon as you can build test and commit I can add in those base package
updates that will make it all work nicely. I will also go through all the 3D
Aircraft configs to make sure the change in the "pitch-offset" for cockpit
views (see below) are made to maintain current behavior.
Here are the files (changes listed below):
http://www.spiderbark.com/fgfs/viewerupdate.diffs.gzhttp://www.spiderbark.com/fgfs/viewerupdate.tar.gz
All logs and log entries are now disabled by default, unless
explicitly enabled by an 'enabled' property. This works much more
intuitively with the GUI dialog.
if the station is too far away. Instead, simply return the closest station.
All the code that searches navaids does it's own range checking anyway.
This will make the navlist query functions a bit more useful for other
types of functionality where you may need to lookup a station without
consideration of range (i.e. presetting your position relative to a navaid.)
(I thought I'd slip this in along with David's change to the default menu
configure option. I believe that will cause a new config.h to be generated
which will cause a near complete rebuild of FG (as will this globals.hxx
change) so it shouldn't cause additional grief to have these happen at the
same time.)
input bindings. They will work only with the latest CVS; otherwise,
./configure will disable them. There is a new command, 'script',
which takes a single argument, also called 'script', containing PSL
code (currently PSL requires a main() function).
Erik Hofman has written some more elaborate code for triggering PSL
code from drop-down menus and scheduling events; I will look at
integrating that next.
and property-multiply:
Firstly, change back to wrapping modulo the interval, with "min <= x <
max" semantics. I believe the previous implementation did that. The
inline function that Norman mentioned also does that.
Secondly, make it snap to the nearest value (min + N*resolution) when a
"resolution" tag is present, taking special care of floating-point
precision. Or perhaps specify "number of divisions in the interval" as
an integer, instead of "resolution" by which I meant a floating-point
"size of a division".
[also fixed]
While working on this file I noticed some potentially serious warnings:
fg_commands.cxx: In function `bool do_property_adjust(const
SGPropertyNode*)':
fg_commands.cxx:435: warning: control reaches end of non-void function
fg_commands.cxx: In function `bool do_property_multiply(const
SGPropertyNode*)':
fg_commands.cxx:465: warning: control reaches end of non-void function
/usr/local/include/simgear/misc/props.hxx: At top level:
fg_commands.cxx:600: warning: `bool do_presets_commit(const
SGPropertyNode*)' defined but not used
Some more cmall changes to the SimGear header files and removed the
SG_HAVE_NATIVE_SGI_COMPILERS dependancies from FlightGear.
I've added a seperate JSBSim patch for the JSBSim source tree.
experimental lighting rendering (which is very expensive on my
machine, for example). To use distance attenuation,
/sim/rendering/distance-attenuation must also be true.
It adds a command line options to enable/disbale distance attenuation
using a property rather than using a #define inside the code. It also
adds a small change for systems that don't support the OpenGL extension,
so that the lights *do* fade away as they get furher away but they don't
get smaller in size.
property-adjust.
Modified property-adjust and property-multiply so that they always
work with double values, to simplify the code.
Factored out some common code.
Added a 'mask' argument to the property-adjust and property-multiply
commands. If mask is set to "all" (the default), then the command
works as before; if mask is set to "integer", it works only to the
left of the decimal point; and if mask is set to "decimal", it works
only to the right of the decimal place. This functionality is useful
for tuning VHF COM and NAV radios.
- dialog-open
- dialog-close
- dialog-update
- dialog-apply
The last two can copy a value from a property to a GUI field or
vice-versa either individually or across the whole dialog.
I have updated the lighting code to use fog to try to fade the runway lights
in smoothly, but still keep them from being visible until you are about 7-10
miles out, and then only have them be very faint at first. I think what I
have is a bit nicer than before since it completely avoids the "popping" effect,
but I've very open to tweaking the actual ranges based on people's real
world experiences.
option to specify a starting airport + specific runway. If you don't specify
a runway, you get the one that's closest to your specified (or default)
heading.
The general idea is to help clean up some aspects of the FDM init and be
able to provide startup conditions in a less ambiguous manner.
Previously, things like positions, orientations, and velocites were set on
"the bus". These had to be read by the FDMs which then were supposed to
initialized themselves to those values and turn write around and start
modifying those values. It was messy and cumbersome.
Now, all the initial fdm conditions are written to a sub-[property-]tree
under /sim/presets/
The values in /sim/presets/ always stay set to what the user has specified.
The user can change these at his/her liesure, and then request a "reset"
which will reset to the new conditions. I don't even want to say how this
worked before. :-)
Now, an script, or gui interface can stage a set of initial conditions while
the sim is running (without disrupting it), and then call "reset" to commit
the change.
People who should worry about all this are FDM writters, and a small few
others who care about over all program structure and flow.
The biggest and coolest patch adds mouse sensitivity to the 3D
cockpits, so we can finally work the radios. This ended up requiring
significant modifications outside of the 3D cockpit code. Stuff folks
will want to look at:
+ The list of all "3D" cockpits is stored statically in the
panelnode.cxx file. This is clumsy, and won't migrate well to a
multiple-aircraft feature. Really, there should be a per-model list
of 3D panels, but I couldn't find a clean place to put this. The
only handle you get back after parsing a model is a generic ssg
node, to which I obviously can't add panel-specific methods.
+ The aircraft model is parsed *very* early in the initialization
order. Earlier, in fact, than the static list of allowable command
bindings is built in fgInitCommands(). This is bad, as it means
that mouse bindings on the instruments can't work yet. I moved the
call to fgInitCommands, but someone should look carefully to see
that I picked the right place. There's a lot of initialization
code, and I got a little lost in there... :)
+ I added yet another "update" hook to the fgRenderFrame routine to
hook the updates for the 3D panels. This is only required for
"mouse press delay", and it's a fairly clumsy mechanism based on
frame rate instead of real time. There appears to be delay handling
already in place in the Input stuff, and there's a discussion going
on about different mouse behavior right now. Maybe this is a good
time to unify these two (now three) approaches?
Now the options can be localized as well. This adds a slight problem for
the --language options, but not that much (worst case, the strings are
loaded twice consuming some more memory). I tried to be as accurate as
posiible when copying the options texts, but there might be some
mostakes left.
This adds supports for a language specific font, defined in locale.xml
I've also moved the fgInitLocale() routine from main.cxx to fg_init.cxx
to prevent an ungly extern definition in options.cxx.
are now working. A runway light is defined by a point and a direction. The
point and direction are combined with the local up vector to create a small
triangle orthogonal to the direction. The two ficticous corners of the
triangle are given an alpha value of zero, the orignal corner is given an
alpha of one. The triangle is drawn in glPolygonMode(GL_FRONT, GL_POINT)
mode which means only the corner points are drawn, and since two have alpha=0
only the original point is drawn. This is a long way to go to draw a point,
but it ensures that the point is only visible within 90 degrees of the light
direction, behind the light it is not visible. This is still a long way
to get to drawing a point, but we use an environement map, with the direction
vector as the normal to mimic a light that is brightest when viewed head
on and dimmest when viewed perpendicularly or disappears when viewed from
behind.
- warning, there is a bug in how the current runway light direction vector
is calculated which will adversely effect runway lighting. The airports
should be regenerated in order to fix this problem.
The FGGlobals constructor does not initialise the locale pointer.
Under MSVC, uninitialized pointer have a value of 0xcdcdcdcd, not
0, so a test in mainLoop fails and the program segfault.
This patch set un initial value to locale.
This patch fixes some bugs for correctly reporting un-updated
configuration files, and adds support for a --language=<code>
commandline option, overriding the language specified by the OS.
jump whenever you cross a tile, but there are currently a lot of other
positioning problems as well, so this doesn't really detract too much and
means you can play with 3d clouds from just about any starting point.
I removed some pending random code and I also fixed a
small cosmetic glitch where dt_play was cleared before it was printed.
Curt: Erik changed the sound update intervale and I further I tweaked it.
The issue is that if we put too much into the sound buffer, then we can't react
quick enough to sounds like tire squeek that need to be synced with the visuals
and the action. We put too little into the sound buffer and we risk the
audio dropping out for moment if a frame takes longer to draw than the amount
of audio in the buffer.
I've modified the code to display a brief help message instead of the
whole bunch of options. To get the complete message -v or --verbose has
to be added to the command line.
Here is a FGIO class derived from FGSubsystem that replaces the fgIOInit()
and fgIOProcess() functions. The FGIO::update(double delta) doesn't use the
delta argument yet. I suspect it could be used as a replacement for the
calculated interval value but I'm not familiar enough with that piece of code
just yet.
I've also added two "command properties" to fg_commands.cxx that select the
next or previous view. Writing any value to these properties triggers the
corresponding action. As an example I modified my keyboard.xml:
<key n="118">
<name>v</name>
<desc>Next view</desc>
<binding>
<command>property-assign</command>
<property>/command/view/next</property>
<value type="bool">true</value>
</binding>
</key>
<key n="86">
<name>V</name>
<desc>Prev view</desc>
<binding>
<command>property-assign</command>
<property>/command/view/prev</property>
<value type="bool">true</value>
</binding>
</key>
And of course these actions can also be triggered from external scripts via
the props server.
- Removed some old cruft.
- Removed some support for older versions of automake which technically was
correct, but caused the newer automakes to squawk warnings during an
initial sanity check (which isn't done very intelligently.)
NOTE: this fix is technically not correct for older version of automake.
These older version use the variable "INCLUDES" internally and could have
them already set to an important value. That is why we were appending
our values to them. However, newer versions of automake don't set this
value themselves so it is an error to append to a non-existant variable.
We seem to "get away" with overwriting the value on older versions of
automake, but if you have problems, consider upgrading to at least
automake-1.5.
Animations are now contained within the scene graph itself and are
updated whenever the graph is traversed -- that saves time by not
updating animations not currently in sight, and it allows animations
to be used for static objects and random objects as well.
Added new FGModelLoader and FGTextureLoader classes. These are intern
tables for models, to guarantee (mostly) that no model is loaded more
than once. FGTextureLoader is not yet used anywhere, but
FGModelLoader is now in place everywhere that ssgLoad* used to be
used (thus adding the ability to use animations).
In the future, FGModelLoader will add some interesting functionality,
including the ability to reload 3D models on the fly.
I've merged FGProps and FGTelnet so there is just a single property server.
I've left in the --telnet=port# command line option but it could be removed
if we wanted to. The command line accepts two forms of the --props option.
The original (--props=medium,dir,hz,host,port#,style) and the shorter
--props=port#. If you accept this change then src/Network/telnet.[ch]xx
can be removed from the cvs repository.
the triangles containing the objects were out of the view Frustum,
they were never traversed by ssg (and thus, never culled). Now, every
200 frames, do a pass through the whole scene graph with cull-testing
disabled and without drawing anything; that will allow random-objects
to be collected incrementally.
The present sets of bindings result in the throttle being "squared"
about its centre, which is silly. This is because the "squared"
parameter is not set by the throttle binding, but the default is
"true". We discussed this before and I think there was general
agreement that the default should be "false" on the basis of
generality.
Make locally-used strings local instead of global. (The safety and
cleanliness benefit outweights the slight performance hit. If
performance is an issue, the way these strings are used should be
optimised.) Use existing defined constant instead of a literal
number.
This is the small code fix which is needed for the new options.xml file.
It is needed because otherwise the "--prop:name=value" is showed
incorrectly.
There is another problem though, when compiling with --without-logging
the help message isn't displayed at all! We *must* change that somehow.
Curt: good point, the SG_LOG()'s have been switched to cout's ...
I've updated the FIXME in the code, and fixed a typo (descr instead of
description), but the SG_LOG() functions doesn't produce any output for
me. Could you confirm it's still working for you?
Curt Olson:
I did a bit of further tweaking and it all looks good now. The tricky thing
is that SG_LOG() always appends an endl at the end of every message.
This is an enhanced version of the options patch.
It's more robust now, and gives some helpful information if something
goes wrong. Also the naming in the options.xml file has changed to the
syntax David suggested.
Since no one objected to the patch I think it is safe to included it.
contain colon-separated ranges. For examples, winds from 180 degrees
10 knots gusting 15 knots would be
--wind=180@10:15
Winds variable from 180-220 degrees 5 knots would be
--wind=180:220@5
FGEnvironment does not yet support variable-direction winds, so
nothing will yet happen in the second case.
Fetch all pending remote fdm network packets so there is not chance of
getting behind.
Add support for driving control panel lights.
Working on better modeling KX 155 tuning behavior.
This is a small fix for what turned out to be a major bug. Ground elevation
was calculated incorrectly when distant from one of the view locations. This
resulted in several problems including bizarre gear trimming, mid air
"crashes" (as in thinking we hit the ground) and so on when close to or on the
ground.
Unfortunately it does require a second ssg traversal when in tower view
(only), but the increased load isn't all that noticable. For the time being
this really is the best solution. In a future update I will be eliminating
the unecessary per frame traversals for the static views (without having to
maintain multiple ssgRoots).
When we go to multiple FDM instances we will perhaps need to put the ssg
traversal and ground elevation queries for the FDMs into an event timer that
updates the FDMs ground elevation in a round robin fashion (maybe every 1/n
seconds where n is the number of FDM instances running).
This is a new improved patch for the previous tile manager fixes.
Rather than building dependencies between FGlocation or the viewer or fdm with
tilemgr what I ended up doing was linking the pieces together in the Mainloop
in main.cxx. You'll see what I mean...it's been commented fairly well. More
than likely we should move that chunk somewhere...just not sure where yet.
The changes seem clean now. As I get more ideas there could be some further
improvement in organizing the update in tilemgr. You'll note that I left an
override in there for the tilemgr::update() function to preserve earlier
functionality if someone needs it (e.g. usage independent of an fdm or
viewer), not to mention there are a few places in flightgear that call it
directly that have not been changed to the new interface (and may not need to be).
The code has been optimized to avoid duplicate traversals and seems to run
generally quite well. Note that there can be a short delay reloading tiles
that have been dropped from static views. We could call the tile scheduler on
a view switch, but it's not a big deal and at the moment I'd like to get this
in so people can try it and comment on it as it is.
Everything has been resycned with CVS tonight and I've included the
description submitted earlier (below).
Best,
Jim
Changes synced with CVS approx 20:30EDT 2002-05-09 (after this evenings updates).
Files:
http://www.spiderbark.com/fgfs/viewer-update-20020516.tar.gz
or
http://www.spiderbark.com/fgfs/viewer-update-20020516.diffs.gz
Description:
In a nutshell, these patches begin to take what was one value for ground
elevation and calculate ground elevation values seperately for the FDM and the
viewer (eye position). Several outstanding view related bugs have been fixed.
With the introduction of the new viewer code a lot of that Flight Gear code
broke related to use of a global variable called "scenery.cur_elev".
Therefore the ground_elevation and other associated items (like the current
tile bucket) is maintained per FDM instance and per View. Each of these has a
"point" or location that can be identified. See changes to FGLocation class
and main.cxx.
Most of the problems related to the new viewer in terms of sky, ground and
runway lights, and tower views are fixed.
There are four minor problems remaining. 1) The sun/moon spins when you pan
the "lookat" tower view only (view #3). 2) Under stress (esp. magic carpet
full speed with max visibility), there is a memory leak in the tile caching
that was not introduced with these changes. 3) I have not tested these
changes or made corrections to the ADA or External FDM interfaces. 4) The
change view function doesn't call the time/light update (not a problem unless
a tower is very far away).
Details:
FDM/flight.cxx, flight.hxx - FGInterface ties to FGAircraftModel so that it's
location data can be accessed for runway (ground elevation under aircraft)
elevation.
FDM/larsim.cxx, larcsim.hxx - gets runway elevation from FGInterface now.
Commented out function that is causing a namespace conflict, hasn't been
called with recent code anyway.
FDM/JSBSim/JSBSim.cxx, YASim/YASim.cxx - gets runway elevation from
FGInterface now.
Scenery/newcache.cxx, newcache.hxx - changed caching scheme to time based
(oldest tiles discard).
Scenery/tileentry.cxx, tileentry.hxx - added place to record time, changed
rendering to reference viewer altitude in order to fix a problem with ground
and runway lights.
Scenery/tilemgr.cxx, tilemgr.hxx - Modified update() to accept values for
multiple locations. Refresh function added in order to periodically make
the tiles current for a non-moving view (like a tower).
Main/fg_init.cxx - register event for making tiles current in a non-moving
view (like a tower).
Main/location.hxx - added support for current ground elevation data.
Main/main.cxx - added second tilemgr call for fdm, fixed places where viewer
position data was required for correct sky rendering.
Main/options.cxx - fixed segfault reported by Curtis when using --view-offset
command line parameter.
Main/viewer.cxx, viewer.hxx - removed fudging of view position. Fixed numerous
bugs that were causing eye and target values to get mixed up.
Here is the new super improved telnet property interface. CVS changelog
is at the end of this message. Once this new telnet code is in and
compiles every where we can remove Network/props.[ch]xx. I've added a
--telnet=<port> command line option to invoke the new server. Later on
we could remove the --props option, or least change it to invoke the new
server. I'll let you decide.
I've added some new commands to the telnet interface:
view next Select the next view.
view prev Select the previous view.
view set <n> Select view 'n'
view get Return index of current view
I'm not sure if these same effects could be achieved through property
operations. The commands provide a convenient shortcut in any case.
I'm also planning on adding a panel command to manipulate panels and
objects contained therein (eg simulated mouse clicks). There is going
to be some commonality with the command objects so we may need to
rationalize this in the near future.
Finally, I've also included my python stuff. This is still very much a
work in progress, basically I've been using it to test the new telnet
server. I have tested it with python 2.2. Feel free to add it to the
repository if you want. I would suggest a scripts/python directory
CVS Changelog
Network/telnet.cxx: New property telnet protocol interface. It supports
the same user interface provided by the --props server. Additionally it
handles multiple simultaneous connections. Added "view" command to
manipulate viewmgr.
Network/protocol.hxx: Added protocol configuration exception.
Main/fg_io.cxx: Added new "telnet" protocol. Added protocol
configuration parse exceptions. Simplified protocol configuration
parsing.
Main/options.cxx: Added --telnet=<port> command line option and help
message.
Removed configuration option --with-new-environment and
FG_NEW_ENVIRONMENT macro.
Added configuration option --with-weathercm and FG_WEATHERCM macro.
FGEnvironment is now the default; use --with-weathercm to get the old
weather.
object rather than a pointer.
FGEnvironment now has the beginning of an atmospheric model, and will
recalculate temperature (not pressure or density, yet) based on
elevation.
FGEnvironment has a copy constructor.
- changed FGSubsystem::update(int) to
FGSubsystem::update(delta_time_sec); the argument is now delta time
in seconds rather than milliseconds
- added FGSubsystem::suspend(), FGSubsystem::suspend(bool),
FGSubsystem::resume(), and FGSubsystem::is_suspended(), all with
default implementations; is_suspended takes account of the master
freeze as well as the subsystem's individual suspended state
- the FDMs now use the delta time argument the same as the rest of
FlightGear; formerly, main.cxx made a special case and passed a
multiloop argument
- FDMs now calculate multiloop internally instead of relying on
main.cxx
There are probably some problems -- I've done basic testing with the
major FDMs and subsystems, but we'll probably need a few weeks to
sniff out bugs.
The FlightGear patch is to take account the change in the getChildren
function that now returns a vector<SGPropertyNode_ptr>. If the
removeChild functionnality is to be added in FlightGear, all those
SGPropertyNode * floating around should be changed to
SGPropertyNode_ptr.
1. If /position/longitude-deg and /position/latitude-deg are in range,
use them.
2. Otherwise, if /sim/startup/airport-id is not empty, use it.
3. Otherwise, set the lon/lat to the middle of the KSFO field.
The default used to be Globe, AZ, but that doesn't make sense since we
don't distribute that scenery by default any more.
With this change, starting from a save file seems to work properly:
fgfs myflight.sav
I have finished working the bugs out of my "Enhanced" version of the Magic
Carpet FDM. The UFO FDM works the same as the Magic Carpet with the
following exceptions:
The aircraft's pitch is determined by the Elevator setting (with a pitch
rate of 45 degrees per second).
Climb is forward velocity * sin(pitch)
Speed is forward velocity * soc(pitch)
Roll is tied to the aileron (again, with a roll rate of 45 degrees per
second)
Turn rate is sin(roll) * 45 degrees.
Yes, this does mean that turning is quite a bit more sluggish than
climbing.
If you are wondering why a UFO FDM, it is because it's best that I not
replace the existing magic carpet and this FDM does behave like a UFO (it
hovers, can spin and pitch while hovering, and does not obey the laws of
physics ;)
