1
0
Fork 0
Commit graph

11 commits

Author SHA1 Message Date
curt
a37515d7fe Add support for passing a CG offset (in inches) to an external FDM. 2003-11-13 03:10:09 +00:00
curt
23c1057a19 Add support for sending out a requested aircraft weight to an external FDM
via the "pipe" interface.
2003-11-10 21:56:32 +00:00
curt
562ce6f5e2 Ooops, I added another item to what I write to the buffer, but
forgot to make it big enough to hold the new item.  This was manifesting
itself as a crash on reset (if the ExternalPipe FDM was being used.)
2003-08-01 17:06:11 +00:00
curt
419f09f804 Curt:
I have added a fledgling replay system that records flight data and control
positions during the flight.

I have added an internal command called "replay" which will trigger a replay
of the entire saved flight data set.  This could be bound to a keyboard or
menu command, in fact this entire module is screaming for someone to build
a gui to control playback speed, amount of playback, etc.

This is the initial version so there are kinks that still need to be worked
out, please be patient.
2003-07-17 18:24:17 +00:00
ehofman
e3bcb4b619 MingW 0.92 fixes 2003-06-08 12:01:43 +00:00
curt
2c20e61b4b Removed some extraneous debugging output. 2003-03-09 12:48:29 +00:00
david
4b78f5305f Ignore generated files. 2003-03-09 03:21:34 +00:00
curt
92cfd383d6 Remove std:: 2003-03-04 00:25:35 +00:00
curt
11e0a3b1f8 Don't remove the named pipe on a "Reset" or position change (i.e. when
FGExternalPipe is destructed.)  This leaves the name pipe hanging around
even after flightgear exits, but assuming we put the files in /tmp that
shouldn't be a big deal.
2003-03-03 17:48:09 +00:00
curt
dbf7218c63 A small optimization, pass the number of iterations to the remote end and
have it do all the work, rather than calling the remote end "iteration"
number of times.
2003-03-03 04:59:41 +00:00
curt
cc269730a5 First stab at a "named pipe" interface to an external FDM. Compared to the
ExternalNet interface:

- allows a much more closely coupled execution.  A remote network FDM will run
  at it's own rate, and maybe a particular data packets will come, maybe it
  won't.  This makes it very hard to control timing and keep the animation
  smooth.  There are also cpu scheduling issues with running multiple
  processes on a single machine.  The linux scheduler by default runs at
  100hz.  If an FDM process uses a sleep/alarm system to avoid wasting
  CPU, it will be forced to run at 100hz, 50hz, 25hz, 20hz, etc.  This
  makes it *impossible* to serve a display system running at 60hz without
  dropping frames.

- the downside is that the FDM process must now run on the same machine as
  the master flightgear process.
2003-03-03 04:30:16 +00:00