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)
/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.
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.
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.
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.
- 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
