ViZDoom
ViZDoom copied to clipboard
get_last_action from a recorded episode for TURN_LEFT_RIGHT_DELTA is incorrect
When replaying an episode, get_last_action
is inaccurate in value for TURN_LEFT_RIGHT_DELTA
. For example, if the true action was 90, recovered action is -90 and if the true action was -90 the recovered action is 90. Issue #285 discusses that there shouldn't be any issues with get_last_action
with replays, at least for this action.
Here is a log of replay actions in the format (true_action, replay get_last_action):
[1 0] [1.0, 0.0]
[1 0] [1.0, 0.0]
[ 0 90] [0.0, -90.0]
[ 0 -90] [0.0, 90.0]
[ 0 90] [0.0, -90.0]
[1 0] [1.0, 0.0]
[1 0] [1.0, 0.0]
[ 0 90] [0.0, -90.0]
[ 0 -90] [0.0, 90.0]
[ 0 90] [0.0, -90.0]
[ 0 90] [0.0, -90.0]
[1 0] [1.0, 0.0]
[1 0] [1.0, 0.0]
[ 0 -90] [0.0, 90.0]
[1 0] [1.0, 0.0]
(the first element is the action for moving forward, but that's not relevant)
I've also noticed that sometimes, these just aren't accurate, even with the inversion. For example:
[ 0 90] [0.0, -90.0]
[ 0 -90] [0.0, 90.0]
[1 0] [1.0, 0.0]
[1 0] [0.0, -90.0]
[ 0 90] [0.0, 90.0]
[ 0 -90] [0.0, -90.0]
[ 0 90] [0.0, 90.0]
[ 0 -90] [0.0, -90.0]
[ 0 90] [0.0, -90.0]
[ 0 90] [1.0, 0.0]
[1 0] [1.0, 0.0]
[1 0] [1.0, 0.0]
[1 0] [0.0, 90.0]
[ 0 -90] [0.0, -90.0]
[ 0 90] [1.0, 0.0]
This does not happen when some delay (like sleep(0.01)
) is added between tics during replay.
Hello @ankitkv, Thanks for reporting the problem, I will look into this tomorrow.
I fixed the problem with incorrect values (reversed values). The problem with accuracy is still unresolved. Recordings are based on the game's network code and it looks like the problem is caused by 2 threads that read/write simultaneously to the same variables and game normally doesn't care about it. The challenge is to find where is a critical section in this old code :)
Adding a very small sleep during replay (sleep(0.001)
) solves the problem, and I recommend it as a hotfix while I am trying to fix it.