Actually, I think I'm off the hook here; the problem is pre-existing.
What's happening is that the x/y offsets enter the modelview matrix at
line 346 in the current panel.cxx. But note that the same
transformation also occurs before each instrument rendered at line
403. What's happening is that the instruments are double-translated
relative to the background.
Unless I'm not understanding something, the one inside the instrument
render loop looks unnecessary. Removing it fixes the issue and
doesn't cause any bugs that I can find. It also fixes a bug where you
could scroll the instruments on top of the 3D panel, where the offsets
are supposed to be ignored. :)
Attached is a new panel.cxx which fixes that bug, and substantially
simplifies the virtual panel code (the matrix inversion that I thought
was needed wasn't, but there were some offsetting scale bugs that hid
the problem).
These changes add to the "Add Waypoint" dialog so that you can see the entire
list in the pui dialog that you are adding to. Also made some minor changes
so that the autopilot is now activated (toward first waypoint target heading)
when a waypoint is added.
command will save *all* properties, rather than just those marked as
archivable. This feature was requested by Tony Peden to make it
easier to write documentation on the properties, but it should also be
useful for debugging. There is currently no default binding for the
command with the write-all parameter set to true.
What the attached patch does is map your panel definition onto a (non
z-buffered) quad in front of your face. You can twist the view around
and see it move in the appropriate ways.
Apply the patch (let me know if folks need help with that step), and
then set the /sim/virtual-cockpit property to true. You can do this
on the command line with --prop:/sim/virtual-cockpit=1, or via the
property picker. Bind it to a key for fast toggling if you like.
The default bindings don't allow for "panning" the view, so you'll
have to modify yours. These are the mappings to my joystick's hat
switch, for those who need hints:
<axis n="6">
<desc>View Direction</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
<axis n="7">
<desc>View Elevation</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
While the current implementation is happy with just plastering the
panel's notion of "screen" into the 3D world, this is actually more
general. Each panel can, in principle, have it's own coordinate
system, and you could build a cockpit out of a bunch of them. The
mapping is specified by providing a 3D coordinate for three corners of
the quad the panel should be mapped to; this should be pretty simple
to work with.
All that's needed for a perfectly general solution is a convention on
where to store the information (a cockpit xml file, or put it in the
aircraft -set file, or...), and some work on the panel's coordinate
system conventions (some of which don't coexist very nicely with a
generalized 3D environment). Combine that with a plib model for the
non-panel interior of the cockpit, and we're golden.
I'm actually really pleased with this. It worked better and more
quickly than I could have imagined, and impact on the surrounding code
is quite light -- a few property tests only. But some stuff is still
missing:
+ No equivalent work was done to the HUD, so it still displays
incorrect headings when the view changes. The use of pixel
coordinates deep in the HUD code is going to give me fits doing the
port, I sure. It's not nearly so well put together as the panel
(where I just changed the setup code -- none of the rendering code
changed at all).
+ I forgot that the panel was clickable. :) Input events still have
the screen coordinates, which essentially kills the interactivity
when in virtual cockpit mode. This won't be hard to fix; it's only
broken because I forgot the feature existed.
And one note about the implementation choice: to get away from the
inevitable near clip plane issue, the virtual cockpit renderer simply
disables the z buffer. This means that cockpits built using these
panels need to be z-sorted, which isn't too hard since they are static
geometry. It also means that no two "virtual panels" can ever be
allowed to interpenetrate. No biggie.
actually very powerful when combined with factor and offset -- for
example, on the C310 model the nose wheel can now retract completely
before the doors start closing.
subsystem to Flightgear. No more functionality is implemented
than at present (apart from an ATIS bug-fix - station wouldn't
change if the radio was switched directly from one station to
another) but it is much neater than the current hack and should be
easily extendable.
Some cruft is still probably left over in radiostack.[ch]xx such as
the bindings to the comm frequencies but I'll leave removing those
until I'm sure they're not needed there.
newauto.cxx. Basically everything is the same functionally except for a
changed in the initial altitude setting to 3000ft instead of meters (the panel
is in feet).
and scaling of control values to properties. Also added a time interpolation
feature that replaces the hacked-in "retract-time" feature for the gear in
a more general way (applicable to flaps, too!). Incompatibly breaks
the XML syntax; get new files!
individual aircraft to have different sounds (and cleaning up my code
a fair bit). The most important user-visible change is the renaming
of the /sim/sound property to /sim/sound/audible.
(other than "none") is "spin", which must be tied to a property giving
a value in RPM. This gets the DC-3 propellers turning. The next type
will be "rotation", which will allow the flaps, elevators, ailerons,
and rudders to move (and even gear, eventually). Later, I'll add
"shift" for sliding things around, and will figure something out for
blinking lights.
the XML file, including the path to the 3D file.
This change obsoletes the existing /sim/model/*-offset-deg and
/sim/model/*-offset-m properties in the main property tree, and
replaces them with /offsets/*-deg and /offsets/*-m in the model
property file. The /path property in the model XML file is relative
to the XML file's location rather than FG_ROOT.
Added two new properties:
/environment/temperature-sea-level-degc
/environment/pressure-sea-level-inhg
These are now supported in FGEnvironment as well, though they always
have the same value for now. They need to be hooked up to the FDMs.
different locations, and hitched it into FGGlobals. FGEnvironmentMgr
has taken over as the subsystem, while FGEnvironment is simple the
information that it returns. I've removed current_environment
completely -- everything now uses properties or goes through
FGGlobals. FGGlobals itself has a couple of useful methods:
const FGEnvironment * get_environment ();
const FGEnvironment * get_environment (double lat, double lon, double alt);
The first one returns the environment data for the plane's current
position, while the second returns the environment data for any
arbitrary location. Currently, they both return the same information,
but that will change soon.
properties have been renamed from wind-(north|east|down)-fps to
wind-from-(north|east|down)-fps, and the FDMs modified appropriately.
No other changes should be visible unless FG_OLD_WEATHER is defined.
Attached are patches for adding the command line options to set initial
glideslope and climb rate. This was really easy to do as all the pieces
were in place. It works well with JSBSim because the trimming routine
finds the right throttle and elevator settings. It should work with
LaRCsim as well, but it has no trimming routine so there will be some
dynamics at startup. I don't know what YASim will do.
the panel controls for the autopilot. The heading dialog would only show the
last setting you did through it, even if it was later tweaked with the bug on
the hsi. The altitude dialog did a similar thing. Now the values default to
the same that show on the panel displays.
via the command line (--enable-clock-freeze / --disable-clock-freeze)
and can be toggled during a run. However this property is not currently
bound to any menu or keystroke so you have to do it via the gui property
interface or externally via the web property browser or a script.
are being driven from an external data source.)
Akso found and fixed a bug in the simgear that caused the time to go goofy
temporarily while scenery was being loaded.
as well as visibility.
This means that if you are using this protocal to exchange data with a
visual channel, you should be able to change time and visibility on the master
and all the slaved visual channels will match it.
Attached is a fix to add a short period of cranking time required
before the engine fires. I've also added a little hack to limit the
torque applied by the starter motor when the rpm is less than 10 in
order to avoid the rpm overshooting idle in the first time step when
the prop is producing very little resistance due to the low rpm.
- remove buffer with class scope
- remove variable 'length' (isn't used anywhere)
- make process_command private (it isn't used anywhere outside, and it
shouldn't be)
- define buffers where they are needed (two places)
- comment out stale debug message (it doesn't buy anything, because the
contents are output two lines below, anyway)
- let every error message begin with "ERR ". This makes error messages
less beautiful, but easier to recognize for scripts. Every internet
protocol that outputs text, has such a tag for distinguishing regular
output from error messages. (pop3 uses "-ERR ", smtp uses error codes,
etc.)
- fix html bug (<form> was closed by another <form>, instead of </form>)
- remove useless <br>
- fix a bug, that would have truncated an argument containing a '&'
- extend the comment for urlEncode: cite the concerned RFC
max(width, height) by default (easily changeable) rather than just width.
(src/GUI/gui.cxx, src/Main/main.cxx, src/Main/viewer.cxx, src/Main/viewer.hxx)
This works on a CygWin build, and probably works on non-Cygwin builds
as well.
2. Enable FG to start even if audio is not available. (soundmgr.cxx)
Avoids the FGSoundMgr constructor crashing; the rest of FG then runs
OK without sound.
1. Enable auto-configure on more versions of auto tools. (configure.in)
2. Warnings from auto-configure tools. (src/Time/Makefile.am)
3. Typo: "the it's" -> "its". (docs-mini/README.Joystick)
4. Remove definition of FGViewer::update() that now is (or can be) pure
virtual\
. (src/Main/viewer.cxx)
5. Preferred form of function name according to comments in plib:
"not_working"\
-> "notWorking". (src/Sound/soundmgr.hxx)
format before reading/writing data from/to remote machine. This allows
different endian machines to talk to each other. Also added support for
passing time and time offset (warp) in the data packet.
I've attached 3 diffs against files in FlightGear to fix some printf
format strings. The changes are pretty straight forward. Let me know
if you have any questions. (BTW, I'm using gcc 2.95.4)
/sim/freeze/master (implimented)
/sim/freeze/fuel (implimented)
/sim/freeze/position (not implimented)
/sim/freeze/time-of-day (not implimented)
/sim/freeze/master is bound to the 'p' key via keyboard.xml, however,
/sim/freeze/fuel is not bound to anything at the moment so you must
change it via the external property interface, or specify an initial
value on the command line.
properties /sim/view/view-tilt-deg and /sim/view/goal-view-tilt-deg
control the tilt. There are (temporarily) keyboard bindings in the
base package for experimentation: Ctrl-O to tilt the view down, and
Ctrl-P to tilt the view up.
otherwise, the logic in FGEngine::ConsumeFuel breaks down and the
engine is starved when *any* feed tank is empty, rather than when all
feed tanks are empty.
FDM people. FlightGear now supports an unlimited number of fuel
tanks. Also added correct fuel-flow reporting for piston engines, and
tracked new features in SimGear property support.
other -- it is now possible to set properties at startup (such as an
autopilot altitude). The only user-visible change, other than the
fact that the properties work as they are supposed to, is that the
heading bug no longer starts at a random value.
function to allow property files as non-option parameters after the
options have finished (and added "--" to terminate options). It's now
possible to do something like
fgfs denver-am.fgd
or even
fgfs at-lax.fgd in-c310.fgd around-sunset.fgd
This works the same way as the --config option, but will be friendlier
for GUIs, where start-up situation files can now be associated easily
with FlightGear.
Changed _set_Accels_Pilot_Body to use FGAuxiliary::GetNpilot instead
of FGAuxiliary::GetPilotAccel. It looks like a similar change was
started but never finished, and there are artifacts still lingering.
With this change, the slip/skid ball now works reasonably on the C172
when in motion, but not at rest (that will have to wait for fixes to
the gear code).
material-specific logic is now removed from the material library and
encapsulated in the material class itself, and materials are loaded
from $FG_ROOT/materials.xml rather than $FG_ROOT/materials. This also
removes a nasty bug in the old material-loading code that caused a
floating-point exception.
- automake-1.4 sets default values for INCLUDES which we can't
overwrite.
- automake-1.5 renames this to DEFAULT_INCLUDES and leaves INCLUDES
open for the developer to use.
Thus for automake-1.4 we are forced to 'append' to INCLUDES and in
automake-1.5 we can just set the value to whatever we like.
Unfortunately, the behaviors of the two versions are mutually
incompatible.
The solution I am committing now works for both versions but
automake-1.5 generates a lot of spurious warning messages that are
annoying, but not fatal.
(i.e. multiloop). Most subsystems currently ignore the parameter, but
eventually, it will allow all subsystems to update by time rather than
by framerate.
beginning of main() for the exceptions that can be enabled (only
divide-by-zero is enabled by default, but you can uncomment any ones
you want); eventually, FlightGear should run cleanly with all FPEs
enabled.
(i.e. multiloop). Most subsystems currently ignore the parameter, but
eventually, it will allow all subsystems to update by time rather than
by framerate.
has absolutely no bearing on actual wheel performance and has nothing to do
with the fdm. It is just a simplistic wheel spin velocity model used to
avoid subsequent squealing when a tire is bouncing, or touches down right after lifting off. If at some point tire spin is modeled by an FDM we could
transition to using real data.
FGInterface::_updateGeocentricPosition() for clarity. Also added an
FGInterface::_updateGeodeticPosition() since it is useful.
A few clean ups to native_fdm.cxx and raw_fdm.hxx.
These will log trace messages whenever a specific property value is
read or written through the property manager. They do not cause
FlightGear to poll bound values, so if a class variable that is bound
is changed directly, no trace message will be displayed.
These options are also useful in conjunction with a debugger.
--trace-read will cause the private SimGear SGPropertyNode::trace_read
method to be invoked, and --trace-write will cause the private SimGear
SGPropertyNode::trace_write method to be invoked; in a debugger
session, a user can set breakpoints on these methods then get a
backtrace to see what specific points in the code are reading or
writing properties.
works like this:
1. Parse preferences.xml, which will usually specify a default
aircraft using the /sim/aircraft property.
2. If /sim/aircraft is specified and not empty, parse the properties
in $FG_ROOT/Aircraft/{/sim/aircraft}-set.xml to set up a default
aircraft.
3. During command-line parsing, whenever the --aircraft option appears
set /sim/aircraft appropriately and parse the properties in
$FG_ROOT/Aircraft/{/sim/aircraft}-set.xml. Any --config, --prop, or
--aircraft options afterwards will take precedence.
more intuitive. We switch to an include in the preferences.xml to include
the default model, and then if the user specifies --aircraft=, that is
expanded immediately so portions can be overwritten by subsequent command
line options.
Here's an unusual patch for FlightGear -- I've created .cvsignore
files for every source directory, to make CVS output more informative.
This is especially nice when using cvs-examine from (X)Emacs to look
for changes.
a top level aircraft def file (c172-set.xml)
preferences.xml or --aircraft= or any other property setting mechanism can
be used to set the property "/sim/aircraft". After all options and config
files are parsed, the contents of /sim/aircraft is expanded into a *-set.xml
file and loaded.
Note there is still a problem when doing a 'reset' after doing
a 'goto'. Curt says: I also see that doing two subsequent reset's on a
JSBSim model results in a segfault in a deconstructor deep inside JSBSim.
- changed all sound file properties to end in /path for pathname, and
added /sound and /pitch (with current values as defaults)
- don't activate the stall horn if CAS is less than 30kt (this needs
to be refined somehow)
- declarations to support changes to cxx file
Dynamics (Sim)ulator. Basically, this is a rough, first cut of a "different
take" on FDM design. It's intended to be very simple to use,
producing reasonable results for aircraft of all sorts and sizes,
while maintaining simulation plausibility even in odd flight
conditions like spins and aerobatics. It's at the point now where one
can actually fly the planes around.
- delete table in destructor
** src/FDM/flight.cxx
- bind engine properties in FGInterface::bind, and publish properties
for all engines rather than just engine 0
** src/Main/fg_props.cxx
- removed all engine properties; now bound in FGInterface::bind
** src/Sounds/fg_fx.cxx
- support multiple engine and cranking sounds
** src/Sounds/fg_fx.hxx
- support multiple engine and cranking sounds
to control logging
- /sim/logging/classes takes a value like "terrain|astro", where the
names are the macros from simgear/debug/debug_types.h with the
initial "SG_" removed and converted to lower case; for none, use
"none"
- /sim/logging/priority takes a single name like "warn", where the
name is a macro from simgear/debug/debug_types.h with the initial
"SG_" removed and converted to lower case
(the global temperature property returns that at the aircrafts altitude) and
adding "information" to the airport name to avoid having to store it
in the default.atis file 1200 odd times.
Heres an update to the ATIS stuff. In brief:
The possible buffer overflow in the display with wind should
hopefully be fixed.
Temperature is taken from the global temperature property instead
of being hardwired.
The display class now includes an implementation of the member
function to change the repeating message.
The message callsign is no longer hardwired. The first message
from each station is generated with a random callsign.
Subsequent messages from the same station have the callsign
incremented every hour. A map of airport-id vs. last callsign and
transmission time is kept for each station that has transmitted for
the duration of the FlightGear session. The logic might be flaky if
FlightGear is run for more than 24 hours at a stretch between
visiting the same ATIS station though! (ie I don't check the day.)
This map is kept in the atislist class. This might not be the best
long-term place for it (in an ATC class of some sort might be
better), but it works for now.
What was happening was that we screwed up and scheduled tiles for
(lon,lon) rather than (lon,lat) ... note the typo. This generated
bogus tile id's which the system happily accepted, put into the tile
cache system, and attempted to load. The problem was that these bogus
tile id's were negative where as all valid tile id's should be >= 0.
These negative tile id's up the logic used to remove tiles from the
cache. When identifying tiles for removal, we look for the furthest
tile away from us by starting out the furthest id at -1 and if we find
something further, we update the furthest tile id. Then at the end we
check if the furthest tile id >= 0 to see if we found anything we
could remove. However, the furthest tile id was these bogus tiles
with negative tile id's so the system always assumed there was nothing
appropriate for removal. This made it impossible to ever remove a
tile from the cache meaning it quickly filled up and no more tiles
could be loaded.
I fixed the one instance of scheduling tiles for a bogus location, and
added a sanity check so if it ever happens again we'll bomb with an
appropriate error message.
ends of the same runway share the same frequency. This is probably the best
we can do until we impliment some sort of operator interface to manually set
which end is active (like is done in real life.)
fix startup sequence problems where we initialize the FDM before we know
the desired starting altitude.
These changes delay fdm initialization until the local tile has been loaded
and we can do a real intersection and find the true ground elevation.
In order to do this, I depend more on the property manager as glue, rather
than the FGInterface.
There are some glitches still when switching to a new airport or reseting
the sim. I will work on addressing these, but I need to commit the changes
so far to keep in sync with other developers.
meaning of "win_ratio". I've removed win_ratio and added fov_ratio and
aspect_ratio, as it seems both are needed.
n.b. The multi-line changes in fgReshape comprise:
extracting common code,
removing an apparently arbitrary "+1" on the view height,
changing "set_win_ratio" to "set_aspect_ratio".
through the controls interface and the running and cranking flags through
the engine interface. This has no current effect on LaRCsim (other than
to make the code neater) but is necessary to add engine startup to JSBSim
which is now underway. I've also put in main.cxx which escaped getting
committed in the previous round of changes - adding this will add
the cranking sound to LaRCsim during engine startup.
one I sent yesterday. I have re-zipped all four files so you can
neglect the last lot but only io360.cxx has changed if you've
already committed. It's untested since I can't start the engine until
John has committed his update with separate properties. Should
work fine though.
- use guiErrorMessage
- added new properties /sim/view/pilot/x-offset-m,
/sim/view/pilot/y-offset-m, and /sim/view/pilot/z-offset-m to
control pilot-position offset from CG
but no entries qualify for removal. It will keep trying to schedule the
tile(s) until an entry frees up. Entries in the cache do not qualify for
removal if they are in the process of being loaded.
I've updated the WeatherDatabase to be able to use only the n closest
stations. This can speed up the initalization dramatically.
To take a benefit from that you need:
- http://129.13.102.67/out/flight/current.txt.gz in
FG_ROOT/weather/current.txt.gz
- --prop:/environment/weather/working-type=internet
- --prop:/environment/weather/max-stations=what_ever_you_want
The WeatherCM stuff now publishes its data in the property system.
/environment/weather/wind-north-mps
/environment/weather/wind-east-mps
/environment/weather/wind-up-mps
/environment/weather/temperature-K
/environment/weather/air-pressure-Pa
/environment/weather/vapor-pressure-Pa
/environment/weather/air-density
are the new properties.
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.
