Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: CountBuggula on September 25, 2014, 12:14:46 pm
-
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 (http://www.hard-light.net/forums/index.php?topic=42873.5)
Replay recorder script (http://www.hard-light.net/forums/index.php?topic=67351.5)
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?
-
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?
-
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.
-
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.
-
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 (http://www.hard-light.net/forums/index.php?topic=42873.5)
Replay recorder script (http://www.hard-light.net/forums/index.php?topic=67351.5)
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.
-
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:
from the Guided Tour (http://scp.indiegames.us/guided_tour.txt) 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.
-
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).
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
The biggest problem would probably be framerate mismatches between the original run and the replay. You'd need to store a more detailed snapshot than just player input at regular intervals to avoid desynchronization.
-
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.
The random number SEXPs can already be seeded in this way.