| View previous topic :: View next topic |
| Do you want a third-party, external replayviewer? |
| Yes, any external replayviewer would help. |
|
63% |
[ 21 ] |
| Yes, the featured mentioned would make it cool enough to use. |
|
15% |
[ 5 ] |
| No, I'll wait for SCS to make one. |
|
12% |
[ 4 ] |
| No, I don't use them. |
|
9% |
[ 3 ] |
|
| Total Votes : 33 |
|
| Author |
Message |
MaHuJa
Joined: 10 Jan 2002
Posts: 447
Location: 59.96156N 11.02255E
|
 Posted: Sat Mar 25, 2006 9:47 pm Post subject: Do you want a third-party replayviewer? (att: Barleyman) |
 |
|
I've been thinking about it ever since I (a couple hours ago:-j) read barlymans post in the suggestions thread, and thought about the things I put in the reply below.
I will, however, need to have someone else writing the graphical interface... I'm thinking that one can make the gui totally pluggable. (I'll be using C++, but if your programming language of choice can use C interfaces, and I believe most suitable for the task can, we can make it work.)
Essentially, if I were to make a replay viewer, it would likely have the following features when "finished":
-The DDI from the navmap, with information about depth, speed, etc. would be available.*
-Creating "keyframes" and indexes, for fast forward/backward motion. I'm intending to cache it in a file right besides the replay file as an option.
-Exporting the state of the replay into a mission file, so that, using the same interface, you can see (approximately, due to TA/dipper length/depth etc) what the player could see at that point
-The possibility of toggling the three categories of contacts (truth, link, own solutions) between fully visible, transparent, and invisible. (slider?)*
-If a gui-maker decides to go advanced enough, you could perhaps get the 3d view too...*
-We'll have to see what more ideas pop up.
* Depends on whoever makes the gui in use, I guess...
I'm supposing that SCS will give me the specs of the replay files, etc. - I hear they have been similarly friendly before, with database editors.
As you might guess from the poll, I'm gauging interest. Would be a bummer to spend the time on it if noone was going to use it anyway.
--- --- --- --- --- --- ---
Barleyman, I read through your post in the suggestion box, but found that this big reply doesn't quite belong there, so I made a new thread instead.
I do not think you see quite the depth of the problems... I'll try to outline them for you.
First of all, I agree that replays as they are now are unacceptably slow when moving backward or forwards in time. However, your thinking haven't brought us much closer to a solution at all, because you overlook too many things.
Secondly, some of the idea was to (already) save data so that a replayer could show the whole thing in the navmap or similar interface, complete with 3d. Only, such a replayer hasn't been made yet. (I believe one could even compute the sensor data etc along the way, just so that is said. You could essentially see everything the user playing it saw.)
When creating a system like the replay saver, you have to balance a few factors:
-File size
-Speed
-Accuracy
-Continuity effects (the ability to move forwards and backwards in the replay - which is broken now)
(Continuity is a bad choice of word, but I couldn't think of anything better.)
In general, anything you do to improve one, will negatively impact at least one of the others.
In addition, you have some additional restrictions on what your system must be able to handle:
-Variable number of platforms (torpedoes launched, aircraft shot down, ships sunk then removed)
-Difference direction front vs travel should be accurately represented.
-You need to interleave data about contacts made, and their state at the time. Remember these go from bearing lines updated every few seconds to solutions.
For example, they could store the positions in floats rather than doubles (32 and 64 bit floating point numbers) to reduce size, but at the cost of accuracy.
With the game engine using double-precision floating points natively for positions, probably with good reasons, it's only natural to use these 8-byte values throughout.
They could send it through a compressor to reduce the file size, with only a very slight hit on speed, but this would very likely be very bad for continuity, since it would have to be decompressed start-to-end.
AFAIK (if I remember the SCS statements correctly) they do leave out some data, primarily positions, rather "adding it up" as they process it from start to end. Reduction to filesize, bad for continuity and speed.
They could add data to the replay file only when something changed (and otherwise the reader would just calculate from last information). Speed hit (for the reader), continuity hit, negligible accuracy hit. (And this presumes waves, wind gusts etc. conform to chaos theory predictability)
| Quote: | | 4byte X latitude, 4byte Y latitude, 2 byte altitude(for replay purposes not really needed), 2 byte direction and 2byte speed recorded once a second |
This lacks way too much metadata to be of any real use.
Look at this example:
| Code: | struct objectState {
short id; //2 - need to know what object we're dealing with. Corresponds to the number in truth mode.
// position - assuming z to be altitude here
double px; //8
double py; //8
float pz; //4 - they would get away with float if size was a concern, but at some speed cost.
// Where the object is pointing, direction
float dx; // 4 - pitch
float dy; // 4 - course
float dz; // 4 - roll
// And that is if they aren't using quaternions, which is often a better idea than euler directions, but is four floats.
// How the object is moving
float vx,vy,vz; // 12
// This is because the direction of flight/movement is *not* always equal to where the object is pointing. This is especially because of wind and water currents, but not only. Check with your average flight simulator that shows where the nose is pointing and the actual flight direction
}
|
That's 66 bytes (presuming I didn't think of and add yet another entry since I summed it). Presuming one of those a second, one object will create nearly 250kB per hour. That means four objects, for one hour, will be 1MB. 100 objects? 25Mb. I think this is about the rate DW does produce (not sure), but DW does it more often, since once a second will have aircraft maneuvering jumping about like some laggy flight sim. (Ever played flight sims, and tried to chase down a guy lagging very badly? With his aircraft "blinking" around madly?)
And in addition to that, there would have to be a way to "package" that, and keep tabs on the "when" for each piece of data (without it, you have to assume a constant number of entries for objects... see "additional restrictions above"), and add the contacts etc, which will lead to additional overhead. Look to the mpeg, avi, ogg, and matroska (mkv, mka) multiplexer formats to see what I mean. (Though I guess one could package those features into the entries themselves, it would likely become far less efficient in all ways.)
The most "backward compatible" would be to copy the video codec trick of "key frames". Every five minutes or so, write down the whole state of everything that is in there right then. Then the reader will only have to move on from there. |
|
| Back to top |
|
 |
Bellman
Joined: 14 Feb 2004
Posts: 1724
|
| Posted: Sun Mar 26, 2006 3:11 am Post subject: |
|
|
 I voted yes for 'any' improved RV but would be happy with one which gave me some more information
and where I could 'export' as you outline. |
|
| Back to top |
|
|
LuftWolf
Joined: 09 May 2005
Posts: 1872
Location: Free New York
|
| Posted: Sun Mar 26, 2006 5:35 am Post subject: |
|
|
DW absolutely needs to have a third-party replay viewer.
In terms of extra features, I would definately include some features on the front end, like automatically importing new replay files and allowing the user to name them.
Perhaps you could simply code the program to have an "import" feature that could default to main DW directory, find and extract and allow the user to rename the new replay.dat file, all with a single menu or button selection in the replay view interface.
That would be so far beyond cool. In fact, it would make playing DW in MP so much greater, because I could easily save, name, and store my replays, essential tools to becoming better and learning opponents (if I ever get the time to play DW online in large amounts again... perhaps I should join an MP-VF, any takers???  ) |
|
| Back to top |
|
|
Molon Labe
Joined: 16 Jun 2004
Posts: 1052
Location: Bloomington, IN, USA
|
| Posted: Sun Mar 26, 2006 9:09 am Post subject: |
|
|
| Hehe, there is at least one that encourages modded play.. |
|
| Back to top |
|
|
MaHuJa
Joined: 10 Jan 2002
Posts: 447
Location: 59.96156N 11.02255E
|
| Posted: Sun Mar 26, 2006 11:21 am Post subject: |
|
|
This project will be on hold until three things have happened (in any order):
1 - I need to get the other project, the autoneutrals or whatever I'll call it, reasonably up and running. This seems like the simpler project, anyway, and I'm (as of yet) giving it a high priority.
2 - I need at least one gui programmer "on the team" before I can do much useful. I can make the "core" before then, but it will be hard to test properly without a working gui.
3 - I send a request for information to and get a (positive) reply from SCS.
I think that in the end, the "replay core" will be a dll that the gui program can link to.
| LuftWolf wrote: | | Perhaps you could simply code the program to have an "import" feature that could default to main DW directory, find and extract and allow the user to rename the new replay.dat file, all with a single menu or button selection in the replay view interface. |
Perhaps even automatic on startup of the application, renaming it according to some template (that could in the end be user-settable?) like "datetime playerlist scenario" (provided scenario name is included in the replay file?) |
|
| Back to top |
|
|
LuftWolf
Joined: 09 May 2005
Posts: 1872
Location: Free New York
|
| Posted: Sun Mar 26, 2006 3:26 pm Post subject: |
|
|
| One thing to be aware of in 1.03 (I'm not sure I noticed this in previous version): MP replays are named by the Sim as [NickName]_replay.dat. |
|
| Back to top |
|
|
Barleyman
Joined: 07 Jul 2002
Posts: 113
Location: Finland
|
| Posted: Mon Mar 27, 2006 7:08 am Post subject: Re: Do you want a third-party replayviewer? (att: Barleyman) |
|
|
Let me clarify my position a little - I'd be quite happy with the present replayer UI .. IF the seek bar actually worked properly, which it does not. 3D replay would be neat but for me, I'm mostly interested to see what happened in the 15 mins before "OMG We're going to die, we're going to die KABOOM"
There isn't usually THAT much happening in the scenario, so I'd just like to see who picked me up and where did those torpedoes actually hit (if anything) .. I can do that right now but that requires saint's patience and/or a good book.
There was stand-alone replay viewer for Sub Command but time seek was as grievously broken as it is now.
So, 3D eye candy aside, most pertinent information for me would be who has detected who. Possibly by viewing OPFOR solution the same way you see your own with "show truth" off. Or just by highlighting or something all contacts which have detected you.
On the plus side, you can ditch almost all of the information of what you presented to show simple 2D nav map replay. Which regardless provides all the relevant information about who did what and with whom.
| MaHuJa wrote: | | The most "backward compatible" would be to copy the video codec trick of "key frames". Every five minutes or so, write down the whole state of everything that is in there right then. Then the reader will only have to move on from there. |
And that is an excellent suggestion. Makes a person wonder why has it not been implemented within the decade SCS subsims have been with us!?
Every 5 mins is probably bit sparse, but even at 1min you get quite nice granularity. Plus get rid of the warping subs-phenomenom in replays. |
|
| Back to top |
|
|
MaHuJa
Joined: 10 Jan 2002
Posts: 447
Location: 59.96156N 11.02255E
|
| Posted: Mon Mar 27, 2006 11:30 am Post subject: Re: Barleyman |
|
|
| Barleyman wrote: | | 3D replay would be neat but for me, |
That's SCS' unrealized idea, not mine. I don't expect it to happen at all, except for showing depths of subs and torpedoes when you click on them. Just what is shown is up to whoever makes the GUI.
| Quote: | | I'm mostly interested to see what happened in the 15 mins before "OMG We're going to die, we're going to die KABOOM" |
I see your point.
| Quote: | ...I'd just like to see who picked me up and where did those torpedoes actually hit (if anything) .. I can do that right now but that requires saint's patience and/or a good book.
...most pertinent information for me would be who has detected who. Possibly by viewing OPFOR solution the same way you see your own with "show truth" off. Or just by highlighting or something all contacts which have detected you. |
This information is not stored in the replay file, I believe. If one has access to the game engine itself one could possibly calculate it, but it would be a very heavy process.
Instead, at least for singleplayer games, look into using a debugviewer and the /debugoutput option, for those features. (There is something in these forums on them.)
| Quote: | | On the plus side, you can ditch almost all of the information of what you presented to show simple 2D nav map replay. Which regardless provides all the relevant information about who did what and with whom. |
| Quote: | | MaHuJa wrote: | | The most "backward compatible" would be to copy the video codec trick of "key frames". Every five minutes or so, write down the whole state of everything that is in there right then. Then the reader will only have to move on from there. |
And that is an excellent suggestion. Makes a person wonder why has it not been implemented within the decade SCS subsims have been with us!?
Every 5 mins is probably bit sparse, but even at 1min you get quite nice granularity. |
Perhaps this is the first time they've heard it mentioned regarding replays...
Either way, in my external viewer, it would be generating the keyframes and saving them in a "companion file". My intention was to make the time between each frame user-settable.
| Quote: | | Plus get rid of the warping subs-phenomenom in replays. |
Haven't noticed much of those, except for those where that actually seemed to be the gamestate - in other words, it not being a replay phenomenon, but a thing of multiplayer desync.
If you ask me, the network code is what needs most work. I'd go so far as to recommend ditching directplay altogether. SCS is the only ones who have actually stuck with it of all "commercial-grade" game developers I know who used it in the first place. And we can see how well that worked out for scs... :shifty: |
|
| Back to top |
|
|
GunnersMate
Joined: 17 Feb 2006
Posts: 225
Location: Boston, MA
|
| Posted: Mon Mar 27, 2006 2:38 pm Post subject: |
|
|
| Does FRAPS work at all? |
|
| Back to top |
|
|
Barleyman
Joined: 07 Jul 2002
Posts: 113
Location: Finland
|
| Posted: Tue Mar 28, 2006 5:03 am Post subject: Re: Barleyman |
|
|
| MaHuJa wrote: | | The most "backward compatible" would be to copy the video codec trick of "key frames". |
| MaHuJa wrote: |
Perhaps this is the first time they've heard it mentioned regarding replays...
Either way, in my external viewer, it would be generating the keyframes and saving them in a "companion file". My intention was to make the time between each frame user-settable.
|
Perhaps. Kind of long long time for no-one to think about it, thought. I suppose it is because Jamie + co play with DOD supercomputers and for them the replay works like a charm.
So in effect you're planning to make external utility which would crunch the replay file for however long it takes and then produce a keyframe file which would contain necessary info for replay? If it worked with reasonable speed it's a neat idea, true. However, since there is the warping problem..
| Barleyman wrote: | | Plus get rid of the warping subs-phenomenom in replays. |
| MaHuJa wrote: |
Haven't noticed much of those, except for those where that actually seemed to be the gamestate - in other words, it not being a replay phenomenon, but a thing of multiplayer desync. |
Good theory, but I have only ever played singleplayer. There's definite warping going on in the replay for both your boat and the bad guys boad/helo/whatever. Only the dead boat appears on the correct place.
Takes the edge off the fun of watching the dance between CMs and torpedoes..
Optimal solution would be to kick SCS coder butt to implement a keyframe feature as an option in the game settings. Should be relatively straightforward to implement in code level, no? And, yes, I definitely do think this would increase the commercial salability of the game instead of obscure (to most people) tweak about mavpoon capabilities and such.. |
|
| Back to top |
|
|
Molon Labe
Joined: 16 Jun 2004
Posts: 1052
Location: Bloomington, IN, USA
|
| Posted: Tue Mar 28, 2006 9:04 am Post subject: |
|
|
/OT Rant mode on
I think "most people" that play hardcore military sims like DW know what the frak a Maverick is and can tell modeling it such that the range is over twice what it has in real life absofrackinlutely ridiculous. Getting it fixed is much less obscure than wanting the fictitious "65cm torpedo" replaced with the real 65-76 wakehomer, which people also justifiably bitched about.
Anyone who didn't notice just "isn't familiar with the problem," http://www.mit.edu/activities/safe/humor/avoid-foul-language.    and anyone who didn't care doesn't give a rat's ass about realism, in which case they have earned a GSGT Hartman-esque evaluation of their personal worth.
/OT rant mode off
Ah, that feels better! |
|
| Back to top |
|
|
OneShot
Joined: 24 Mar 2005
Posts: 704
Location: Germany
|
| Posted: Tue Mar 28, 2006 9:45 am Post subject: |
|
|
Totally OT :
I like this part | Molon Labe wrote: | | ... in which case they have earned a GSGT Hartman-esque evaluation of their personal worth. |
Tho shouldn't it be GySgt Hartman? :know:
:lurk: |
|
| Back to top |
|
|
Molon Labe
Joined: 16 Jun 2004
Posts: 1052
Location: Bloomington, IN, USA
|
| Posted: Tue Mar 28, 2006 3:00 pm Post subject: |
|
|
| OT: You might be right, I'm not sure what the proper USMC acronym scheme is. |
|
| Back to top |
|
|
Barleyman
Joined: 07 Jul 2002
Posts: 113
Location: Finland
|
| Posted: Wed Mar 29, 2006 6:27 am Post subject: |
|
|
| Mavpoon capability can be (and has been!) modded easily. Functional replay cannot. |
|
| Back to top |
|
|
LuftWolf
Joined: 09 May 2005
Posts: 1872
Location: Free New York
|
| Posted: Wed Mar 29, 2006 11:46 am Post subject: |
|
|
Of all the amusing things in this thread, the one I find the most amusing is right at the top, in the poll itself.
| Quote: | | No, I'll wait for SCS to make one |
And people actually voted for this option too!!! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
