Spring RTS Engine

Assume the whole game was without desync errors. Why would a replay of such a game lag or stutter when your connection was bad in said game?

It makes no sense to store 'lag information'/delays in replays as it is now.

Well, this is something new to me. I have never seen my replays lag.

http://replays.adune.nl/?1822
watch this one.
Somewhere halfway or 2/3rd ish there is a big lag.

I could possibly modify my demo reader to correct lag...

replays lag because packet timestamps are saved in the demo and are used during playback. like aegis said, you could probably easily fix this by going over a replay and setting the timestamp to framenum/30 or so.

aegis wrote:I could possibly modify my demo reader to correct lag...

DO EEEET

imbaczek wrote:replays lag because packet timestamps are saved in the demo and are used during playback. like aegis said, you could probably easily fix this by going over a replay and setting the timestamp to framenum/30 or so.

Why don't we just do this when saving?

(I suggested this 2 days ago to BD actually when he was making his dedicated client [as gu->modGameTime wasn't available in this] and this worked fine.)

Or is it that we really want to record the duration of pauses?

Tobi wrote:Or is it that we really want to record the duration of pauses?

Length of pause in the sense of pressing the pause button is not recorded afaik.

The 'lag pause' is useless unless you want to prove you were lagging.

Why does it save timestamps at all, let alone issues of changing them.

Probably to prevent dumping the entire replay at once into the (loopback) network buffers.

Not sure what kind of (adverse) effects that has though, feel free to try

imbaczek wrote:replays lag because packet timestamps are saved in the demo and are used during playback. like aegis said, you could probably easily fix this by going over a replay and setting the timestamp to framenum/30 or so.

Why wouldn't you make all events frame-dependant instead? At least framerate is always constant. Timestamps are affected by lag. At least to me that seems a far better way of doing it.

one of the possible negative effects is the compression of events that happends in pre-game into a single instant ( frame count fixed at 0 )

That is a positive effect imo, we dont have to wait for noobs who take forever to select start pos :)

zerver wrote:That is a positive effect imo, we dont have to wait for noobs who take forever to select start pos :)

/skip +1

When pausing you might want to have the ability to read the chat and not getting printed 100 lines of chat at once. If you don't /skip +1 helps there too.

Then why not go for the timestamps on the first part, since that is blabbering anyways, and once the game has started switch to frame numbers? It just requires some extra code like this:
if(frameNum > 0)
{
//record/play using frames
} else {
//record/play using timestamps
}
Although I guess things are quite a bit more complicated than that, but you get the idea