Remove weird seek call in GameplayClockContainer
#19837
Conversation
Hopefully not required anymore. This can actually cause incorrect seeks to occur, at random, during actual game and test execution.
| { | ||
| // Seeking the decoupled clock to its current time ensures that its source clock will be seeked to the same time | ||
| // This accounts for the clock source potentially taking time to enter a completely stopped state | ||
| Seek(FramedClock.CurrentTime); |
There was a problem hiding this comment.
I also wonder if this was somehow related to audio devices taking time to pause? I'm not sure if that's a thing though... Because then it would be doing the seek for the only reason of seeking the track back to the current time.
Edit: But it looks like maybe DIFC does that internally on .Start() if I'm reading correctly?
There was a problem hiding this comment.
Possibly. We'll have to see how this plays out in CI and local testing. I've been testing these changes only via tests so will do some actual gameplay tonight to test any non-tested edge cases.
|
At very least, we do seem to have test coverage of this (maybe indirectly)
Will investigate further. |
|
It looks to be related yeah. This is with 0 audio offset: Master: 2022-08-18.19-37-41.mp4This PR: 2022-08-18.19-38-27.mp4Notice the jumping after unpause. |
|
Closing and will keep as part of #19828. The composite changes there do not have the failures seen here due to other related changes. |
Hopefully not required anymore. This can actually cause incorrect seeks to occur, at random, during actual game and test execution.
Split out from #19828 for isolated testing (and more test runs).