Author Topic: Flight Recorder  (Read 5043 times)

0 Members and 1 Guest are viewing this topic.

I was all ready to go grab some video clips of gameplay to make a trailer for Fate of the Galaxy when I realized to my horror that there's no mission recorder in FSO.  So in order to get good shots of various camera angles, internal and external, I'll either have to just fly with strange angles or hack something together using FRED, which I'm not at all skilled at yet.

There's been two attempts at throwing something together here:
Replay demo system
Replay recorder script

I'd love to be able to just "save" and entire mission, then go into some sort of film room where I can play back through the mission from various viewpoints and camera angles.  I'm sure this would be a valuable tool for many other projects as well.  Thoughts?

 

Offline Thaeris

  • Can take his lumps
  • 211
  • Away in Limbo
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?
"trolls are clearly social rejects and therefore should be isolated from society, or perhaps impaled."

-Nuke



"Look on the bright side, how many release dates have been given for Doomsday, and it still isn't out yet.

It's the Duke Nukem Forever of prophecies..."


"Jesus saves.

Everyone else takes normal damage.
"

-Flipside

"pirating software is a lesser evil than stealing but its still evil. but since i pride myself for being evil, almost anything is fair game."


"i never understood why women get the creeps so ****ing easily. i mean most serial killers act perfectly normal, until they kill you."


-Nuke

 

Offline ngld

  • Administrator
  • 29
  • Knossos dev
This might be a crazy idea (especially regarding the state of FSO's netcode) but couldn't someone use FSO's network protocol as a starting point?

In multiplayer games all the necessary information to view the mission is broadcasted anyway. If you'd simply record that, you should be able to play it back...
This would only work for multiplayer missions but would reduce the amount of work necessary to make the recorder work.
Essentially you have to write two parts:
  • The recorder. It joins a multiplayer game and instantly vanishes (it has not playable ship). Then it records everything the server transmits and saves it to a file.
  • The playback program. It simulates a standalone server. Once the mission starts the player ship is set to no-collide and hidden. Afterwards the recorded data is played back. Now the player can fly through the recorded mission!

The most complicated part would be simulating the server. Since I never actually looked at FSO's netcode I have no idea if this is feasible but it sounds like this would guarantee the most independence from FSO's engine code.

 

Offline chief1983

  • Still lacks a custom title
  • Moderator
  • 212
  • ⬇️⬆️⬅️⬅️🅰➡️⬇️
    • Minecraft
    • Skype
    • Steam
    • Twitter
    • Fate of the Galaxy
If anything along those lines is done, you might want to consider Karajorma's proposal for modifying multiplayer into always using a 'standalone' server for multi, even when not connecting to a separate standalone.  Essentially, for multi, the standalone would be fired up as a thread or something on the hosting computer on demand, and would replace the current non-standalone multiplayer hosting code.  This way we'd eliminate the code for doing the same thing that is basically in two different places, each with their own independent quirks.

I mention this, because if a standalone could always be fired up for multiplayer, and the standalone thread is always fed this data, then perhaps that model could even be used in single player for capture-only purposes.  Just a thought.
Fate of the Galaxy - Now Hiring!  Apply within | Diaspora | SCP Home | Collada Importer for PCS2
Karajorma's 'How to report bugs' | Mantis
#freespace | #scp-swc | #diaspora | #SCP | #hard-light on EsperNet

"You may not sell or otherwise commercially exploit the source or things you created based on the source." -- Excerpt from FSO license, for reference

Nuclear1:  Jesus Christ zack you're a little too hamyurger for HLP right now...
iamzack:  i dont have hamynerge i just want ptatoc hips D:
redsniper:  Platonic hips?!
iamzack:  lays

 

Offline Mongoose

  • Rikki-Tikki-Tavi
  • Global Moderator
  • 212
  • This brain for rent.
    • Minecraft
    • Steam
    • Something
Not sure if it'd help at all (and it probably wouldn't), but I know the original FS development owed something to the Descent 1/2 engine, and those had demo playback capabilities from the very beginning.  They're open-source too, so a peek at that might be useful.  I don't believe they supported multiple camera angles though.

 
I was all ready to go grab some video clips of gameplay to make a trailer for Fate of the Galaxy when I realized to my horror that there's no mission recorder in FSO.  So in order to get good shots of various camera angles, internal and external, I'll either have to just fly with strange angles or hack something together using FRED, which I'm not at all skilled at yet.

There's been two attempts at throwing something together here:
Replay demo system
Replay recorder script

I'd love to be able to just "save" and entire mission, then go into some sort of film room where I can play back through the mission from various viewpoints and camera angles.  I'm sure this would be a valuable tool for many other projects as well.  Thoughts?

Just wanted to mention that Orbiter 2010, a space simulator similar to Kerbal, does have that functionality and produces very small sized recording files.

If I get the time to, I could look into it.

 

Offline Goober5000

  • HLP Loremaster
  • Moderator
  • 214
    • Goober5000 Productions
There was an attempt to make a flight recorder / demo system in the original public FS2 code release.  It didn't completely work and was eventually removed from the code.  Here's what DaveB had to say about it:
Quote
from the Guided Tour document

There was a demo recording/playback system I half-heartedly was playing with at one point. Its still in there, in very incomplete form.

 

Offline z64555

  • 210
  • Self-proclaimed controls expert
    • Minecraft
    • Steam
Recording a singleplayer mission wouldn't be all that difficult, just save the states of everything major (particularly the player and probably objective ships). Using the multiplayer code would be a good start.

There would be a bit of difficulty with playback, however, as in order to get that to function you essentially have the AI take over the player craft and have it go through the various frames and try its best to closely match what was recorded.

Although, if you've ever played something like X-Wing vs. TIE that had the playback, you'd know that each play of the recording isn't exactly the same. To overcome that, you'd have to make the AI semi-procedural in it's decision making, perhaps based on current mission time and the seed value of the mission that it was originally recorded (which might also be time).
Secure the Source, Contain the Code, Protect the Project
chief1983

------------
funtapaz: Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Juche.
z64555: s/J/Do
BotenAlfred: <funtapaz> Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Douche.

 

Offline jr2

  • The Mail Man
  • 212
  • It's prounounced jayartoo 0x6A7232
    • Steam
Until this is all set up, FRAPS or any similar alternative works as a temporary measure.

 
Until this is all set up, FRAPS or any similar alternative works as a temporary measure.

Yep, the main issue with that is the difficulty of capturing any sort of viewpoints other than your primary 1st person cockpit (or 3rd person) while actually playing the game, dogfighting, etc.  Hard to grab other cinematic shots while you're in the middle of it, which is why playback would be nice.

 

Offline jr2

  • The Mail Man
  • 212
  • It's prounounced jayartoo 0x6A7232
    • Steam
How would demo playback help? Unless it can also allow you to switch viewpoints?

 
in flight recorders in other games, it does allow you to switch viewpoints.  That's the whole point - it's not recording what's happening on the screen, it's recording the simulation for playback in different viewpoints.

 

Offline chief1983

  • Still lacks a custom title
  • Moderator
  • 212
  • ⬇️⬆️⬅️⬅️🅰➡️⬇️
    • Minecraft
    • Skype
    • Steam
    • Twitter
    • Fate of the Galaxy
Yeah, jr2, maybe 'flight recorder' isn't the right term here really.  'Replay' might be better, but none really give the impression that you're definitely talking about recording all action within the scope of the mission, and not just framecaps of one vantage point.  'Tracks' is a term I've heard before I think.  That's one reason suggesting the net code makes sense.  The net code already has to gather data about what is going on in a mission on the host, and then send all that data to the clients.  Since all the data about the events is already in one format, possibly using that code to stream to a replayable file format that could be loaded later might be worth consideration.  This is all pretty theoretical though, and there was mention that some work on a recorder was already done, so that might be a good starting point as well.
Fate of the Galaxy - Now Hiring!  Apply within | Diaspora | SCP Home | Collada Importer for PCS2
Karajorma's 'How to report bugs' | Mantis
#freespace | #scp-swc | #diaspora | #SCP | #hard-light on EsperNet

"You may not sell or otherwise commercially exploit the source or things you created based on the source." -- Excerpt from FSO license, for reference

Nuclear1:  Jesus Christ zack you're a little too hamyurger for HLP right now...
iamzack:  i dont have hamynerge i just want ptatoc hips D:
redsniper:  Platonic hips?!
iamzack:  lays

 

Offline Cyborg17

  • 29
  • Life? Don't talk to me about life....
Could this be done with scripting?

This is a possibly overly-complicated way of handling it:

Have a script which records the initial positions, orientations, flags, healths, the speeds of the ships (forward and maneuvering speeds), and every instance of a weapon firing, along with the amount of damage that shot fires.  Theoretically, then it could generate another mission file that has the same major events, all ships in "play dead", and sexps which generate the weapons fire that was recorded during the mission. 

The data would be stored in arrays whose indexes would be time, number of ships, and the categories you want recorded.  (With maybe some physics approximations to save on memory?)

ShipDataArray(xnumberofships, ycategories, ztime)

This might be too memory-intensive or CPU intensive, but just thought I'd put it out there.

 

Offline chief1983

  • Still lacks a custom title
  • Moderator
  • 212
  • ⬇️⬆️⬅️⬅️🅰➡️⬇️
    • Minecraft
    • Skype
    • Steam
    • Twitter
    • Fate of the Galaxy
I have a feeling that at least one or both of the links in the OP dealt with a scripting-based solution, but my fear is that it would be less than accurate enough.  Or resource intensive.  If hooks could be made to the right events though, approximations could possibly be avoided, but I still think the scripting overhead would be substantial.  Don't mind being proven wrong though.
Fate of the Galaxy - Now Hiring!  Apply within | Diaspora | SCP Home | Collada Importer for PCS2
Karajorma's 'How to report bugs' | Mantis
#freespace | #scp-swc | #diaspora | #SCP | #hard-light on EsperNet

"You may not sell or otherwise commercially exploit the source or things you created based on the source." -- Excerpt from FSO license, for reference

Nuclear1:  Jesus Christ zack you're a little too hamyurger for HLP right now...
iamzack:  i dont have hamynerge i just want ptatoc hips D:
redsniper:  Platonic hips?!
iamzack:  lays

 

Offline Cyborg17

  • 29
  • Life? Don't talk to me about life....
There is definitely a trade off there.  Maybe if it would record ships variables only once every half or quarter second and then space out the recording over frames, you might reduce the overhead in the recording evenly.  What else could reduce CPU overhead..... Turning off sound and music, perhaps?  Since you don't need it, but that would probably be almost nothing.  ......  What if the player didn't mind playing at a slower speed?  Like at .75 or .8 time compression.  That could help them compensate for possible choppiness.

Also, during replay, you could turn off collision detection to reduce CPU overhead since you already know if something is being hit.

Just thought of another problem: asteroids.  Asteroids have the potential to mess this up a lot, since they're randomly generated.  Are there any hooks for asteroids?  I don't think it's possible to manipulate them through sexp.

Anyway, I'm taking a look at the second link now.

 
Necro!
Usually replay systems work by saving the initial state - usually that's the mission data and the state of the RNG - and external events, basically player input and the time when that input happened. Far less overhead than trying to save the general state every few seconds, I don't think there are more than ~200 bytes of player input per second. With the non-deterministic elements recorded and input again in just the same time, the outcome of the mission will be deterministic. In programming terms, take the code that converts player input into action, and instead of getting the input from the mouse/keyboard/joystick get it from a file. For everything where a RNG is used, if you start with the same seed, the amount of calls each frame should stay the same, so the results should be the same as well. Just in case someone wants to implement this. Unfortunately I currently got no time, and it will stay like that for the next few months. :/

 
Interesting. So, if I get this straight basically you just keep track of the non-deterministic elements of the game, ie. random numbers & player actions, then you can just let the mission 'play' itself.

Sounds like quite a task, tracking down all the RNGs alone sounds frightening, but a flight recorder system does sound like a handy tool for modders. Aside from video production, it could be a rather useful tool for debugging, reproduce the exact steps that lead to an error, crash or whatever. Hell, if it could be exposed to scripting or SEXPs, it might provide yet another tool for mission designers somehow.

 

Offline z64555

  • 210
  • Self-proclaimed controls expert
    • Minecraft
    • Steam
Interesting. So, if I get this straight basically you just keep track of the non-deterministic elements of the game, ie. random numbers & player actions, then you can just let the mission 'play' itself.

Sounds like quite a task, tracking down all the RNGs alone sounds frightening, but a flight recorder system does sound like a handy tool for modders. Aside from video production, it could be a rather useful tool for debugging, reproduce the exact steps that lead to an error, crash or whatever. Hell, if it could be exposed to scripting or SEXPs, it might provide yet another tool for mission designers somehow.

Exactly. The biggest issue is making sure FSO's RNG is predictable with a given seed.
Secure the Source, Contain the Code, Protect the Project
chief1983

------------
funtapaz: Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Juche.
z64555: s/J/Do
BotenAlfred: <funtapaz> Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Douche.

 

Offline chief1983

  • Still lacks a custom title
  • Moderator
  • 212
  • ⬇️⬆️⬅️⬅️🅰➡️⬇️
    • Minecraft
    • Skype
    • Steam
    • Twitter
    • Fate of the Galaxy
Well, if we're super lucky, we only seed the RNG once and use that same seed throughout a mission at least.  Then we just need to save that seed to the replay file.  But I would be surprised if one RNG seed is all that it takes to make the game play deterministically.  Also, trying to ensure that player inputs are played back at exactly the same point they were first recorded, that also sounds like the engine would need to have been built around a concept like that, or would take a good bit of work to make it behave that way.  I'm curious if it's possible.
Fate of the Galaxy - Now Hiring!  Apply within | Diaspora | SCP Home | Collada Importer for PCS2
Karajorma's 'How to report bugs' | Mantis
#freespace | #scp-swc | #diaspora | #SCP | #hard-light on EsperNet

"You may not sell or otherwise commercially exploit the source or things you created based on the source." -- Excerpt from FSO license, for reference

Nuclear1:  Jesus Christ zack you're a little too hamyurger for HLP right now...
iamzack:  i dont have hamynerge i just want ptatoc hips D:
redsniper:  Platonic hips?!
iamzack:  lays