Playback Incorrect

[SeaQueen]

I was trying to watch the replay of a mission I just completed, for an ~20 hour game, the playbacks have always been slow, but now I've noticed that the position of my own ship is radically wrong.

Has anyone else had this problem?

[Sonoboy]

A 20 hour game?! That's... hardcore.

[Bellman]

20 Hour replay :o I am beginning to suspect that you are the player who ran Silent Hunter in real time and
reported it blow by blow. :roll: ;)

Replays have always been screwed. I still see some of what I saw in SC MP, only now I dont waste time in pursuing
suspicions about opponents behaviour. Their replay almost always reflected a different picture of certain events.

Two or three participants replays may allow some reconstruction of in-game events. (May !)

[LuftWolf]

SeaQueen, for a run that long, the replay is next to useless... and will take forever to run unless you have some grunt in the front of your computer.

[Mau]

But I still don't understand why that Replay is so innefective.

I mean Flight Simulator for exemple, there are more data and in 3D!! and it is very fluid.

Is that because we are dealing with some older technology here?

[LuftWolf]

Flight sims are running a physics, a graphics, and a sound engine.

DW is running a phsyics, a graphics, and a sound engine, AND the acoustic engine.

It's a massive drain on the processor.

My suspicion is that the coding challenge of making the game capable of storing a replay file that can be easily replayed without errors that doesn't significantly drag the performance of the software down as a whole was beyond the budget of SCS.

[MaHuJa]

LW is correct that the acoustics engine draws a lot of cpu, but I think he overestimates its role in causing problems for the replay.

Replays have problems, that's for sure. But what causes these problems? Lack of cpu time? Hardly. Ergo: the acoustics engine doesn't affect it; at least not the part of it draining cpu time.

I think it's a coding problem more than anything else. Without looking at the code, I can only guess; but at least I can evaluate a probability for a guess. Here's my guesses for culprits.

#1: Storing only deltas, instead of the positions themselves. I remember there were statements that *could* mean this.
This means that if there is an incorrect update, the rest of the replay is pretty much bogus.
It also means that fast-forward and fast-backward is slow, and jumping to a very different time is very slow. We know that is the case from observation. ("keyframes" could mitigate this; as discussed in another thread - "third-party replayer")

#2: Insufficient accuracy in the deltas
The replay saying course and speed, but without accounting for wind and currents.
If true, this will really only have them "slide" from their original position. I've seen platforms "jump around". Still, it could be a factor.

#3: Race conditions, partial updates of values before they were recorded
Could probably explain at least some jumping around. These are usually quite hard to debug. Esp since there may be some safeguards against it, that the compiler just happens to optimize away :damn:
If this is part of the problem, then it's no wonder if SCS let dead beast lie :roll:

Those are my guesses.

[SeaQueen]

A 20 hour game?! That's... hardcore.

That's actually pretty typical of one of my missions. There's usually sufficient randomness in the game that it can vary a lot. Sometimes it lasts just a few hours, sometimes it goes for 8...12...16...

I try to set things up so that there's an interesting search problem.

That SAVE & EXIT option was made just for me. :-)