Problems with simContinueForTime() in the new binaries

[yannbouteiller]

Hello, simContinueForTime() has become bugged in the new binaries. It doesn't unpause the visualization window when it is called, and using it with a high ClockSpeed (e.g. 100.0 on my machine, which gives cpu_time_steps of 0.001 s in my algorithm, that is simContinueForTime(0.001)) it often never pauses the simulator, which sends me in an infinite loop because I am doing:

simContinueForTime(0.001)
while not simIsPaused():
pass

I use this API because I think it is the only way to simulate more or less proper time steps at high ClockSpeed (because using simPause(False), action.join() and then simPause(True) instead means that there is a small amount of time during which the drone is using to the default action due to the communication between the client and the AirSim server, and this small amount of time becomes big at high ClockSpeed).

[madratman]

#17 (comment)
now it should

[madratman]

With the unreal binary in windowed mode and without the "ViewMode": "NoDisplay" on, I can get a max unreal game thread rate of ~200-250 fps on my machine.
A visual inspection of the rotors' drones pausing by calling c.simContinueForTime(0.005) seems like a good test, and spins up and pauses the rotors every time.
Anything lower than that - simContinueForTime(0.001) is not reliable as unreal game thread is maxing out at 200 fps.

with "ViewMode": "NoDisplay", in my settings, unreal game thread oscillates b/w 900-1000 Hz, though.
what is it on your machine?

[yannbouteiller]

'Game fps' is the value that we see under 'game' when typing 'stat unigraph' in the unreal console, right?

With t.maxFPS set to a high value and without vsync, I usually get something between 1 and 10 ms for this, but I don't really know the meaning of these values. Does that mean that a physics frame is computed every 1-10 ms? And simContinueForTime() would unpause the simulator for at least this amount of time?

(the problem about the simulator not pausing seems to be solved, and the problem about frozen window seems better and related to the fact that I was using a cpu_time_step that is too small indeed, so I close this issue)