That's not true. Havok and suchlike decouple their physics from the frame rate and still achieve determinism via a time accumulator (which I linked, but here it is again gafferongames.com/game-physics/fix-your-timestep/).
Basically you only step the physics a fixed amount k, after after dt > k wallclock time has passed. You keep track of the remainder k-dt and use it in future calculations to decide whether to perform a physics step or not.
In summery, you decouple the physics stepping from the rendering thread entirely.
This means several frame renders may occur in series before actually updating positions. To stop jerkiness, you integrate the time remainder with the velocity and last updated positions. i.e. you linearise the motion model and project into the future when demanded by the rendering thread.
This decoupling physics from framerate is a common pattern in game development. But its not obvious unless you have seen it before, see also gamedev.stackexchange.com/questions/1589/fixed-time-step-vs-variable-time-step
In construct 2 a event tick is tied to frame rate. So to decouple physics we have to decide whether to step or not. So we would need functionality to globally enable or disable physics evaluated every tick. Or choose to manually tick the physics ourselves in the event sheet.