Continuous replay:
If the user replays a continuous recording from file and then end replay
with the 'My controls' or 'End replay' buttons, we now forget about the
continuous recording. This enables the usual in-memory record/replay to be
used subsequently. Also added a '-continuous' suffix to continuous fgtape
filenames.
New recovery system:
If /sim/replay/recovery-period is set and greater than zero, we
periodically save a single-item continuous recording to a recovery file
called <aircraft-type>-recovery.fgtape (with no date or time in the name),
doing so in such a way as to ensure that there is always a valid recovery
file even if flightgear crashes. One can then resume the flight from the
most recently-saved point by loading this from within flightgear or with
the --load-tape=... option.
Also did a fair amount of refactoring and tried to clarify the different
property nodes that we embed within recordings.
This background recording keeps the user aircraft stationary while recording
all movements of multiplayer aircraft. Allows one to look at replay without,
for example, disturbing continuous record to file.
This allows full-fidelity recordings of arbitrary length (limited only by disc
space) to be created and replayed. These recordings always contain multiplayer
information, regardless of /sim/replay/multiplayer.
When an uncompressed recording is loaded, it is not copied into memory. Instead
we extract individual frame information as required when replaying.
Recording to file is activated by setting /sim/replay/record-continuous to
true. We use the same filename pattern as ordinary fgtapes. The file format
is similar except for being uncompressed (so that replaying can seek within
the recording; gzip etc don't seem to support seeking within the uncompressed
stream.)
Fgtape:
If multipayer replay is active we write multiplayer packet information to
fgtape files. We also add /sim/replay/multiplayer to the properties written
to fgtape file so at load time we knows whether to expect multiplayer
packets.
New builds of fg can load and replay old recordings.
It is expected (but has not been tested) that old builds of fg will be able
to read new fgtape recordings where /sim/replay/multiplayer was unset or
false (currently the default).
Old builds of fg will not be able to load fgtape recordings that include
multiplayer data.
Avoid incorrect removal of multiplayer aircraft when replaying:
We now clear multiplayer motion history when we jump forwards or backwards
during replay. This ensures that multiplayer code doesn't remove
multiplayer aircraft because of inconsistent-looking time stamps.
We preserve some multiplay information when purging recorded information
to save space. This ensures that when replaying we get frequent enough
packets to avoid the multiplayer code thinking that multiplayer aircraft
have disappeared.
At the moment this only works for live replays - we don't (yet) write the
multiplayer information to fgtape files.
Enable with:
--prop:bool:/sim/replay/multiplayer=true
This works by copying all raw multiplayer packets into a buffer in
FGMultiplayMgr. Each time it is called, FGFlightRecorder::capture() moves all
the available packet from this buffer into its FGReplayData. Thus we store
roughly syncronised multiplayer packets along with the user aircraft's detailed
replay properties.
When replaying, FGFlightRecorder pushes packets into a buffer in
FGMultiplayMgr, which are used instead of live multiplayer packets. [Actually
when replaying FGMultiplayMgr still reads live packets in order to handle live
chat messages, and ignores chat messages from FGFlightRecorder.]
Requires corresponding SimGear change. With this last round, we work
with FGData on non-Latin1 path on Windows. (Final fixes are for
Nasal io.readfile, which needed io.stat to work, and SGSky allowing
correct SGPath use)
This is a clean up commit prior to the subsystem API standardisation to simplify
the diffs. It includes all SGSubsystem and SGSubsystemGroup derived classes.
Upcoming flight-planning changes want to use the perf computation code
in route-path, so move it to a public class, and implement some of the
missing functionality, especially correct GS computation for altitude.
This change is the logical counterpart of SimGear's change from commit
79f869a7f32910197be72b21f6489fbbba02c836 that moved the following files
from simgear/misc to simgear/io/iostreams:
gzcontainerfile.cxx
gzcontainerfile.hxx
gzfstream.cxx (formerly zfstream.cxx)
gzfstream.hxx (formerly zfstream.hxx)
sgstream.cxx
sgstream.hxx
sgstream_test.cxx
Requires FGData commit: 0565eaab10a5d466cd485766b17d1870936a0a57
(which actually renames the file).
Also disables the preferences-load command since I don’t believe it
would actually be safe to reload the defaults without doing a simulator
reset (aircraft -set.xml values would be overwritten, for example)
Remove uses of .str(), .c_str() and some other methods of SGPath.
Pass SGPath directly where possible, or explicitly convert to the
appropriate 8-bit encoding.
- consistent with pause (freeze), /sim/speed-up is now applied to the
dt value for all subsystems, not just the FDM and some instruments.
For example AI traffic can now be sped-up or slowed down.
- requires both an FGData and Simgear update.
When using the default (generic) config, which references many props which may not exist in a particular aircraft, suppress the 'recording non-existent' property warning.
Record the historical flight-path (by default, since last takeoff). Optionally display the flight-path in the map; other visualisations (e.g., an 'in-world' view) could also be created. Nasal API to follow so Canvas-map or FMS can show the same data.
Altitude and attitude (Euler angles) are currently recorded but not used anywhere.
FGControls create/init/bind order was incorrect, causing initial property tree state to get over-written. Restructure the code so bind() sees correct values.
