making the build between Simgear and Flightgear consistent.
- Fix an issue with lib/lib64 path between CentOS/RedHat distributions
and Debian derived distributions.
- Fix a compilation issue with HLA in the Flightgear code.
Several checks were off by one, resulting in a segfault when only one
parameter was missing.
Also improve error messages, giving details about what is expected.
- no dependency on libJpeg or Simgear
- no duplicate rendering of the scene (uses a draw callback)
- supports other image types, eg PNG
- threaded so doesn't block the main loop ever
Many light aircraft include GPS loggers capable of recording the flight
path using IGC records. Lots of third party utilities are available to
analyze, process and convert igc files.
Usage: "fgfs --igc=file,out,1,OutputFile.igc"
New module contributed: AV400WSim.
Supports communication with external (aka real) Garmin 400/500 WAAS flight
sim units. Includes changes to options.cxx and fg_io.cxx to support
invoking and configuring the new module.
- this exposed a bizarre issue on Mac where dragging in <AGL/agl.h> in
extensions.hxx was pulling in all of Carbon to the global namespace
- very scary. As a result, I now need to explicitly include CoreFoundation
in fg_init.cxx.
- change SG_USING_STD(x) to using std::x
SimGear change. It changes all the SG_xxxx to be the 'real' includes, and gets
rid of many #ifdef SG_HAVE_STD_INCLUDES. As an added bonus, rather than
replacing 'SG_USING_NAMESPACE(std)' with 'using namespace std', I just fixed
the small number of places to use std:: explicitly. So we're no longer polluting
the global namespace with the entire contents of std, in many cases.
There is one more 'mechanical' change to come - getting rid of SG_USING_STD(X),
but I want to keep that separate from everything else. (There's another
mechnical change, replacing <math.h> with <cmath> and so on *everywhere*, but
one step at a time)
format. I have a Garmin 295 to test with, but so far I haven't been able
to make this work (code should compile cleanly though.) I don't know if
I've made a mistake in the protocol or if my 295 just doesn't support this.
More work on this to come.
The new multiplayer patch with an extension to transmit some properties with
the base package. The properties are transmitted in a way that will not
immediately brake the packet format if we need new ones.
Even if the maxmimum number needs to be limited somehow, that format might
work well until we have an improoved packet format which is even more compact
and that does not require to retransmit redundant information with each
packet.
That part is relatively fresh and based on that what Oliver provides on his
multiplayer server web page.
The properties are transferred to the client and I have modified the seahawks
rudder animation property to use a relative property path to verify that it
works appart from the fact that you can see it changing in the property
browser.
The movement is still a bit jerky, but that can be fixed/tuned later without
again braking the packet format.
explicit calls to shutdown_all() which was causing this to be called twice.
This could cause problems with some IO modules (such as attempting to close
an invalid file descriptor the second time.)
