have multiple ptrs to individual entries (aliases) but the destructor was
trying to delete every ptr so it would delete already freed memory for aliases.
I implimented a simple ref counting scheme (similar to the plib mechanism) to
track references to material lib entries and only "delete" them when the last
reference is removed.
that overrides in JSBSim will work (i.e. properties can be set)
- modified set_(u|v|w)Body to use set_Velocities_Wind_Body, so
that overrides in JSBSim will work (i.e. properties can be set)
can bind a single input to multiple properties)
Made the following properties archivable:
- /controls/aileron
- /controls/elevator
- /controls/elevator-trim
- /controls/rudder
- /controls/flaps
- /controls/throttle[*]
- /controls/mixture[*]
- /controls/propellor-pitch[*]
- /controls/brakes[*]
in init)
- free data structures in destructor
- ensure that interpolation tables are allocated before any searching
is done; otherwise, starting at some locations (such as CYYZ) causes
a segfault
node, and to modify that directly for scaling events: that will make
handling joystick axes much more efficient
- modified FGBinding to work with the new command state, so that
commands can save their state (i.e. compiled arguments) from the last
pass
- removed FGBinding::_fire implementation
- implemented FGBinding copy constructor
pointing to a non-existant material name. (This has been fixed.)
The alias code didn't check to see if this condition would occur so it
was putting a 'NULL' entry in the material library which was causing
the crash. It now checks for and skips bad aliases and prints a
warning message.
- moved shift-F3 (reload panel) bindings to XML
- moved shift-F4 (reload prefs) bindings to XML
- moved shift-F5, shift-F6, shift-F7, and shift-F8 (scroll panel) to
XML
- no longer includes Main/bfi.hxx
- added implementations of GLUTkey, GLUTkeyup, GLUTspecialkey, and
GLUTspecialkeyup
- include Input/input.hxx
- register GLUTkeyup and GLUTspecialkeyup with glut
- comment out call to fgJoystickRead
- comment out call to fgJoystickInit
- add call to FGInput::update to replace fgJoystickRead
this way, keyboard buttons can work the same way as joystick buttons
- added declaration for FGBinding::fire(double); this adds a setting
property to the arguments passed to the command, so that it can use
the current axis position as part of its calculations
- added data structures from joystick.cxx
- go back to using index as key code (otherwise, we'll get nasty
surprises when users try to override bindings)
- XML config file now nests bindings inside modifiers
- allow user to specify whether key is repeatable
- removed hard-coded bindings for 'b', ',', and '.'
- added code from joystick.cxx, with the following major changes:
- changed from js0, axis0, button0 to js[0], axis[0], button[0], etc.
- removed factor, offset, etc. since they will be args to command in
binding
- allow multiple bindings, as with key mappings
- allow access to keyboard modifier keys for bindings
- include infrastructure for modifiers (only FG_MOD_UP is used so far)
- removed unused 'saturation' property
- temporarily removed capture property and trim code; it will have to
be rewritten to be more generic
- allow modifiers for joystick buttons
want binding/property rather than binding/control
- removed hard-coded bindings for F3 (screenshot), Ctrl-S
(autothrottle), v (cycle view) and all of the keypad view-direction
keys; these are now defined in $FG_ROOT/keyboard.xml
- removed unused action method
a crash when relocating to a new airport. Pending work from the old
area is now just completed as normal, rather than trying to empty the various
queues in their various stages when can lead to many problems in a threaded
environment.
with different modifiers (the format of the key bindings has changed
again slightly, adding a <code>..</code> element; see keyboard.xml for
details).
2. Modified FGInput to try default modifiers for ctrl, shift, and alt
when the initial bindings fail (i.e. you don't have to specify
mod-shift explicitly for upper-case 'P' any more).
3. Fixed problems with properties and panel reloading reported by
Martin Dressler and John Check.
4. Updated preferences.xml to get rid of obsolete references to
/controls/brakes/left and /controls/brakes/right (as reported by John
Check).
There were also two non-bugs reported by John Check:
(a) Differential braking doesn't work (John was using the obsolete
properties from #4 above).
(b) Duplicates show up in the property tree using the telnet interface
(the property tree doesn't show indices, and John was seeing separate
entries for each possible engine, etc.).
Fixed a few glitches in the autopilot keys
Added a #define to be able to make a compile time decision to revert to
older GPS like autopiolt behavior this define SHOULD become a property
so that it is run time switchable.
(src/Input). So far, FGInput replaces most of src/Main/keyboard.cxx
(I've left a tiny stub); in the very near future, it will also take
over control of the joystick, mouse (Norm permitting), and panel
instrument interactions, so that there is a single mechanism for
configuring all input devices.
The new format should be (close to) self-explanatory by looking at the
new base-package file keyboard.xml, which is now included by
preferences.xml (I'll do the same thing for the joystick when I have a
chance). I have not managed to move all keybindings into this file
yet, but I've made a good start. I'm including Tony in the recipient
list so that he can see how bindings can use an external XML file.
This patch also adds support for multiple bindings for a single key,
special keys (i.e. keypad and function keys), and key modifiers
(shift/alt/ctrl); special keys use the PUI convention of adding 256 to
the Glut key code.
Unfortunately, everything comes with a price; in this case, I have not
yet found a general mechanism for the old (hard-coded) modal bindings,
which behaved differently depending on the autopilot state (i.e. left
rudder or move AP heading left); with my patches, this functionality
disappears, but you can still adjust the autopilot using the panel or
the GUI input dialogs.
to have attached an ssg loaded object to this branch, then plib will remove
it and all it's states (and textures) which will call opengl api commands
which will crash the program if run from a separate thread from the main render
thread.
- model loading deferred to primary thread
- tile removal deferred to paging thread
- other tweaks and rearrangments.
Airport signs
- first stab at some support for adding taxiway and runway signs. This
is non-optimal, but I'm under the gun for a demo.
a newly loaded tile to the scene graph. Instead it puts it in a queue
for the tile manager. I've used your counter_hack to check the loaded
queue and add any tiles to the scene graph. I was playing around with
the counter_hack so there might be some commented out code, etc. I also
changed some SG_DEBUGs to SG_INFOs so I could track the tile loading.
He writes:
Here are the final changes to add threads to the tile loading. All the
thread related code is in the new FGTileLoader class.
./configure.in
./acconfig.h
Added --with-threads option and corresponding ENABLE_THREADS
definition. The default is no threads.
./src/Scenery/tilemgr
Removed load_queue and associated references. This has been replaced by
a new class FGTileLoader in FGNewCache.
Made the global variable global_tile_cache a member.
schedule_needed(): removed global_tile_cache.exists() tests since
sched_tile() effectively repeats the test.
initialize_queue(): removed code that loads tiles since this is now
performed by FGTileLoader.
update(): ditto
./src/Scenery/newcache
Added new class FGTileLoader to manage tile queuing and loading.
tile_map typedefs are private.
exists() is a const member function.
fill_in(): deleted
load_tile(): added.
./src/Scenery/FGTileLoader
The new threaded tile loader. Maintains a queue of tiles waiting to be
loaded and an array of one or more threads to load the tiles. Currently
only a single thread is created. The queue is guarded by a mutex to
synchronize access. A condition variable signals the thread when the
queue is non-empty.
CLO: I made a few tweaks to address a couple issues, hopefully what we
have is solid, but now we kick it out to the general public to see. :-)
tile has been loaded. Since this flag can be set by another thread I've
declared it "volatile bool".
Also cleaned up delete vs delete[] usage. Gcc is happy with delete[],
which is the correct usage.
The files in the attached tarball make the following changes to
FlightGear:
- rename the existing FGInterface::init() method to
FGInterface::_setup to get it out of the way
- move *all* FDM initialization code out of src/Main/fg_init.cxx and
into FGInterface::init(), and clean up fg_init.cxx a little
(especially by removing the zillions of attempts to place the plane on
the ground at various locations in the code)
- modify FGInterface::bind() so that no values are picked up
automatically at bind time (they are set previously by init() instead)
- modify the init() methods of the classes derived from FGInterface
(i.e. larcsim, jsbsim, balloon, magic, and ada) to invoke
FGInterface::init() explicitly before doing their own setup
I don't claim that the code in FGInterface::init() is optimal (or even
correct), but it seems to work for on-ground starts with both LaRCSim
and JSBSim on runways pointing various directions from near sea level
to about 700' ASL (the range I happened to test). I expect that Jon
and Tony will want to look at the code and refactor and correct it now
that they can see what's going on in one place.
Here's a quick outline of what is invoked:
cur_fdm_state = new <whatever>(dt);
cur_fdm_state->init();
cur_fdm_state->bind();
The constructor allocates memory and sets default values only (with
the help of the FGInterface::_setup() method). The init() method pull
any required properties out of the property tree and sets up the
initial state of the FDM. The bind() method takes ownership of
FDM-related properties so that the FDM can publish them to the rest of
the sim.
Note that bind() and init() are virtual, so any implementation in a
subclass will hide the implementation in FGInterface; that's why
subclass implementations of init() and bind() have to invoke
FGInterface::init() and FGInterface::bind() explicitly, probably at
the start, so that they get the basic initialization.
hope, with earlier versions as well)
- support for the new LONG value type
- gear support for UIUC (updated for the newly renamed SG_* stuff;
otherwise identical to what I sent you before)
- fixed reported MSVC problem in src/FDM/flight.cxx
I have created a set of patches to provide configurable landing gear
for the UIUC models. The patches (including four new files) are
available at
http://megginson.com/private/fgfs/uiuc-20010309.tar.gz
A modified UIUC configuration file for the Twin Otter (DHC-6) is
available at
http://megginson.com/private/fgfs/aircraft.dat
It should be possible to configure appropriate gear for all of the
UIUC models now. As a bonus, the models also support braking, both
absolute and differential, as well as nose-wheel steering (all of
which are currently missing from the UIUC models) -- when you land,
you don't have to keep rolling off the end of the runway anymore, and
you don't have to bank to steer in a taxi.
My sample configuration file contains absolutely bizarre, wild
guesses, and many places that I didn't even bother to guess properly.
The only actual data I had was the wing-span of the DHC-6 (65ft),
which I used for positioning the wing tips. The wing-tips for this
model actually work now -- I hit the aileron hard while accelerating
for take-off, and the wingtip noticeably strikes the ground and
bounces up (quite dramatic in external view using the DHC-6 model from
Wolfram's site).
Details
-------
The UIUC models now support up to 16 gear points each where a gear
point is anything in the aircraft that can come in contact with the
ground, including the tail and wing-tips. I have added the following
new fields to the UIUC configuration files, where <index> is an
integer between 0 and 15, and <value> is a real number:
gear <index> Dx_gear <value> # x offset from CG [ft]
gear <index> Dy_gear <value> # y offset from CG [ft]
gear <index> Dz_gear <value> # z offset from CG [ft]
gear <index> cgear <value> # spring damping [lbs/ft/sec]
gear <index> kgear <value> # springiness [lbs/ft]
gear <index> muGear <value> # rolling coefficient
gear <index> strutLength <value> # gear travel [ft] (not yet used)
Most of these names were already pencilled into the UIUC documentation
(as TODO items), but I had to make up Dx_gear, Dy_gear, and Dz_gear --
if those are inappropriate, I'd appreciate suggestions for better
names.
It will be necessary to modify the other UIUC configuration files to
include some kind of gear support as well, or the planes will sink
nose-first into the ground down to their CG's (it's actually quite
funny to watch with an external view).
Background
----------
As I frequently remind everyone here, I have no math background worth
spitting at, so I will not even pretend to have done the hard stuff.
The UIUC code uses a copy of a very old version of the LaRCsim
c172_gear.c -- I wanted to update it with Tony Peden's excellent newer
version, which includes differential braking among other goodies (the
UIUC models don't support brakes, period).
I copied the newer code into uiuc_aero.c, and it compiled and ran, but
all of the planes ended up sitting on their tails with their noses in
the air. Since Tony made his gear code nicely parameterized, I
experimented with different values, and found that it wasn't too hard
to balance the Twin Otter by moving the gear back a bit. At first, I
used properties to set different values, but then I decided to
integrate the whole thing properly into the UIUC configuration
framework. Thanks to Tony Peden, who did the real modelling work -- I
can take credit only for two or three hours of integration. It turns
out that Tony's code is generalized enough to deal with a wide range
of different gear structures -- I suspect that it will even work for
the 747, when I get around to trying some values.
implicitly correcting for that yet. The plane now makes it to 11000ft on
autopilot *slowly*. I think I'll have to look at the prop parameters
next - altering the diameter and blade angle just slightly can have
quite an effect. If you want to play then try changing the values
prop_diameter and blade_angle in FGNewEngine::init. Keep blade
angle between 20 and 25 (since those are the only values for which
I've entered data and I interpolate between them) and ignore
FGProp1_Blade_Angle since that's an old variable that isn't used. I
really ought to read all the engine and prop parameters from file to
avoid recompilation when tweaking !
the actual air pressure and temperature from the LaRCSim model
instead of assuming that it is at sea level as before. This has
reduced the ceiling from over 60000 ft to about 9000 ft. This is a bit
low (should be around 13 - 14000 ft I think) but I still have some
stuff to do with the engine power correlation and its ignoring the
temperature at the moment so I'm not panicking yet :-)
I've also changed the mixture-power correlation to one from a
published paper since the curve from the IO360 manual seemed to
be a load of rubbish, and didn't have any numbers on the mixture
axis anyway.
I've also knocked the full rich mixture down a touch in line with
Riley Rainey's recommendation, and cleaned up the code a bit.
a) I was compairing feet vs. meter (making the range 3x too. big)
b) I was using the diameter in place of the radius (making the range an
additional 2x too big.)
c) Updated the equation for calculating range to model the weak transmitter
not being picked up at upper altitudes.
We still might need some additional tweaking, but I think we are starting to
get in the right ball park.
is 9 not 8.) Note that the initial altitude setting was placing us way below
the ground, but as it doesn't seem to have caused us problems, it's probably
redundant!
When you tune into a station start at a "random" point in the sequence.
Sped up the words per minute to 13 to which means one sequence per about 4 secs.
This means we get through the whole sequence in about 20 seconds leaving 10
seconds of silence.
joystick input, and then will ignore the actual position of that input
until the user places it in the proper position to match the trimmed position.
At that point the joystick input captures control over the value and the
value will match the joystick position from then on. This is primarily set
up so that the FDM can trim in an initial throttle position.
Added fuel-flow and total fuel to the LaRCSim model. Its still a bit
rough for now but it works, except the engine dosn't stop when fuel runs
out at the moment since there's no refuelling capability in the sim just
now. It takes about 4 gallons use before you see the fuel guages begin
to drop since there's 28 gal per tank but the guages go to 26.
DG heading bug initializes to a random setting.
Activating heading hold doesn't touch the DG heading bug any more.
Max autopilot decent rate is now -1000.
Basically I've rewritten the prop model along similar lines to how
Jon has done his - using published efficiency and coefficient of
power data. It works *much* better - try pulling the throttle back
to idle and putting the plane into a dive before and after updating
and you'll see what I mean. It doesn't require a fudge factor either
:-)
good as we can get" until we find a data source with actual VOR magnetic
offsets. We can use VOR offsets from some fixed date, but not all VOR's
were installed on the same day so no matter what date we pick we will be off on most of them.
restoreInitialState methods to FGGlobals, as well as the two-stage
commit described above for loading saved files. fgInit now takes a
snapshot of the initial state before handing off to the main loop, and
the GUI reInit function restores that state explicitly before calling
fgReInit.
The FlightGear patches also modify fg_props.hxx to add optional
useDefault arguments to all of the fgTie functions -- that lets you
choose whether you want to pick up any default value in the property
tree when you tie the property (the default is true).
FGOptions is history, and the modules are (starting) to use the property
manager directly. Let me know if I left any files out.
Inevitably, there will be some problems with broken options, etc.,
that I haven't found in my tests, but I'll try to fix them quickly.
We also need to stress that the property names currently in use are
not stable -- we need to reorganize them a bit for clarity.
FlightGear subsystems -- it isolates some of the config and #ifdef
stuff in a single place.
2. Added a new FGSubsystem interface, defined in fgfs.hxx; so far,
only FGControls implements it, but if that works, we can start letting
it propagate through the system and simplify the code in main.cxx and
fg_init.cxx (which is terrifyingly complex for anyone new to the
project).
3. Added new src/Main/fgfs_props.[hc]xx files with convenience
functions for tying properties under FlightGear.
4. Experimentally modified src/Controls/controls.cxx to tie properties
directly (rather than tying to BFI functions). I'd appreciate it if
you could get this into CVS as soon as possible, so we can see if the
template stuff causes trouble for any other platforms before I add
properties to the other subsystems.
5. Miscellaneous superficial modifications to other files.
In addition, I've made a couple of further changes:
6. Modified BFI to add support for setting the view axes (i.e. with a
joystick hat).
7. Cleaned up bfi.cxx and removed all cout statements.
====================================
Cockpit.cxx
-----------
Commented #ifdef FIGHTER_HUD.
Hud.cxx
-------
Included code to read the xml file and draw the corresponding instrument.
Hud.hxx, Hud_ladr.cxx, Hud_card.cxx and Hud_labl.cxx
---------------------------------------------------
Integrated code to draw any kind of hud.
Preference.xml
---------------
Included XML file path in the sim/hud property.
ReadMe.xmlhud
-------------
The Readme.xmlhud describes the reconfigurable HUD implemented thru XML
files.
Save/restore seems to be working now, thanks to a couple of
unspeakable kludges:
1. Every time the altitude changes, pause the flight simulator for
five frames and then change it a second time.
2. Every time the latitude or longitude changes, wait five frames,
then invoke fgUpdateSkyAndLightingParams() a second time.
structure. The new approach is simpler, more flexible, and more dynamics.
We can now dynamically size the tile cache up and down. Also, the range
of tiles to load is now dependent on visibility and is calculated to always
bring in enough tiles.
bring EGT down to a more reasonable range. EGT is now returned in
deg Fahrenheit (yuk!!) by the accessor function since that is what
the guage is calibrated in, and the absolute max value that can be
output (max power mixture at max power) is about 750 deg F. Dave, I
suggest that you set the guage to run from 450 - 750 deg F between
the four big marker ticks. What do the offset and scale actually
refer to in the .xml config file BTW?
Fuel flow, better handling of manifold pressure wrt engine speed, and
proper consideration of altitude effects next, hopefully.
- removed Toggle Clouds menu item
src/Main/options.cxx:
- (minor) added some code to sync up options with properties
src/Main/bfi.[ch]xx:
- removed (get|set)Clouds(ASL)?
- removed setSpeedNorth, setSpeedEast, and setSpeedDown -- these are
all read-only now
- added setAirspeed (for calibrated kt)
- extensive rewrite to support Tony's FDM changes
- rearranged everything in bfi.hxx to mess up Curt's ediff examination
- added properties for setting initial panel position
src/Main/save.cxx:
- reinit the tile cache after restore
temperature. The cylinder head is assumed to be at uniform
temperature. Obviously this is incorrect, but it simplifies things a
lot, and we're just looking for the behaviour of CHT to be correct.
Energy transfer to the cylinder head is assumed to be one third of the
energy released by combustion at all conditions. This is a reasonable
estimate, although obviously in real life it varies with different
conditions and possibly with CHT itself. I've split energy transfer
from the cylinder head into 2 terms - free convection - ie convection
to stationary air, and forced convection, ie convection into flowing
air. The basic free convection equation is: dqdt = -hAdT Since we
don't know A and are going to set h quite arbitarily anyway I've
knocked A out and just wrapped it up in h - the only real significance
is that the units of h will be different but that dosn't really matter
to us anyway. In addition, we have the problem that the prop model
I'm currently using dosn't model the backwash from the prop which will
add to the velocity of the cooling air when the prop is turning, so
I've added an extra term to try and cope with this.
In real life, forced convection equations are genarally empirically
derived, and are quite complicated and generally contain such things
as the Reynolds and Nusselt numbers to various powers. The best
course of action would probably to find an empirical correlation from
the literature for a similar situation and try and get it to fit well.
However, for now I am using my own made up very simple correlation
for the energy transfer from the cylinder head:
dqdt = -(h1.dT) -(h2.m_dot.dT) -(h3.rpm.dT)
where dT is the temperature different between the cylinder head and
the surrounding air, m_dot is the mass flow rate of cooling air
through an arbitary volume, rpm is the engine speed in rpm (this is
the backwash term), and h1, h2, h3 are co-efficients which we can play
with to attempt to get the CHT behaviour to match real life.
In order to change the values of CHT that the engine settles down at
at various conditions, have a play with h1, h2 and h3. In order to
change the rate of heating/cooling without affecting equilibrium
values alter the cylinder head mass, which is really quite arbitary.
Bear in mind that altering h1, h2 and h3 will also alter the rate of
heating or cooling as well as equilibrium values, but altering the
cylinder head mass will only alter the rate. It would I suppose be
better to read the values from file to avoid the necessity for
re-compilation every time I change them.
derive specific viewer classes from it. Here's what I currently have in mind:
FGViewer
|
|-> FGViewerPRH (current system with orientation specified in
| LaRCsim Euler angle convention)
|
|-> FGViewerLookAt Feed in a position, view direction, and up vector
|
|-> FGViewerHPR (similar to PRH, but using ssg hpr euler angle
| convention)
|-> others?
LaRCsim c172 on-ground and in-air starts, reset: all work
UIUC Cessna172 on-ground and in-air starts work as expected, reset
results in an aircraft that is upside down but does not crash FG. I
don't know what it was like before, so it may well be no change.
JSBSim c172 and X15 in-air starts work fine, resets now work (and are
trimmed), on-ground starts do not -- the c172 ends up on its back. I
suspect this is no worse than before.
I did not test:
Balloon (the weather code returns nan's for the atmosphere data --this
is in the weather module and apparently is a linux only bug)
ADA (don't know how)
MagicCarpet (needs work yet)
External (don't know how)
known to be broken:
LaRCsim c172 on-ground starts with a negative terrain altitude (this
happens at KPAO when the scenery is not present). The FDM inits to
about 50 feet AGL and the model falls to the ground. It does stay
upright, however, and seems to be fine once it settles out, FWIW.
To do:
--implement set_Model on the bus
--bring Christian's weather data into JSBSim
-- add default method to bus for updating things like the sin and cos of
latitude (for Balloon, MagicCarpet)
-- lots of cleanup
The files:
src/FDM/flight.cxx
src/FDM/flight.hxx
-- all data members now declared protected instead of private.
-- eliminated all but a small set of 'setters', no change to getters.
-- that small set is declared virtual, the default implementation
provided preserves the old behavior
-- all of the vector data members are now initialized.
-- added busdump() method -- FG_LOG's all the bus data when called,
useful for diagnostics.
src/FDM/ADA.cxx
-- bus data members now directly assigned to
src/FDM/Balloon.cxx
-- bus data members now directly assigned to
-- changed V_equiv_kts to V_calibrated_kts
src/FDM/JSBSim.cxx
src/FDM/JSBSim.hxx
-- bus data members now directly assigned to
-- implemented the FGInterface virtual setters with JSBSim specific
logic
-- changed the static FDMExec to a dynamic fdmex (needed so that the
JSBSim object can be deleted when a model change is called for)
-- implemented constructor and destructor, moved some of the logic
formerly in init() to constructor
-- added logic to bring up FGEngInterface objects and set the RPM and
throttle values.
src/FDM/LaRCsim.cxx
src/FDM/LaRCsim.hxx
-- bus data members now directly assigned to
-- implemented the FGInterface virtual setters with LaRCsim specific
logic, uses LaRCsimIC
-- implemented constructor and destructor, moved some of the logic
formerly in init() to constructor
-- moved default inertias to here from fg_init.cxx
-- eliminated the climb rate calculation. The equivalent, climb_rate =
-1*vdown, is now in copy_from_LaRCsim().
src/FDM/LaRCsimIC.cxx
src/FDM/LaRCsimIC.hxx
-- similar to FGInitialCondition, this class has all the logic needed to
turn data like Vc and Mach into the more fundamental quantities LaRCsim
needs to initialize.
-- put it in src/FDM since it is a class
src/FDM/MagicCarpet.cxx
-- bus data members now directly assigned to
src/FDM/Makefile.am
-- adds LaRCsimIC.hxx and cxx
src/FDM/JSBSim/FGAtmosphere.h
src/FDM/JSBSim/FGDefs.h
src/FDM/JSBSim/FGInitialCondition.cpp
src/FDM/JSBSim/FGInitialCondition.h
src/FDM/JSBSim/JSBSim.cpp
-- changes to accomodate the new bus
src/FDM/LaRCsim/atmos_62.h
src/FDM/LaRCsim/ls_geodesy.h
-- surrounded prototypes with #ifdef __cplusplus ... #endif , functions
here are needed in LaRCsimIC
src/FDM/LaRCsim/c172_main.c
src/FDM/LaRCsim/cherokee_aero.c
src/FDM/LaRCsim/ls_aux.c
src/FDM/LaRCsim/ls_constants.h
src/FDM/LaRCsim/ls_geodesy.c
src/FDM/LaRCsim/ls_geodesy.h
src/FDM/LaRCsim/ls_step.c
src/FDM/UIUCModel/uiuc_betaprobe.cpp
-- changed PI to LS_PI, eliminates preprocessor naming conflict with
weather module
src/FDM/LaRCsim/ls_interface.c
src/FDM/LaRCsim/ls_interface.h
-- added function ls_set_model_dt()
src/Main/bfi.cxx
-- eliminated calls that set the NED speeds to body components. They
are no longer needed and confuse the new bus.
src/Main/fg_init.cxx
-- eliminated calls that just brought the bus data up-to-date (e.g.
set_sin_cos_latitude). or set default values. The bus now handles the
defaults and updates itself when the setters are called (for LaRCsim and
JSBSim). A default method for doing this needs to be added to the bus.
-- added fgVelocityInit() to set the speed the user asked for. Both
JSBSim and LaRCsim can now be initialized using any of:
vc,mach, NED components, UVW components.
src/Main/main.cxx
--eliminated call to fgFDMSetGroundElevation, this data is now 'pulled'
onto the bus every update()
src/Main/options.cxx
src/Main/options.hxx
-- added enum to keep track of the speed requested by the user
-- eliminated calls to set NED velocity properties to body speeds, they
are no longer needed.
-- added options for the NED components.
src/Network/garmin.cxx
src/Network/nmea.cxx
--eliminated calls that just brought the bus data up-to-date (e.g.
set_sin_cos_latitude). The bus now updates itself when the setters are
called (for LaRCsim and JSBSim). A default method for doing this needs
to be added to the bus.
-- changed set_V_equiv_kts to set_V_calibrated_kts. set_V_equiv_kts no
longer exists ( get_V_equiv_kts still does, though)
src/WeatherCM/FGLocalWeatherDatabase.cpp
-- commented out the code to put the weather data on the bus, a
different scheme for this is needed.
ing features:
a) ADA Flight model - ADA.cxx, ADA.hxx, flight.hxx
b) Fighter a/c HUD - flight.hxx, hud.hxx, hud.cxx, cockpit.cxx, hud_ladr.c
xx, hud_card.cxx
c) 3-window display - options.hxx, options.cxx, viewer.cxx
d) Moving objects (ship) - main.cxx
e) Patches - main.cxx
ADA.cxx, ADA.hxx
--------------------------
Interface to the external ADA flight dynamics package.
flight.hxx
----------
Included prototypes for accepting additional data fron the External flight
model for fighter aircraft HUD
Hud.hxx
-------
Included prototypes for accepting additional data for fighter HUD from Exernal F
light model.
Defined FIGHTER_HUD pre-processor directive to enable compilation of fighter hud
code.
hud.cxx, cockpit.cxx, hud_ladr.cxx, hud_card.cxx
---------------------------------------
Included code to initialise additional reticles/text for fighter HUD which is co
nditionally
compiled if FIGHTER_HUD is defined.
options.hxx
-----------
Added window_offset, and function to retrieve its value for 3 windows
options.cxx
-----------
Changed few options to suit ADA/CEF projection system/screens and checks for win
dow offset.
views.cxx
---------
Added code to retrieve view offset for window.
Main.cxx
--------
Added code to load and move an aircraft carrier.
Patch to enable clouds from command line until Curtis fixes it. By default cloud
s are disabled.
with jsbsim since no engine is currently created. This will all have to be
revamped in the future, but jsbsim has the structure for doing engines so
that is good.
I have a scrollable panel working (it didn't take long in the end). A
panel can now be much wider or higher than the available area, and the
user can scroll around using [Shift]F5, [Shift]F6, [Shift]F7, and
[Shift]F8. The user can also scroll the panel down to get a bigger
external view. Mouse clicks seem still to be working correctly.
To set the panel's (virtual) height and width, use the panel file's /w
and /h properties in a panel XML file; to set the initial x- and y-
offsets (untested), use the panel file's /x-offset and /y-offset
properties; to set the initial height of the external view (untested
and optional), use the panel file's /view-height property. Note that
none of these show up in the regular FGFS property manager.
Unfortunately, these patches will not affect your initialization
problems with the property manager -- I'm having a hard time tracking
them down because I cannot reproduce them.
I have also made some patches to main.cxx and views.cxx to do two
things:
1. Expand or shrink the external view as the panel moves up and down.
2. Set the window ratio correctly, so that we don't get an oval sun
and flat clouds when the panel is visible (the problem before was
integer division, so I added casts).
Unfortunately, the window ratio is not set properly at start-up --
there are too many dependencies, and I haven't figured that part out
yet. As soon as you hide and redisplay the panel or move it
vertically (i.e. force fgReshape to be called), you'll see the correct
ratio.
- /engines/engine0/rpm changed to read-only
- /engines/engine0/egt added (read-only)
- /controls/mixture added
- /controls/propellor-pitch added (not used for C172)
BFI:
- getEGT() added
- getMixture() and setMixture() added
- getPropAdvance() and setPropAdvance() added (= pitch)
- cleaned up reinit function a bit
- force reinit only when values are actually changed; for example,
setting the flight model to the current flight model will not cause
a reinit
LaRCSim:
- hook up mixture and pitch to FGControls (they were hard-coded
before)
- /engines/engine0/rpm changed to read-only
- /engines/engine0/egt added (read-only)
- /controls/mixture added
- /controls/propellor-pitch added (not used for C172)
BFI:
- getEGT() added
- getMixture() and setMixture() added
- getPropAdvance() and setPropAdvance() added (= pitch)
- cleaned up reinit function a bit
- force reinit only when values are actually changed; for example,
setting the flight model to the current flight model will not cause
a reinit
LaRCSim:
- hook up mixture and pitch to FGControls (they were hard-coded
before)
and prop inertia and passed the timestep from LaRCsim in order to have
the engine rpm behaving according to the applied torque and the laws of
physics.
Added an initial freeze on startup so that we can try to avoid bouncing the
plane on it's back during the very low frame rate / scenery loading startup
conditions.
src/Cockpit/radiostack.cxx
- extended VOR ranges to make them slightly more usable (pending some
real radio code)
src/Cockpit/sp_panel.cxx
- fixed heading bug on gyro compass (sort-of -- the AP still doesn't
work quite as expected)
- skid ball moves the right direction
- moved whiskey compass more to the co-pilot's side, as suggested by
Alex a while back
src/Joystick/joystick.cxx
- included Norm's Windows patches
- renamed brake properties (see bfi.cxx, below)
src/Main/bfi.cxx
src/Main/bfi.hxx
- renamed getBrake and setBrake to getBrakes and setBrakes
- added getCenterBrake and setCenterBrake
- added getAPHeading (without mag correction, needed for the panel)
- renamed property /controls/brake to /controls/brakes/all
- renamed property /controls/left-brake to /controls/brakes/left (as
requested by Alex)
- renamed property /controls/right-brake to /controls/brakes/right (as
requested by Alex)
- added property /controls/brakes/center
- added property /autopilot/settings/heading
- fixed bug in setAltitude so that altitude will be property restored
from a save file
- fixed getBrakes to return the highest of the three brake settings
src/Main/save.cxx
- call FGBFI::getBrakes instead of FGBFI::getBrake
Cleaned a bit of cruft out of gui.[ch]xx
Cleaned up win_ratio() and fov code to make more sense and be a bit more
consistant and robust and less buggy and less susceptible to screw ups.
Panel is activated now by default, HUD is off by default.
from the pre-ssg / render everything ourselves days. Replaced with a
material library manager that is much better suited for working in the
context of ssg. This simplified and cleaned up a ton of old junk.
1. I've modified src/Time/fg_time.cxx so that the --start-date-gmt
option works correctly, at least on my system.
2. I've modified src/Main/bfi.cxx to return the correct time from
FGBFI::getTimeGMT(), so that saving and reloading now keeps the time set
correctly again.
3. I've modified src/Main/main.cxx so that the engine still makes a
noise when it's idling (it sounded very strange when the engine simply
turned off at idle then magically turned on again with a little
throttle).
I've done some substantial reengineering of the 2D panel: except for the
radios, the whole panel is built from a large table now. I'd be
grateful if you could add these changes to the main distribution.
Since I always like to provide some eye-candy with my updates, I've
fixed the ADF gauge to be more usable by slimming the needle and adding
markings every 45 deg (you'll need to use the attached textures).
This set of changes cleans up my previous ones quite a bit:
[tony@valkyrie FlightGear]$ tar -ztf tp_changes.tgz
src/Controls/controls.cxx
src/Controls/controls.hxx
src/FDM/JSBsim.cxx
src/Main/fg_init.cxx
src/Main/options.cxx
src/Main/options.hxx
src/Joystick/joystick.cxx
controls.[ch]xx: removed the trimmed_throttle stuff. This undoes the
changes I submitted last time.
JSBsim.cxx: updates for the removal of the trimmed_throttle stuff
fg_init.cxx: removed the autothrottle logic. The autothrottle is now
off
by default.
options.[ch]xx: Sets trim_mode to false by default. It is enabled only
when --notrim is not used and JSBsim is the FDM.
joystick.cxx: Added logic for syncing the throttle lever. This is
only enabled when trim_mode is enabled. The way I
did it is, I hope, a good way of going about it.
I tested:
fgfs --fdm=larcsim
fgfs --fdm=jsb --aircraft=c172 --vc=100 --altitude=500
fgfs --notrim --fdm=jsb --aircraft=c172 --vc=100 --altitude=500
All work as intended, at least for me.
Make sure your joystick is calibrated and give:
fgfs --fdm=jsb --aircraft=c172 --vc=100 --altitude=500
a try, I think you just might be impressed.
I am. ;-)
Tony submitted:
JSBsim:
Added trimming routine, it is longitudinal & in-air only at this point
Added support for taking wind & weather data from external source
Added support for flaps.
Added independently settable pitch trim
Added alphamin and max to config file, stall modeling and warning to
follow
c172.cfg:
Flaps!
Adjusted Cmo, model should be speed stable now
FG:
Hooked up Christian's weather code, should be using it soon.
Hooked up the trimming routine. Note that the X-15 will not trim.
This is not a model or trimming routine deficiency, just the
nature of the X-15
The trimming routine sets the pitch trim and and throttle at startup.
The throttle is set using Norman's code for the autothrottle so the
autothrottle is on by default. --notrim will turn it off.
Added --vc, --mach, and --notrim switches
(vc is airspeed in knots)
uBody, vBody, and wBody are still supported, last one entered
on the command line counts, i.e. you can set vc or mach or u,v,
and w but any combination will be ignored.
- the panel uses much, much less texture memory, and draws much
faster, at least on my hardware
- there is a wet (magnetic) compass at the top of the panel
- the gyro compass shows true heading again, but don't get used to it:
we're going to set it up to drift soon
- there are TO/FROM flags on NAV1 and NAV2 (but no GS flag yet)
- the ADF looks a little more realistic (if you can forgive the ugly
needle)
- when the HUD is not open, the framerate is moved to the right side
of the screen so that it won't be obscured by the mag compass
