That sort of feature has been available on innumerable flight sims in the past, including the old Lucas Arts sims you're trying to re-capture in a sense.
Perhaps one of the things to do would be to talk to someone who may be able to give detailed technical insight into how this works, like someone in BMS Falcon or someone who worked on FreeFalcon? I recall the FreeFalcon 6 code was rather callously dumped upon the web, to many contributor's dismay. You could try and browse through the code and find something on the ACMI code, which is the palyback feature available for the Falcon 4 family of sims:
https://github.com/FreeFalcon/freefalcon-central...Just as a brainstorming exercise, we already know that FS records mission messages and things of that sort during the given mission. I also assume it would be easy to record when a SEXP is executed (which is probably how mission records are recorded, anyway)... The main challenge must be recording position data.
If someone does choose to try and develop a recorder where others have failed, perhaps the first part is getting FS to generate a data-dump on command without bogging down the system (which seems to have been the aim of the second link you posted). If you can toggle a mission recorder on and off (like in X-Wing), it will begin generating a temporary file which the user can choose to save or not to save at the conclusion of the mission... or, it could be toggled on and off, so some parts of the mission could be recorded with others left out. The file, if saved, is dumped to a directory where it can be used at a later date.
...Initial development of the recording software may be better suited if the program is kept separate from FSO, until it is ready to be merged. If you can dump data on command from a mission, and then view it later on in a separate program, that may be a good way to go regardless. A separate program may be a good option for basically creating a whole playback system with recording options; basically, an FSO movie maker!
Hopefully I'm not speaking out of my backside at this point, but one possible benefit of keeping things "semi-separate" from FSO for at least a period of time may include improving the lifespan of the recorder. If something changes in the codebase that breaks the recorder, that's a problem. A solution may therefore be to use the engine for playback, but also to ensure that exported data from a mission is not so tightly wired into the engine that it becomes unusable in the future. This involves identifying critical data from a mission, which can be rapidly read and written by software; ideally, this also keeps file sizes small.
In that regard, I'd propose this:
(a.) "global" events are written directly to file, possibly by means of their respective triggers. If the latter is done, the limiting factor may be the .vp from which the mission was called. The problem here is thus portability of files, as someone else's software may differ from the next's. You'd likely not be able to play a mission recording from another user without having some version of the mod being played. (as a "safety" feature, the playback file should indicate the mod/version, and version of FSO from which it was generated)
(b.) General ship information is written in a vector format. FSO may have a ship limit, but that should not have an impact on the recorder. The recorder just records, after all... This information will point to the global events with respect to each ship. The number of ships will be a vector (dynamic) quantity, but the additional dimensions of the vector should be similar to a simple array. This information is used to pre-load data into playback functions.
(c.) Individual ship flight logs should be the final necessary data entry to an output file. These logs are individual vectors, and each point to their respective ship. "Deltas," or changes to the factors by which a ship behaves in FSO are logged. Position data can also be logged. By storing this sort of event data, mission playback software can re-create exactly what happened during a mission with regards to each ship.
(OUTPUT PROCESS) Mission output is passively passed to a temporary file of either specified or dynamic size when the recorder is engaged. Specifying limits to an output cashe may help remove the issue of memory problems... of a sort I don't know about yet. Or, you may end up with an amount of data which is too large for the specified size, resulting in either an error or a method of trimming the mission record so that the amount of data recorded before the max size can be reviewd before the force termination. Alternately, an algorithm could be used based on the mission file and a user input, etc., etc. Dynamic sizing would probably slow the simulation down to a degree if it was employed...
After the completion of the mission, and if the mission output is saved, the data is compiled into the three catagories listed above (a., b., c.).The data can then be read by FSO or software using FSO's engine.
(INPUT PROCESS) The mission playback software reads the compiled information and assembles a virtual mission. Ships may be "spawned" at coordinates, and coordinates, to whatever degree are recorded during the mission, may be periodically checked by the software; however, the principal means of re-creating the mission will be user-input deltas or physics deltas. In short, what should happen is that a virtual, fixed playthrough of a mission is occurring. Information is fed to some variant of the FSO engine to whom all the information is pre-processed. If that actually can be made to run well, it means you can go to any ship from any view to any point of the battle, pause, rewind, and slo-mo things as much as you want without changing any of the outcomes of the mission.
Any thoughts on the above algorith, or questions you think I could answer?