Wiki Entry - Demo Recording
by Matthew Barney · in Torque Developer Network · 02/11/2008 (6:36 pm) · 15 replies
I was searching the site for more info on the TGEA demo recording functionality and I thought perhaps I'd hit a good source of info when I found a wiki link to an entry on the subject. Sadly the page is blank. I've searched through the site and the most info I can find is in the form of 6+ year old forum posts. Is there any documentation that is more recent on this functionality? I'd like to start using it and possibly extending it, but I was hoping for some reference material.
Thanks in advance!
Thanks in advance!
#2
I've found some useful stuff though, so hopefully I can start figuring things out. Although I currently have no idea how to even play back my recordings I've captured...
02/12/2008 (12:58 pm)
Yeah, that is my one gripe in my 2 years of experience with GG products, lack of documentation/out dated documentation. That and lousy forum search, but alas what can you do.I've found some useful stuff though, so hopefully I can start figuring things out. Although I currently have no idea how to even play back my recordings I've captured...
#3
02/12/2008 (2:06 pm)
? That should be built into the stock engine. I think F3 to record, F4 to play. Or via the gui on the main menu.
#4
Do you have any info on recordMove from screenshot.cs? I get an error when I use it from the console... I'm passing in a string for the name and an int for fps...
02/12/2008 (2:11 pm)
F4 is stop, but thanks. At this point I think I'm gonna have to do something else since the kind of playback produced isn't quite what I need.Do you have any info on recordMove from screenshot.cs? I get an error when I use it from the console... I'm passing in a string for the name and an int for fps...
#5
More accurately called journaling, when you are "recording" a session, you are capturing the OS and Network event streams to a file that can be replayed at a later time. The purpose is for troubleshooting--you can have a player record a stream of a crash, send you the file, and then you can run that stream under debug mode with your executable and (most of the time) reproduce the crash in a debug environment.
02/12/2008 (7:41 pm)
The "recording" system built into Torque has nothing to do with video, demos, or anything along those lines (although it -can- be twisted into a basic demo if you put some work into it).More accurately called journaling, when you are "recording" a session, you are capturing the OS and Network event streams to a file that can be replayed at a later time. The purpose is for troubleshooting--you can have a player record a stream of a crash, send you the file, and then you can run that stream under debug mode with your executable and (most of the time) reproduce the crash in a debug environment.
#6
The ability to pause/fast forward and upload them into somekind of youtube like file sharing would be an awesome addition to the engine.
I still plan on going back and seeing if its achievable at a later date.
02/12/2008 (8:06 pm)
I was looking into this a few months ago. It seems like with a bit of engine tweaking you could emulate halo 3s video playback functionality.The ability to pause/fast forward and upload them into somekind of youtube like file sharing would be an awesome addition to the engine.
I still plan on going back and seeing if its achievable at a later date.
#7
Does it at least work with multiple players, or does it only record the player who initiated the recording?
What if I had an observer watching several players play and they initiated the recording, would I see what all the other players do or just what my observer did?
02/13/2008 (11:11 am)
I see. I'm working on a training game of sorts and was hoping to be able to use it to evaluate player's and provide feedback to them.Does it at least work with multiple players, or does it only record the player who initiated the recording?
What if I had an observer watching several players play and they initiated the recording, would I see what all the other players do or just what my observer did?
#8
02/13/2008 (12:51 pm)
You would only see what occurred on the client that initiated the recording. If objects are within network scope of the control object of that client, then events related to them (in this case, all networking events) would be recorded, but none of their inputs, and nothing that occurs out of scope of that client's control object.
#9
Is there a good starting point for understanding the record data? Somewhere in the code that I can get a good handle on what it stores/how it stores it.
If I can't implement FFWD, I'd like to be able to tag points and then skip back to them...
02/13/2008 (1:03 pm)
I see. Thanks Stephen.Is there a good starting point for understanding the record data? Somewhere in the code that I can get a good handle on what it stores/how it stores it.
If I can't implement FFWD, I'd like to be able to tag points and then skip back to them...
#10
Error could not find ClientMissionCleanup group.
And I think the top of the window is indicating that the offending file is code\engine\game\fx\particleemitter.cpp @ line 605
Is this a problem caused by my code or the engine?
02/15/2008 (3:12 pm)
Ok one more question demo recording. When I playback a demo and watch it to completion and then attempt to watch another demo I get the following error:Error could not find ClientMissionCleanup group.
And I think the top of the window is indicating that the offending file is code\engine\game\fx\particleemitter.cpp @ line 605
Is this a problem caused by my code or the engine?
#11
I would assume (I'm guessing here), that the SimEvent where the ClientGroup was deleted went to completion (it's done at the end of any mission), but since your recording didn't capture the creation of the ClientGroup initially at the start of the mission, when you try to play your second recording, it's not been created.
02/15/2008 (3:58 pm)
Recordings are not designed for anything except for helping you find crashes--and by definition a crash is going to not allow you to play another recording in the same execution run :)I would assume (I'm guessing here), that the SimEvent where the ClientGroup was deleted went to completion (it's done at the end of any mission), but since your recording didn't capture the creation of the ClientGroup initially at the start of the mission, when you try to play your second recording, it's not been created.
#12
That makes a lot of sense.
Thanks again Stephen.
Since demo recording is more of a debugging tool, if I wanted to implement some sort of in engine recording system with play, stop, pause, skip to marker type functionality would it best to extend the demo recording system or try to write something new?
02/15/2008 (4:07 pm)
Ah, so if I start recording in the middle of a session that would be why that group isn't being seen as created?That makes a lot of sense.
Thanks again Stephen.
Since demo recording is more of a debugging tool, if I wanted to implement some sort of in engine recording system with play, stop, pause, skip to marker type functionality would it best to extend the demo recording system or try to write something new?
#13
What you want to do isn't particularly easy, and while the low level functionality of demo recordings will accomplish a lot of what you want, you're going to need to understand the system pretty fully, and then implement on top of it to get all of the functionality you want.
For example, I'm reasonably certain that rewind is -not- going to work, and skipping directly to a marker won't without quite a bit of work (-possibly- via a fast forward of some sort, but the event stream is going at a frequency of 30hz, which is the speed the engine already runs at).
Do know that it is possible however--a company called Valador wrote an extension to Torque that reads in telemetry streams from a file and allows for full recording style control of the simulation. Their team was lead by Eric Priesz, who I like to call "the best non-GG employee Torque engineer in the world" (he denies it!), but it's doable.
02/15/2008 (5:11 pm)
Honestly, it depends on your energy, willingness to learn, and experience.What you want to do isn't particularly easy, and while the low level functionality of demo recordings will accomplish a lot of what you want, you're going to need to understand the system pretty fully, and then implement on top of it to get all of the functionality you want.
For example, I'm reasonably certain that rewind is -not- going to work, and skipping directly to a marker won't without quite a bit of work (-possibly- via a fast forward of some sort, but the event stream is going at a frequency of 30hz, which is the speed the engine already runs at).
Do know that it is possible however--a company called Valador wrote an extension to Torque that reads in telemetry streams from a file and allows for full recording style control of the simulation. Their team was lead by Eric Priesz, who I like to call "the best non-GG employee Torque engineer in the world" (he denies it!), but it's doable.
#14
Rewind, I can probably get by without, skipping to a marker was supposed to be a simpler replacement for FFWD, but if FFWD is easier then by all means I'd prefer that.
I've dug through the engine and I'm reasonably sure I understand how/where recording occurs. I've managed to implement a pause function that works, so I know I can make some changes to it succesfully.
My intuition for FFWD is that either I need to control the speed of the stream, or somehow modify that which it outputs. You said it goes at 30hz, is that coded in somewhere or just a byproduct of the engine?
What data exactly is being written in the packets that are saved? How is this data pooled?
I know this is probably a monumental task, but its what I've been asked to do and I'm doing my best to accomplish it...
02/18/2008 (12:23 pm)
Well energy and willingness to learn I've got (I'm being paid to make this happen currently), experience I suppose I'm a bit short on.Rewind, I can probably get by without, skipping to a marker was supposed to be a simpler replacement for FFWD, but if FFWD is easier then by all means I'd prefer that.
I've dug through the engine and I'm reasonably sure I understand how/where recording occurs. I've managed to implement a pause function that works, so I know I can make some changes to it succesfully.
My intuition for FFWD is that either I need to control the speed of the stream, or somehow modify that which it outputs. You said it goes at 30hz, is that coded in somewhere or just a byproduct of the engine?
What data exactly is being written in the packets that are saved? How is this data pooled?
I know this is probably a monumental task, but its what I've been asked to do and I'm doing my best to accomplish it...
#15
One thing you won't be able to do is to skip portions of the recorded event stream--the simulation is reliant on consistent input of all events to be able to deterministically reproduce a state, and therefore at best you'd have to try to run them at double speed or something--which has possible consequences of it's own.
When I said it goes at 30hz, I should have been more specific:
When playing back a recording, the simulation is acting normally, which is at the default 32 milliseconds per tick cycle, and 100 ms per network cycle.
The stream is simply coordinated to start (and continue) sending the events at whatever intervals they were originally recorded at. I'm not sure of the mechanism to be honest, but I'm expecting it probably saves off sim timestamps for each of the events.
02/18/2008 (12:50 pm)
It's a stream of Events, nothing more, nothing less. I personally haven't ever looked at the serialization portion, but you'd probably need to learn that first, and then see where you can add to it for your markers and such.One thing you won't be able to do is to skip portions of the recorded event stream--the simulation is reliant on consistent input of all events to be able to deterministically reproduce a state, and therefore at best you'd have to try to run them at double speed or something--which has possible consequences of it's own.
When I said it goes at 30hz, I should have been more specific:
When playing back a recording, the simulation is acting normally, which is at the default 32 milliseconds per tick cycle, and 100 ms per network cycle.
The stream is simply coordinated to start (and continue) sending the events at whatever intervals they were originally recorded at. I'm not sure of the mechanism to be honest, but I'm expecting it probably saves off sim timestamps for each of the events.
Torque Owner Lee Latham
Default Studio Name
I don't believe the docs exist--I've looked. It's fairly straightforward if you follow the scripts.
But yeah, I'm not at all fond of those blank wiki's that seem like they're going to be exactly what you're looking for from the name of the link.