Hi Eric. This solution is … less than ideal for us.
Here’s the problem: our game is a simulation, and it allows the player to change the game speed at any time, on the fly. It has a set of “VCR” buttons that let you set the game to 0x, 1x, 2x, 4x, or 8x speed.
We used to set the game speed to 0, but this actually didn’t set the game speed to 0; it seemed to be clamped to a very small value (like 0.00001) and you could see stuff moving very slowly when the user hit the in-game ‘pause’ button.
So we ended up using time dilation for 1x / 2x / 4x / 8x speed, and we worked around the problem of 0x game speed not working by using the “paused” state for actually pausing the game.
I’m not sure how we would go about pausing the full simulation properly, as you suggest, including fully pausing the physics simulation.
If we set the game speed to 0, it never actually gets set to 0 … but if we use the paused state, we run into the problem in the original post.
It seems to me that there is a deeper problem here.
I think that the notion of a “tick” in Unreal is trying to represent two things: both the speed of the game itself, and the simulation it represents. And you very often want to fully pause the underlying simulation, including all the physics, without affecting rendering or UI in any way.
So it seems to me that Unreal should really have two separate tick types – the simulation tick, which is subject to pausing and time dilation, and the real-time tick, which is never paused or time-dilated in any way.
I.e. the “game speed” of the underlying simulation should be able to be modified without affecting the “app speed” of the application itself, which should always tick in real time.
And things like TemporalAA should use the real-time tick and should not be dependent on the underlying simulation at all. For it to be tied to the simulation tick as it currently is simply seems wrong.