Replay Control for STK

[Alayan]

Hi!

To preface this I would like to offer an explanation of what ReplayControl actually does and what it does not do.

I understand that some of what I wrote may not be easily understood from the outside (even from the inside it's a little confusing!) so let me explain. The advance() function is ReplayControl's own accumulator. One tick (in seconds) is passed into the function. From there, after checking if ReplayControl's pause is active and a check to see if the replay is finished, it adds the product of 1 tick and the rate multiplier to the head of the playback. This function's caller is WorldStatus::updateTime(). advance() runs and it's return value is given to setTime(), thus making m_head the source of truth when ReplayControl is enabled.

Essentially, when ReplayControl is active, instead of incrementing the clock normally, it goes through advance() instead. The way setTime() works is that it truncates to ticks and then feeds that same truncated tick count back to m_time. This is a non-issue under normal circumstances but under rate multipliers this inaccuracy quickly adds up, hence the need to keep m_head as an exact value and the need for ReplayControl to have it's own accumulator.

To tie it back to the world clock, moving m_head also moves the clock and changing the rate changes how much time is added to the world clock by means of multiplying the time delta. It writes to the same m_time and m_time_ticks that get called by anything that needs the world's time, such as a ghost kart. It does not change the world's stepping, 120 physics ticks pass
no matter what ReplayControl does, leading the desync with the world that you mentioned when the rate changes or when ReplayControl enables it's pause.

That clears up how your code used to work.

My earlier confusion arose because I considered the link between world clock and world events as something we'd want to keep as an invariant.

Sadly there's no easy approach to it. Smooth and continuous rewind would most likely involve restoring to a snapshot every single frame and a rewind system like the one in multiplayer faces the risk of incurring noticable memory/performance problems in relation to snapshot frequency. Too often and your memory usage explodes, too sparse (say 2 seconds) and you cram 240 ticks worth of physics calculations into one frame which, as you can imagine, would cause a stutter. Perhaps an edit to the replay format would help a bit but that's beyond my scope and certainly a decision that cannot be made by myself (and, as you pointed out, on 1.5 we don't have the freedom to edit it). I could go on about the difficulties this poses but I think you get the gist.

You sent me a PM on this, so you have already partially solved the issue. Essentially, there are a lot of things that are actually pretty easy to get right when rewinding, so the memory cost related to the extra data that needs to be stored shouldn't be prohibitive.

Fortunately for us both, while I was waiting for a reply I built a prototype control interface for ReplayControl. As of writing it's only been a couple of hours since I finished it. No doubt there are a few style nits in the code itself but it's pretty clean and it works as intended so I think for a demo it'll be fine.

Seems good. I will soon test the updated version ported to BalanceSTK2 that you mentioned as well as the version you mentioned in PM.

In regards to the code contribution guide, I think it covers pretty much everything you'd need to know in regards to contributing. Perhaps for the "Coding Style" section you could give a side-by-side example of code that fits the style and code that doesn't? We see code snippets in the "Layout" section yet the one titled "Coding" is a big text wall. I think some examples might help new contributors better understand the STK conventions.

That's a good point, a few code snippets to illustrate some principles could be a good idea.